Deinterlace before encoding x264?

[Kwinz]

Hi!

I record TS streams from DVB-S in SD.
Theese are soccer games and I watch them on my PC.

To save space I:

demux them with ProjectX
crop and deinterlace them with AviSynth using yadif
encode them with x264
and mux them as mkv with the original MP2 audio.


Would I get any quality enhancements if I ommitted the deinterlacing in AviSynth and used the --interlaced switch with x264?

I'm speaking of quality gains in x264 only. I don't want to start a discussion about software player's deinterlacing quality. Let's just assume it was same as AviSynth yadif.

Thanks for reading (and hopefully answering) my thread.
Kwinz

[Dark Shikari]

x264's interlaced encoding is not as efficient as its progressive encoding; while it isn't too bad, its generally recommended (whenever possible) to deinterlace instead.

[Kwinz]

Thank you for the quick and conclusive answer.
Your posts are allways a pleasure to read. :)

[GodofaGap]

If you want to maintain motion fluidity (it's sports after all) encoding as interlaced and bob at playback might be not as costly in terms of filesize/quality as encoding a bobbed source. Having said that, I have not tried the interlaced mode of x264.

[Kwinz]

If I get you right, you advise me to encode interlaced and use bob after encoding.
According to my understanding this discards half of the vertical resolution at the player. How is this supposed to improve quality?

[LoRd_MuldeR]

If I get you right, you advise me to encode interlaced and use bob after encoding.
According to my understanding this discards half of the vertical resolution at the player. How is this supposed to improve quality?

He recommends to keep it as-is, encode as interlaced and do the bobbing at playback time.
If you bob it before encoding, this will double the framerate. You can encode as progressive, but you have to encode the double number of frames.
So the first method (encode interlaced) should save some bitrate, even if interlaced encoding isn't as efficient as progressive encoding.

If you don't wont to use a bobbing deinterlacer, forget about this and deinterlace first.

[Kwinz]

He recommends to keep it as-is, encode as interlaced and do the bobbing at playback time.
If you bob it before encoding, this will double the framerate.

It will double the frame rate but also half the resolution. I think this will save more bitrate, than encoding nearly identical frames twice.


If you don't wont to use a bobbing deinterlacer, forget about this and deinterlace first.

I like the fluidity of bob, but I think the hardware accelerated DXvA motion compensation thing I use at playback performes pretty good without the disadvantages of bob.

[Dark Shikari]

It will double the frame rate but also half the resolution.What?

[LoRd_MuldeR]

It will double the frame rate but also half the resolution. I think this will save more bitrate, than encoding nearly identical frames twice.

No, it won't! Bobbing will create full frames at double framerate.
For example from a 720x576 source at 50 fields per second (e.g. PAL TV) you will get 720x576 output at 50 frames per second.
Of course this only applies to bobbing. It does not apply to other deinterlace methods!

[Kwinz]

I'm very sorry if I'm causing confusion right now due to false assumptions.
I am refering to a few articles about deinterlacing I read. I'm going to quote wikipedia:

Line doubling takes the lines of each interlaced field (consisting of only even or odd lines) and doubles them, filling the entire frame. This results in the video having a frame rate identical to the field rate, but each frame having half the vertical resolution, or resolution equal to that of each field that the frame was made from. Line doubling prevents mouse teeth but it causes a noticeable reduction in picture quality since each frame displayed is doubled and really only at the original half field resolution. This is noticed mostly on stationary objects since they bob up and down. This technique is also called bob de-interlacing for this reason. Line doublers retain all vertical and temporal resolution at the expense of bobbing artifacts on stationary and slower moving objects.

[LoRd_MuldeR]

Have a look here:
http://upload.wikimedia.org/wikipedia/de/1/1e/Interlaced_Animation.gif

[Guest]

A dumb bobber will lose vertical resolution in static picture areas. A smart bobber will do its best to retain it.

(For a purely static areas, you can weave the fields and have full resolution. For non-static areas, weaving produces combing.)

[Kwinz]

Ok, I give up. You are the gurus.

Still have a look at http://www.100fps.com/why_bobbing.htm
It clearly states "As you can see below the former fields (and now frames) have half the height.". Look at the picture.
This is bugging me. Maybe you are referring to a bobed video after a debobing filter??

[LoRd_MuldeR]

If you have an interlaced frame at 720x576, it actually consists of two fields (Top and Bottom field).
You can separate those by separating the even lines from the odd lines. So you'll get two fields at 720x288 from each input frame.
Now you can can throw away half of the fields and extend the remaining fields to full frames. This way you keep the framerate, but you loose half of the temporal resolution.
In contrast Bobbing will extend all fields to full frames, so the framerate is doubled (compared to the input). This way you won't loose any temporal resolution, motion still runs fluid.
There are more sophisticated deinterlace methods of course, but basically that's it...

[Guest]

As I said, in static areas, you can weave to get full vertical resolution because both fields have the same picture. For non-static areas, you can't do it because the fields contain different pictures. So naive bobbing of static scenes or picture areas does indeed discard vertical resolution in the output frames.

[Kwinz]

@ LoRd_MuldeR Ok. I agree with you. The moste accurate description would be:
"A bobing filter results in half of the vertical resolution in a single frame."

A dumb bobber will lose vertical resolution in static picture areas. A smart bobber will do its best to retain it.

(For a purely static areas, you can weave the fields and have full resolution. For non-static areas, weaving produces combing.)

Ok, but then you are using a false term. You can't call a more sophisticated combination of filters bob. According to http://www.100fps.com a combination of Bob+Weave is called "Progressive Scan".

[LoRd_MuldeR]

"A bobing filter results in half of the vertical resolution in a single frame."

Well, that statement is correct if "resolution" means "visual information" and if you refer to a dumb bobber.
It would not be correct if "resolution" means "number of pixels/lines", because each frame produced by the bobber will have the full number of lines.
The question is: How have the missing lines been restored? Simple interpolation? Motion compensation? And so on...

Still the most important fact is: In contrast to other deinterlacing methods, bobbing will double the number frames (double the framerate).
And that's why bobbing before encoding might be a bad idea, unless you don't care about bitrate...

[Kwinz]

Well, that statement is correct if "resolution" means "visual information" and if you refer to a dumb bobber.
It would not be correct if "resolution" means "number of pixels/lines", because each frame produced by the bobber will have the full number of lines.
The question is: How have the missing lines been restored? Simple interpolation? Motion compensation? And so on...

You are right. You could simply resize by half though, store anamorphic and stretch to the right size just like I do with DVDs all the time.
Soooo to get back to origninal statement that brought us off topic: There is no, or not much overhead due to bobing before the encoding, compared to bobing after the encoding because "reduced inforation per frame compensates the doubled number of frames". :D

[LoRd_MuldeR]

"reduced inforation per frame compensates the doubled number of frames". :D

That would be right, if you assume the "perfect" encoder ;)
In reality doubling the number of frames will nearly double the filesize/bitrate (assuming you still want to achieve the same quality).

[GodofaGap]

Ok, but then you are using a false term. You can't call a more sophisticated combination of filters bob. According to http://www.100fps.com a combination of Bob+Weave is called "Progressive Scan".
It's not a false term. A distinction is usually made between dumb bobbers (always interpolating) and smart bobbers (motion adaptive). 100fps does not have the final say in this. :p

"reduced inforation per frame compensates the doubled number of frames".
But there is no 1:1 reduction of information with smart bobbers (like yadif!). In non-moving areas information is retained.

[LoRd_MuldeR]

"reduced inforation per frame compensates the doubled number of frames". :DBut there is no 1:1 reduction of information with smart bobbers (like yadif!). In non-moving areas information is retained.

Well, an easy test can be done to decide this:

First encode you interlaced source "as-is" using x264 with "--interlaced" and a certain CRF value (e.g. --crf=22).
Then bob your source (e.g. using Yadif in Bob mode) and encode it again with the same CRF value, but without "--interlaced".

Compare the resulting filesize...

[LoRd_MuldeR]

Here we go:

File: Size:
test.interlaced.crf22.avi 64.367.974
test.yadif_bob.crf22.avi 93.829.608

So the bobbed encode is ~150% in size, compared to the interlaced one. This means roughly 50% overhead!

[Kwinz]

Thanks for testing. Very interesting. :)

[Jay Bee]

Modern GPUs are very good at deinterlacing so I would advise to try encoding as interlaced if you're worried about the extra file size of a good pre encode 50 fps deinterlacer.

That said, last time I tried interlaced x264 I didn't get very good results but maybe it has improved since then.

Another alternative would be to yadif 50 fps deinterlace and then downscale to a lower resolution to save file size. Similar to how sports broadcasts are sometimes converted from 1080i25 to 720p50.

Deinterlacing to 25 fps should not be an option for sports, it's unwatchable IMO.

[Kwinz]

I'd like to do a test with different settings and add plain Avisynth Bob() for comparison, but I don't know which BicubicResize values I should use.
Can somebody help me with the API? Basicly I want to set the height to the half like I described earlier. :thanks:

[1]: http://avisynth.org/oldwiki/index.php?page=Bob

[Inventive Software]

Just do Bob(), don't bother tweaking the values unless you know what you're doing. ;)

[Guest]

Well, an easy test can be done to decide this There's no need to test it because theoretical considerations are conclusive. And your test involves other factors.

Smart bobbing a static scene (i.e., weaving it instead of interpolating the "missing" lines) gives twice the resolution as dumb bobbing. For static scenes, the exact missing lines are present in the other field. To deny that would show only that you don't understand what is happening.

[Kwinz]

I just independently reconsidered that this is not proving anything. CFR tries to retain constant quality of what it gets from AviSynth and not from the original file. This renders the following test useless but anyhow here are my test results with 4000 frames of soccer:


Bytes
66.693.407 ORF-soccer.crf22.interlaced.fast.mp4
73.303.177 ORF-soccer.crf22.interlaced.insane.mp4
64.340.448 ORF-soccer.crf22.yadif.fast.mp4
69.972.386 ORF-soccer.crf22.yadif.insane.mp4
62.742.354 ORF-soccer.crf22.yadif_bob.fast.mp4
65.665.614 ORF-soccer.crf22.yadif_bob.insane.mp4
49.390.078 ORF-soccer.crf22.plain_bob.fast.mp4
52.799.917 ORF-soccer.crf22.plain_bob.insane.mp4
20.630.580 ORF-soccer.crf22.plain_bob.HR.fast.mp4
23.503.381 ORF-soccer.crf22.plain_bob.HR.insane.mp4


Why are the insane encoded files larger? Maybe my MeGui profiles are messed up.

[Dark Shikari]

Why are the insane encoded files larger?Because better encoding settings improve quality relative to bitrate; so they could very well increase bitrate and increase quality.

There's no guarantee that an interlaced video will look "just as good" as a deinterlaced version (or vice versa) just because they're encoded with the same CRF.

And lower filesize after encode is not necessarily a good thing; yadif bob gives higher filesize than plain bob because it retains more detail, most likely.

[Atak_Snajpera]

yadif bob gives higher filesize than plain bob because it retains more detail, most likely.
AMEN! The same rule applies if you use LanczosResize instead of BilinearResize

[LoRd_MuldeR]

There's no need to test it because theoretical considerations are conclusive. And your test involves other factors.
Well, theoretical considerations are one thing. But in the end you need some results for a "real life" encode, not some theoretical one.
Of course a lot of factors will impact the test, but those factors will effect my "real" encode as well. And of course one single test isn't enough, it only gives a first hint.

Smart bobbing a static scene (i.e., weaving it instead of interpolating the "missing" lines) gives twice the resolution as dumb bobbing.
Yes, smart bobbing will give twice the resolution in static scenes (compared to dumb bobbing), if "resolution" refers to "information" or "detail". 100% agreed.
But if "resolution" simply refers to "number of lines" (or "number of pixels"), both types of bobbing will give exactly the same resolution, as both produce "full size" frames.

For static scenes, the exact missing lines are present in the other field. To deny that would show only that you don't understand what is happening.
I'd never deny that ;)

[Kwinz]

But if "resolution" simply refers to "number of lines" (or "number of pixels"), both types of bobbing will give exactly the same resolution, as both produce "full size" frames.


That is not nessesarly true with the Avisynth function as you can define a height parameter (see url [1] in my previous post).

[LoRd_MuldeR]

That is not nessesarly true with the Avisynth function as you can define a height parameter (see url [1] in my previous post).
That parameter is not specific to a "dumb" or a "smart" bobber. I think it could be implemented for both kinds.
Also I was referring to the default behavior. And all bobbers I have used so far produce "full size" frames by default.

Bobbing to half vertical size and encoding it anamorphic sounds like feasible solution though.
At least if you don't want to spend the bitrate/diskspace for a "full size" smart bobbed encode...

[Guest]

But if "resolution" simply refers to "number of lines" (or "number of pixels"), both types of bobbing will give exactly the same resolution, as both produce "full size" frames. Obviously we are referring to detail! Using this interpretation would be trite.

As I said, smart bobbing of static areas retains all available vertical detail (resolution), while dumb bobbing loses vertical detail (resolution).

With the former, you could resolve a vertical spatial frequency of 2 present in the original scene. With the latter you could not. Your resolving power (resolution) has diminished.

Well, theoretical considerations are one thing. But in the end you need some results for a "real life" encode, not some theoretical one. No you don't. Why do you think that the theoretical demonstration above is not adequate? Do you think that some magic is going to restore the detail lost by dumb bobbing in static areas?

If I show theoretically that Pythagoras's theorem is correct, would you demand empirical proof?

[LoRd_MuldeR]

No you don't. Why do you think that the theoretical demonstration above is not adequate?
Because this discussion is all about whether it's better (more efficient) to do the bobbing before or after the encoding. So the result has to be judged after encoding (at playback), obviously. And that's hard to do without any "real" encoding tests. Or do you want to tell me that you can predict x264's output size and/or quality for different inputs only with your "theoretical considerations", while even the developers aren't too sure about it's interlaced encoding efficiency? ^^

BTW: I still totally agree to what you said about "dumb" and "smart" bobbers. And I never did not.

[Guest]

In this post:

http://forum.doom9.org/showthread.php?p=1150276#post1150276

...in response to:

But there is no 1:1 reduction of information with smart bobbers (like yadif!). In non-moving areas information is retained.

...you said:

Well, an easy test can be done to decide this

...which belies your claim above.

[akupenguin]

Well, an easy test can be done to decide this:
First encode you interlaced source "as-is" using x264 with "--interlaced" and a certain CRF value (e.g. --crf=22).
Then bob your source (e.g. using Yadif in Bob mode) and encode it again with the same CRF value, but without "--interlaced".
Equal CRF was never intended to mean equal quality precisely enough to just compare bitrate. Especially if the videos are different framerate. And especially if one of them is interlaced, since interlacing changes the apparent frame complexity that CRF uses to decide bit allocation.

No, the correct test is:
Encode 2pass interlaced, then bob it at display time.
Encode 2pass bobbed, and display it directly.
See which one looks better.

[LoRd_MuldeR]

@neuron2:
This is only half of the truth. I was also (and mainly) responding to:

"reduced information per frame compensates the doubled number of frames". :D

And that's really all the test was intended to confirm or confute ;)


@akupenguin:
Thanks for clearing that up.

I know that CRF can very well increase both, bitrate and quality. So even if the file became larger, the "quality relative to bitrate" could be better.
Nevertheless I think 50% increase in size would require some significant quality improvement to be worth it...

[akupenguin]

Nevertheless I think 50% increase in size would require some significant quality improvement to be worth it...
CRF ignores interlacing. What if it just sees your combed frame, says "that's complex, allocate it a high QP", and then the real encode deals with it reasonably efficiently and ends up at 2/3 the bitrate?
IOW, I have no a priori reason to expect that the encode with 1.5x the bitrate doesn't have 1.5x the quality.

(Ok, we blend-deinterlace before CRF analysis, so it doesn't actually see the combs. But blend does reduce the effectiveness of motion compensation by a lot, and CRF cares about motion compensated residual.)

[LoRd_MuldeR]

CRF ignores interlacing. What if it just sees your combed frame, says "that's complex, allocate it a high QP", and then the real encode deals with it reasonably efficiently and ends up at 2/3 the bitrate?

I guess that would pretty much destroy any useful comparison :eek:

Okay...

[foxyshadis]

I like the fluidity of bob, but I think the hardware accelerated DXvA motion compensation thing I use at playback performes pretty good without the disadvantages of bob.

I'll reiterate Jay Bee's suggestion that you encode interlaced and point out something that might have cleared up the confusion earlier: the "hardware accelerated DXvA motion compensation thing I use at playback" is a smart bob. ;)