x264 development

[gotaserena]

Ok, I did some encodes in windows (using celtic_druid's builds, based on r59 I believe).

The problem does not show in pass=1, decoding with libavcodec.

The problem does show in pass=2, decoding with libavcodec.

I thought it would be a simple thing to decode the output using Moonlight's H.264 decoder, but alas no luck, no matter what container I used. Funnily mp4creator refused to put the stream into mp4.

To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

[RadicalEd]

Originally posted by gotaserena
To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

That's just ffdshow's vfw part.

[gotaserena]

So, is quartz.dll some sort of DShow wrapper for vfw codecs?

[akupenguin]

Originally posted by gotaserena
The problem does not show in pass=1, decoding with libavcodec.
The problem does show in pass=2, decoding with libavcodec. Are you sure that's not just a question of quantizer? Try a first pass with different qp_constants.

[gotaserena]

Yes that seems a problem of quantising...
@q=22 there's no problem
@q=25 it begins to show and gets worse as q raises.

This is surely consistent with your point that these are regions the codec chooses not to change from one frame to the other. As q increases, so does the region in the approximation taken.

I compiled the reference codec from the link you posted elsewhere but I must admit my knowledge on how to deal with raw yuv files is wanting. If I could play the stream I could tell for sure if this is the decoder's fault.

[gotaserena]

Ok, here's what I did to avoid (unsucessfully) using libavcodec -- in windows -- during this game.

- Open the MPEG2 source in VirtualDubMod, resized to 512x384 using the built-in Lanczos filter and saved in huffyuv. Now since in all probability vdm uses libavcodec to decode mpeg2 I was left with little choice than just open the resulting video to see whether the problem showed up. It did not. By the way ffplay ran the huffyuv file without any black boxes either.

- mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-q30.avi -ovc x264 -x264encopts pass=1:qp_constant=30:nofullinter:cabac:keyint=250:psnr:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-hfyu.avi
Here's another point where I depend on libavcodec, but since ffplay did not show any black boxes, I went on and trusted that this step did not screw things up.

- Resulting file shows boxes on frames 40, 111 and 173 when played using a libavcodec decoder.

- avi2raw60 segment-q30.avi segment-q30.264 (avi2raw60 from mpeg4ip (http://mpeg4ip.sourceforge.net/))

- Compiled the source from http://iphome.hhi.de/suehring/tml/download/ and decoded the file segment-q30.264 using ldecod.exe. The input parameters for the decoder where kept on default.

- Converted from YUV 4:2:0 to RGB24 using this (http://www.ee.surrey.ac.uk/Personal/S.Worrall/dloads/yuv2avi_p2.zip) utility. The program wraps the resulting stream in avi so I can open it using virtualdub.

- The final file shows boxes on frames 40, 111 and 173.

[RadicalEd]

IIRC VDM uses libmpeg2.

[akupenguin]

OK, I enabled the debug output of decoded frames, and x264 itself displays the blocks. New hypothesis: the skip decision algorithm is too lenient at high quants. (I already know it's too strict at low quants.)

edit: yep, that's it.
Conditions for the bug: If the current area of the picture is flat (no gradient or detail), and the motion vector predicted from the neighboring blocks points to a flat region of another color (in this case black), and the inter DC quantizer brings that difference down to 1 unit, then the block will be erroneously skipped.
Now, how to fix it without killing the whole pskip decision? I might need more psychovisuals than just the current hadamard + weighted coeffs.
Eventually I'll implement a rate/distortion optimal skip decision, but there must be some fast way, too.

[pogo stick]

Maybe it's too early for this and there are some other more important stuff that can be improved and implemented, but I just thought about this feature. Will it be hard to do in encoder? Is it similar to MPEG-4 video - PAR in bitstream? And I wonder if FFDShow already capable of auto-resizing anamorphic H.264 video?

[gotaserena]

My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

[akupenguin]

Fixed.
x264 already supported PAR, but MEncoder didn't set that parameter.

[giandrea]

Originally posted by gotaserena
My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

Hi gotaserena! How do you mux h.264 video into MP4? Do you use the latest mpeg4creator from CVS? I tryed to compile it, but it failed under MacOS X, I will try again soon anyway.

[pogo stick]

Look here (http://forum.doom9.org/showthread.php?threadid=84456).

[giandrea]

Talking about quality, from a test that I've done recently, x264 at fixed quantizer=19 and 1Mbps scored an average psnr of 52.75, while xvid scored an average psnr of 52 at 2.3 Mbps for the same clip. Is it possible for x264 to be so much superior to xvid in the early developement stage it is in now? Or I made some mistake and x264 hasn't got that high psnr?
thanks,

giandrea

[Mug Funky]

either:

a) x264 is really kicking a$$
b) you scored some choice x264 settings
c) you broke xvid's settings :)

hehe... maybe it's all 3. but x264 is looking very promising, at any rate. i get the impression that right now it's not even close to what it could finish up as. that fills me with optimism, as it's already awesome.

[snacky]

Just guessing, but I'll vote for:

d) neither encoder achieved the requested bitrate, so the comparison turns out to be invalid ;)

There are certain sequences that may be encoded at low cost with h.264, but are "pathological" for mpeg4 asp. I've been known to perseverate on certain types of rapid flashing sequences, where you can get nearly arbitrary (e.g., 1/100th the bitrate) improvements with h.264 as compared to mpeg4 asp.

But in my experience, you're very lucky to see x264 get more than a 25-30% bitrate improvement over xvid or lavc, and the more typical case is only a marginal improvement.

[Tommy Carrot]

In my experience x264 has big advantage at low bitrates, where the image of xvid tends to fall apart, while x264 remains solid. But at higher bitrates, the advantage is not clear, or there are cases where x264 is even inferior to xvid. This can be attributed to inloop-filtering imo, which can smooth away the finer details even at higher bitrates, thus making the video looking "flat". Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile.

[akupenguin]

Originally posted by Tommy Carrot
Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile. Hopefully that will be addressed by H.264 high profile, which allows a transform more like ASP's DCT. No word on when I'll have time to implement it, though.

[virus]

Hi,

seeing that the commandline encoder seems to have been updated recently, I decided to give it a shot. So I fed it with the simple cmdline:
x264 -o test.h264 foreman.yuv 352x288


and ended up with something like this in the output (I've replaced the ridiculously long overflowed numbers with the short "huge value" text...):

...
x264 [info]: analyse=76(2760ms) encode=0(10ms) write=380(0ms) filter=10(370ms)
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y: (huge value)
U: (huge value) V: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2372 PSNR Mean Y:-0.00
U: 0.00 V: 0.00 Avg: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice I Avg I4x4:319 I16x16:0
...

Houston we have a problem :)

Also, I'd like to know if there's a way to retain the "x264 [info]" output without the lengthy per-frame info labelled "x264 [debug]"; the option "--quiet" removes almost everything from the output. I don't see a "log level" option in the encoder (but I think there was one available in x264, or not?).

virus

[akupenguin]

I reduced default verbosity to [info], and added a -v to put to back to [debug].

The messed up stats are probably a failure to recompile something after updating. I've never got annoyed enough at make to track down the problem, since jam works.

[virus]

hey, that was quick :)

Thanks. As for the messed up stats, yeah, sometimes things gets screwed due to missing dependencies in the makefile, but not this time it seems: I've checked out a completely fresh copy of revision 81 and compiled it: the error is still present.

[akupenguin]

Works For Me (tm).

[virus]

No problem, I've already tracked the issue... this is the Week Of Programs That Break On My Machine Only. :D

It's the usual incompatibility introduced by Micro$oft in their msvcrt.dll implementation. Instead of using the ISO standard "%lld" prefix for 64-bit integers, they use their own "%I64"-based format. I use MinGW and it of course is forced to behave the same way to produce code that work on M$'s runtime libraries.

So, I changed line 1354 of /encoder/encoder.c to:
"slice %s:%-4d Avg QP:%5.2f Avg size:%-5I64u PSNR Mean Y:%5.2f U:%5.2f V:%5.2f Avg:%5.2f
Global:%5.2f MSE*Size:%5.3f\n",

Note the change in the "Avg size" field. Now the output looks OK, unless you're able to identify further problems that I currently don't see:
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y:41.08 U:44.10 V:46.82
Avg:42.08 Global:42.08 MSE*Size:0.844
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2680 PSNR Mean Y:37.78 U:41.72 V:44.64
Avg:38.93 Global:38.91 MSE*Size:0.345

I'm not sure what kind of defined symbol we need to test to fork between the 2 versions of the code, though. Any idea?

virus

[akupenguin]

Interesting. I see several cases of %lld in MPlayer, and the official win32 builds use MinGW, and I haven't heard of this issue from there...

If this really is the problem, the easiest fix is to cast most of them back to int and use "%.0f" for the rest.

[virus]

Well, it's quite possible that newer versions of Windows come with a more decent version of msvcrt.dll that supports the ISO format strings... but I have Win98SE here, and I guess nobody tests against it. You should just see the spectacular bluescreens that Videolan produces here when you try to play something ;)

Anyway, this is the note I have in /MinGW/include/inttypes.h:

/* 7.8.1 Macros for format specifiers
*
* MS runtime does not yet understand C9x standard "ll"
* length specifier. It appears to treat "ll" as "l".
* The non-standard I64 length specifier causes warning in GCC,
* but understood by MS runtime functions.
*/

It's MinGW 3.1.0, not exactly the very latest version but still a recent one.

virus

[virus]

Yet another boring feature request :)

Can we have an alternative makefile added to the repository (named, say, "Makefile.nodebug" or "Makefile.release") without the -g option enabled in CFLAGS and with -s turned on? That gives much smaller filesizes for everything (up to 2.5x smaller)... it would be really handy imho.

virus

[Yong]

1. 4x4 B frame search will be possible in the future?
2. How many options will be available in the complete of x264 encoder?
3. It is possible adding adaptive quantization to x264 encoder?

(sorry for my crappy english and stupid questions):p
Thanks for the replies.:)
too bad, seems noone could answer my questions:devil:

[IgorC]

How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to bitstream?

[bond]

Originally posted by IgorC
How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to beatstream? http://forum.doom9.org/showthread.php?s=&threadid=86870

[Sergejack]

Is x264 limited when used in avi container ?

What are the best free and not free containers to use with x264 ?

[bond]

Originally posted by Sergejack
Is x264 limited when used in avi container ?depends
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames
b-frames is the only avc technology used till now in x264 causing problems with avi and vfw

apart from that .avi will limit the possible audio/subtitle formats

What are the best free and not free containers to use with x264 ?there is no best, it all depends on what you want to do
but i think x264 is atm already usable in .avi, .mkv, .ogm and .mp4, all of which are free (meaning licensefree and free tools are available for creation and playback)

[len0x]

Originally posted by bond
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames


This is worrying. Is there a detail explanation of why and when frames are lost?

[bond]

Originally posted by len0x
This is worrying. Is there a detail explanation of why and when frames are lost? its not really a problem (who cares about 2 of 200000 frames in a movie?)
its just the same old problem that vfw is simply not able to handle b-frames. there are workarounds for this for divx5 and xvid (but for not other codec) in virtualdub(mod) (but in no other vfw based encoding tool), its just that these workarounds are not that easily applyable for x264

also to show the importance of this problem: note that till the last update virtualdub 1.6 was buggy and didnt apply the b-frames fix when encoding with xvid and divx5 for some months, but noone realized it ;)

[Sergejack]

I'm soewhat totally confused.

If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?

[bond]

Originally posted by Sergejack
If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?the frames are lost "forever" if you use both together:
- sex264 in virtualdub(mod)
- b-frames

if you encode in mencoder with x264 the frames are not lost

[len0x]

Originally posted by bond
its not really a problem (who cares about 2 of 200000 frames in a movie?)


ah, you never said it was just two frames :)

[bond]

Originally posted by len0x
ah, you never said it was just two frames :) well i wrote "2 out of 200000" ;)

actually it depends on how many b-frames you use:
with 1 b-frame in a row you loose 1 frame, with 2 b-frames in a row you loose 2, aso...

[len0x]

Has anyone noticed this: when opening x264 encode (in AVI) in VDubMod via DirectShowSource and scrolling frame-by frame through it - every 5-10 frames you get out of order frame (i.e. a frame that was 2-3 frames back already) then it resumes normally (but frame that was supposed to be instead of dupe is lost though). However normal playback doesn't seem to have this issue.

p.s. ffdshow was used for decoding.

[Bogalvator]

What date is your ffdshow? Try again with the latest celtic_druid compile as it may have been an issue that has been fixed ;)

[len0x]

Indeed, I tried the build from 17th of Jan and its seems ok.

@bond

I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame).

[bond]

Originally posted by len0x
I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame)during playback you will not see it
also virtualdub will show the correct framenumber, thats because the missing frames are "zero length frames", frames that are marked like frames in .avi, but actually dont exist :D

if you extract the stream from .avi with mpeg4ips avi2raw you will see that it will report 1 zero length frame
also when you analyse the stream with mplayers analysing function you will see the same result

[Sergejack]

A question about the variability parameter :

Is it the variability of the bitrate ? In wich case set it to 100% should be a good thing assuming the RDO function is properly done.

Or is it variability of PSNR (or wathever metric measure the quality) ? In wich case, what should be tough of when setting this parameter ?

[akupenguin]

100% variability is equivalent to constant quantizer. 0% variability is CBR.
There are two factors stopping 100% from being the optimal setting: The human visual system (or at least mine) is less sensitive to errors in high-motion scenes. And the quality of one frame influences the quality of the following frames predicted from it. Neither of those can be determined by any normal RDO algorithm. I have found the PSNR-optimal setting to be around 70%, and the psy-optimal setting to be around 60%. But neither of those have been tested on enough full length movies to be really certain, so YMMV.

[len0x]

Question: how can IDR settings affect compressibility result when using snips of original source? Usually we have 14-frame snips so every 14 frames for XviD/DivX its guaranteed to be an I-frame (that was usually discarded from calcualtions along with last frame of the snip). Now I see that min IDR-keyframe interval is 25. Does this mean that you should no longer discard start/end frame of the snip or discard even more or change snip size to at least 25 to make sure I-frames are inserted only at the beginning of a snip?

Is this also dependent on max frames reference parameter?

[akupenguin]

What are "snips"?
What calculations are you discarding I-frames from, and why?

Note that min keyint does not prevent I-frames from occurring wherever they are appropriate, and increasing min keyint will never reduce compression, only seeking precision. (as long as there's plenty of space between min and max.)
Currently, min keyint only helps with multiple reference frames.

[Manao]

When computing the compressibility, GK uses an avisynth script, selecting 15 consecutive frames every 300 frames. Hence a tendency to put I frames every 15 frames, which makes them overnumerous, so their size must not be taken into account for the compressibility value.

[akupenguin]

For that purpose, you don't need to adjust snip size or calculations, and it doesn't matter what you set min keyint to. min keyint = 14 might be slightly faster.

[len0x]

Actaully everything matters. Let me explain: for compressibility test there are good frames (that contribute to more precise result) and bad frames (that contribute to less precise result). Basically the diffence is how close size of the frame during comp test to what would have been during actual encode. That's why I-frames in the beginning of snip are bad, because they are artificial (i.e. they would usually not be present in the actual encode).

Now, you were saying that min keyframe interval doesn't affect comp test. I was thinking that indeed keyframes are not inserted much more often than usual (if you have much lower snip size than min keyframe distance), however since every non I frame is a difference frame and snips are taken from different parts of the movie then there is bound to be a huge difference between last frame of one snip and first frame of next snip. Situation complicates even more if you have multiple reference frames (if I'm not mistaken ASP only can have one while AVC can have several, right?), because then not only first, but may be more starting frames will be dependent on frames from previous snip (situation that we try to avoid since it won't happen in the actual encode).

So in the end the most logical step would be to have snip_size=min_keyframe_diff. This will ensure that first frame of each snip will most probably be a keyframe, which you can ignore during calculations. I've done some tests and indeed it works! However the most presize result I get is when I don't discard any frames from the snip... (but this may be just a coincidence and source dependent).

P.S. this was all done without trying to use b-frames. It will get really crazy later on when they are taking into account :)

[akupenguin]

First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.
(The reason I don't just make all I-frames into keyframes is that in a full encode, the frames after a scenecut are not necessarily unrelated to the previous frames: if it cuts and then cuts back to the first scene, you save some bits by putting only non-key I-frames inbetween.)

It is true that you won't see the full benefit of multiple references on the first few frames of a snip, but even with lots of references it's probably not worthwhile to discard more than the first 2 P-frames.

Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).

With those points in mind, a snip size bigger than 15 is probably useful. But I can't suggest a new size without lots of tests. Personally, I just use 3-pass encoding, and then I know that the first pass is accurate, and get slightly better ratecontrol too. But I understand that some people are more interested in speed.

[len0x]

Originally posted by akupenguin
First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.


Thanks, good to know! Now I understand why it is imperative to make comp test with the snip size that equals min keyframe distance(and may be actual I-frames do not matter that much as all my tests so far were more precise when i didn't discard anything)

Originally posted by akupenguin
Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).


For XviD it was found to be better to discard first three and last three frames of a snip. I'll test that against x264 later on.

Originally posted by akupenguin
With those points in mind, a snip size bigger than 15 is probably useful.

Well, statistically the smaller the snip the better accuracy is, because snips cover the whole movie range more smoothly. But yes lots of tests are to be done... So far I found snip=14 without discarding any frames the most presize option when not using b-frames (and yes setting min keyframe interval 14 as well).