Good compromise on speed/quality for 1080i 25fps to PAL resize script?

[edheaded]

Howdy.

I've received over eight hours worth of MXF files (1080i 25fps, mpeg-2, AES audio) that need to be encoded for PAL DVD.

The normal safe/tedious workflow we use is to transcode using Episode to ProRes Quicktime, play out and downsize to PAL using a blackmagic card -> blackmagic card, then encode. However, I'm convinced I can more efficient results using avisynth to resize these, but there seems to be so many different methods out there.

I wondered if anyone had a fairly fast but good quality method for parsing 1080i 25fps mxf files for PAL MPEG-2 encoding?

I've used the hd2sd script before, but it's slow as hell (I don't have several days to encode) and I've ended up with some horrible aliasing artifacts/jitter, especially on vertical pans (even with a failry heavy vertical blur). I also tried using just a spline resize with a blur, which seemed to give good results and was fast but I'm concerned what it's doing with the fields.

I'm now playing around with various scripts and running test, but it seems debatable whether to:

a) deinterlace->resize->reinterlace
b) separate fields->resize->reinterlace
c) hd2sd with blur
d) just resize and let the encoder (Totalcode or HCenc) deal with interlacing and cross fingers

Anyone have a tried and tested methods? I seem to be going round in circles here.

[ajk]

Since you are going down from a high resolution to a low one, in my opinion a simple bob()/yadif() + reinterlacing should do just fine. Try something like

xxxSource("...")

bob() # or yadif(mode=1)

bicubicresize(720,576)
blur(0, 0.5) # not required, but some vertical blur may look nicer in the final image, experiment

separatefields()
selectevery(4, 0, 3)
weave()

You may also need to switch the field order, I'm not familiar with MXF files and what they contain exactly.

[edheaded]

Thanks, I'll give this a go.

The original mxf is top field according to Mediainfo. There's some quite nasty line flicker on some vertical scrolling credits at the end (which is apparent in the source as well), which I'm hoping is just a computer monitor/interlacing issue.

[TheSkiller]

However, I'm convinced I can more efficient results using avisynth to resize theseCertainly. :)

The first thing you should check is if the source files actually do show interlacing (in contrast to a tool reporting interlacing). The result is either 1) yes, all the time 2) no, only certain parts 3) no, never.

In case of 1) and 2) you want to keep the interlacing and need to account for it. In case of 3) you can ignore what the flags say and pretend it's all progressive.
However, if you're not 100% sure about 3) then go for the interlaced route because you absolutely don't want to blend any fields during resizing.

Since you are going down from a high resolution to a low one, in my opinion a simple bob()/yadif() + reinterlacing should do just fine.I agree. Though QTGMC with a fast preset is pretty fast, too. It all depends on how fast it needs to be but yeah, Bob() and Yadif(mode=1) are as fast as it gets and there would be a very minor improvement only if you use anything slower.


When it comes to lowpassing the lines vertically after resizing, at first it may seem odd but except for computer animated sources it's recommendable to have Blur() followed by Sharpen(). What this actually does is it "thickens" the vertical details a bit instead of just blurring them together.

This is what I would recommend:

#[Pick one line]
Blur(0, 0.6, false) Sharpen(0, 0.4, false) #this is very mild
Blur(0, 0.7, false) Sharpen(0, 0.4, false) #good starting point
Blur(0, 0.8, false) Sharpen(0, 0.5, false) #for very sharp sources

Where do these values come from? Elaborate tests I did. ;)

[ajk]

Sounds worth a try :) I corrected the script a bit, had assumefieldbased() where assumeframebased() was intended.

[TheSkiller]

You don't need either actually, instead you should specify the desired field order of the output.
Replace AssumeFrameBased() with AssumeTFF() or AssumeBFF().


Also, you don't need

interleave(selectodd(), selecteven())

it doesn't do anything at all, except wasting CPU cycles.

[ajk]

Yeah, I've just now actually ran the script on a clip, shouldn't answer threads when at work... :) Of course bob() leaves the clip in the frame based state already and the interleaving is performed by the selectevery(). Updated the script again.

[edheaded]

Thanks for the advice.

So, here's my final script:

FFVideoSource("myVideo.mxf)
Load_Stdcall_Plugin("C:\..\yadif.dll")

AssumeTFF()
Yadif(mode=1)
BicubicResize(720,576)

Blur(0, 0.6, false).Sharpen(0, 0.4, false)
ConvertToYV12()

separatefields()
selectevery(4, 0, 3)
weave()

I can't see any interlacing/combing apart from the end credits scroll, but thought it's safest to presume interlaced.

I also need to convert to YV12 for the encoder. I've put this before it's re-interlaced. Is this correct?

[TheSkiller]

Yes, the script is fine, ConvertToYV12() can be put before the re-interlacing lines.

Before you start encoding, to make sure the field order is correct (believe me, you really should test this), you may add Bob() at the end of the script, open the script in VirtualDub and play back the part with the interlaced credits. If the motion is fluid you can remove Bob() and encode with Top Field First setting. :)

[2Bdecided]

Simple BicubicResize is unnecessarily soft in the horizontal domain. You want to try to maintain as much horizontal sharpness as possible. lanczosX, splineX, etc. Or something even more clever (though that would slow things down).

Cheers,
David.

[Boulder]

Didée came up with a brilliant idea for using BicubicResize when downsizing. Play with the b and c parameters, like BicubicResize(720,576,-0.6,0.3). When I resize 1080p stuff to 720p, I usually end up with having c between 0.2 and 0.35, b is 2*c and negative.

[TheSkiller]

I remember that, here (http://forum.doom9.org/showthread.php?p=1583525#post1583525) it is. :)

[henryho_hk]

with reference to http://forum.doom9.org/showthread.php?p=1177125#post1177125, & provided that the MXF files contain true interlaced footage:

Global NewWidth = 704
Global NewHeight = 576

xxxSource(.....)

# Pick the right one manually:
AssumeTFF()
#AssumeBFF()

SeparateFields()

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

E = SelectEven() . Spline36Resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd() . Spline36Resize(NewWidth, NewHeight/2, 0, -Shift)
Echr = SelectEven() . Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Ochr = SelectOdd() . Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)

Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Echr, Ochr)) : Last
Weave()

Pick the resizer as you prefer .... you may even try a sharper resizer for luma (E & O) and a softer resizer for chroma (Echr & Ochr).

[2Bdecided]

The separated fields resizing trick above DOUBLES the height of any resizer artefacts/effects/etc compared with the bob/resize/re-interlace approach. You may find that to be a good or bad thing, but it certainly changes the decision of which resizer and parameters to use.

I think it limits the final vertical resolution to half that for a full frame. With interlaced content, if you maintained full vertical resolution it would twitter/shimmer like mad, but going down to half is a little brutal IMO.

Cheers,
David.

[TheSkiller]

I agree with 2Bdecided. The field based approach seems impractical considering a plain ultra fast Bob() provides better results...

I'm not sure if a field based resize results in vertical resolution cut in half, but it sure gives a very soft vertical.
If it does reduce the vertical resolution to half or less it would make that whole interlacing affair redundant – you might as well store the video as 288p/240p then. :p

Yeah you can't put that on DVD but the point is one really needs to find that sweet spot of vertical resolution that looks good: detailed, but not so much that it results in pronounced line twitter and aliasing (hence my Blur-Sharpen recommendations in post #4).

[edheaded]

Thanks for the suggestions.

So, I've tried out the original suggestions by TheSkiller and the updated chroma/luma script by henryho_hk but we're always seeing some bad horizontal line shimmer/wobble on both interlaced broadcast monitors and progressive LCD TVs (despite increasing the amount of blur).

To be honest, although I'm a bit paranoid about what it's doing with the fields, this script seems to give the best quality (can't see any difference in movement either) on both displays:

#1080i 25fps ProRes source
Spline16Resize(720,576)
Blur(0.1, 0.6, false).Sharpen(0, 0.3, false)
ConvertToYV12

It is being flagged as an interlaced source on the encoder (Totalcode/Cinevision) before encoding, but I'm concerned it's effectively being deinterlaced by the script and re-interlaced by the encoder.

Any ideas?

[henryho_hk]

What about .... :

FFVideoSource("myVideo.mxf)
Load_Stdcall_Plugin("yadif.dll")
AssumeTFF().Bob()
BilinearResize(720,576)
separatefields().selectevery(4,0,3).weave()
ConvertToYV12(interlaced=true)

[smok3]

If it is progressive then something like this should give you some speed boost, (if it is interlaced its probably not worth bothering with anyway);

SeparateFields().SelectEven().BilinearResize(720,576)

(If there are short burst of interlaced stuff, this will take care of that as well, since we are only taking "one field")

[smok3]

If it is progressive then something like this should give you some speed boost, (if it is interlaced its probably not worth bothering with anyway);
SeparateFields().SelectEven().BilinearResize(720,576)

[TheSkiller]

So, I've tried out the original suggestions by TheSkiller and the updated chroma/luma script by henryho_hk but we're always seeing some bad horizontal line shimmer/wobble on both interlaced broadcast monitors and progressive LCD TVs (despite increasing the amount of blur).
Not entirely sure but it sure sounds like you have put the Blur().Sharpen() combo after the re-interlacing lines, which is wrong and will produce rubbish (whenever there is interlaced content).
Sorry, I should have explained where to put it.


To be honest, although I'm a bit paranoid about what it's doing with the fields, this script seems to give the best quality (can't see any difference in movement either) on both displays:
#1080i 25fps ProRes source
Spline16Resize(720,576)
Blur(0.1, 0.6, false).Sharpen(0, 0.3, false)
ConvertToYV12

This is where to put it. However the lack of a Bob deinterlacer and re-interlacing means: this script does mess up the interlacing (while the non-interlaced parts will be absolutely fine). The fields will be blended together, which may not be too obvious until you come across fast scrolling credits for example. It's pretty much like a blend-deinterlacer.

henryho_hk's suggestion is almost what you want:

#1080i 25fps ProRes source
Bob()
Spline16Resize(720,576)
Blur(0, 0.6, false).Sharpen(0, 0.3, false)
ConvertToYV12()

AssumeTFF() #for Top Field First OR:
#AssumeBFF() #for Bottom Field First output

SeparateFields().SelectEvery(4,0,3).Weave()



SeparateFields().SelectEven().BilinearResize(720,576)
Problem is, like you've mentioned, this totally throws away one field. In case of fast scrolling interlaced credits for example, this will make them appear like a strobe and it'll be hard and annoying to read. Since we're going to make an interlace-enabled DVD anyway, this is not recommended imo.

[smok3]

@TheSkiller, sure, but credits could be processed separately.

[henryho_hk]

I've received over eight hours worth of MXF files (1080i 25fps, mpeg-2, AES audio) that need to be encoded for PAL DVD.

Could you post a short sample source clip with the "worst" scenario?

Also, which MPEG2 encoder are you using for the DVD encode?

[2Bdecided]

To be honest, although I'm a bit paranoid about what it's doing with the fields, this script seems to give the best quality (can't see any difference in movement either) on both displays:



It is being flagged as an interlaced source on the encoder (Totalcode/Cinevision) before encoding, but I'm concerned it's effectively being deinterlaced by the script and re-interlaced by the encoder.Your script is converting 50i to 25p by blending both fields together. What the subsequent encoder flags the frames as is irrelevant.

If you can't see any difference, then either you are only looking at parts where the original is already progressive, or your monitoring is hopelessly inadequate.

Cheers,
David.

[scharfis_brain]

To give even more speed just process the vertical dimension shen it comes to de/reinterlacing.

Bicubicresize(704, last.height) #reduce width
Any_bob()
Bicubicresize(last.width, 576) #reduce height
Reintercace()