Debate: Interlaced vs. Progressive

[MfA]

It's not true for eye-tracked motion however - but then most modern displays are already a disaster for eye-tracked motion anyway, so it matters less.
Getting better all the time though. As long as we are going to put ever more computing power and algorithms into something I'd rather have it go into better motion compensated framerate conversion than better deinterlacing. With 240 Hz displays with 2 msec gray-gray I'd guess the display technology is pretty close to where no further improvements in smoothness can be perceived ... assuming good content to actually drive it at 240 Hz (where the computing power and algorithms come in).

[knutinh]

Getting better all the time though. As long as we are going to put ever more computing power and algorithms into something I'd rather have it go into better motion compensated framerate conversion than better deinterlacing. With 240 Hz displays with 2 msec gray-gray I'd guess the display technology is pretty close to where no further improvements in smoothness can be perceived ... assuming good content to actually drive it at 240 Hz (where the computing power and algorithms come in).

Would not mocomp frc also be an example of technology that has worse benefit/cost if done blindly in the display, as opposed to integrated in the lossy codec? Using B-frames (or similar), in-between frames can be described with the added benefit of explicit encoder control. Given that 240fps content is available to the encoder (generally not true), or that the encoder can afford more processing cost than the decoder (generally true for broadcast), even a few bits spent for controlling behaviour could improve things compared to spending no bits.

-k

[MfA]

Bitwise yes, moneywise no ... the costs added on display devices for the extra necessary gates to decode high fps streams is problematic (progressive vs. interlaced, when EBU was deciding things, was already not a big deal in any part of the chain). When H.265 is being hammered out and almost all displays are 144 Hz+ to begin with, HD slowmo cameras ubiquitous and transistors cheaper than ever I would definitely want to see high fps modes being a fundamental part.

[lovelove]

... interlacing does (at least partly) achieve the gains it's supposed to. That's why it's used. It's not a conspiracy, and it's not a mistake - it actually works (i.e. gives better quality / lower bitrates). Even with H.264 (if the encoder handles interlacing well enough). [...]

It does make logical sense that packaging the (adaptive) interlacing and (adaptive) deinterlacing into the encoder should make it work better than externally - but it's more complexity: more tuning in the encoder; more work in the decoder. Has anyone ever done it?

I found this:

x264's interlaced encoding is inherently less efficient than its progressive encoding, so it is probably better to deinterlace an interlaced source before encoding rather than use interlaced mode.

2Bdecided, is this the bottom line or do you still maintain that it gives "better quality/lower bitrates" in h264? If yes, what other encoder than x264 are you refering to?

[GodofaGap]

I doubt that x264's interlaced mode is so bad that bobbing first and encoding afterwards will result in a better quality video than encoding interlaced first and bobbing afterwards at an equal bitrate.

[lovelove]

You doubt, that's okay. But that's guessing only.
Also note that it's not necessarily x264's interlaced mode being "so bad", but potentially it's non-interlaced mode being "much more efficient".

[Manao]

lovelove : Deinterlacing != bobbing. The quote from mewiki is misleading. If you deinterlace an interlaced source, you lose information (since you halves the motion). So saying it's more efficient is misleading, because the efficiency doesn't consider the lost information. What the quote wants to say is that, if you take an interlaced video, encode it with some bitrate X, and measure the PSNR, you'll get a (far lower) PSNR than if you deinterlace, encode it at the same bitrate X, and measure PSNR (against the deinterlaced version, of course). You're actually comparing apples and oranges when you do that, but it's an easy mistake to conclude that it's more efficient.

Furthermore, x264 is a very efficient encoder, but when encoding interlaced content, it's lacking some major tools (either field picture support, or adaptive mbaff, or both) that seriously hampers it in regards to the concurrence. That doesn't mean it will be worse, but it does mean there is a lot of room (from 0.5 to 2dB, depending on the sequence) for improvement in x264 when it comes to interlacing.

[lovelove]

First of all: PSNR != quality (and that's a direct quote from the x264 devs).

Secondly, note that neither my posting nor the quotes in my posting mention bobbing.

Thirdly, bob(bing) IS a deinterlacing method according to www.100fps.com

Fourthly:
measure PSNR (against the deinterlaced version, of course). that is your supposition only.

You're actually comparing apples and oranges when you do that exactly, and that would be a good reason for the author not to have used this comparison and for your supposition to be wrong as a result.

----

x264 ... when encoding interlaced content, it's lacking some major tools ... that seriously hampers it in regards to the concurrence. so which other encoders can you recommend for interlaced content then ?

[Didée]

lovelove : Deinterlacing != bobbing.
bobbing == Deinterlace(parity=alternating)

[Manao]

I think we can agree that on this forum, when somebody says he "deinterlaced a video", nobody will assume he bob-deinterlaced it, just that he took a 50i/60i video and made it 25p/30p. Bobbing has become more than a deinterlacing method, it has become the process of taking a 50i/60i video and making it 50p/60p (see the number of avisynth filters with 'bob' in their name, and look at what they do).

If I talk of PSNR, it's because as of now, we still haven't a way to measure quality. If you prefer, I could have said the quantizer would be lower on the deinterlaced encoding.

I still stand by my interpretation of mewiki's quote (it's easy for a guy writing a documentation to get carried on and make a mistake)

Finally, all the broadcast encoders support one or both of the tools x264 lacks. I'm pretty sure mainconcept's does to.

[GodofaGap]

You doubt, that's okay. But that's guessing only.
What makes you think the MeWiki is not guessing? They say it's 'probably' better. IOW it may be better, but it also may not be better. Tautological.

I think we can agree that on this forum, when somebody says he "deinterlaced a video", nobody will assume he bob-deinterlaced it, just that he took a 50i/60i video and made it 25p/30p.
I'm fine to agree with that, but I just wanted to point at the flaw in the statement of the MeWiki. There is actually something that you destroy with deinterlacing (in your definition) and keeping this instead may be well worth accepting the lower efficiency of interlaced mode depending on the content.

[Didée]

I think we can agree that on this forum, when somebody says he "deinterlaced a video", nobody will assume he bob-deinterlaced it, just that he took a 50i/60i video and made it 25p/30p. Bobbing has become more than a deinterlacing method, it has become the process of taking a 50i/60i video and making it 50p/60p (see the number of avisynth filters with 'bob' in their name, and look at what they do).
It's true that most people use the term "deinterlacing" in the simple way, meaning 25/30i -> 25/30p. But in fact, that is not a good nomenclature.

I don't need to explain anything to *you*, Manao. ;) - But you made the whacky assertion of "deinterlacing != bobbing", and that is just not true. Bobbing IS deinterlacing, and evenmore it is the "true" way of deinterlacing. Opposed to the "usual" meaning of deinterlacing, which is only a crippled subset.

(The process of) "Deinterlacing" is exactly the opposite of (the process of) "Interlacing".

During interlacing, every two raw source frames are combined into one frame. From my understanding, the reverse operation of that is to undo that combination again.

Now, when the majority of people thinks the reverse operation is to undo that combination and to throw away half of the result, then it's a sign that too little education or clarification has been done in all those years.

Having stumbled of this bobbing/deinterlacing confusion more often than enough, I pretty much prefer the terms "same-rate deinterlacing" and "double-rate deinterlacing". Though not quite perfect (it should rather be "half-rate" and "full-rate"), at least it makes clear what is really going on, and should avoid lots of unnecessary confusion.

[Manao]

But in fact, that is not a good nomenclature.Agreed. Still, mewiki simply states "deinterlacing", and the most likely correct interpretation is half rate deinterlacing. Or, rather, if it isn't interpreted like that, then mewiki is incorrect, because 50i -> 50p before encoding will most likely increase the required bitrate (at constant quality, psnr, whatever), even with x264.