x264 development

[Dark Shikari]

Correct me if i'm wrong, but I guess x264 can't use 0 ref frames.Technically it can by not using any P-frames at all, but I'm not sure if such a thing can be written in the stream (i.e. whether the "number of reference frames" value can be zero in the h264 frame header).

[Ratio2]

according spec (http://www.itu.int/rec/T-REC-H.264):
num_ref_frames specifies the maximum number of short-term and long-term reference frames, complementary
reference field pairs, and non-paired reference fields that may be used by the decoding process for inter prediction of
any picture in the sequence. num_ref_frames also determines the size of the sliding window operation as specified in
subclause 8.2.5.3. The value of num_ref_frames shall be in the range of 0 to MaxDpbSize (as specified in subclause
A.3.1 or A.3.2), inclusive.

[kandrey89]

according spec (http://www.itu.int/rec/T-REC-H.264):

Beh, sounds like a lawyer wrote it :devil:

[burfadel]

I've got a question relating to thread allocation. When x264 is encoding, I know that avisynth runs in it own thread, but in a multicore environment, does the multithreading nature of x264 take thread cycles away from the avisynth thread in order to encode, thus actually possibly resulting in a reduction of encoding speed because of the reduction in data flow? It wouldn't affect simple avisynth scripts unless you have say 8 cores or more, but it would affect the more complex scripts. x264 should only run in the spare cycles left from avisynth, not delay the avisynth thread in order to process its own (through priority). In fact, x264 should give all thread priority to the avisynth chain to maximise speed. Also, since other threads are taking place on the computer, when they take a certain amount of cycles away from the avisynth thread, x264 should sacrifice its own threads in another core to continue running the avisynth script. It is possible to change the affinity (which core it uses) on the fly. It can be done through the task manager by right clicking on the process, you can select which cores it can run on :) The reason why the latter would be important is since the cpu load is towards 100 percent, instead of the other system processes using the core with the least load, since the load would be pretty even they'll use any core, which on a quad core leaves a 1 in 4 chance of slowing down avisynth (and hence x264), and on a dual core 1 in 2! Since most people generally run with a reasonably complex script, and avisynth isn't multithreaded, this would be beneficial for encoding speed in most cases.

[saint-francis]

Since most people generally run with a reasonably complex script, and avisynth isn't multithreaded, this would be beneficial for encoding speed in most cases.

But don't most people who use complicated scripts use MT?

[Dark Shikari]

I've got a question relating to thread allocation. When x264 is encoding, I know that avisynth runs in it own thread, but in a multicore environment, does the multithreading nature of x264 take thread cycles away from the avisynth thread in order to encode, thus actually possibly resulting in a reduction of encoding speed because of the reduction in data flow?If a thread is blocking, the operating system will allocate it time until it no longer blocks other threads that depend on it. This will ensure that Avisynth will get all the time it needs.

[Manao]

No, avisynth won't get all the time it needs when it runs in its own thread, if the encoder is configured to use at least as much threads as CPUs. So if avisynth is the bottleneck, reducing the number of threads for x264 to #CPUs - 1 should help.

[Shinigami-Sama]

No, avisynth won't get all the time it needs when it runs in its own thread, if the encoder is configured to use at least as much threads as CPUs. So if avisynth is the bottleneck, reducing the number of threads for x264 to #CPUs - 1 should help.

or just boost avisynth priority a notch or two

[Trahald]

diff --git a/common/bs.h b/common/bs.h
index c8edbdc..3979d2f 100644
--- a/common/bs.h
+++ b/common/bs.h
@@ -141,6 +141,17 @@ static inline void bs_align_1( bs_t *s )
bs_flush( s );
}

+static inline void bs_align_10( bs_t *s )
+{
+ if( s->i_left&7 )
+ {
+ s->cur_bits <<= s->i_left&7;
+ s->cur_bits |= 1 << ((s->i_left&7) - 1);
+ s->i_left &= ~7;
+ }
+ bs_flush( s );
+}
+
/* golomb functions */

static const uint8_t x264_ue_size_tab[256] =
diff --git a/encoder/set.c b/encoder/set.c
index f47954d..aee4790 100644
--- a/encoder/set.c
+++ b/encoder/set.c
@@ -499,7 +499,7 @@ void x264_sei_version_write( x264_t *h, bs_t *s )
for( i = 0; i < length-16; i++ )
bs_write( s, 8, version[i] );

- bs_rbsp_trailing( s );
+ bs_align_10( s );

x264_free( opts );
x264_free( version );the reason why is...SEI Payload syntax
*snip*
if( !byte_aligned( ) ) {
bit_equal_to_one /* equal to 1 */ 5 f(1)
while( !byte_aligned( ) )
bit_equal_to_zero /* equal to 0 */ 5 f(1)
}is supposed be used at the end of an SEI message syntax... where as rbsp_trailing is currently used which works since the message is over but is technically wrong. (writes a 1 bit that shouldnt be there)

[akupenguin]

+ s->cur_bits <<= s->i_left&7;
+ s->cur_bits |= 1 << ((s->i_left&7) - 1);
+ s->i_left &= ~7;

You can still use bs_write1, the only thing added is the if.

Now, can anyone explain the reasoning for this rule? Normal rbsp_trailing allows one to identify the exact bit that the NAL ends on, without parsing the whole thing. But the SEI version doesn't allow that; you can't tell whether the last byte is full of data, or whether it contains some trailing bits.

[Trahald]

i was wrong.. (sorta) x264 is writing the output correctly.. within the scheme of how its layed out its technically wrong (rbsp_trailing_bits probably shouldnt be in the function , but outside of the function. a sei nalu should have rbsp_trailing bits at the end... and since user data is the only thing x264 writes in the nalu the output is correct..

(btw.. bs_align_10 as it is in regaurds to a user data sei message is a NULL result because user_data always ends aligned but i like it being there because its called that way in the spec) ..
leaving x264 code as is... if someone where to write a function that appended a second message in the same nalu it would result in incorrect data. but anyways since noone does i guess its moot.

regards to ' You can still use bs_write1, the only thing added is the if.' im not sure what you mean

[Trahald]

here is a proper layout of nal w/seisei_rbsp( ) { C Descriptor
do
sei_message( ) 5
while( more_rbsp_data( ) )
rbsp_trailing_bits( ) 5
}

sei_message() {
*snip*
if( !byte_aligned( ) ) {
bit_equal_to_one /* equal to 1 */ 5 f(1)
while( !byte_aligned( ) )
bit_equal_to_zero /* equal to 0 */ 5 f(1)
}
}

[akupenguin]

regards to ' You can still use bs_write1, the only thing added is the if.' im not sure what you mean
if( s->i_left&7 )
bs_write1( s, 1 );
instead of
if( s->i_left&7 )
{
s->cur_bits <<= s->i_left&7;
s->cur_bits |= 1 << ((s->i_left&7) - 1);
s->i_left &= ~7;
}

[Sharktooth]

possible bug.
when specifying to high values for the --sar option, x264 completey ignores and apply no SAR correction at all.

[kemuri-_9]

possible bug.
when specifying to high values for the --sar option, x264 completey ignores and apply no SAR correction at all.

what are these 'too high' values? the official h264 spec only goes as far as to define *EDIT* originally said 2:1, it is correctly 32:11 */EDIT* outside of extended mode, which makes sense for me as anything higher would really start showing the stretch *EDIT* it would probably be fairly obvious at 32:11 (nearly 3x stretch) and whoever does it should have a really good reason for doing so */EDIT*
...
looked briefly at the x264 code for it and found code that effectively reduces the sar parameters to relative primes between 0 and 65535 if possible; if either value reduces to 0 in the process, the sar is invalidated.... (which is a huge range)
...
also noticed that x264 doesn't treat the h264 spec sars of 4:3, 3:2, and 2:1 as their idc values of 14,15,16 respectively but would treat them as extended sar (idc 255) if occurred.

[Sharktooth]

ok. got it.

[Sharktooth]

what will happen with something like: --sar 3040878027465:2513169434243

[kemuri-_9]

they both overflow the int type and will likely ensue in invalidation,
since it seems that the function is accepting (default signed) ints, so the maximum positive value would be 2147483647 (2^31 -1)
so pick numbers lower than that.

assuming it will modulate into a 32 bit number, the resulting numbers would be 41181897:613566083;
the gcd is 1 so unable to reduce further and maintain ratio,
so therefore the x264 code will divide them continually by 2 (integer style) until they are less than 65535:

2513:37449
would be the result in this assumptive case.

[Sharktooth]

ok, maybe i found the AR problem in megui then
thanx.

[Selur]

small question :)
Why is
// {"1b", 1485, 99, 152064, 128, 350, 64, 64, 0, 0, 0, 1 },
commented out in the x264 sourcecode (set.c -> const x264_level_t x264_levels[]) ?

Cu Selur

[akupenguin]

Why is "1b" commented out?
Because x264's level variable is a number, there's no way to ask for "1b".

[easy2Bcheesy]

May I suggest support for slices in x264? I'm attempting to decode 1080p60 x264 on PlayStation 3 and it jerks and judders badly. However, the 1080p video (http://www.wipeouthd.com/en_GB/index.html) here decodes beautifully with no problem. The only difference in the encoding profiles between my clip and that one is that the Sony clip has eight slices, which the machine could well be decoding in parallel.

[Sagekilla]

I believe x264 actually used slice based parallelization at one point for encoding, on the same token decoders that supported this could decode it as well. I don't think there's much you can do on that end, other than -MAYBE- disabling CABAC and deblock and hope it decodes a bit faster, since they've abandoned slices for parallel encoding.

[Dark Shikari]

I believe x264 actually used slice based parallelization at one point for encoding, on the same token decoders that supported this could decode it as well. I don't think there's much you can do on that end, other than -MAYBE- disabling CABAC and deblock and hope it decodes a bit faster, since they've abandoned slices for parallel encoding.Abandoning slices for parallel encoding doesn't mean you can't still make it an option.

[Sagekilla]

True, I just find it a shame that the PS3 doesn't feature frame based parallelization.

[Sharktooth]

i thrown my PS3 outta window (well... not properly... i brought it back...).
however im noticing also some other decoders use slice based parallelism (quicktime for first...).
so, i back up the request for slices support.

[bob0r]

Hardware This. Hardware That.

Is it THAT HARD for ANY H.264 decoding device maker to make it support FULL H.264 specs (at least what x264 and all satellite providers can produce)????

To me it sounds so pathetic that Windows + CoreAVC can play all, yet all the devices(with enough cpu/chip power) can not. Therefor i hope pengvado will NEVER adjust to this kind of requests, based on pathetic support from the BIG companies!

[Sharktooth]

satellite streams are usually sliced too.. :P

[Sulik]

Hardware This. Hardware That.

Is it THAT HARD for ANY H.264 decoding device maker to make it support FULL H.264 specs (at least what x264 and all satellite providers can produce)????

To me it sounds so pathetic that Windows + CoreAVC can play all, yet all the devices(with enough cpu/chip power) can not. Therefor i hope pengvado will NEVER adjust to this kind of requests, based on pathetic support from the BIG companies!

Is this that hard for open-source SW to follow the same specs as well ?
Satellite transmission, Blu-ray media all have requirements that adds additional restrictions on top of the standard, as well as enforcing level restrictions -> there is a reason why levels are present.
Available power & memory is virtually infinite for SW decoders, but it is certainly not the case for HW.

Specifications like BD/ATSC/DVB have explicit requirements, such as that there shall at most XXX MBs per slice, level shall be 4.1, a P-frame shall not use a B-frame as a reference, etc. If you do not respect these specifications, your stream won't play on the device, it's as simple as that. All these requirements are usually there for a very good reason.

The real issue is that unlike the 14496-10 standard, these specifications are usually more difficult to obtain, or the OSS developers are just not aware of them.

[CruNcher]

Very well spoken Sulik, tough X264 target never was Hardware in the first place but this changed with main developers being more active for IPTV companies and getting confrontized with it now :)
Some people even say to give X264 a very efficient and stable VBV it would need almost a complete rewrite of it but i can't say if that is true as im no Engineer here (and some Engineers also for sure don't see every way that might be possible to go with less work but almost same result).

[Manao]

Some people even say to give X264 a very efficient and stable VBV it would need almost a complete rewrite of it That's complete bullshit. It would need some work, but mostly on the rate control, which is only a single .c file in x264.

[Selur]

@akupenguin:
Because x264's level variable is a number, there's no way to ask for "1b".
okay, I had that one coming ;)
i rephrase:
Why not switch to char/string as variables or use a not used int (e.g. 14) instead of leaving out one level?

[Shinigami-Sama]

Hardware This. Hardware That.

Is it THAT HARD for ANY H.264 decoding device maker to make it support FULL H.264 specs (at least what x264 and all satellite providers can produce)????

To me it sounds so pathetic that Windows + CoreAVC can play all, yet all the devices(with enough cpu/chip power) can not. Therefor i hope pengvado will NEVER adjust to this kind of requests, based on pathetic support from the BIG companies!

+1
if these big companies want support then they can chip in 0.001% of their yearly profit to get someone to add it...

[kemuri-_9]

hmm.... has anyone else been getting some severe performance hits from the latest revision (r955)?

from my profile logs, the new revision is encoding at severely slower speeds (the opposite of handwritten asm's purpose) on the average.

--- x264-old\x264_profile.i686.gcc-3.4.5.athlon-xp.log 2008-08-30 15:34:18.7217 (r953)
50000 -0400
+++ x264\x264_profile.i686.gcc-3.4.5.athlon-xp.log 2008-09-01 04:55:33.0156 (r955)
25000 -0400
-encoded 4350 frames, 11.48 fps, 1322.67 kb/s
+encoded 4350 frames, 9.15 fps, 1322.67 kb/s

-encoded 4350 frames, 23.02 fps, 5231.54 kb/s
+encoded 4350 frames, 11.61 fps, 5231.54 kb/s

-encoded 4350 frames, 18.90 fps, 1520.46 kb/s
+encoded 4350 frames, 11.21 fps, 1520.46 kb/s

-encoded 4350 frames, 4.18 fps, 2479.76 kb/s
+encoded 4350 frames, 4.33 fps, 2479.76 kb/s

-encoded 50 frames, 8.42 fps, 445.20 kb/s
+encoded 50 frames, 7.55 fps, 445.20 kb/s

-encoded 50 frames, 14.81 fps, 14018.51 kb/s
+encoded 50 frames, 15.61 fps, 14018.51 kb/s

-encoded 50 frames, 46.34 fps, 17216.05 kb/s
+encoded 50 frames, 50.81 fps, 17216.05 kb/s

--- x264-old\x264_profile.i686.gcc-3.4.5.pentium2.log 2008-08-30 12:47:37.9092 (r953)
50000 -0400
+++ x264\x264_profile.i686.gcc-3.4.5.pentium2.log 2008-09-01 04:00:32.8281 (r955)
25000 -0400

-encoded 4350 frames, 11.15 fps, 1322.67 kb/s
+encoded 4350 frames, 9.02 fps, 1322.67 kb/s

-encoded 4350 frames, 22.39 fps, 5231.54 kb/s
+encoded 4350 frames, 10.87 fps, 5231.54 kb/s

-encoded 4350 frames, 18.75 fps, 1520.46 kb/s
+encoded 4350 frames, 10.64 fps, 1520.46 kb/s

-encoded 4350 frames, 5.35 fps, 3119.76 kb/s
+encoded 4350 frames, 5.48 fps, 3119.76 kb/s

-encoded 4350 frames, 4.17 fps, 2479.76 kb/s
+encoded 4350 frames, 4.13 fps, 2479.76 kb/s

-encoded 50 frames, 8.33 fps, 445.20 kb/s
+encoded 50 frames, 8.49 fps, 445.20 kb/s

-encoded 50 frames, 14.61 fps, 14018.51 kb/s
+encoded 50 frames, 15.53 fps, 14018.51 kb/s

-encoded 50 frames, 45.05 fps, 17216.05 kb/s
+encoded 50 frames, 50.00 fps, 17216.05 kb/s


the 50 frame sections can generally be ignored as they haven't ran long enough to have the speed stabilize.

the only times the speeds are reasonably close is on profile runs
4: --crf 18 -b3 -m7 -r5 --thread-input --psy-rd 0.0:0.0 --me umh -8 -t1 -A all --mixed-refs --b-rdo -w --b-pyramid --direct auto --bime --no-fast-pskip
5: --crf 22 -b3 -m6 -r4 --thread-input --psy-rd 1.0:1.0 --me esa -8 -t2 -A all --mixed-refs --b-rdo --bime

[audyovydeo]

hmm.... has anyone else been getting some severe performance hits from the latest revision (r955)?



well I found r953 coming back from vacation, and ran my usual speed tests, I got about 3% slower than r928, which was the last I'd tested before leaving. I tested r938 and decided to encode my holiday vids with it, as a consequence.

my settings are even simpler than yours :

--crf 25 -r 3 --me hex -m 5 -A all -8 -t 1 --aq-mode 0 --threads auto

was going to gather more data & ask here sometime.
I figure the "slowdown" is between r935 and r953.

cheers
a/v

[Quark.Fusion]

I notice that x264 raises input thread priority, but I manage to get better cpu usage and fps (+20%) by separating processing to another process, linking with TcpServer() and lowering priority of x264 process. Also in multithreaded AviSynth new threads created with default priority.
Maybe it will be better idea to lower all x264 threads by 1 instead of raising input thread priority?

P.S. my AviSynth script is GPU-bound.

[burfadel]

Some (if not all) of the slowdown is attributed to quality improvements! :)

Some modded builds of rev 953 contained a bug that slowed it down quite considerable when --b-adapt 2 was optioned.

Before going by speed drop alone, check the quality of the output files, both visually (most important) and by the SSIM etc for comparative purposes. Its only really an issue if quality has dropped along with the speed!

[kemuri-_9]

what i posted are diff -U 0 logs generated from the fprofiling. there's no difference in the log files at all in them except the speeds:
that is all frame decisions, sizes, QPs, SSIMs, PSNRs, b-frame usage, mb decisions, ref usage, transform decisions, and bitrates ARE EXACTLY THE SAME.
the profiles are deterministic being single threaded.

same patches applied, the only difference in builds is the r955 asm.

and as another note, i don't profile from .avs scripts but from .y4m files.
so anything related to avs doesn't matter

[bob0r]

Random speedtest 900/910/920/930/940/950/955 2 runs:
http://x264.nl/x264-900-955-random-speedtest.txt

speed.bat settings:
--threads auto -B5000 -m6 -r5 --direct=temporal --me=hex -b2 -w --qcomp=0.10 -A"p8x8,i8x8,i4x4" -8 --fps=25 --progress --output NUL 720p50_mobcal_ter.yuv 1280x720

Note: Rev 940 was a regression, doesn't really count.
Note: Rev 950 > 955 indeed some difference.

Simply a basic test, do with it what you like :D

Edit:
The speedloss comes from Rev 951, our heroes are on the case!
And they most likely already solved it!

[Quark.Fusion]

Just for note: my previous post about AVS isn't related to current discussion about r955 slowdown, but to x264 in general.

[audyovydeo]

well I found r953 coming back from vacation, and ran my usual speed tests, I got about 3% slower than r928

hello Dark Shikari

r956's speed test results are coherent with the speed improvement curve you've been spoiling us with (I get 0.82% faster than r928).

thanks as usual
cheers
audyovydeo

[juGGaKNot]

r965 only uses 256 MB of ram

older versions used up to 1.2 GB of ram on my pc

[Ranguvar]

Um. Well, that's odd, and almost certainly something's amiss with your system, but isn't that a good thing if speed didn't drop too?

[Manao]

juGGaKNot : memory takes into account all the memory allocated by the avisynth script, which is often far more than the memory allocated by x264

[juGGaKNot]

Um. Well, that's odd, and almost certainly something's amiss with your system, but isn't that a good thing if speed didn't drop too?

well changed lots of stuff now so i don't realy know

moved on to crf 18 with trellis2 + subme7 + merange 32 so its realy slow, 1.8 FPS

before 2 pass with trelis 1 + subme6 + merange 16 was about 5-7 FPS for 1024x576 30 FPS

juGGaKNot : memory takes into account all the memory allocated by the avisynth script, which is often far more than the memory allocated by x264

i have 4 GB so i could care less, its just that encoding time is huge now.

i only render footage at 1024x576 <10 min now so its k i guess

[Quark.Fusion]

i have 4 GB so i could care less, its just that encoding time is huge now.
No, you can't care less because you have 4GB, instead you should care more if not using 2.5.8 AVS. This is because 32-bit apps have limit for 2GB of virtual memory — if you break limit app will crash/freeze/bug. Note that virtual memory is all allocated (not necessary used) memory and virtual memory fragmentation also counts.

[Octo-puss]

I might be posting in wrong thread, but I wanna say it anyway:
No idea what you recently changed in the code, but in 2pass encoding, the first one I am doing about 30-40FPS faster than before lately. 2nd by up to 10. Excellent work on the whole thing, keep up :) Cheers.

[juGGaKNot]

No, you can't care less because you have 4GB, instead you should care more if not using 2.5.8 AVS. This is because 32-bit apps have limit for 2GB of virtual memory — if you break limit app will crash/freeze/bug. Note that virtual memory is all allocated (not necessary used) memory and virtual memory fragmentation also counts.

I use 2.5.8 RC4 with the new b-frame, techouse r965

"%mypath%\bin\x264.exe" --crf 18 --stats "%mypath%\temp\%mymovie%.stats" --level 4.1 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --trellis 2 --analyse all --8x8dct --me esa --merange 32 --threads auto --thread-input --cqmfile "%mypath%\bin\eqm_avc_hr.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output "%mypath%\temp\%mymovie%.mkv" "%mypath%\temp\%mymovie%.avs"

[Esc]

Versions 994 and 995 with following parameters
program --pass 2 --bitrate 1400 --stats ".stats" --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct temporal --trellis 2 --psy-rd 0.0:0 --partitions p8x8,b8x8,i4x4 --ratetol 4.0 --qcomp 0.8 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
created through MeGUI 0.3.0.2018 both produce black video and encoding FPS is 83.02 on second pass vs 2.24 on first pass.

[martino]

r999
rm gtk

I don't remember why I allowed a gui into the repository in the first place. There's nothing that makes this one special relative to all the other x264 guis.

I'd like the devs to rethink this action. While there are many guis for win32, you don't have that many for Mac/Linux (or at least not that I'm aware of), and I think it'd be nice to have something around that works "right from the box". Why would someone need to get extra piece of software to do some very simple task (let's just say no cmd guru, or just someone that wants to do a quick encode) when you could have it in the package already. Just my opinions, any feedback is welcome.