Log in

View Full Version : odd compression results with deinterlacing


njustn
27th October 2006, 13:17
I've been working on a script to automate handling of episodic content and I'm getting very interesting results with the compression. I'm using x264 cli on linux and mplayer or transcode to create the raw y4m.

At first I was only using mplayer, but i've been trying to port it to work on both linux and osx, which meant make mencoder unnecessary, and I noticed that using transcode piped into x264 was creating files a third again as large and the command i was using was designed to be identical to the mencoder command.

mencoder -nosound -aspect 4:3 -of rawvideo -ovc x264 -vf yadif -x264encopts crf=23:trellis=1:frameref=3:bframes=5:b_adapt:b_pyramid:weight_b:mixed_refs:4x4mv:subq=6:threads=4 -ofps 29.970 -o mencoder.264 ./vob/*.vob

mkfifo video.fifo.y4m
transcode -i ./vob/ -o video.fifo.y4m -x vob -y yuv4mpeg,null
x264 --crf 23 --trellis 1 --ref 3 --bframes 5 --b-pyramid --weightb --mixed-refs --analyse all --8x8dct --threads 4 --fps 29.970 -o x264-cli.264 video.fifo.y4m 720x480

with these two commands, given the same ~140 second chunk of video (anime content in case it might matter), i got the following results

mencoder.264 15M
x264-cli.264 20M

As one might expect, this left me mightily confused, i opened both results in vim to read the options, and the only differences were in analyse, 8x8dct (causes mencoder to crash for some reason) and deadzone. So, I continued testing trying to get things in sync, but nothing would close the gap, so finally i tried the following mencoder line to see what would happen.

mencoder -nosound -aspect 4:3 -of rawvideo -ovc x264 -x264encopts crf=23:trellis=1:frameref=3:bframes=5:b_adapt:b_pyramid:weight_b:mixed_refs:4x4mv:subq=6:threads=4 -ofps 29.970 -o mencoder2.264 ./vob/*.vob

mencoder2.264 20M

note that the only difference is the removal of the yadif deinterlacing filter. At that point I assumed perhaps there was a problem in the compression for interlaced content, and so tried transcode with the tomsmocomp deinterlacer as in the following.


mkfifo video.fifo.y4m
transcode -j tomsmocomp -i ./vob/ -o video.fifo.y4m -x vob -y yuv4mpeg,null
x264 --crf 23 --trellis 1 --ref 3 --bframes 5 --b-pyramid --weightb --mixed-refs --analyse all --8x8dct --threads 4 --fps 29.970 -o x264-cli2.264 video.fifo.y4m 720x480

x264-cli2.264 20M

So, at this point I'm wondering if there's some variable I have failed to consider, or if yadif has some kind of particular worth as a pre-encode filter for x264, has anyone had similar experiences?

The raw chunk used in these tests is 137M in vob form, if anyone is sufficiently interested i can post the chunk, but i imagine the results will hold at least for any given animated content. Please tell me what your thoughts are because I am still... perplexed.

Also, if anybody is aware of another script or program designed to handle episodic content i would like to know of it (automatically batch encoding along episode boundaries and so forth and so on), and on a side note, can anyone recommend a custom matrix for mid-quality animated content?

akupenguin
27th October 2006, 18:45
Why can't you use mencoder on macosx?
You're compressing interlaced content without --interlaced, and wondering why it takes more bitrate than deinterlaced content? duh. (Well, it'll still take more bitrate even if you do use interlaced encoding mode.)

And just as a general statement: you can't measure the utility of a preprocessing filter just based on how much it reduces the bitrate at a given qp. Because reducing the bitrate means it threw out some information before the codec even saw it. Maybe it threw out irrelevant information (noise), or maybe it threw out real information. You have to look at the compressed file (after adjusting the crf values so that both versions are the same bitrate) and see which one looks better.

njustn
27th October 2006, 18:56
while it is possible, i'm attempting to limit the number of dependencies in the script, and i need transcode for several things whereas mencoder was only being used for the video encoding

:o LOL, indeed so, can't believe i missed that, i do still wonder why i got such drastically different results with different deinterlacers, but it's probably a flaw in my testing method, thanks alot

also, as to the preprocessing filter, i agree with you that in general bitrate is not a good calculator, but what i will say in this case is I was originally using yadif because it provided by far the best deinterlacing of tools and options i had tested, both before and after x264 encoding and I mean in terms of quality it does not by itself change output size without recoding, some information must have been lost, or honestly my guess is that the way it deinterlaces had the effect of making motion more predictable frame to frame, though that's just an outsider's guess i suppose

i'm running some more tests today, but yesterday results showed that yadif actually gave both better quality, and size than the smartyuv or tomsmocomp deinterlacers from transcode, and much better than just leaving it interlaced, i'll try some with the --interlaced flag and see what the result is.

anyway, thanks again for the reply