Properly deinterlacing h264 MBAFF

[billranton]

Hello,

I taped some stuff for my son off BBC One HD on freesat over christmas, and noticed that they seem to have forgotten to set the old copy protection flag on this channel. So I thought I'd have a go at archiving it with megui.

The trouble is that I can't find a combination of deinterlacing settings in the avs script creator to deinterlace the MBAFF properly. I'd used yadif to start with, but no megui filter I tried (TDeint, LeakKernelDeint, TomsMoComp, FieldDeinterlace) could deal with it properly. If one frame was ok, the next would be blocky.

Can anyone tell me the correct filter/settings to use for MBAFF?

Thanks for any pointers

[LoRd_MuldeR]

Hi :)

If your footage is "true" interlaced (and not Telecined), then there are various deinterlacing filters available from which you can choose.

Yadif should do a fairly well job, it works "out-of-the-box" and it's pretty fast. TDeint usually needs more tweaks to get the desired result. I wouldn't use KernelDeint nowadays.

Really good results can be achieved with TGMC or it's QTGMC variant. By default (Q)TGMC is very slow, but there now are presets to tweak more for speed...

(For a more detailed analysis, provide a sample of your original unprocessed footage! Quite possible that the "blocks" are in your source already)

[SeeMoreDigital]

Are you able to provide a short sample of your captured source?

[billranton]

Thanks for the fast response. I managed to make a 1.5MB 2 second chop of a part I know has the mbaff, when the white flash appears. I hope megaupload is ok. I can upload it somewhere else if needed.

http://www.megaupload.com/?d=DLS5K7IQ

Attached is a frame from my processed file, showing the blocks I get. They happen every 1-3 frames, and any frames between look completely fine. If I view the source in megui with no deinterlace, then I see combed blocks in the same kind of arrangement around the fast moving parts of the flash.

Moved the big image to external link (ImagesHack), so it doesn't destroy the layout:
http://img401.imageshack.us/img401/7281/attachmentga.jpg

[LoRd_MuldeR]

billranton, this looks like a decoding problem! I can't see any blocks with your sample, using DGDecNV. Also there's no interlacing in that sample.

Here's my result, not using any filters at all, except for DGSource():
http://www.mediafire.com/?vl7cpcq48qv1l4a

(Before you ask: Yes, I know that DGDecNV has a built-in deinterlacing filter. But it definitely was turned off this time ^^)

[billranton]

Here's the blocks of combing I see. Isn't that interlacing?

http://i.imgur.com/za1VA.png

[LoRd_MuldeR]

Here's the blocks of combing I see. Isn't that interlacing?

http://i.imgur.com/za1VA.png

Nope. It's not interlacing (although it looks a bit like that), but the result of a decoder bug. Use a H.264 decoder which doesn't fail on that particular stream (e.g. DGDecNV) and you'll get perfect progressive frames from the sample file. Please see the clip that I provided in my previous post. What H.264 decoder are you using currently? I also tested FFmpegSource2 on your sample and it failed...

UPDATE: It seems using Haali Media Splitter + DivX H.264 Decoder through DSS2() seems to work okay too. So if you don't want to buy DGDecNV, this would be a free solution.

[deets]

bbc HD always produces those kinda of blocks on any DXVA decoder I use. is a royal pain in the backside.

[billranton]

Yeah I don't see this problem anywhere else apart from in megui. All players show it fine. I don't have a license for the nv version, so this is coming from dgavcindex. Is that using it's own local libavcodec.dll? The version in that folder is dated 06/08/2008. Could it be too old? I tried to replace it, but it complained.

[LoRd_MuldeR]

Yeah I don't see this problem anywhere else apart from in megui. All players show it fine. I don't have a license for the nv version, so this is coming from dgavcindex. Is that using it's own local libavcodec.dll? The version in that folder is dated 06/08/2008. Could it be too old? I tried to replace it, but it complained.

DGAVCIndex is a dead project. It uses a hopeless outdated version of libavcodec with various known issues. And there won't be any updates for DGAVCIndex, unfortunately!

If you aren't willing to license DGDecNV (NVidia decoder) or DGAVCDecDI (DiAVC decoder), then you are better off giving FFmpegSource2 a try, which is free and uses an up-to-date libavcodec.

But, as said before, in my test FFmpegSource2 (v2.14) produced artifacts with your sample file too. DSS2() with Haali Media Splitter and DivX H.264 Decoder might be a solution though...

[billranton]

I think you've nailed the problem there. Thanks very much for helping to solve this. I'd not considered licensing DGDecNV before, as I didn't know DGAVCIndex had so many inadequacies, but maybe now I will. I'm sure it'll give me a speed boost too. It's a shame the free one is so rotten, as the default megui toolset works perfectly for me otherwise.

Bet you that this decoding problem is actually incorrect handling of MBAFF interlaced macroblocks though ;)

[deets]

yeah its a good bit of software and should speed things up as it handles the resizing and any de interlacing needed as well. I am using it right now to convert a film for my android but I use it all the time for UK HD stuff and I wouldn't be without it!

[SeeMoreDigital]

billranton, this looks like a decoding problem! I can't see any blocks with your sample, using DGDecNV. Also there's no interlacing in that sample.Agreed... The sample looks very nice and "progressive" to me :)

[billranton]

I find this MBAFF fascinating. From what I've read, it makes interlacing optional, so when there are spare bits, the encoding is progressive. It gives the encoder the option to turn on interlacing at the level of the individual macroblock level when things are soaking up the bitrate, which would look like my sample picture if it wasn't being handled properly. i think this kind of piecemeal interlacing is too much to expect a whole frame based deinterlacer to handle, which is why it gets handled internally by the h264 decoder, which is why you're not seeing it.

Either way, I'm interested in what is producing this combing.

[LoRd_MuldeR]

I find this MBAFF fascinating. From what I've read, it makes interlacing optional, so when there are spare bits, the encoding is progressive. It gives the encoder the option to turn on interlacing at the level of the individual macroblock level when things are soaking up the bitrate, which would look like my sample picture if it wasn't being handled properly. i think this kind of piecemeal interlacing is too much to expect a whole frame based deinterlacer to handle, which is why it gets handled internally by the h264 decoder, which is why you're not seeing it.

Either way, I'm interested in what is producing this combing.

If the source is interlaced, then you can't encode individual blocks as "progressive", just because you are low on bits! Well, of course you can, but it would destroy the content in those blocks (even when decoded correctly!). However in an interlaced source, there always are areas that are "static" (no motion) and therefore can be treated like "progressive". The same way all those "adaptive" deinterlace filters will detect "static" areas and skip them, as there's no combing visible in those areas. These would be the same areas that you could encode as "progressive" blocks safely and thus safe a few bits there...

[kieranrk]

Either way, I'm interested in what is producing this combing.

Buggy decoders.

[xv]

I also wondered how deinterlacing of MBAFF sources works:
I noticed while watching 1080i50 HD tv on pc without any deinterlacing, the movie itself was not interlaced, but if there is a overlay like for example a moving news line at the bottom, it was interlaced.
I understand it like this: Each macroblock can be coded as two fields (1/2 frame) or one frame, not two frames per block.

A deinterlacer now only needs to deinterlace those parts of the image that are actually interlaced.
The question is: Are those flags in the macroblock set correctly or are all macrobocks set interlaced even when the content is not interlaced.
And the next question: Is this important information for a good deinterlacer or does it automatically find interlaced parts of the image without reducing quality of non-interlaced parts?

[Mug Funky]

simplistically, MBAFF assumes the entire frame is interlaced, (so the decoder knows how it must treat the stream), and chooses between frame or field coding per-macroblock, depending on coding efficiency or some other (encoder-specific) property.

basically best of both worlds.

i suppose a decoder could save a little time looking for interlacing by only deinterlacing the field-coded blocks, but this in my opinion would be assuming way too much - the encoder may have made a bad decision...

@ xv:
what you're seeing is progressive content that had interlaced titles added to it in the online session. this happens way before the encoder gets it's hands on it. though it is a situation where MBAFF would shine - it would only need to encode the moving edges of the titles as fields, and the rest could encode as frames without ill-effect.

[kieranrk]

Deinterlacers already check whether a particular region is progressive or not. Also just because the encoder has encoded a macroblock as a field doesn't necessarily mean the underlying region is interlaced.

[dansus]

Im struggling to encode some BBCHD streams with DGNV after recent changes from pure interlaced to mixture of progressive and MBAFF.

Ive tried using use_pf=true and deinterlace=2 but im still getting frame doubling on the progressive parts.

[Guest]

Im struggling to encode some BBCHD streams with DGNV after recent changes from pure interlaced to mixture of progressive and MBAFF.

Ive tried using use_pf=true and deinterlace=2 but im still getting frame doubling on the progressive parts. You cannot decimate the doubled progressive frames alone without killing audio sync (unless you go to some VFR solution).

[dansus]

You cannot decimate the doubled progressive frames alone without killing audio sync (unless you go to some VFR solution).

VFR solution sounds ok, care to expand?
.

[Guest]

VFR solution sounds ok, care to expand? It's a difficult thing and your playing device has to support it. You can read about it here:

http://forum.doom9.org/showthread.php?t=64314&highlight=Test+Case%2C+VFR

Why not just treat it in a standard way: deinterlace the interlaced frames and leave the progressive ones alone, leaving the original frame rate.

[dansus]

Why not just treat it in a standard way: deinterlace the interlaced frames and leave the progressive ones alone, leaving the original frame rate.

Its sport, so want get the 50fps for motion. VT's are p25 so easy to spot. Think i will just cut it up, encode separately and join it together for now.

[Guest]

Its sport, so want get the 50fps for motion. VT's are p25 so easy to spot. Think i will just cut it up, encode separately and join it together for now. That won't help. You'll have 50 fps for the interlaced segments and 25 for the (decimated) progressive segments. You won't be able to join them in a constant frame rate clip.

You'd have to do frame interpolation on the progressive parts to bring them up to 50 fps. Expect a lot of artifacts doing that. Simplest is to just accept the doubled progressive frames.

[dansus]

You'd have to do frame interpolation on the progressive parts to bring them up to 50 fps. Expect a lot of artifacts doing that. Simplest is to just accept the doubled progressive frames.

Thats a good idea, ive got a script ready to go for that too. Thanks for the reminder.

But your right, at this point, may as well except dupe frames. Not like its going to add much to the size.