MBAFF and deinterlacing

[seandarcy]

I've been encoding a set of dv tapes using x264. The input is interlaced - bff.

ffmpeg -i $INPUT -an -vf "yadif=1:0,hqdn3d" -r 60000/1001
-vcodec libx264 -preset slower -tune film -crf 17 out.m4v

But with MBAFF in x264, does this still make sense? Should I still deinterlace? If not, do I need to give any options x264? Do I need to signal bottom field first? If so, how?

Does this Just Work:

ffmpeg -i $INPUT -an -vf "yadif=hqdn3d" \
-vcodec libx264 -preset slower -tune film -crf 17 out.m4v

I'm assuming that in this second case the output is interlaced, correct?

Thanks,

sean

[LoRd_MuldeR]

If you apply a deinterlacer, such as Yadif, on interlaced footage, the result is progressive video. Well, that's the purpose of a deinterlacing filter ;)

Consequently you are encoding progressive video and therefore you do not need to (and shouldn't) encode it as interlaced! MBAFF would only be relevant for interlaced encoding.

And nope, in the second case you are still applying Yadif, so you still get progressive output. Last but not least there is no field order signaling for progressive video.

(If at all, you would have to signal the field order of the input video to the deinterlacing filter, so it will output the progressive frames in the right order)

[Audionut]

I think you missed the main question LM.

"But with MBAFF in x264, does this still make sense? Should I still deinterlace?"

I don't mind the performance of my nvidia card deinterlacer.
And from what I gather, with mbaff, there isn't the bitrate/quality hit compared to progressive anymore.

Can't help you out with the cmd line though.

[seandarcy]

Me and my fat fingers!!

Here's what I meant for the second case:

ffmpeg -i $INPUT -an -vf "hqdn3d" \
-vcodec libx264 -preset slower -tune film -crf 17 out.m4v

That is just denoising, not deinterlacing.

sean

[LoRd_MuldeR]

Me and my fat fingers!!

Here's what I meant for the second case:

ffmpeg -i $INPUT -an -vf "hqdn3d" \
-vcodec libx264 -preset slower -tune film -crf 17 out.m4v

That is just denoising, not deinterlacing.

sean

That makes a difference, of course!

While it is impossible to know from the command-line whether your source video is actually interlaced and I'm not sure whether the denoiser works on interlaced video, you potentially get interlaced output here. This means, if you do not want to deinterlace, you have to tell x264 that the video is interlaced and you have to signal the correct field order - unless FFmpeg does that automatically for interlaced sources. With x264 you would use "--tff" or "--bff" to enable interlaced encoding and indicate the proper field order. I don't know what the corresponding FFmpeg syntax is though.

Regarding "Should I still deinterlace?" it is hard to give a general advice. It depends a lot on what you are going to do with the re-encoded video. Keeping the video interlaced means you will have to deinterlace at playback time - every single time you watch the video on a progressive screen (and this applies to all LCD/Plasma screens and projectors that we have nowadays).

[Stereodude]

Keeping the video interlaced means you will have to deinterlace at playback time - every single time you watch the video on a progressive screen (and this applies to all LCD/Plasma screens and projectors that we have nowadays).Heck, even interlaced displays will still deinterlace the video to scale it for display unless it's the native resolution of the display.

[Sharc]

One my also want to keep the temporal resolution of the interlaced source for later use.
On the fly deinterlacers (during playback) do a pretty good job these days.

[sneaker_ger]

One my also want to keep the temporal resolution of the interlaced source for later use.

Or you can just keep the temporal resolution by bobbing, as seandarcy apparently does.

[Sharc]

Sure, but it doubles the framerate and produces larger files.
And how about blu-ray compliance with the double frame rate (if blu-ray compliance is considered important)?

[sneaker_ger]

720p50 and 720p60 are supported.

[aegisofrime]

Sure, but it doubles the framerate and produces larger files.
And how about blu-ray compliance with the double frame rate (if blu-ray compliance is considered important)?

The doubled framerate is nice (especially if you use a decent deinterlacer like Q/TGMC) and the file size isn't that much bigger; Roughly about 25% bigger, and not 100% bigger as some might think.

[LoRd_MuldeR]

Heck, even interlaced displays will still deinterlace the video to scale it for display unless it's the native resolution of the display.

Well, PC screens certainly do not. So you have to rely on the playback software and/or the renderer to do the deinterlacing ;)

If you play the video on a "standalone" player connected to a TV screen, then the deinterlacing/scaling might be done by the player or by the screen.

In all these cases the deinterlacing quality may vary greatly, depending on the individual playback software/equipment...

[CruNcher]

The doubled framerate is nice (especially if you use a decent deinterlacer like Q/TGMC) and the file size isn't that much bigger; Roughly about 25% bigger, and not 100% bigger as some might think.

But Q/TGMC isnt really usefull in a Realtime Playback scenario yet and with a full Realtime framework you don't have to think about filesize (Bandwith) anymore and by the next GPU generation hopefully we finally gonna see Q/TGMC vanish, though we might already be their @ least with DXVA it seems so, though no one could utilize the better Driver algorithm yet outside of DXVA, now it seems we are able to do that @ least with Nvidia Cards (not with the same speed obviously as over DXVA (depends highly on the system balance especially in a discrete environment) @ Realtime Playback and only under Vista/7,their are ways to do it under pre Vista/7 also but they cost a lot of additional overhead that makes it rather useless their) :)

[Didée]

@CruNcher: some proof or reference? I just hear you talk & claim.

[Blue_MiSfit]

I find it very hard to believe that [Q]TGMC quality playback deinterlacing will be available in hardware via consumer level GPUs anytime soon. I'm also wondering if you have any source, CruNcher.

Derek

[Didée]

Well ... it's a topic with several facets to consider. And one of the main 'problems' is the possibility of evaluability. (If that's a valid english word)

It's not that the - admitted - *huge* computational effort of QTGMC would be necessary for a fair viewing experience of interlaced content. For casual viewing, of course you can get away with much less. Hey, a simple kernel-bob does not look explicitely bad, especially with 1080i sources! It's okay for casual viewing!

On the other hand, of course there is a worthwile gain that is achieved from that computational effort. A major part of that effort is the usage of active motion search via MVTools, and ... there is no way (yet) that GPUs would use active motion search+compensation for means of deinterlacing. (And "vector adaptive" is not what some might interpret it as...)

I'd surely love to have the possibility to make use of GPU deinterlacing at free will, and in a controlled & reproducable way. Just to be able to make some "objective" comparisons. (Well, maybe there are ways to do it, I haven't really played Sherlock Holmes in this case.)

For the not-so-intrigued, the current situation is that you can use GPU deinterlacing as a black box during playback, period. "And? Does it look good? Oh, it does? Dang, there's your proof!! GPU kixxazz!!"


Analogy: There's no doubt that H.264 (x264) is superior technology compared to ASP (Xvid). This can easily be proven - but only because you can use both at free will, in a fully controlled & reproducable environment.
If, however, the only posssible way of comparison was realtime-watching on screen, and the samples would be 1080p @ 12000 kbps, then the differences probably would be less obvious. Hmh yes, maybe x264 looks a little better. But hey, Xvid does look pretty good, too!

Another point is that you can't even be fully sure which level of deinterlacing you're getting under various circumstances. For example, when using hardware deinterlacing via DGDecodeNV, then I'm not convinced if the driver is delivering "the best" deinterlacing method (aka "vector adaptive"), or perhaps is using a more simple method in fact ...

You just don't know / can't be sure. A black box is a black box is a black box.


Possibility of controlled comparison that can be objectively analysed. If that is not possible, all talk is just words in the wind.

[kieranrk]

NNEDI would be suitable for conversion to run on the GPU. Possibly the motion search on a Sandy Bridge would be good enough for deinterlacing.

[TheRyuu]

I'd surely love to have the possibility to make use of GPU deinterlacing at free will, and in a controlled & reproducable way.

DGDecodeNV?

[roozhou]

DGDecodeNV?
DGDecodeNV is not free. Use LAV CUVID.

[TheRyuu]

DGDecodeNV is not free. Use LAV CUVID.

I don't think their comparable.

One is an avisynth filter which allows me to use it in a controlled environment with frame accuracy to boot.

It looks like LAV CUVID is just another dshow filter and is the same "black box" sort of deal on playback.

Unless I'm misunderstanding something here? (I don't know that much about LAV CUVID and I've never used it)

[Didée]

DGDecodeNV?
Well ...
For example, when using hardware deinterlacing via DGDecodeNV, then I'm not convinced if the driver is delivering "the best" deinterlacing method (aka "vector adaptive"), or perhaps is using a more simple method in fact ...

Mind you, deinterlacing via DGDecodeNV I already have checked intensively.

There are numbers (http://forum.doom9.org/showthread.php?p=1378244#post1378244), and there are samples (http://www.mediafire.com/download.php?d6xb7m46ua4l6iv), samples (http://www.mediafire.com/download.php?i7znn4nfpvr8nwe), samples (http://www.mediafire.com/download.php?azei61r2098os0d) ...

If *that* is "the best" that Nvidia can do, then it's nothing to phone home about. From practical results, that is Yadif's niveau. Some minor differences, but basically its a close call between them two. (NV slightly less artificial, Yadif with better temporal stability.)

Better let's hope that NVidia has more to offer than that. (IIRC, Donald once said there is no control in DGDecodeNV which algorithm shall be used ... he's just setting the "deinterlace this for me" flag, and receives what the driver decides to deliver. I.e.: "using the black box".)


Waiting for CruNcher to reveal some not-yet-revealed magic. :)

[roozhou]

I don't think their comparable.

One is an avisynth filter which allows me to use it in a controlled environment with frame accuracy to boot.

It looks like LAV CUVID is just another dshow filter and is the same "black box" sort of deal on playback.

Unless I'm misunderstanding something here? (I don't know that much about LAV CUVID and I've never used it)
Everything is a "black box", including DGDecodeNV, unless it's open source.

DirectShow decoders can be frame accurate, as long as the demuxer outputs correct timestamps. Most containers have an index so frame accuracy can easily be guaranteed.

[aegisofrime]

Maybe Cruncher has a project for running Q/TGMC in CUDA/OpenCL :p

Though IIRC, -Vit- mentioned he had some ideas for offloading MVTools2 functions onto GPU...

[CruNcher]

Myself isn't yet on Vista/7 so i cant proof it but others seemed to have proven it already LAV CUVID gives the access to a DXVA interop mode (defined via their Nvcuvid API) that seems to use the better deinterlacing algorithm it works though only on Vista/7 @ Win XP it ends up in strange artifacts :(

You can follow the whole thing here
http://forum.doom9.org/showthread.php?p=1492525#post1492525 ( it started with that old talk log from Donald with an Nvidia Engineer)
http://forum.doom9.org/showthread.php?p=1493002#post1493002 (some discussion and old results from DXVA)
http://forum.doom9.org/showthread.php?p=1492967#post1492967 (added my experience with Nvidia Drivers and known ways they do decisiioning, and speculation why they should hide this, though no answer yet why their API gives access to it then)
http://forum.doom9.org/showthread.php?p=1493025#post1493025 (first build with DXVA interop used by yesgray according to him its proven)
http://forum.doom9.org/showthread.php?p=1493445#post1493445 (tried to reproduce his results, found this issue with DXVA interop and XP)
http://forum.doom9.org/showthread.php?p=1493460#post1493460 (lower jitter impressed me even knowing it could come from the errors ;))
http://forum.doom9.org/showthread.php?p=1493232#post1493232 (might be a reason why Nvidia said only for DXVA)
http://forum.doom9.org/showthread.php?p=1493246#post1493246 (first release with DXVA Interop)

So its up to everyone now to proof/disprove yesgray, i don't see why he should lie and his results make sound, and Nvidia likes to hide stuff i remember the GPU utilization stuff and their marketing blabla of only G200 cards no G92 supported exclusive feature yeah until someone found out that by accident overclocking enables it on G92 cards in a specific driver revision, and i was very angry about this practice and i really was crying out loud http://forums.nvidia.com/index.php?showtopic=165957&st=0&p=1037944&#entry1037944 and seems no user heard me but maybe Nvidias Engineers/Marketing did, today it's available in every driver for every card ;)

[Didée]

I have LAVCUVID installed since yesterday. It generally works (i.e: it does decode, without artifacts), but the deinterlacing feature seems to have a life of its own. Some things it deinterlaces as it should (confirmed: AVC 1080i), some things it does not deinterlace at all (anything 576i, no matter if mpeg2 or AVC. Tried *all* settings in the filter.)
My hardware should be good: Nvidia card with VP4 engine, latest official driver (270.61 WHQL), OS is Win7-HP (x64).

Here is an interlaced source: Stockholm, PAL 576i (x264 @ CQ1) (http://www.mediafire.com/?idkekwg8vh8veqg)

Someone wanna show me the incredible deinterlacing power of NVidia's hardware deinterlacing, in bob mode (50fps)?? Please?? :)

[Audionut]

I've got PAL 576i mpeg2 content that gets deinterlaced fine here. After converting with x264 is also deinterlaced fine.
Confirmed by disabling deinterlacing in LAV CUVID and getting interlaced results.

[Didée]

Sorry, I formulated wrong. 576i does get deinterlaced, but bobbing 25i -> 50p doesn't take place with 576i sources. Or more precisely, not reliably. Depending on moon phase and air humidity, 25i might become 25p, or 50p with evry odd frame being a dup, or - sometimes - true 50fps indeed.
(Don't poke me for the "settings" - I tried them all, and it *does* work as expected with 1080i.)

Moreover, the deinterlacing of 576i is not good. Really bad jaggies, looks like bicubic interpolation. Even DGDecodeNV deinterlaces better, for me.

http://www.abload.de/thumb/lavcuvid_vs_dgdecodenvn74a.jpg (http://www.abload.de/image.php?img=lavcuvid_vs_dgdecodenvn74a.jpg)
Left is LAVCUVID, right is DGDecodeNV. You see? Yay.
Again, apparently it's only SD resolutions that act this strange. 1080i is better. Funny, isn't it?

I'm not interested in tracing this down. I don't need actually need it, anyway. And, do *I* need to jump through loops, just to disproove CruNcher's claim "no need anymore for QTGMC"? Nah ... that's ridiculous anyway.:rolleyes:

[kieranrk]

And, do *I* need to jump through loops, just to disproove CruNcher's claim "no need anymore for QTGMC"? Nah ... that's ridiculous anyway.:rolleyes:

Like everything he writes...

[Audionut]

I just tried to get QTGMC to run in realtime in MPC and couldn't. This is neither here nor there, as it clearly isn't designed to do so (although I believe some people have had success).

One is obviously designed for real time deinterlacing during playback.
And the other is obviously designed for high quality deinterlacing during encode.

They both serve their function.

[CruNcher]

Sorry, I formulated wrong. 576i does get deinterlaced, but bobbing 25i -> 50p doesn't take place with 576i sources. Or more precisely, not reliably. Depending on moon phase and air humidity, 25i might become 25p, or 50p with evry odd frame being a dup, or - sometimes - true 50fps indeed.
(Don't poke me for the "settings" - I tried them all, and it *does* work as expected with 1080i.)

Moreover, the deinterlacing of 576i is not good. Really bad jaggies, looks like bicubic interpolation. Even DGDecodeNV deinterlaces better, for me.

http://www.abload.de/thumb/lavcuvid_vs_dgdecodenvn74a.jpg (http://www.abload.de/image.php?img=lavcuvid_vs_dgdecodenvn74a.jpg)
Left is LAVCUVID, right is DGDecodeNV. You see? Yay.
Again, apparently it's only SD resolutions that act this strange. 1080i is better. Funny, isn't it?

I'm not interested in tracing this down. I don't need actually need it, anyway. And, do *I* need to jump through loops, just to disproove CruNcher's claim "no need anymore for QTGMC"? Nah ... that's ridiculous anyway.:rolleyes:

So how is the Deinterlacing Quality with DXVA interop ticked with 1080i compared to QTGMC, according to yesgray it's better then without it ticked so better then the Yadif comparable Deinterlacer that's used by default (so theirs only the vector adaptive left and looking @ his results that makes sound better anti aliasing of the football field line) and in other Nvcuvid based apps like DGDecNV.

Ok seems i can reproduce it with the Stockholm 576i clip BOB actually seems to trigger it Adaptive doesn't show this issue, setup is (VP2 G92) + OS (Win XP) and driver 270.71 Quadro currently.

Adaptive Result 25p:

http://img685.imageshack.us/img685/4518/576iokadaptive.th.png (http://img685.imageshack.us/img685/4518/576iokadaptive.png)

Bob Result 25p:

http://img191.imageshack.us/img191/4391/576ibadbob.th.png (http://imageshack.us/m/191/4391/576ibadbob.png)

Cyberlink Bob Result 50p:

http://img17.imageshack.us/img17/4518/576icyberlinkbob.th.png (http://imageshack.us/m/17/4518/576icyberlinkbob.png)

[nevcairiel]

The "BOB" option in DGDecodeNV is not actually pure BOB.

BOB in DGDecodeNV equals "Adaptive" with "Double Frame Rate" ticked in LAV CUVID.
The Double Frame Rate will actually do "bobbing", deinterlacing both fields, outputting 50 real frames.

Anyhow, the 50i->50p conversion relys on the bitstream flagged properly. Future versions will offer you an option to override this and just always output 50p, if requested.

Now if 50p just outputs every frame dup'ed .. thats out of my hands, thats all NVIDIAs doing.

I should probably rename the options a bit, and write a manual, or something. :p

[nm]

If *that* is "the best" that Nvidia can do, then it's nothing to phone home about. From practical results, that is Yadif's niveau. Some minor differences, but basically its a close call between them two. (NV slightly less artificial, Yadif with better temporal stability.)

I've used Nvidia's filters through VDPAU on Linux and I completely agree with this statement. VDPAU allows you to select one of three 50i->50p filters: simple bobbing, "motion-adaptive" deinterlacing and "motion-adaptive" with edge-guided interpolation (which is similar to yadif). Differences between these modes are clearly visible and the best mode is far from TGMC quality.

[Blue_MiSfit]

The only real benefit IMO these days to nVidia deinterlacing is that it saves a lot of CPU cycles. If your'e a speed freak, it's not too bad, especially if you're downscaling the result (1080i60 to 480p30 for example)