Transcoding/interlacing help, best practice?

Mr Whippy

New member
I currently record DVB S2 TV in the UK, mostly from HD channels. It's AVC/h264 and it's always marked as top field first 25fps (ffmpeg stream details)

So I'm assuming that any given player like ffplay or vlc, or VideoReDo (with deinterlacing off) is showing me 25 frames per second, and each frame displayed is the pair of fields.

So any 'frame' that looks correct, is essentially a 'progressive' frame split into two fields, and any frame that has the pattern (obvious on moving elements) is interlaced.

I can clearly see the differences when I watch something like a sports show and it's got the lines, and then a film generally they don't.

I've ended up leaving most of the films in the native format and just smart trim recoding so the interlacing (or not) isn't an issue.

However some stuff like Simpsons episodes could do with being squashed down and so re-encoded, but this is where I'm struggling.

Simpsons come in old SD stuff that is often interlaced, and new HD stuff that isn't interlacing looking, but is still a pair of aligned fields per frame.

In VideoReDo if I leave the interlacing as 'no change' then my otherwise fine looking full frames actually become 'interlaced', so when I load the exported file up in VideoReDo it's all dashy around the edges of elements. If interlacing is left unchanged, then surely the pair of fields should be re-encoded again to one visible 'frame'?

If I set the interlacing as "auto" then the final result looks good with all footage that I add.

If I set the interlacing as "smart" then the result looks good for footage which is interlaced (like the old SD Simpsons), I've done test outputs of both auto and smart and they look identical.
However, if I use "smart" for the HD footage (which as noted is really just two fields that make a proper progressive looking frame), then the result is really patchy, like a diagonal ink line in frame is really intermittent like a badly aliased up-scaled diagonal line.

I note the help docs for V5 suggest that smart just analyses the video and decides whether to use BOB or Weave.

I assume for the SD footage that BOB is being chosen because it matches in both auto and smart.

In the HD footage, smart and BOB match. They both have that really bad aliasy upscaled look.

However in the HD footage, Weave and auto do not match... weave looks soft, while auto looks nice and sharp. That makes sense because weave seemingly copies one field to the other.

So in the SD footage it seems auto = bob, and bob is fine.

In HD, the auto isn't bob, and it's not weave, and it's not smart (which was choosing bob)

So what exactly is auto doing here? Whatever it is, it's better than bob and weave.

In the documentation it says that smart should be best, but it's clearly not. And it doesn't mention any other deinterlacing methods.

It'd be quite nice to be able to explicitly set whatever auto is choosing to do for this footage for consistency, because if I'm encoding a lot of recordings I don't want to have to babysit every encode and check for errant behaviour like running bob or weave occasionally and me not noticing until I've deleted the source recordings.

Can anyone clarify on this?

Easy enough to reproduce with any old footage, but happy to upload a small sample if anyone wants to check for themselves.

Many thanks



HD source footage, with the exception of old school HDV and AVCHD tape, is progressive, not interlaced. However, the broadcast streams you capture may or may not be interlaced in the transmission, depending on your locale. I'm not versed on what BBC does.

You cannot upscale interlaced SD footage without deinterlacing first; even then, it's not likely to give pleasing results.
You can play interlaced footage locally; however, all modern internet streaming is progressive, and the upstream server processing is generally lousy, so you just as well deinterlace yourself before uploading.

Those factors taken into consideration, the deinterlace setting you choose in VRD is a matter of personal preference, since they all trigger a number of perceptual factors that can't be quantified. When I have had VRD do the job, Auto has worked just fine, since I have explicitly tested most of the schemes available and understand their limitations.
Last edited:

Mr Whippy

New member
I'll admit I'm a bit confused. I assume BBC must do 50p, and then squish it into 25i for sports and things like that. But for all the things like films etc they just squish 25p into 25i, with the resultant headache at the capture end of having to unravel the pair of temporally matching interlaced fields back to a progressive frame for reencoding.

In any case, the main issue I'm having is that Auto appears to be doing something unique with this footage that BOB, Weave and Smart are not doing, which isn't a documented feature.

Is it easy to check in logs somewhere to see what is actually happening?

Clearly Auto can invoke some other deinterlacing to those described in the documentation or the drop-down selection, and I'd like a way to easily check it (ie, I can just check the logs from batches of processed files before deleting source recordings)

Better yet VRD should offer all options available under de-interlacing so you can explicitly set the best one.

Mr Whippy

New member
Heh, just done a quick check of the logs.

The auto setting is just using 'none' for interlacing.

From VRD txt log
Video Deinterlacer, Using deinterlace method: None, using 1 threads.
External encdoder JSON log
"interlaceMode": 0,
Currently the de-interlacing options are:

None - what I need but can't choose.

No Change - selects the same as the source file which is interlaced due to fields being set, but appears progressive. Transcodes actually get interlaced and looks terrible/juddery.
Auto - selects None, but I won't know this for certain without checking all logs for every file I process because it could pick bob or weave too.
Bob/Weave - work fine, but they break the footage (soften it with weave, or cause artifacting with bob) because they're trying to de-interlace progressive footage merely stored in fields, not actually interlaced field data.
Smart - picks Bob, but really the smartest and best looking is None, so smart isn't so smart here.

Is there any way to force None for de-interlacing?

The footage *does* need de-interlacing, because it's encoded to fields, but there is no way to choose None, which is far and away the best performing setting.

Mr Whippy

New member
V5 help documentation seems to suggest a NONE setting. It's not there in V6 software.

Some clarification from the developers would help. Is NONE not an option for a reason?

Just for clarity, does Auto use frame analysis to determine which method to use? I'm assuming it does?

So if Auto can correctly determine which method to use, can it also invoke Smart where necessary?

So smart should only be chosen because you explicitly know you want deinterlacing to occur, and you want it done using this time consuming method?

Otherwise you use auto and it'll deal with everything?

I still think it'd make sense to have 'none' as an option as per V5.

I also think you need to sort out the documentation.

Mr Whippy

New member
VideoReDo doesn't appear to be setting flags for progressive or field orders on it's outputs, so players like VLC aren't playing them properly.

Is the interlacing feature set within VideoReDo a 'working' system when using hevc? I've read hevc isn't really designed for interlaced footage so curious in that regard.

I've decided for the footage at hand to use ffmpeg bwdif and fill out 1080i 25fps to 720p 50fps. That sets all the flags properly and files play smoothly everywhere, and they look good enough in hevc with a good file size. Frame by frame it's a unique smooth looking frame at a time.

It's quite frustrating that documentation for VideoReDo is so limited in the regard of dealing with interlaced footage and maximising quality.

Ie, I just tried to do the above recode I'm doing in ffmpeg with VRD and it results in a juddery file in VLC as it plays with interlacing on (no progressive flag set), and then when I turn deinterlacing off the video is clearly just doubling frames to get 50fps.
Set frame rate to automatic or 50fps, and interlacing to smart, and it just doubles the frames.

I bought VRD to trim ts and streams to mkv, and it's really working great for that.

It's just a shame that it's encoder isn't really set up very good for the interlacing side, which quite frankly is critical given that most TV footage comes interlaced and needs dealing with in some way.



Senior Developer
Staff member
Long thread, but if you want to force the output to interlaced that option is called "force interlaced" and is in the deinterlacer drop down.

If you're recoding you can adjust the field order in Advanced at the very bottom in the encoder settings. Otherwise the output will have the same field order as the input.

The auto deinterlace setting only deinterlaces on recode and the option it chooses depends on what the output resolution is compared to the input. If the resolution is exactly 1/2 the source it'll use simple bob, if it's odd then it'll use smart.

Mr Whippy

New member
Just for clarification.

- VRD V6 sets no flags inside mkv with regard progressive or interlaced in either AVC or HEVC? I thought mkv standards were pretty strict with regards metadata? Is VRD making compliant mkv files?

- Can you re-encode the existing fields? Or will VRD always result in a new appearance with new combing or different frames etc? I've tested this briefly in ffmpeg too but it results in the field order going from top first to top encoded first (swapped)... I don't even know what VRD is doing because no flags are written to the mkv.

- How do you go from 25i to 50p using VRD? So far I just get frame doubling at 50fps. There seems to be no combination of settings to make the deinterlacer output a frame per field.
In ffmpeg the deinterlacer can output a frame per field (yadif or bwdif) and automatically make it a smooth 50p file.

I'll do more testing here on pure AVC to mp4 to double check it's not h265 or mkv causing issues, but it seems that AVC/HEVC to mkv just isn't very good at all for dealing with anything with interlacing.

For now it seems not a big issue. I'll just use VRD for cutting the TS and trimming streams, and then do all my transcoding jobs in ffmpeg with full control.

I'm also interested on what smart deinterlacing is actually doing vs something like ffmpeg bwdif.
It'd be cool to see the difference between a VRD smart deinterlaced 1080 25i > 720 50p file vs the same in ffmpeg with bwdif. But right now it's just a juddery 25p frame doubled to 50p output.

It'd be nice if VRD is improved so it can deal with these things properly. To be quite honest for the money I expected it to be a one stop shop and no-brainer for anyone to get the guaranteed best results from. But by not offering full control, and trying to automate it, but then making the wrong choices, it's actually guaranteed to give you sub-standard results which is pretty bad.




Senior Developer
Staff member
There is no requirement to put field order into the MKV file. It's stored in the header of the video stream. We actually use the ffmpeg muxer for MKV output so our files are compliant.

When you recode a file telling it to flip the field order we actually swap the fields. We don’t deinterlace and then re-interlace.

When going from 25i to 50p we deinterlace first, so 25p, then frame double to 50p. You can't just create a frame from one set of fields or it would look terrible.

Mr Whippy

New member
There is no requirement to put field order into the MKV file. It's stored in the header of the video stream. We actually use the ffmpeg muxer for MKV output so our files are compliant.

When you recode a file telling it to flip the field order we actually swap the fields. We don’t deinterlace and then re-interlace.

When going from 25i to 50p we deinterlace first, so 25p, then frame double to 50p. You can't just create a frame from one set of fields or it would look terrible.
Roger that on flags/header data. I usually use ffmpeg to check file information. It's surprising to see VRD leave very little information there for you to visually check what kind of file you have. It does seem like it'd be handy for VRD.

On the recoding, I've not tried to do any re-ordering, just re-encoding the 1080i 25fps from AVC to HEVC, trying to retain the fields as they were. It's clearly not working right with VLC being unhappy, the fields look different between source and re-encode within VRD side by side.
The main issue is that the 50hz motion looks quite nice on 50hz material, so dropping to 25p isn't so nice. I can cope with 25p on The Simpsons etc as it's animated and so jerky any way. But on live action like a sit-com it's more pleasant to watch at 50hz.

Going 25i to 50p, this is where the details of the process are critical.

From what you're describing you deinterlace the pair of fields in one frame, so take two temporal interlaced fields and make one temporal progressive field. Ie, you don't lose any field data, you use it to reconstruct one quality frame. That sounds like essentially taking the woven frame and fixing it up using bob and other methods where combing is present.
But that must only be possible using your deinterlace smart option?

But as I've noted using ffmpeg, and interlace using bob/weave/cubic interpolation using bwdif, so each field is filled out to a full progressive frame at 1080px, and then lanczos resizing to 720p gives a pretty ok result at 50p.

I'm sorry for going over this, but it's not completely clear what is going to happen in VRD when you select certain options. It's only inferred.

For 25p at 25i, where each frame looks progressive (no combing), and in my sample file here (last 1min of Mission Impossible and then 30s of the credits)

Auto - correctly chooses none, can check this because the end credits which do have combing have it preserved in the encoded file. Not a show stopper but looks a bit pants. 49meg for my sample.
Weave - technically this should look the same as none, but for some reason the fields are bobbed or interpolated, and then overlaid (some laterally moving credits are like ghosted versions, not combed) 43meg for sample.
Smart - looks the best on the end credits, even better than weave and deinterlacing in VLC, and the 25p footage parts look the same as the other pair of encodings too. So all good. 45meg for sample.

Interestingly 'none' gives the largest size, possibly because the end credits are all combed and take up lots of data.

Now I'd use "deinterlace smart" all the time given those results because it is transparent to the frames without combing issues, and then when there is combing (the credits) it fixes it up nicely.

But on my 25p at 25i footage of the Simpsons HD intro, the line quality was really horrible with deinterlace smart. It looked like it was using bobbing, and not using the pair of perfectly overlaid fields and weaving them... is this because it is large blocks of colours and sharp lines, and is confusing the deinterlacing?

It's this odd behaviour that makes me weary of using deinterlace smart all the time because it's reacted so badly in that case. I don't want to have to babysit every encoding to check the output.

And then the problem with auto is it might choose weave or bob, and I can't easily check which one it has used because it doesn't say.

Right now it seems that...

Deinterlace smart works as expected. Use it everywhere you want progressive frames from interlaced footage, *even* when the pairs of fields line up and would otherwise use none or weave, the smart filter should just leave these alone.
Except for stuff where it might get confused like Simpsons HD or other line art/block colour type footage? In that case use Auto, and double check it picks none by looking in the log files?

It'd be pretty nice if we could pick none.

It'd also be useful if we could flag different blocks selected in VRD to be deinterlaced using different methods. Ie, I can select credits separately and set them to use deinterlace smart, with the main body being none.

Mr Whippy

New member
After lots more reading and testing.

For those encoding DVB 25i type stuff, which is 25p source, so films and stuff that is originally 25fps, the Deinterlace Smart is a bad choice.

In The Simpsons HD distinct lines can end up being detected across different fields and somehow the algorithm that determines what is combing will decide this needs bobbing rather than weaving. Bobbing just doubles up the field info from one field to the other, so a fine line becomes thicker over the size of the block that is detected as 'combed'
This means that lines that have nice defined edges can become stair-cased, or aliased.

I ran a bunch of films through with Deinterlace smart and then ran VMAF inside FFMetrics and then I started looking into the dips in VMAF value, and they were all corresponding with areas where the Deinterlace Smart was falsely detecting combing and then bobbing.
In three different films, Mission Impossible with some edging around a desk with lots of parallel lines which went all stepped and blocky, Independence Day Resurgence where they're watching a screen with lots of parallel lines got a moire pattern across it, and then Skyscraper with some steps from an aerial shot become blocky.

Deinterlace Smart shouldn't be put anywhere near anything that looks progressive but is inside interlaced encoding.

Technically weave is the correct method for this footage, however I've run it on some film credit sections and it gives different results to Auto (none), with none preserving the combing, and which weave should also preserve but didn't.

VideoReDo doesn't offer a 'none' setting for deinterlacing. You can however use Auto, and then double check it's using 'none' by checking the logs. V5 had a 'none' option, but V6 appears to have removed it.

The current best practice method for dealing with anything that looks progressive and that you want to re-encode using VideoReDo, is to use Auto and double check the logs to make sure it's using 'none'

Technically I think we should be able to choose Weave, but I'm not sure why it gives different results to Auto (none)

The only issue with this is credit sections in films can often be interlaced and use the 1/50th sec interval for motion (fast credits especially), and so Auto (none) results in combed credits. The sensible way around this is to just encode the main film with Auto (none) and then the credits with Deinterlace Smart, and then combine the sections with VideoReDo afterwards. I've not tried this yet but it seems like a good way to get the best quality.

Generally speaking though, the recoding of 1080i 25fps to 1080p 25fps seems unnecessary but in a few tests I've dropped file sizes from 8gb of the original stream AVC to 4gb or so with VMAF values (1080p) around 95 using VideoReDo HEVC CQRF 20 slow.

I'm not bashing VideoReDo, I think it's pretty amazing at doing the cutting, and the encoding seems to be very effective and does almost everything you could want... it's just this interlacing that isn't so nice to work with, it's certainly not obvious what settings you should choose.

Merely from a user point of view I think it'd be good if VideoReDo could be improved in two small areas.

- There should be a deinterlacing None option. Having to check logs to see what is happening is not user friendly.

- Perhaps a way to flag certain sections for different deinterlacing methods, so you could set the credits to Deinterlace Smart and the rest of a film to none.

Also I think it'd be good to understand what Weave is doing and what None are doing, and why the results differ. From everything I've now read they should be the same... they technically are the same?



I think you may be wishing for a single deinterlacing solution for all of your source needs.
If such a thing exists, I haven't found it in nineteen years of post-production.
Yes, animation, telecine, tape, and film source all have their special considerations.

The defining basics of bob, weave, blend, etc., are abundantly spelled out on the internet, as they are not unique to VRD.
Top Bottom