x264 development

[kemuri-_9]

When kemuri9 finishes the range patch.

OK, so I wasn't really aware that I was blocking this from getting fixed <_<

[upyzl]

How about the Google Summer of Code MVC extensions? Me want some x264 3D! :)

Do you mean this (http://mewiki.project357.com/wiki/X264_Settings#frame-packing)?

[kemuri-_9]

Do you mean this (http://mewiki.project357.com/wiki/X264_Settings#frame-packing)?

he's talking about this (http://wiki.videolan.org/SoC_x264_2011#H.264.2FMVC)

[rallymax]

he's talking about this (http://wiki.videolan.org/SoC_x264_2011#H.264.2FMVC)

Sure am :)
It's my understanding that to pass 3D Blu-ray confomance you need AVC+MVC extensions: Not just the 3d frame packing that already exists and I want 3D Blu-ray asap.

If programming cycles are needed I'm willing to input time.
Does someone have the spec?

[nm]

How about the Google Summer of Code MVC extensions? Me want some x264 3D! :)

There seems to be some recent progress: https://github.com/gurunathan/SHP-MVC-x264/commits/master

Plus this separate work: http://forum.doom9.org/showthread.php?t=162651

[hydra3333]

Not sure where to look, advice would be appreciated. A google yields too many results, perusing them seems to indicate that this X264 commandline
x264.exe --demuxer ffms --thread-input --profile high --level 4.1 --preset fast --video-filter yadif:mode=0,order=tff/resize:width=720,height=576,sar=16:11,method=lanczos --no-interlaced --fps 25/1 --no-cabac --bitrate 2000 --sar 16:11 --colormatrix bt470bg -o "out.mp4" "inp.mpg" should deinterlace/downsize australian PAL mpeg2 1440x1080i50 "HD" to 720x576p25 SD mpeg4, but it gives error x264 [error]: invalid filter `yadif' This is the first time I've attempted deinterlacing/resizing from a commandline, for use on a WDTV-Live player.

The X264.exe is from my usual source http://x264.nl/

Thanks

[Atavarius]

I don't think the builds there are compiled with the yadif filter. Try JEEB's builds. (http://x264.fushizen.eu/)

[hydra3333]

Thanks, tried Jeeb's and did some tests.
It can be up to 30% faster to front-end X264.exe with avisynth 32 bit and DGdecode [the NV version] to do HD -> SD, than use the internal yadif filter mentioned above.
(it's also slightly faster to front-end X264.exe with avisynth 32 bit and DGdecode [the non-NV version, recently modified but available via hank's site])
So I'll stick with that :)

[DVD Logic]

Hi everybody,

we are developers of BD Muxer (EasyBD) and we have problems with B-pyramids in x264. If anybody have technical info please send us to support@dvd-logic.com

Thanks,
Valery Koval.

[Kurtnoise]

Please, explain with more details what are your issues...

[DVD Logic]

we can't mux x264 with B-pyramids as receive errors in time calculation. This becouse we do not have any info about B-pyramids in our AVC specification. That is why I am asking about any technical info regarding B-pyramids.

[Kurtnoise]

http://forum.doom9.org/showthread.php?p=1352347#post1352347

[DVD Logic]

we can't mux x264 with B-pyramids as receive errors in time calculation. This becouse we do not have any info about B-pyramids in our AVC specification. That is why I am asking about any technical info regarding B-pyramids.

[nixo]

I'd suggest it would be easier to go to #x264dev@freenode and ask specific, technical questions.

--
Nikolaj

[laserfan]

we can't mux x264 with B-pyramids as receive errors in time calculation.If it makes you feel any better ;) Sony DVD Architect Pro has (or at least had, I don't know if they've fixed it) a similar problem with muxing BDs with x264's bpyramid option.

I've used it once in a while (at work) and have had to use --b-pyramid none when encoding with x264. Otherwise the muxed result somehow gets frames out-of-order.

[jpsdr]

Any news of the treillis patch for which the subme mode 11 has been made ? I'll soon have encodes to do, and i don't mind waiting a little if the patch is due more or less soon, but if it's not before 6 months, i may not wait until for doing my encodes.

[Dark Shikari]

The student didn't manage to finish the patch into a working state; after all, it was a pie-in-the-sky research project that had never really been done before. There is no ETA.

[jpsdr]

Ok, thanks for the answer, i'll not specialy wait for it.
But does it mean that it's dropped and never be finished, wich would be somehow a pity (hope i use good word to express what i want to say) or is there any hope this work/research leads to something ?

[redfordxx]

Hi, I have few questions x264 related.
1) Is there possible/recommended way of recovering the encoding process? Suppose encoding with very heavy filtering which takes very long and there will be some restart or crash of the OS (caused by other application) resulting in reboot again, during the encoding process. Then would be good to continue and not to start all over again..
2) When I have x264 encoded clip let's say quality 25 and then I encode it with higher quality or even lossless the bitrate is much higher. But to encode x264 file of certain bitrate losslessly should be perfectly feasible at the same bitrate, or am I wrong in this conclusion?
3) Would it be possible to do somehow some basic operations fast without reprocessing the full file. And losslessly again. For example I have x264 clip with black borders and I want to crop the borders. I think it would be very efficient if some tool can go through the file and to analyse borders crop them fix/reencode with havin the most of the frame untouched. Of course when the cropping is mod16 or some other relevant limitations.
Anyway don't consider these questions to be a sign of me being unhappy about x264. I like it very much and thanks to any contributor for this great stuff...

[sneaker_ger]

1) Is there possible/recommended way of recovering the encoding process? Suppose encoding with very heavy filtering which takes very long and there will be some restart or crash of the OS (caused by other application) resulting in reboot again, during the encoding process. Then would be good to continue and not to start all over again..

Only limited. I'm not aware on how to do such a thing in 2pass encodes. For CRF/single pass you could do it, but you have to make sure to cut off any unfinished GOP from the file first, note the number of frames successfully encoded and then start the new encode from that position with the --seek command. You can use mkvmerge for cutting and catting for example. If you search the forum you will find a few topics about this. (search also for "pausing"/"resuming", similar topic)

2) When I have x264 encoded clip let's say quality 25 and then I encode it with higher quality or even lossless the bitrate is much higher. But to encode x264 file of certain bitrate losslessly should be perfectly feasible at the same bitrate, or am I wrong in this conclusion?

The conclusion is wrong. The encoder does not have access to the compressed data itself, but gets fed with the decoded, totally uncompressed data from the source.

3) Would it be possible to do somehow some basic operations fast without reprocessing the full file. And losslessly again. For example I have x264 clip with black borders and I want to crop the borders. I think it would be very efficient if some tool can go through the file and to analyse borders crop them fix/reencode with havin the most of the frame untouched. Of course when the cropping is mod16 or some other relevant limitations.

No, that is not possible. (There is a small exception in which you can crop a maximum of 14 or 15 pixels from the right side and the bottom, though.)

[redfordxx]

Thank you for your answer.Only limited. I'm not aware on how to do such a thing in 2pass encodes. For CRF/single pass you could do it, but you have to make sure to cut off any unfinished GOP from the file first, note the number of frames successfully encoded and then start the new encode from that position with the --seek command. You can use mkvmerge for cutting and catting for example. If you search the forum you will find a few topics about this. (search also for "pausing"/"resuming", similar topic)


I'll try that, thank you...yes, I thought mkvmerge should be involved due to GOP...and yes I prefer qrf quality encoding, which seems to me better in focus on the resulting quality (and of course speed), because every source is different and bit/pix ratio won't answer it.
Which reminds me of another issue: I thought setting crf=xx will solve my problem of demanding same satisfactory "xx" quality for all sources. However, this was not the case, because some clips are nicely sharp and some blurry. I believe it depends on the amount of noise... but if I want to stay in one pass constant quality is still the best approach, isn't it?
The conclusion is wrong. The encoder does not have access to the compressed data itself, but gets fed with the decoded, totally uncompressed data from the source.OK, I hear you. But even if the uncompressed video is the source data, when it was highly compressed, there is nothing to encode, so what are the extra bits used for? Or is it the in-loop deblocking's fault and the deblock filter makes it "high detail and uncompressible" source again and the encoder doesn't know how to encode it with deblocking efficiently enough again.
No, that is not possible. (There is a small exception in which you can crop a maximum of 14 or 15 pixels from the right side and the bottom, though.)OK, maybe later, someone makes some tool for this;-) Same as higher compression of already compressed data (like throwing away some of higher frequencies and that's it). I know there are other things in play, like MoComp etc... OTOH it seems to me very unlikely that the encoder finds better motion vector than it is in source file while reencoding encoded source (not mentioning the speed of that).

I am sorry I am just throwing some ideas, maybe noone is interested in them. This is definitely not me quesioning how the encoding process works which is not my cup of tea.

[sneaker_ger]

Which reminds me of another issue: I thought setting crf=xx will solve my problem of demanding same satisfactory "xx" quality for all sources. However, this was not the case, because some clips are nicely sharp and some blurry. I believe it depends on the amount of noise... but if I want to stay in one pass constant quality is still the best approach, isn't it?

Yes, probably. As you've found out, CRF does not do a perfect job of keeping the quality constant. This is a shortcoming of x264 and not your fault. (And since quality is subjective, this problem hasn't even been solved in theory.)

OK, I hear you. But even if the uncompressed video is the source data, when it was highly compressed, there is nothing to encode, so what are the extra bits used for? Or is it the in-loop deblocking's fault and the deblock filter makes it "high detail and uncompressible" source again and the encoder doesn't know how to encode it with deblocking efficiently enough again.

It's true that a highly compressed source has lost many details and might therefore be easier to compress losslessy. Also the encoder gets the decoded output, not the input the original lossy compressor had.
But in the end: why reencode to a lossless format instead of just copying/keeping the lossy compressed data? You have nothing to gain.

OK, maybe later, someone makes some tool for this;-) Same as higher compression of already compressed data (like throwing away some of higher frequencies and that's it). I know there are other things in play, like MoComp etc... OTOH it seems to me very unlikely that the encoder finds better motion vector than it is in source file while reencoding encoded source (not mentioning the speed of that).

Doubtfully. You cannot just crop away the data, because the blocks depend on each other. And for black borders it does not really save bits, as they practically compress to zero.

[nm]

Which reminds me of another issue: I thought setting crf=xx will solve my problem of demanding same satisfactory "xx" quality for all sources. However, this was not the case, because some clips are nicely sharp and some blurry. I believe it depends on the amount of noise...

Yep, a noisy source easily becomes blurry when you encode at high CRF values (20 and above). However, similar blurryness should be visible in a clean source: edges may be sharp but fine texture gets smoothed out---unless the video is already smooth as plastic in the first place.

If you can't use a lower CRF (below 20, preferably) because of file size concerns, I'd suggest denoising with a decent motion-compensated filter and then using lower CRF. You'll end up with much nicer quality for noisy sources without wasting space on encoded noise.

Also, make sure you are using --tune film or similar settings when encoding noisy or finely textured videos.

[jpsdr]

Buffer underflow
Redoing an old encoding, i've again encounter a buffer underflow error while muxing with scenarist, on the exact same video i've got the problem around 1 - 2 years ago. I don't know if posts are on this thread or another. Issue at this time was indeed because it was not yet "discovered" that buffer shouldn't exced bitrate. Buffer/bitrate was 15000 this time. Re-encoding with buffer at 14950 solved issue, nevertheless, if it happened to me, it can happen to anyone else. I've encoded dozen of hours of video with the exact same parameters without issues, but, this specific scene seems to have triggered something.

[redfordxx]

If my imagination is correct, the quality parameter defines something like difference from the source. So unless we talk about very low crf, video with no noise gets washed, but video with tiny noise will be sharp, because the tiny noise is where the difference is and the detail which is little bigger than noise is perfect.

Once I was thinking how to achieve objectively same quality for different sources. Please tell me if is makes sense to you. (the other thing is that it requires extra encoding but let's leave that for now)

There are two things which are eating bitrate. Motion and detail.
So, what if we do following on some representative sample of the movie:
1) denoise it strongly or even blur
2) encode it at constant quantizer
this would result in certain bitrate/quality depending on how much motion is there, because detail is smeared away
3) then encode entire movie at constant bitrate/quality. The compression value would be obtained from the resulting bitrate/quality increased by choice.
in case of clean source it might be serious overkill, so the bitrate is spent on detail retention and nice gradients
in case of noisy source it might be not enough so some of the noise is removed by the quantization process

The resulting encoding might cut some quality from the noisy clip, so the noise is removed and favor little bit the clean source, so it is not washed out... so we end up with similar level of detail in the encoded clips.

[akupenguin]

If my imagination is correct, the quality parameter defines something like difference from the source. So unless we talk about very low crf, video with no noise gets washed, but video with tiny noise will be sharp, because the tiny noise is where the difference is and the detail which is little bigger than noise is perfect.

No. Adding a bunch of tiny noise coefs that get quantized to zero, doesn't affect the encoder's willingness to quantize the remaining large coefs. (With some caveats in psy-rd, but that doesn't do what you said either.)

[redfordxx]

OK, so...is it possible to explain what exactly means cfr with some simple formula. I thought it is something like sum of squared differences...

[LoRd_MuldeR]

Read here:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/ratecontrol.txt;h=e93ced2aa374a4a36fa1f34121358d943a28f6bc;hb=bcd41dbcaa4430b2118d9f6828c2b9635cf9d58d

Also read here:
http://x264dev.multimedia.cx/archives/98

[LigH]

Don't confuse CRF (Constant Rate Factor) with CFR (Constant Frame Rate). ;)

[ajp_anton]

In the header where x264 prints its settings, I have a question about the analyse setting.
It seems to add the values for each partition size:
p8x8 = 10, p4x4 = 20, b8x8 = 100, i8x8 = 2, i4x4 = 1
Why are the 8x8 and 4x4 swapped (for values 1 and 2) for p and i partitions?

[Emulgator]

Buffer underflow
Redoing an old encoding, i've again encounter a buffer underflow error while muxing with scenarist, on the exact same video i've got the problem around 1 - 2 years ago...Issue at this time was indeed because it was not yet "discovered" that buffer shouldn't exced bitrate. Buffer/bitrate was 15000 this time. Re-encoding with buffer at 14950 solved issue, nevertheless, if it happened to me, it can happen to anyone else....

I can confirm just the same finding on a 1280x720x50p Blu-ray-Mux using Sony DVD-A 5.2.
Main Movie: Buffer 24Mbps, Bitrate 25Mbps -ok.
Menu: Buffer 20, Bitrate 20Mbps -> Underflows.
Credits: Buffer 12, Bitrate 8 Mbps -> Underflows.

I guess the find is the same:
Buffer wants to be set a little less than bitrate.

[jpsdr]

For what i know, you must have buffer<=bitrate, so, for your credits, no surprise you have an error.
Nevertheless, it was a very specific and hard scene, where i've posted sample and others things, and problem on this scene have been discussed around 1-2 years ago here on forum. I've encoded dozen of hours of video with bitrate and buffer exactly at 15000 without problem, except for this very specific case.

[chompy]

When you say bitrate what do you mean? --bitrate or --vbv-maxrate? All my encodes have bitrate lower than buffer (but maxrate always bigger) and Scenarist has never complained.

[jpsdr]

Sorry, you're right, my post wasn't clear enough, or can be misunderstood. It's max bitrate>=buffer, so --vbv-maxrate.

[RunningSkittle]

vbv-maxrate is not max bitrate, it is max rate at which buffer should fill.
http://mewiki.project357.com/wiki/X264_Settings#vbv-maxrate

[jpsdr]

Ok, so it's : --vbv-maxrate >= --vbv-bufsize whatever vbv-maxrate truly is (even if it's apparently commonly considered as somehow the max bitrate).

[LigH]

The "Video Buffering Verifier" is a rather complex system which simulates the decoding in a hardware player already while authoring or even encoding material. It calculates how fast A/V media data can be read from the containing media (CD/DVD/Blu-ray disks) and allocates parts of a ring buffer, and how fast the decoding uses the buffered data and frees parts of the ring buffer after playing the decoded content.

If the encoded and stored bitrate (as the "sum" of video, audio, and subpicture data in a GOP) is too high, the drive is unable to read the disk and allocate the buffer fast enough for the decoder which misses some compressed media data that arrives too late – the result is a "Buffer Underrun". The "VBV maximum bitrate" is related to the disk drive speed and technology reading out the disk content and filling the buffer (I believe this is the typical 10.8 Mbps rate for "1x Speed" DVD drives specified in the DVD Video Specs, as one example).

If the encoded and stored bitrate is too low, the drive would read too much data from the disk, more than necessary to decode and play one GOP ... but that's a less serious issue, usually.

[Selur]

here is also an explanation try:
Normally it goes like this, you have a source (CD/DVD/BD/HDD/Network) that can deliver content with an average bitrate to the playback buffer or your device/player. --vbv-maxrate now specifies how fast the buffer can be filled (+ the source also need to be able to send stuff with this bitrate). So the device/player must at least be able to handle input with a data rate of --vbv-maxrate to support the input properly. Depending on --vbv-bufsize which specifies the size of the coded (!not decoded!) picture buffer the playback device is required to have and the relation between vbv-maxrate and vbv-bufsize this allows longer or shorter high bitrate scenes. So you never specifying a peak bitrate directly, but you specify only how large your buffer is an how fast it can be refilled. vbv-init specifies how full the buffer needs to be before playback shall start. (start playback when buffer if filled with 'vbv-init * vbv-bufsize' off data)
since this is still hard to imagine plyaing around with http://handbrake.dynaflashtech.net/cgi-bin/vbv_calculator.cgi might help to understand what vbv-maxrate&vbv-bufsize combinations imply which max peak bit rates are possible,...

Cu Selur

[Stereodude]

I just wanted to post and thank the x264 developers for their continued hard work. I recent upgraded from 2106 (x64) to 2164 (x64) and was shocked to see how much faster it is with the same command line options on my Windows 7 x64 box. I didn't do any real back to back benchmarking yet, but my off the cuff guess is that it's at least 50% faster just by comparing frame rates.

[Remicade]

50% ?????

[LoRd_MuldeR]

50% ?????

There was a significant CABAC/Trellis optimization for x64 committed recently.

That patch series alone may have a significant speed impact:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=748fe16c1303b89d2a1d0378addd83fb4198f51a

The speed improvement you'll see greatly depends on your individual settings, of course.

[Stereodude]

50% ?????I'm in the middle of my back to back benchmark of the same source with identical settings changing only the x264 version, so I can't give you an exact number yet. But, with 2106 I would typically see frame rates in the 3.5 to 4.5FPS range. With the two encodes I've done with 2164 I've seen frame rates of 5.74 and 5.99FPS. I will post back exact numbers when the 2nd pass is done with 2106.

[CruNcher]

Dont forget to run a lot of times to warm up the caches :) and never compare a new 1 st run after restarting also keep the new CPU architectures with their dynamic speed throttling stuff in mind (they get to hot they get slower) ;)

[Dark Shikari]

Or just post the standard error of your measurements instead of worrying about all the possible sources of error.

[Stereodude]

50% ?????Ok, so I was wrong. It's actually 75.15% faster.

Command lines:
x264.exe --bitrate 30440 --preset veryslow --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --b-adapt 2 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 --qpfile source.chp -o NUL source.AVS
x264.exe --bitrate 30440 --preset veryslow --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 --qpfile source.chp -o source.264 source.AVS

x264 64bit 8bit-depth R2106:
131591 frames, 3.42 fps, 30455.13 kb/s

x264 64bit 8bit-depth R2164:
131591 frames, 5.99 fps, 30456.06 kb/s

PC: i7-2600k @ 4.3gHz / 16GB DDR3 / Windows 7 SP1 x64

[mandarinka]

Oh, bluray profile/bitrate. I was wondering how could you gain so much :)

Turbocharging :)

[sneaker_ger]

Can one of the devs comment on this (http://forum.doom9.org/showthread.php?p=1565516#post1565516)? Is x264 creating the timing SEIs correctly?

[rallymax]

hi all. two questions
1: with "--crf" mode is it possible to overshoot the vbv-maxrate? I would assume not????
2: What "--tuning" should be used to best compress a MPEG2 1080p source that has artifacts because it's at 15Mbps? Is this the perfect time to use PSNR?
thx
Rallymax

[rallymax]

I recompiled x264 to take advantages of the new 64bit support but it crashes somewhere in the libav front end code.
Where should I post questions for libav?

[LoRd_MuldeR]

1: with "--crf" mode is it possible to overshoot the vbv-maxrate? I would assume not????

As you should know, vbv-maxrate is not the maximum bitrate, but the bitrate at which the VBV buffer is filled.

The VBV model ensures that the VBV buffer won't underflow. And that's it. Consequently there may be short bitrate spikes higher than vbv-maxrate, as long as the buffer doesn't underflow.

x264 will ensure VBV compliance, if both, vbv-maxrate and vbv-bufsize are set. If the VBV buffer ever underflows, x264 will print out a fat warning. This usually doesn't happen.

2: What "--tuning" should be used to best compress a MPEG2 1080p source that has artifacts because it's at 15Mbps? Is this the perfect time to use PSNR?

There is no tuning that can help against artifacts already present in your source. Actually there is no way to magically make these artifacts go away, except for a better source.

Using the "psnr" tuning is a bad idea, except when you want to optimize for maximum PSNR score. It disables all the nice Psy optimizations. Better use "film" or "animation" for normal encodes.

I recompiled x264 to take advantages of the new 64bit support but it crashes somewhere in the libav front end code.
Where should I post questions for libav?

Why not grab one of the various pre-compiled binaries?

Anyway, questions about libav that are not specific to x264 should go to the libav mailing list:
http://libav.org/contact.html

[rallymax]

As you should know, vbv-maxrate is not the maximum bitrate, but the bitrate at which the VBV buffer is filled.

The VBV model ensures that the VBV buffer won't underflow. And that's it. Consequently there may be short bitrate spikes higher than vbv-maxrate, as long as the buffer doesn't underflow.

x264 will ensure VBV compliance, if both, vbv-maxrate and vbv-bufsize are set. If the VBV buffer ever underflows, x264 will print out a fat warning. This usually doesn't happen.

Thx. yes that's as I understood it - I just wanted to check that for --crf that the vbv code wasn't bypassed.



There is no tuning that can help against artifacts already present in your source. Actually there is no way to magically make these artifacts go away, except for a better source.

Using the "psnr" tuning is a bad idea, except when you want to optimize for maximum PSNR score. It disables all the nice Psy optimizations. Better use "film" or "animation" for normal encodes.

Understood that I can't remove the damage - I was just wondering what tuning settings (with say --crf 10) would help it along the way to best replicate the source while taking advantage of the psycho-visualization optimiations that x264 is so good at.


Why not grab one of the various pre-compiled binaries?

Anyway, questions about libav that are not specific to x264 should go to the libav mailing list:
http://libav.org/contact.html

thx. I'm on that list but thought there might be a more forum based one like this is for the x264 dev mailing list. You are right though - it's very much appropriate for the dev list since it's crashing.