HD 1080i to DVD (all interlaced) - how? [Archive]

florinandrei

30th June 2008, 06:24

I have an AVCHD file (.m2ts) that I want to convert to DVD. I use HCenc as the MPEG2 encoder, because it offers excellent quality.

The source is 1080i (interlaced, top field first), 29.97 frames / sec.
The destination is DVD, so it's 480i (interlaced), 29.97 frames / sec.

So it's an interlaced-to-interlaced conversion.

First off, I did a straight MPEG2 encoding, no resizing:

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
ConvertToYV12()

This worked fine. It produced an MPEG2 stream that was obviously too large (the encoder cannot resize) but looked OK. I opened it up in a player (VLC), hit Play, then Pause. Due to the jaggies on the moving objects, I deduced that the interlacing was preserved correctly. Cool. Now I needed to scale the image down to 720x480.

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
LanczosResize(720, 480)
ConvertToYV12()

That looks weird. It's like the moving objects consist of two "ghost" images on top of each other. Like a bad deinterlacer.

I tried a few options, like SeparateFields(), AssumeTFF(), to no avail.

So the problem is to scale down 1080i to 480i, at the same frame rate, while preserving interlacing. What is the "magic incantation" to do that?

By the way, at the end of the file, HCenc just hangs, "this program is not responding", so I have to kill it. Could be HCenc's fault, could be AviSynth's. Any ideas?

hanfrunz

30th June 2008, 08:08

Hello florinandrei,

please try something like this:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
SeparateFields()
LanczosResize(720, 240)
Weave()

hanfrunz

themostestultimategenius

30th June 2008, 08:10

Blue_MiSfit

30th June 2008, 08:41

You don't _have_ to bob before resizing - separating fields and resizing to 720x240 will work, but the bobbed version will probably look better :)

~MiSfit

Alex_ander

30th June 2008, 11:24

You have to deinterlace before resizing.

DirectShowSource("File")
mcbob() #If you can spare the time. If not, use some other bobber.
Spline36Resize(720,480)
Weave()

Someone please correct the script if it's wrong.

After bobbing the video has double frame rate and is frame based progressive.
To re-interlace it, one wants to use half of fields from it, like this:

LoadPlugin("path\LeakKernelDeint.dll")
DirectShowSource("path\video.mts")# better to use DGIndex project for mpegs
LeakKernelBob(order=1)# order=1 is for TFF input video
LanczosResize(720,480)
AssumeTFF()# the assumed order will force outputting TFF
SeparateFields()
SelectEvery(4,0,3)
Weave()

The previously suggested 'separate fields + resize' method (then SelectEven) would work good for progressive target video (in case the original video is not too sharp).

halsboss

30th June 2008, 12:01

http://forum.doom9.org/showthread.php?t=136109

florinandrei

1st July 2008, 01:14

You have to deinterlace before resizing.

I actually wanted to do tests first and then post a reply, but I'll post first, because it's an important issue to me:

Deinterlace before resizing sounds scary. I hope I don't have to do that. I definitely don't want to deinterlace, because, based on my previous experience with deinterlace/reinterlace filters with other applications, this always degrades the image.
My goal is to preserve the fluidity of the motion in pristine quality, and the way I understand the process now, that can't be done if I deinterlace/reinterlace.
Remember, both the source and the destination are interlaced: 1080i and 480i. So I will do my best to find a method to not deinterlace. After all, I came to AviSynth after being disappointed with some commercial software (http://www.camcorderinfo.com/bbs/t142395.html) which seems to deinterlace when there's no need to.

Please correct me if I'm wrong.

P.S.: I will do tests as soon as I can.

Blue_MiSfit

1st July 2008, 01:41

there's a difference between "normal" (half rate) deinterlacing, and bob deinterlacing.

Bobbing preserves all temporal information, so 1080i bobbed becomes 1080p60. Then, you can scale these 60fps down to 720x480, separate it into fields, throw away half the info, and re-interlace down to 480i

You can do all this without deinterlacing, but smart bobbing first will give better results - namely less aliasing etc due to spatial alignment I think.

~MiSfit

florinandrei

1st July 2008, 03:10

I used this script:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\LeakKernelDeint.dll")
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
LeakKernelBob(order=1)
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYV12()

I opened the result in VLC, the jaggies looked normal for a 480i. So far so good.

I generated the audio track, multiplexed, authored a very simple DVD image, burned it. It played just fine on the TV, although that test might be less relevant, since there are quite a few layers of processing on the PS3 and the HD screen which may mask issues with the DVD. But it looked good, no ghosting, no huge jaggies due to field order reversal (but I guess the PS3 would try and hide those), motion was fluid, etc.

So I guess this is it?

Any suggestions I could use to improve it? Remember, I am trying to convert 1080i TFF to 480i and keep everything interlaced, with fluid motion and crisp images.

henryho_hk

1st July 2008, 03:17

Have you tried the "InterlacedResize()" function in SimpleResize.dll ?

Edit(1): Unfortunately, is it said to be broken for YV12.

Edit(2): You probably need to apply some field shift correction for the separate-resize-combine method, as suggested in http://forum.doom9.org/showthread.php?p=594339#post594339

florinandrei

1st July 2008, 04:43

Have you tried the "InterlacedResize()" function in SimpleResize.dll ?

Edit(1): Unfortunately, is it said to be broken for YV12.

But it shouldn't matter, since ConvertToYV12() is applied after that, right?

henryho_hk

1st July 2008, 06:05

For best result, we need a motion-sensitive(compensated?) ConvertToYUY2 and ConvertToYV12. :devil:

BTW, nnedi+tmm+tdeint is a nice bobber too:

TFF Clips:
inp=src.nnedi(field=3)
emk=src.tmm(mode=1,order=1)
src.tdeint(mode=1,order=1,type=1,edeint=inp,emask=emk)

BFF Clips:
inp=src.nnedi(field=2)
emk=src.tmm(mode=1,order=0)
src.tdeint(mode=1,order=0,type=1,edeint=inp,emask=emk)

Blue_MiSfit

1st July 2008, 07:15

Yes! Please use TDeint+TMM+NNEDI!

LeakKernelBob is prety out of date :)

~MiSfit

florinandrei

1st July 2008, 09:23

Edit(2): You probably need to apply some field shift correction for the separate-resize-combine method, as suggested in http://forum.doom9.org/showthread.php?p=594339#post594339

So how about this:

Global NewHeight=480
Global NewWidth=720

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")

AssumeTFF()
SeparateFields()

Shift=(Height()/Float(NewHeight/2)-1.0)*0.25

Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()

ConvertToYV12(Interlaced=True)

Visually, it looks better. Those tiny but strange ripples on top of rising/falling oblique objects are gone.
The minimum bitrate and the average bitrate on the encoder have decreased. The encoder has an easier job to do. Not sure if this is a good sign or bad. I don't care about final file size, there's plenty of room left over on the DVD.

It's still a bit blurry. But perhaps this is not objectively true, perhaps I'm unconsciously comparing it with the HD master. Also, the PS3 is doing a lot of processing to convert the 480i to 1080p for the display - I know it's doing a lot of things because the upsampled standard-def (at least the commercial progressive material) looks unnaturally good in most cases. So that might interfere. These things are best verified on true 480i displays and players.

Tomorrow, or when I have time, I'll have to start drawing diagrams and verify whether those formulas that I copy/pasted in the new script are geometrically correct. Of course, the fact that I don't know squat about AviSynth doesn't help - I'm learning it as I go, and it kind of keeps me back. :mad: Only now I'm starting to realize the vast possibilities opened by AviSynth's scripting language.

2Bdecided

1st July 2008, 09:56

Yes! Please use TDeint+TMM+NNEDI!

LeakKernelBob is prety out of date :)As I always say at this point in the discussion: it really doesn't matter! You're throwing half the resolution away, and you have an interlaced output. Dumb bob is more than good enough - unless you have test signals, or similar high frequency gratings in your actual content, and you process the 480i output in such a way as to preserve these features - in that case only, you might notice softening, but it's pretty mild.

Cheers,
David.

2Bdecided

1st July 2008, 09:59

It's still a bit blurry. But perhaps this is not objectively true, perhaps I'm unconsciously comparing it with the HD master. Also, the PS3 is doing a lot of processing to convert the 480i to 1080p for the display - I know it's doing a lot of things because the upsampled standard-def (at least the commercial progressive material) looks unnaturally good in most cases.If the commercial content is 480p30 or 480p24 (typically wrapped in 60i), then it can be upconverted much more easily and crisply than 480i60. If you use 480p30 yourself (and maybe sharpen it a little, accepting the possibility of inter-line twittering on interlaced displays), it'll look just as crisp - but you'll lose the smooth motion of 480i60.

Cheers,
David.

henryho_hk

1st July 2008, 18:18

Agreed. Life is much more easy if it is an ITVC material. ^_^ florinandrei, perhaps you can host a few seconds of your clip somewhere and so we can try working on it too.

Edit: Just notice the "DirectShowSource()". Have you tried dgavcdecode at http://neuron2.net/dgavcdec/dgavcdec.html?

Blue_MiSfit

1st July 2008, 23:37

As I always say at this point in the discussion: it really doesn't matter! You're throwing half the resolution away, and you have an interlaced output. Dumb bob is more than good enough - unless you have test signals, or similar high frequency gratings in your actual content, and you process the 480i output in such a way as to preserve these features - in that case only, you might notice softening, but it's pretty mild.

Cheers,
David.

Sure, but NNEDI with TDeint and TMM is pretty damn fast, so why not use it? ;)

Either way - whatever the OP is happy with...

florinandrei

2nd July 2008, 03:13

Either way - whatever the OP is happy with...

I guess it's fair to say the OP has no clue. :)

Between these two scripts:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\LeakKernelDeint.dll")
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
LeakKernelBob(order=1)
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYV12()

Global NewHeight=480
Global NewWidth=720

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")

AssumeTFF()
SeparateFields()

Shift=(Height()/Float(NewHeight/2)-1.0)*0.25

Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()

ConvertToYV12(Interlaced=True)

The second one is definitely fuzzy. Anybody has a clue why? It was supposed to be the "perfect" resizer for interlaced movies.

The first one looks crisp, but I wonder if the jaggies aren't too much. I don't think there's any way to really tell, other than playing it on an old-school DVD player on a standard-def CRT TV. Anything else would just interfere with its own algorithms.

Just notice the "DirectShowSource()". Have you tried dgavcdecode?

I was skeptical at first, because they say it's essentially libavcodec in a nice package, and libavcodec has problems reading the AVCHD files produced by the new-gen HD cameras. ffmpeg, ffplay and VLC all have serious issues playing these files.
But anyway, I tried it and it works. Visually, there's no difference from DirectShowSource(). It does get rid of the annoying seconds at the end when AviSynth seems to hang and HCenc is totally frozen - with dgavc the encoder just exits normally.

perhaps you can host a few seconds of your clip somewhere and so we can try working on it too

Generous offer! Thank you.
I'd rather not make the initial file public (I sent it to a couple people, but putting it on a forum is a different thing), but I made 3 short clips that everyone can poke at:

http://dl.getdropbox.com/u/29966/00000.MTS
http://dl.getdropbox.com/u/29966/00001.MTS
http://dl.getdropbox.com/u/29966/00002.MTS

There's some motion, and there's some horizontal and oblique edges moving vertically.

there's a difference between "normal" (half rate) deinterlacing, and bob deinterlacing.

Bobbing preserves all temporal information, so 1080i bobbed becomes 1080p60. Then, you can scale these 60fps down to 720x480, separate it into fields, throw away half the info, and re-interlace down to 480i

You can do all this without deinterlacing, but smart bobbing first will give better results - namely less aliasing etc due to spatial alignment I think.

That sounds great, but how do you translate that in actual AVS scripts? Can you relate what you just said to the two scripts I posted above?

Guest

2nd July 2008, 03:47

That sounds great, but how do you translate that in actual AVS scripts? Can you relate what you just said to the two scripts I posted above? It's exactly what you did in your first script!

I don't agree that your second is fuzzy. You are imagining it.

IanB

2nd July 2008, 07:23

@florinandrei,

Interlaced resizing is fast, but you pay a price for generating each new field based only on the original field. Any new pixels spacially between 2 original field lines will effectivly be a weighted average of only the pixels above and below in that field, i.e. a blur. Effectively all the pixels in the new fields are vertically blurred slightly.

Using the SmartBob/Resize/ReInterlace method, although slower, will give vastly superior results in static areas because each new field can be based on a full frame. In static areas there is no "spacially between 2 original field lines". Those new pixels are rendered from complete frame data. i.e. no blur in static areas.

Of course in motion areas any difference can be attributed to how good the SmartBob interpolates the missing pixels. If using linear interpolators like in KernelBob or DGBob there will be no difference to Interlaced Resizing. i.e. a blur again. If using Edge Directed and/or Motion Compensated interpolators then the results can be a significant step up from bog interlaced resizing.

And apart from everything else the eye has trouble seeing bluring of things in high motion, it attributes motion to the blur, instead of blur to the blur. So it is a little unfair to look at individual fields on a PC screen, you really should evaluate the results on an interlaced display device at normal speed.

Alex_ander

2nd July 2008, 10:28

LeakKernelBob is prety out of date :)

NNEDI is newer, but this doesn't mean it can replace the 'outdated' Kernel bobber for any type of image - it works differently. Theoretically, in case of an image being as sharp as HD pixel resolution provides, it simply can't work correctly. It throws away one of the fields at interpolation and this means it halves vertical sampling frequency for an image which demands twice higher value by discretization theorem (by Kotelnikov/Nyquist). To have an illustration to what could happen sometimes, imagine a radical case of image type: all even lines in a still HD frame are black and all odd ones are white. NNEDI would simply alternate black and white frames, while Kernel bobber would still work somehow since it uses data from both fields. Of course the problem doesn't appear with softer or upsampled images and NNEDI is good there.

2Bdecided

2nd July 2008, 10:36

Effectively all the pixels in the new fields are vertically blurred slightly.Yes, demonstrably true, but...

1. You will then resize vertically to less than half the original resolution (or a little more than half the original resolution for "PAL") - that's a fair amount of blur!

2. You will then throw away half the remaining lines in each field to interlace the signal - that's a fair amount of lost information.

3. You will then rely on the deinterlacing in the display, if any, to restore those missing lines - or view on a native interlaced display, which will display inter-line twitter on sharp vertical details unless they are blurred before interlacing! Either way, you will be very lucky to see any extra detail you recovered with a "smart" bob.

As for "why not use X smart bobber - it's still fast?" – fast, yes, but everyone one I've seen (that counts as "fast") is prone to artefacts on something - sometimes quite nasty artefacts. The artefacts can be far more visible on the downconversion than any slight softness due to bobbing.

Of course mcbob to tgmc will do a better job and are almost always artefact free - but with these the slow down is considerable.

Cheers,
David.

2Bdecided

2nd July 2008, 11:05

To have an illustration to what could happen sometimes, imagine a radical case of image type: all even lines in a still HD frame are black and all odd ones are white. NNEDI would simply alternate black and white frames, while Kernel bobber would still work somehow since it uses data from both fields.Your point is well made - NNEDI "needs" to be used with something that can weave both fields as-is when necesary.

However your extreme example is too extreme. In an interlaced system, that image is ambiguous - the original image (before interlacing) could equally well be one frame black, then one frame white - or it could be two identical frames with alternate black/white lines. There is no way of knowing which, other than assuming.

All "smart" deinterlacing is based on assumptions - basically that the content changes little field by field - the camera is still pointing at roughly the same scene. If every field was completely independent, then a dumb bob would be the best you could do.

There are interesting graphs on pages 23 and 24 of this...
http://www.snellwilcox.com/community/knowledge_center/engineering_guides/edecod.pdf
...and I don't claim to fully understand them(!) but the stars represent typical content - mostly low detail and low movement (the centre of the stars) but a little fine detail and significant movement (the "arms" of the stars). If you had lots of fine detail and significant movement - almost random content, the frequency response wouldn't look like a star, but more like a square (up to the Nyquist limits for each dimension).

If you turn the stars into squares in the progressive plot, they don't overlap. If you turn the stars into in the interlaced plot, they do overlap. That's the ambiguous region. Your example is right in the middle of the overlap.

Cheers,
David.

2Bdecided

2nd July 2008, 12:03

I've attached two pictures.

The first one compares the output of bob (dumbest bobber available!) and mcbob (smartest bobber available).

I've stacked the output vertically, resized to 704x480, and added limitedsharpenfaster since the OP seems to want a sharp output (I don't think it's necessary). The script is:
avcsource("00000.dga")
assumetff()

lanczosresize(704,last.height)

a=bob()
b=mcbob()
stackvertical(a,b)

lanczosresize(last.width,480*2)

limitedsharpenfaster()

The output of frame 5 is in progressive.jpg, and the advantages of mcbob on the telegraph cables is just visible if you look carefully. Also, they are slightly more stable in the mcbobbed version than the dumb bobbed version.

However, that's not what the OP wants to do - the OP wants interlaced output.

If you interlace the image, and then do your best to watch it (either on an interlaced display, or via a great deinterlacer like mcbob) then it becomes almost impossible to see any difference. Really. The lines look the same, and their stability is the same.

This is shown in interlaced.jpg, where I took the video shown in progressive.jpg, interlaced it, and then ran it through mcbob. This is the code:
avisource("dga test.avi")

assumetff()
separatefields().SelectEvery(4,0,3).Weave()

converttoyv12(interlaced=true)

mcbob()

Now the advantage of the first mcbob is hidden - you might as well use bob when deinterlacing HD content for an SD interlaced output. If anything, the softer output from the original bob deinterlaces better than the sharper original output from mcbob.

The advantage of better bobbers in HD is not visible in the interlaced SD output for this content.

btw, either way, it's too sharp vertically for interlaced displays IMO - if anything, it needs slight softening in the vertical direction before interlacing, if you expect to watch it on a CRT.

Cheers,
David.

henryho_hk

2nd July 2008, 16:56

florinandrei, while you are bothering with the interlacing stuffs, you may want to consider another issue: aspect ratio.

Do you find your encoded NTSC 16:9 DVD looking a bit "wider/fatter" than your original 1920x1080 source?

As far as I know, if we take the pixel aspect ratio of NTSC 16:9 DVD as 40:33, your 1920x1080 1:1 material will scale to 704x480 [704 = 1920*(33/40)*(480/1080)]; after left and right pads of 8 pixels each, you have 720x480. On the contrary, if you resize to 720x480 directly, the resultant DVD will look a bit "wider/fatter" than your source.

If you don't want to have two thin black bars on the two sides, you may crop 12 pixels from (both) the top and bottom, making it 1920x1056, before resizing to 720x480.

2Bdecided

2nd July 2008, 17:40

I just go to 704 - it's a legal DVD resolution and saves confusion. It gets you the correct aspect ratio in software players and stand-alones (to within one pixel). No need to pad to 720.

http://forum.doom9.org/showthread.php?t=132378
http://forum.doom9.org/showthread.php?p=1100187#post1100187

However, most pros go to 720, and don't care about the slight error which they sometimes introduce, and sometimes don't.

Cheers,
David.

florinandrei

2nd July 2008, 19:02

OK, I'm starting to understand a few things.

Interlaced resizing is fast, but you pay a price for generating each new field based only on the original field. Any new pixels spacially between 2 original field lines will effectivly be a weighted average of only the pixels above and below in that field, i.e. a blur. Effectively all the pixels in the new fields are vertically blurred slightly.

Using the SmartBob/Resize/ReInterlace method, although slower, will give vastly superior results in static areas because each new field can be based on a full frame. In static areas there is no "spacially between 2 original field lines". Those new pixels are rendered from complete frame data. i.e. no blur in static areas.

In this message (http://forum.doom9.org/showpost.php?p=1154761&postcount=19), the interlaced resizing is the second script, right? If that's correct, what I don't understand is the usage of SeparateFields() - if the source is interlaced, what fields are there to separate? Aren't they already separated?
And bob is the first script? If that's the case your prediction appears correct, the second script seems to create output slightly blurred vertically, compared to the first one (at least on a computer and on the PS3 + flat panel).

Encoding speed has no importance to me. I prefer something that's very slow but very accurate. Encode once, watch forever - so better encode it right.

So, in that context, I guess you're saying: "use the first script but with the best bob you can find."

Of course in motion areas any difference can be attributed to how good the SmartBob interpolates the missing pixels. If using linear interpolators like in KernelBob or DGBob there will be no difference to Interlaced Resizing. i.e. a blur again. If using Edge Directed and/or Motion Compensated interpolators then the results can be a significant step up from bog interlaced resizing.

So, again, to obtain that result I just need to use the best bob available with something similar to my first script? E.g., mcbob() or something like that. I guess it's possible to simply remove LeakKernelBob() and just drop in something else? Something like this?

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
MCBob()
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYV12()

Can that be called a very accurate interlaced resizer HD-to-DVD, for real-life video (not computer generated) with no scene changes?

So it is a little unfair to look at individual fields on a PC screen, you really should evaluate the results on an interlaced display device at normal speed.

I know. I guess I need to revive the old CRT and DVD player. That's a much bigger "project" than it seems. :)
OTOH, the DVD will be watched on progressive displays too, not just on old CRT. So I can't neglect either.

Of course mcbob to tgmc will do a better job and are almost always artefact free - but with these the slow down is considerable.

Not a problem. Accuracy comes first.

All "smart" deinterlacing is based on assumptions - basically that the content changes little field by field - the camera is still pointing at roughly the same scene.

That seems to be the case with the material I'm scaling. The source is an HD camera and there are no scene changes (a scene change is always the beginning of a new file).

added limitedsharpenfaster since the OP seems to want a sharp output

My fault, I should have phrased it better. I guess what I'm after is "accuracy". If the original is sharp, I want that sharpness preserved, as much as the scale-down allows. But the result should not be subjectively "sharper" than the original.
What I want is a reduced-size copy that looks, statically and dynamically, as close to the original as possible, aside from the smaller resolution. The master is interlaced HD video captured with a camera (not computer-generated) and has no scene changes. The result will be watched on a variety of screens, from plain old CRT to new smart upscalers + progressive HD panels.

I am aware that there might be conflicting requirements hidden here (such as accurate statically and dynamically). If that's true, that's one of the things I'm hoping to learn from this discussion.

florinandrei

2nd July 2008, 19:11

To put "accuracy" in perspective: I'm shooting with a consumer-level camera, but it's tweaked to be as neutral as possible. It has a Cinema mode which gives a somewhat flatter, non-aggressive gamma curve (unlike the "torch mode" on most cheap cameras) and I also changed settings such as saturation, brightness, etc. to make the result as neutral as possible. If I need brighter colors or bigger contrast, that can be taken care of in post - and now I see AviSynth could be used for that (but that's not the subject of this discussion).

I guess I should really use a "prosumer" camera, but those are 5 times more expensive. Can't do that now.

So I don't need something that looks flashy or "sharp" to the average user. I need something that is close to the original.

Blue_MiSfit

2nd July 2008, 19:20

I think you're taking a very good approach to this project. Kudos for sticking it out and trying to understand what's really happening, instead of throwing in the towel, copying and pasting a script, and being done with it. For reference, here's a little explanation of your script:

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")

#At this point, your video is untouched true 1080i

MCBob()

#Now, we've bobbed 1080i to 1920x1080 @ 59.94fps.
#99.9% of your processing time will be spent here.

LanczosResize(720,480)

#Now we're down to 720x480 @ 59.94fps

AssumeTFF()
SeparateFields()

#Now we've pulled the progressive frames apart into 720x240 fields.
#It's technically at 119.89fps, but that doesnt matter ATM

SelectEvery(4,0,3)

#Now we've decimated away half the information like this:
#Input: A B C D
#Output: A C

#So, we're back to 59.94fps, still 720x240

Weave()

#Now we actually interlace the fields to produce interlaced frames.
#So, we're at 720x480 @ 29.97i fps

ConvertToYV12()

#And finally we convert the colorspace from something else to YV12
#(odd, because AVCHD should be YV12 - must be a decoder error).

#Actually, ConvertToYV12(interlaced=true) would be better

I hope that helps your understanding. As you guessed, any bobber - TDeint(mode=1), bob(), yadif(mode=1) etc etc could be dropped in here with equivalent results, but varying quality.

~MiSfit

mikeytown2

2nd July 2008, 20:06

Building off of Blue_MiSfit's script

DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
#At this point, your video is untouched true 1080i

MCBob()
#Now, we've bobbed 1080i to 1920x1080 @ 59.94fps (1080P).
#99.9% of your processing time will be spent here.

ZoomBox(704,480,"LanczosResize", SourceDAR=16.0/9.0, TargetDAR=16.0/9.0, align=-5)
#Now we're down to 704x480 @ 59.94fps
#Resizer set for a source and target DAR of 16/9.
#Set Align=5 to get rid of black bars and crop instead of adding borders

AssumeTFF()
SeparateFields()
#Now we've pulled the progressive frames apart into 704x240 fields.
#It's technically at 119.89fps, but that doesnt matter ATM

#ConvertToYV12()
#Uncomment this to change colorspace. It's a good idea to change color space while it's still progressive video.

SelectEvery(4,0,3)
#Now we've decimated away half the information like this:
#Input: A B C D
#Output: A C

#So, we're back to 59.94fps, still 704x240

Weave()
#Now we actually interlace the fields to produce interlaced frames.
#So, we're at 704x480 @ 29.97i fps

ZoomBox Thread (http://forum.doom9.org/showthread.php?p=1111789#post1111789)
MCBob takes YV12() so your video is already YV12

Edit: Changed 720 to 704 after reading about DVD players from the links that 2Bdecided gave above (post 27).

IanB

3rd July 2008, 00:19

It seems a lot of the evaluation is being done here looking at static images. As this material is originally interlaced and motion fluidity is important it is vital to view the results in motion at normal speed, preferably on all the target displays. Having really great individual static bobbed frames that vertically twitter like crazy when viewed is about the worst result I could imagine. Examine carefully all thin vertical, horizontal and diagonal lines and sharp high contrast edges.

And one last point, if a ConvertToYV12() is required, where should it go.

I would recommend straight after the Bob and before the Resize. There is a whole raft of discussion about chroma positioning with interlaced 4:2:0 material. Summary is the chroma is positioned the same with both interlaced and progressive, but with interlaced, alternate lines are temporally distinct. This means for a static scene there is no difference between progressive and interlaced chroma. See these threads for the gorey details, AutoYUY2() updated and Adaptive chroma upsampling

2Bdecided

3rd July 2008, 19:32

Not a problem. Accuracy comes first.Going from 20fps to 1fps processing speed for no visible improvement isn't really searching after accuracy - it's OCD.

Cheers,
David.

Blue_MiSfit

3rd July 2008, 21:24

True :)

But the golden rule here is - whatever makes the user happy!

If that means encoding Blu-ray using Apple's MPEG-4 SP encoder at 512kbit, so be it! :D

~MiSfit

henryho_hk

4th July 2008, 04:39

Assuming that Bob() is good enough for 1080i to 480i downsizing, what about this?

AVCSource(dga="mts00000.dga")
#1920x1080i @29.97fps YV12

AutoYUY2()
#1920x1080i @29.97fps YUY2

Bob(0, 1, 480) # .... or Bob(0, 0.5, 480) ?
#1920x480p @59.94fps YUY2; shift correction automatically performed for the vertical resize

AssumeTFF()
#Dunno if the field order is preserved, so play safe

Separatefields().SelectEvery(4,0,3).Weave()
#1920x480i @29.97fps YUY2

ConvertToYV12(interlaced=true)
#1920x480i @29.97fps YV12; will it destroy the AutoYUY2() effects?

BicubicResize(704, 480, 0, 0.5)
#704x480i @29.97fps YV12

2Bdecided

4th July 2008, 11:44

But the golden rule here is - whatever makes the user happy!No, not when the user doesn't know what they want! ;) Seriously though, I think florinandrei wants to learn - that sometimes includes learning that what you originally thought you wanted to do isn't really what you want to do at all!

I'm still thinking about this statement...
I guess what I'm after is "accuracy". If the original is sharp, I want that sharpness preserved, as much as the scale-down allows. But the result should not be subjectively "sharper" than the original.
What I want is a reduced-size copy that looks, statically and dynamically, as close to the original as possible, aside from the smaller resolution.
IME I don't find HD>SD works like that at all. The sharpness of the HD original has little bearing on the sharpness of the SD output (unless it's badly out of focus). For a given processing chain, either both pin sharp and barely sharp HD will give sharp SD, or both pin sharp and barely sharp HD will give barely sharp SD.

If you do a bicubic resize and leave it at that, it'll all look a bit soft.
If you do a lanczos resize and run limitedsharpenfaster, it'll all look very sharp (too sharp?).
Neither will always "keep the perceived sharpness of the original, but on a smaller scale" - resizing doesn't work like that. You have to use the appropriate tools to get the sharpness you want, which is partly independent of the source. If you want it to look like the source, you'll have to throw in the processes that "recreate" that look at the new resolution, because it won't happen by magic.

I think I'm explaining this really badly, but I hope it make sense to someone.

Anyway, at least having a 60i input and 60i output will keep the motion looking the same - that part at least is "easy".

The problem is it contradicts the sharpness goal somewhat: whenever I see really sharp SD, it's progressive (25p in the UK). Interlaced SD never seems to look quite as sharp.

Cheers,
David.

henryho_hk

5th July 2008, 18:03

I don't agree that your second is fuzzy. You are imagining it.

Perhaps he is not. The wires in frame 5 got "broken" by the 2nd script. They are okay with shift=0 or with Bob's resize. Perhaps the shift calculation formula is wrong.

Guest

5th July 2008, 18:37

broken != fuzzy

henryho_hk

6th July 2008, 01:43

Sorry that my english is not good. Perhaps, when the shift adjustment is wrong, the two fields are misplaced. Hence, it makes the wire looking "broken" on computer monitor and the video looking "fuzzy" on CRT TV.

MVBob -> Separatefields -> Weave:

http://img380.imageshack.us/img380/162/00000f5mvbobwt9.jpg

Bob(0, 0.5, 480) -> Separatefields -> Weave:

http://img368.imageshack.us/img368/9969/00000f5bob05da8.jpg

Separatefields -> Spline36Resize (with shift adjustment) -> Weave:

http://img133.imageshack.us/img133/9143/00000f5separatespline36wo1.jpg

IanB

6th July 2008, 06:35

@henryho_hk,

Your last image looks like you had the 2 red statements reversed.Global NewHeight=480
Global NewWidth=720

AssumeTFF()
SeparateFields()
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25

Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()Please post the actual script you used :script:

henryho_hk

6th July 2008, 07:55

Your last image looks like you had the 2 red statements reversed.

Exactly.... I am so silly. :stupid: Thanks IanB. :thanks:

florinandrei

8th July 2008, 07:02

No, not when the user doesn't know what they want! ;) Seriously though, I think florinandrei wants to learn - that sometimes includes learning that what you originally thought you wanted to do isn't really what you want to do at all!

True.

I was thinking I should just do 1080i -> 480p at 30fps, since 480p/30fps, while not a DVD standard, is apparently supported by some (many?) DVD players. You know, just deinterlace and be done with it.
But then, these DVDs will be played on interlaced CRT displays, so it's probably better (?) to keep it interlaced.

One day I'll be able to shoot hi-def progressive and then a lot of problems will disappear. Interlacing is a really bad annoyance.
I was actually thinking to get a "prosumer" (semi-pro) camera, but then for the same price ($3k) next year one could shoot 3k progressive at 120fps in raw format :eek:

http://www.red.com/nab/scarlet

If it's not vaporware, then it beats the hell out of an XH A1 (http://www.usa.canon.com/consumer/controller?act=ModelInfoAct&fcategoryid=175&modelid=14061) at the same price.

Offtopic, sorry.

If you do a bicubic resize and leave it at that, it'll all look a bit soft.
If you do a lanczos resize and run limitedsharpenfaster, it'll all look very sharp (too sharp?).
Neither will always "keep the perceived sharpness of the original, but on a smaller scale" - resizing doesn't work like that. You have to use the appropriate tools to get the sharpness you want, which is partly independent of the source. If you want it to look like the source, you'll have to throw in the processes that "recreate" that look at the new resolution, because it won't happen by magic.

I see your point.
Yes, that is the goal - the perceived sharpness should remain the same (adjusted for resolution changes), preserving the original look. I guess I'll just have to try different things and see what works.

How about lanczos without limitedsharpenfaster?

Alex_ander

8th July 2008, 08:33

I was thinking I should just do 1080i -> 480p at 30fps, since 480p/30fps, while not a DVD standard, is apparently supported by some (many?) DVD players. You know, just deinterlace and be done with it.
But then, these DVDs will be played on interlaced CRT displays, so it's probably better (?) to keep it interlaced.

There's no incompatibility of progressive footage on DVD with interlaced display: the video is outputted by fields (fake interlaced if progressive) from any standard DVD player. The main reason for keeping video interlaced is preserving better motion reproduction. When you deinterlace without doubling frame rate (you can only double it for PC or for 720p TV playback) you lose half of motion phases and get some artifacts.

Blue_MiSfit

8th July 2008, 22:10

Right, but the whole reason interlacing was standardized in the first place was its ability to maintain motion fluidity while reducing bandwidth requirements. It still does this today, but with all the headaches etc that we all know and love :)

On that note, I'm impressed with the quality of a simple separatefields + spline resize, with offset correction. There's less aliasing on the power line than with MVBob!

I did some fun stuff last night - converting a 1080i VC1 adult title to 720p60 with a simple bob (with spline) and was very impressed! Of course, it wasn't as good as MCBob, but there were no motion artifacts, like there were with Tdeint (without using TMM anyway, which slows the whole process down a bit)

~MiSfit

henryho_hk

9th July 2008, 01:44

The aliasing on the power line also exists in the original 1080i material. Therefore, I wonder if separatefields + spline resize will look okay on interlaced TV.

florinandrei

11th July 2008, 06:22

ConvertToYV12()

#And finally we convert the colorspace from something else to YV12
#(odd, because AVCHD should be YV12 - must be a decoder error).

#Actually, ConvertToYV12(interlaced=true) would be better

Correct. I removed all references to ConvertToYV12() and the MPEG2 encoder (the AviSynth host running the script) keeps working just fine.
I know for a fact that HC Encoder complains if the input is not YV12 so that must be it, AVCHD is already YV12.

florinandrei

11th July 2008, 18:34

I did something like this:

SetMTMode(2,2)
AVCSource("00000.dga")
MCBob()
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

It worked fine and the result looks crisp. But it's WAAAY to slow!
The first clip, 358 frames, took 2443 seconds to encode (0.15 fps). At this rate, a 1 hour video will take 200 hours to encode, or more than 8 days. I also tried MCBob-NNEDI but after some superficial testing that one appears to be even slower.
My system is a Core 2 Duo 5200 (one CPU, two cores).

Obviously, MCBob() is too slow for HD, unless it's used on very short clips.

I am willing to sacrifice time for quality, but the logistical issues with running a task for more than 8 days are pretty daunting since I can't dedicate a system to video processing (it's a machine I share with other people in the household). So it looks like I need to find a faster solution.

I noticed there are quite a few Bob functions, but I have zero experience with them. What I am looking for is something that is better that the most trivial Bobs, but not quite as slow as MCBob(). I am willing to wait up to 1 day for a 60 min video to encode, but that's I guess where I have to draw the line. So I have to speed up the process 8x. (*)
Motion compensated processing is a great idea, I understand the advantages, but it looks like MC on HD material with the current hardware is like encoding MPEG2 in 1997 - it just takes forever.

Can somebody point out some Bob functions that might fit the bill? (better quality than the most trivial ones, but faster than MCBob). As always, the goal is bobbing real 1080i footage (not computer generated, but filmed with a real camera) to shrink it to 480i.

Perhaps there are faster resize filters too, but my uneducated guess is that much more time is spent in MCBob() than in LanczosResize().
Also, I could speed up the MPEG2 encoder, which is currently running at max quality, but with these same settings, it produces 80 fps when encoding pure 480i footage, so I don't think it will make a measurable difference to tweak it in this context.
And a trivial Bob runs at 8 fps or so - I guess that's proof positive that MCBob() is the CPU hog.

(*) - I guess I could always buy faster CPUs, but even so I'm not sure whether MT.dll scales well enough with the number of cores, especially given the kind of filters I'm using. And a system that's 8x faster than my current one is going to be very expensive. I can't afford that.
OK, so I just realized that late next year, waiting for Moore's law, I might actually start using MCBob() on HD. But by that time I'm hoping to shoot all footage in 60 fps progressive for a not much bigger investment - bye bye interlaced video, you miserable evil thing. :p

P.S.: By the way, I am planning to keep doing experiments until I'm satisfied I have a procedure that converts 1080i to 480i at the best quality in a reasonable time with current hardware. When that happens, I will summarize my findings in a short HOWTO, either on this forum or on the AviSynth Wiki (if I can get permission to create content there). This looks like a topic that will become more important in the future, as the HD cameras become more popular while co-existing with legacy SD displays - so people will need ways to bridge the two kinds of formats while preserving a good image quality.
I will take a couple more weeks I guess. This is fun.