x264 development

[nurbs]

With x264 r1330 32-bit from x264.nl I get lots of warnings when I try to encode anything. My cpu is an Atlon64 X2.
D:\Test>"C:\Programme\megui\tools\x264\x264.exe" -o "D:\Test\e7_error.mp4" "D:\Test\e7.avs"
avis [info]: 1280x720 @ 23.98 fps (1842 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.1
mp4 [info]: initial delay 1001 (scale 24000)
x264 [warning]: internal error (MV out of thread range)51
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 36,15
completed: 600
x264 [warning]: recovering by using intra mode
x264 [warning]: internal error (MV out of thread range)28
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 73,0
completed: 376
x264 [warning]: recovering by using intra mode
x264 [warning]: internal error (MV out of thread range):34
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 30,0

edit:
with --threads 1 it works without warnings

edit2:
Seems like it doesn't work. There are no warnings or errors during encoding, but the clips show artifacts during playback. I tried current builds of MPC-HC (with DXVA) and ffdshow, so either non of them can correctly decode the clips or something went wrong during encoding. I posted a small sample on megaupload in case anyone wants to take a look. It's most noticeable at the end of the clip. http://www.megaupload.com/?d=28H1OHGH

@juGGaKNot:
I also get crashes like that. I think it's either --subme 10, --trellis 2 or --me tesa. I tried another clip with everything the same except --subme 9, --trellis 1 and --me umh and that worked. Haven't had the time to narrow it down.

[juGGaKNot]

I also get crashes like that. I think it's either --subme 10, --trellis 2 or --me tesa. I tried another clip with everything the same except --subme 9, --trellis 1 and --me umh and that worked. Haven't had the time to narrow it down.

subme 9 = crash with cmd :

encoded 1800 frames, 11.73 fps, 4220.12 kb/s
avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [warning]: internal error (MV out of thread range):49
mb type: 17
mv: l0r0 (0,23374)
limit: 416
mb_xy: 2,21
completed: 632
x264 [warning]: recovering by using intra mode
[2.1%] 37/1800 frames, 2.08 fps, 4692.07 kb/s, eta 0:14:06

subme 10 just crash

subme 9 and trellis 0 crash

[MatLz]

No crashes for me but huge flickerings and wild macroblocks. But I experience same artifacts without weighted p, so it's maybe an other problem?

[jmartinr]

I've got displaced macroblocks as well with this:

"C:\Program Files\x264\x264.exe" "%%~fP" --pass 1 --preset veryslow --keyint %keyint% --bitrate %bitrate% --threads auto --thread-input --sar %sar% --stats "%%~dpnP.x264.stats" --output NUL

"C:\Program Files\x264\x264.exe" "%%~fP" --pass 2 --preset veryslow --keyint %keyint% --bitrate %bitrate% --threads auto --thread-input --sar %sar% --stats "%%~dpnP.x264.stats" --output "%%~dpnP.%x264cont%"

That's a quite ordinary commandline, I guess.

[thewebchat]

If you decode with CoreAVC, you will get very "interesting" results. I'm pretty sure this has been mentioned in the CoreAVC thread and on the page before.

[Forteen88]

Which h264-decoder works with weightp? CoreAVC 2.0 will fix it.

EDIT: @tph, Ok, thanks for the info

[tph]

Which h264-decoder works with weightp? CoreAVC 2.0 will fix it.
libavcodec

[MatLz]

Is there a place to get intermediary revisions?
X264.nl jumps since 1319 directly to 1330...

[Terranigma]

No crashes for me but huge flickerings and wild macroblocks. But I experience same artifacts without weighted p, so it's maybe an other problem?

Same here but only WITH weighted-p enabled, and guys, don't try to blame it on CoreAVC as i'm using the latest version of mpc-hc with ffdshow set as the decoder via libavcodec.

[juGGaKNot]

Patched build works fine ( rack 4.3.4, x264_win_zone_parse_fix_06.diff ), old mpc-hc with divx h264 decoder plays k

unpatched crashes

[Dark Shikari]

Can we all just agree to stop using GCC 4 and all the problems will be solved?

[nurbs]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.

[juGGaKNot]

Can we all just agree to stop using GCC 4 and all the problems will be solved?

x264.nl one causes the problems, rack's 4..... works

[Dark Shikari]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.I'm having no issues with 3.4 builds.

[Terranigma]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.

That's what i've used too.

[juGGaKNot]

http://mirror01.x264.nl/x264/revision1330/x264.exe

x264.exe --preset veryslow --level 3.2 --ref 5 --min-keyint 30 --keyint 300 --bframes 3 --b-pyramid normal --merange 32 --sar 1:1 --aud

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_1330error.png (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=1330error.png)

gcc.exe (GCC) 4.3.4 (x86.core2.Komisar) :

avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 3.2
x264 [info]: frame I:28 Avg QP:20.55 size: 72473
x264 [info]: frame P:770 Avg QP:24.87 size: 24371
x264 [info]: frame B:1002 Avg QP:28.20 size: 10837
x264 [info]: consecutive B-frames: 9.9% 32.5% 34.5% 23.0%
x264 [info]: mb I I16..4: 24.4% 0.0% 75.6%
x264 [info]: mb P I16..4: 34.7% 0.0% 0.0% P16..4: 43.3% 0.0% 0.0% 0.0% 0
.0% skip:22.0%
x264 [info]: mb B I16..4: 9.5% 0.0% 0.0% B16..8: 25.3% 0.0% 0.0% direct:
12.3% skip:52.9% L0:38.5% L1:43.7% BI:17.8%
x264 [info]: final ratefactor: 22.40
x264 [info]: direct mvs spatial:97.6% temporal:2.4%
x264 [info]: coded y,uvDC,uvAC intra: 56.2% 41.1% 11.1% inter: 23.5% 9.7% 0.6%
x264 [info]: i16 v,h,dc,p: 28% 27% 23% 23%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 24% 13% 6% 8% 6% 11% 7% 8%
x264 [info]: Weighted P-Frames: Y:10.4%
x264 [info]: kb/s:4220.44

encoded 1800 frames, 10.46 fps, 4220.44 kb/s
avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [info]: frame I:28 Avg QP:21.71 size: 69265
x264 [info]: frame P:770 Avg QP:25.87 size: 23682
x264 [info]: frame B:1002 Avg QP:29.12 size: 12046
x264 [info]: consecutive B-frames: 9.9% 32.5% 34.5% 23.0%
x264 [info]: mb I I16..4: 12.9% 76.1% 11.0%
x264 [info]: mb P I16..4: 4.8% 21.1% 2.0% P16..4: 33.0% 10.7% 7.3% 0.2% 0
.2% skip:20.7%
x264 [info]: mb B I16..4: 0.7% 4.3% 0.6% B16..8: 34.7% 2.5% 2.6% direct:
9.7% skip:44.9% L0:50.5% L1:42.3% BI: 7.1%
x264 [info]: 8x8 transform intra:75.8% inter:83.5%
x264 [info]: direct mvs spatial:88.1% temporal:11.9%
x264 [info]: coded y,uvDC,uvAC intra: 70.1% 51.7% 15.0% inter: 27.9% 12.5% 1.1%
x264 [info]: i16 v,h,dc,p: 37% 17% 4% 41%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 11% 4% 8% 13% 11% 17% 10% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 9% 4% 7% 16% 12% 18% 9% 14%
x264 [info]: Weighted P-Frames: Y:10.1%
x264 [info]: ref P L0: 50.9% 12.2% 18.4% 6.9% 5.6% 5.3% 0.6%
x264 [info]: ref B L0: 73.1% 12.6% 8.7% 5.6%
x264 [info]: kb/s:4299.33

encoded 1800 frames, 1.16 fps, 4299.33 kb/s
AVC-H264 import - frame size 1184 x 666 at 30.000 FPS
Import results: 1800 samples - Slices: 28 I 770 P 1002 B - 1 SEI - 21 IDR
IsoMedia import - track ID 1 - Audio (SR 44100 - 2 channels)
Saving C:\x264\Movie_2D\1.Movie_X264_2D.mp4: 0.500 secs Interleaving

X264 Encoding started at 06:46 PM and finished at 07:15 PM

Overall Encoding started at 06:46 PM and finished at 07:15 PM

[VFR maniac]

Rev1330 I compiled with 3.4.5 and 4.4.2 are bit identical, while x264.nl build (3.4.6) is difference from them.
I doubt that x264.nl has some problems.

[dvy]

bug ,bug ,bug ,r1330 have huge flickerings and wild blocks and huge artifacts .I very sure it is source code problem,not compiler problem.expert fixing as soon as possible.

[Dark Shikari]

Rev1330 I compile with 3.4.5 and 4.4.2 are bit identical, while x264.nl build (3.4.6) is difference from them.
I doubt that x264.nl has problems.If your two are bit-identical and x264.nl's is different, I suspect x264.nl has problems.

[Dark Shikari]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)

[dvy]

If your two are bit-identical and x264.nl's is different, I suspect x264.nl has problems.

I use git to pull r1330 source code,compile vc++ and gcc, encode three clip,all of encoded clip have problem.it must be source code problem.

[Dark Shikari]

I use git to pull r1330 source code,compile vc++ and gcc, encode three clip,all of encoded clip have problem.it must be source code problem.I have no issues here. Can you post a commandline or something else that I can replicate with?

Furthermore, are you on win32 or win64? I can't try to fix issues when nobody is giving me any useful information.

[dvy]

I have no issues here. Can you post a commandline or something else that I can replicate with?

Furthermore, are you on win32 or win64? I can't try to fix issues when nobody is giving me any useful information.

I use r1330 x264 win32 platform,x264 commandline:

pass 1:
x264.exe" --profile high --level 4.1 --preset slower --pass 1 --bitrate 4000 --stats "H:\Entertainment\Convert\ManU VS FC Seoul.stats" --thread-input --threads 1 --deblock -2:-2 --no-cabac --bframes 3 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --ref 8 --deadzone-inter 17 --deadzone-intra 8 --rc-lookahead 80 --aq-mode 2 --aq-strength 0.7 --merange 16 --me umh --subme 9 --partitions all --trellis 0 --psy-rd 1.0:0 --no-fast-pskip --output NUL "H:\Entertainment\Convert\ManU VS FC Seoul.avs"

pass 2:
x264.exe" --profile high --level 4.1 --preset slower --pass 2 --bitrate 4000 --stats "H:\Entertainment\Convert\ManU VS FC Seoul.stats" --thread-input --threads 1 --deblock -2:-2 --no-cabac --bframes 3 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --ref 8 --deadzone-inter 17 --deadzone-intra 8 --rc-lookahead 80 --aq-mode 2 --aq-strength 0.7 --merange 16 --me umh --subme 9 --partitions all --trellis 0 --psy-rd 1.0:0 --no-fast-pskip --aud --output "H:\Entertainment\Convert\ManU VS FC Seoul.264" "H:\Entertainment\Convert\ManU VS FC Seoul.avs"

before r1330 ,everything is OK,at today I pull r1330 ,problem appear.I compile r1330 in VS2008 and cygwin gcc 3.4,both have problem .

[Dark Shikari]

I can't replicate anything without a source sample either. Anyways, I've found one bug (looking for a fix atm...), so hopefully this might be the problem.

[dvy]

I can't replicate anything without a source sample either. Anyways, I've found one bug (looking for a fix atm...), so hopefully this might be the problem.

Need not replicate ,very huge flickerings and blocks and artifacts is absolutly true.it must be source code bug.expect fixing,x264 is very very good stuff.

[wyti]

When you're searching a bug, you need to be able to replicate the issue to spot WHERE it goes wrong, only knowing it fails somewhere don't help fixing it.

@DS don't know if it's too late but tested rev 1331 compiled with gcc 4.4.2 for win64 (core I7) and got the same md5sum than yours

[dvy]

When you're searching a bug, you need to be able to replicate the issue to spot WHERE it goes wrong, only knowing it fails somewhere don't help fixing it.


problem is commit between 2009-10-30 and today,before is OK.

[Terranigma]

problem is commit between 2009-10-30 and today,before is OK.

I gave Shikari a sample encode with the bug and my source input, and gave him the settings used to encode and he couldn't replicate the problem, so i'm thinking it could just be the builds (32-bit at least) at x264.nl

[kemuri-_9]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)

x264.nl's r1331 binary produces with the above commandline an md5 of

6430be78659b75068f19573fd3bad90f

which would indeed point to it being broken.

[Dark Shikari]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

[Dark Shikari]

OK, I am going insane. I've compiled with both gcc 3.4.4 and gcc 4.3.2 locally and I have been unable to replicate any bugs reported by anyone here.

What the hell is going on? :/

Edit: Linux x86_64 gcc 4.1.2 works.

[juGGaKNot]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

Works.

[kemuri-_9]

mingw 4.4.2, both x86 and x64 matched the md5 here.

Edit:
mingw 4.3.4 (official, not the prerelease variety), both x86 and x64 matched.

[MatLz]

Yes it works.
Don't know if it will help you to understand the bugs but I noticed the artifacts exponentially increased when I decreased motion estimation...like:
Tesa subme9 little flickering, not many wild macroblocks
Umh subme7 huge flickering lot of wild macroblocks
Dia subme2....hum...I thought the video could jump out of my screen...!

[dvy]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.



Dark Shikari, I test your build ,your build and my build have same problem,screenshot below:it must be source code bug,and the bug must be commit between 2009-10-30 and today.

[Dark Shikari]

Dark Shikari, I test your build ,your build and my build have same problem,screenshot below:it must be source code bug,and the bug must be commit between 2009-10-30 and today.I need a source sample to replicate the problem.

[jmartinr]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

Works. Previous problems happened with x264.nl 1330 build.

[IgorC]

I need a source sample to replicate the problem.
Edited: There is no bug on foreman sample with your build but it is here with x264.nl's build (2pass)

x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 60 --mbtree --threads 5 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --mbtree --rc-lookahead 60 --threads 5 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

pause

[VFR maniac]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)


OK. GCC 4.4.2 and 3.4.5 matches the md5.
x264.nl's doesn't match, and the md5 is
aa68827555eb4eab05de2d0c82bbaee7

[Dark Shikari]

It's bug on foreman sample (2pass)

x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 60 --mbtree --threads 5 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --mbtree --rc-lookahead 60 --threads 5 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

pauseI can't replicate any issue here, unless I'm blind, using foreman CIF. JM agrees there's no problem (at least there's no decoder/encoder mismatch).

[kieranrk]

GCC 4.4.0 mingw:

$ x264 crew_4cif.y4m --threads 1 -o - | md5sum
yuv4mpeg: 704x576@60/1fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:4 Avg QP:24.19 size: 37151
x264 [info]: frame P:326 Avg QP:26.30 size: 12931
x264 [info]: frame B:270 Avg QP:27.92 size: 5425
x264 [info]: consecutive B-frames: 9.4% 90.6% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.6% 72.7% 20.7%
x264 [info]: mb P I16..4: 1.0% 7.2% 1.5% P16..4: 47.4% 21.7% 11.6% 0.0% 0
.0% skip: 9.5%
x264 [info]: mb B I16..4: 0.7% 2.5% 0.8% B16..8: 54.1% 1.7% 2.6% direct:
7.1% skip:30.6% L0:36.3% L1:55.9% BI: 7.8%
x264 [info]: 8x8 transform intra:71.4% inter:71.3%
x264 [info]: coded y,uvDC,uvAC intra: 73.1% 75.0% 43.8% inter: 36.6% 40.7% 2.3%
x264 [info]: i16 v,h,dc,p: 54% 16% 4% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 11% 15% 6% 11% 12% 8% 9% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 13% 14% 6% 10% 10% 7% 7% 5%
x264 [info]: Weighted P-Frames: Y:8.6%
x264 [info]: ref P L0: 55.8% 10.1% 28.7% 3.8% 1.5%
x264 [info]: ref B L0: 90.7% 9.3%
x264 [info]: kb/s:4663.00

encoded 600 frames, 9.95 fps, 4663.00 kb/s
d0d5486178c3fb782da5c0e51dbb7c95 *-

Same with --no-asm

[burfadel]

Well, I used the x264.exe 1331 from x264.nl, same problem with the flickering blocks as others have described.

Command line used is:
--keyint 400 --ref 5 --rc-lookahead 50 --nr 900 --bframes 5 --b-adapt 2 --b-pyramid normal --direct auto --subme 10 --trellis 2 --psy-rd 1:0.6 --partitions all --me umh --aq-mode 2

[Raere]

Well, I used the x264.exe 1331 from x264.nl, same problem with the flickering blocks as others have described.

Command line used is:
--keyint 400 --ref 5 --rc-lookahead 50 --nr 900 --bframes 5 --b-adapt 2 --b-pyramid normal --direct auto --subme 10 --trellis 2 --psy-rd 1:0.6 --partitions all --me umh --aq-mode 2

Same problem here - I used 3 different decoders, and all had the same flickering blocks (only about 3 in my 60 second clip)

[Dark Shikari]

It's already well-established that x264.nl's build is broken and jarod doesn't seem to feel like fixing it.

I still can't replicate anything.

[yuvi]

Everyone who is compiling x264 and getting wrong results: does http://pastebin.com/m52baaee5 not fix it?

Note that this is *not* a real solution, I'm just curious if there's anything going on other than emms reordering.

[Dark Shikari]

No problem with gcc 4.3.4 on Linux either.

[nurbs]

I noticed in the log that the value in the weighted p-frame line varies a lot with the number of threads. For instance I got 6.1% with one thread and 16.5% with three threads all other settings the same. I tried different sources and it seems to happen all the time.

edit: that is with the r1330 build from rack04 on 32-bit windows

[gizzin]

i got darks build, see if i can reproduce the flickering, I also got it on a earlier encode but didnt think much of it.

[Dark Shikari]

Confirmed: it's fprofiled that's broken (with Jarod's 3.4.6 build). Regular compilation still works fine.

[Xavius]

Confirmed: it's fprofiled that's broken (with Jarod's 3.4.6 build). Regular compilation still works fine.

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

so, is this ok or not?

[Dark Shikari]

so, is this ok or not?It should be; it isn't fprofiled. I was talking about jarod's build.

[wyti]

Strange, i got the same md5 checksum than yours, but i build my x264 (x64) fprofiled (and without gpac support but i don't know if it can do something)

[bob0r]

x264.nl users, redownload a fresh 'make' copy for now.
You might not even notice any speed difference! Let us know!

[Xavius]

Dark Shikari's x264 rev.1331 is about 672 kb
x264.nl version, rev.1331 is about 991 kb (I'm talking about the very latest, fixed, version)

same sources... more than 200 kb difference in size.
Why there is this difference?

[Dark Shikari]

Dark Shikari's x264 rev.1331 is about 672 kb
x264.nl version, rev.1331 is about 991 kb (I'm talking about the very latest, fixed, version)

same sources... more than 200 kb difference in size.
Why there is this difference?gpac.

[allak]

DS version is compiled without MP4 support, I'd say the difference is from the GPAC library.

[nurbs]

I did some tests with the current r1331 from x264.nl. I tested with the default settings only specifying the number of threads manually from 1 to 5. On my samples I got something like Weighted P-Frames: Y:5.8% for one thread and Weighted P-Frames: Y:16.5% for 2 or more threads. With all of the samples I tested the number was much higher when multiple threads were used.
So, is that a problem?

edit: post 666 :devil:

[Chikuzen]

Does --weightp 2 have problems in play back with DXVA?
I encountered such a phenomenon.
http://forum.doom9.org/attachment.php?attachmentid=10472&stc=1&d=1258095131
http://forum.doom9.org/attachment.php?attachmentid=10473&stc=1&d=1258095191
http://forum.doom9.org/attachment.php?attachmentid=10474&stc=1&d=1258095240

I uploaded all(sourcefile,scripts and binary) to mediafire (http://www.mediafire.com/?mjdm1n1mgoy).

My environment:
Binary:x264.nl r1332(x86)
Player:MPC-HC r1301(x86)
Decoder:MPC VIDEO DECODER(DXVA)/Microsoft DVD-DTV Decoder(DXVA)/ffdshow-tryouts r3130
OS:Windows7pro(x64)
Graphic card:Radeon HD3850+ccc9.9

This phenomenon was generated in FlashPlayer10.

[schoeppchen]

Is there any chance that x264.exe will support encoding on the gpu (e.g. via DXVA)?

[LoRd_MuldeR]

Is there any chance that x264.exe will support encoding on the gpu (e.g. via DXVA)?

If at all, it would use CUDA, OpenCL or even DirectX 11 ComputeShaders to exploit the GPU. But not DXVA, as DXVA is for playback/decoding.

However GPU encoding support in x264 is extremely unlikely to happen (at least not in the near future) for the reasons that have been explained dozens of times :search:

[Assassinator]

Is it just me, or is anyone else having sporadic freezes with the newer versions of x264 since weightp was introduced?

So pretty much what happens is x264 just freezes, with CPU usage at 0. It happens around once every few hours of encoding, is random (the same encode can freeze this time, but work next time), is not location dependent (can freeze at the start of an encode, or at the end) and doesn't seem to be settings dependent either (it happens with both my watch-and-delete PSP encodes with really fast settings, and my slow 4fps encodes. One thing in common is that every encode used weightp... I'm current running some encodes without, but it'll be a while until I can confirm any results).

It may sound to you like a problem on my side (and I'm not denying the possibility), but I don't remember any pre-weightp builds ever freezing like that, and I haven't changed my system configuration in quite a long time. Tried both x264.nl's and JEEB's builds, 1332 and 1336, 32bit, so it isn't a problem with a particular build being bad (unless all of them are miscompiled... :\). Going to try that ICC build that was posted today sometime later.

CPU: AMD Phenom 9550. OS: Windows 7 64bit. Encoding with x264 directly, not through any GUI. Sorry I can't provide much other more useful information at the moment.

[akupenguin]

@Assassinator
Not just you. Debugging it is currently deputized to Saintdev since he seems to be able to reproduce it much more consistently than I can.

[detmek]

I started using new builds with weightp after I reinstaled Win XP SP3. I thougth it is Windows problem or Avisynth problem because I am using MT libraries made by JD.
I tried to convert one AVC file using 2-pass mode. The first time it stoped on first pass. Second time, it stoped on second pass.
I replaced DGAVCSource with DSS2 and it finished convesion. x264 build was 1331. I didn't test again.

[burfadel]

Yeah the crashes are pretty random, its related to x264 and not the encoding chain. I just encoded one file that got to 99.7 before it just stopped encoding like outlined about!

[SledgeHammer_999]

I can confirm exactly what Assassinator said. Random freezes. Sometimes it finishes the SAME encode sometimes it freezes(well megui still displays 0.xxFPS). I am using 2-pass mode. For me only rev1318 works. Every rev till 1336 doesn't. (I haven't tested 1319).

[JohannesL]

I can confirm exactly what Assassinator said. Random freezes. Sometimes it finishes the SAME encode sometimes it freezes(well megui still displays 0.xxFPS). I am using 2-pass mode. For me only rev1318 works. Every rev till 1336 doesn't. (I haven't tested 1319).
You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

[detmek]

You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

Why not? MeGUI is just a GUI for other applications. I'm using it to create AVS script. And MeGUI only generates command line for x264. Other then that, conversion process is completely independent from MeGUI, right? If generated command line is wrong, x264 wont start at all.
Other then using MeGUI to create avs file, I started conversion process using manually created bat file. And I still got same problem as Assassinator.
My avs script contained avcsource and bicubic resize.
x264 command line was like: --tune film --bitrate 888 --pass 2 --me umh --level 4.0 --vbv-maxrate 20000 --vbv-bufsize 25000 --b-adapt 2.

[SledgeHammer_999]

You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

why?

I just feed it an avisynth script and choose the encoding options myself. I just use it to queue encodes.

[moviefan]

I have had freezes as well, just for the record, and I started the encoding purely from the command line.

[Dark Shikari]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

[juGGaKNot]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

Yes but you always find old bugs so ... yes

[Audionut]

My own build has been working fine for me on numerous encodes.

http://rapidshare.com/files/304464362/x264.exe

Revision 1331

[me7]

I did ~20 fine encodes with 1332 from x264.nl. It seems to depend more on your OS and/or source then the compile.

[prOnorama]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

Yes a "stable revision marker" would be nice for the less tech savvy like me. Also maybe GUI developers will like it, I bet they have a hard time keeping up wiith with the rapid pace of x264 development anyway. Meanwhile the techheads here can sort out the bugs when new features are added to x264 like after r1318.

[burfadel]

Without the time to do testing, it seems lower res videos (512,384) don't freeze whereas higher res video sources do?

[Assassinator]

Without the time to do testing, it seems lower res videos (512,384) don't freeze whereas higher res video sources do?

Sure they do. I use a script to batch convert large quantities of videos to PSP (480x272 or ???x272 if not 16:9), and I've gotten quite a few freezes. And no, it's not the script's fault, all that does is extract subtitle streams, generate avs scripts, and set up encodes.

It's probably just that larger videos take more processing, so are more likely to freeze up before completion than smaller vids.




As Dark Shikari said, if anyone's particularly worried about it, just use the older versions that don't freeze.

[Dark Shikari]

Bug [probably] found. Fix [probably] incoming.

[juGGaKNot]

x264 [info]: Weighted P-Frames: Y:4.9% with aq-mode 0
x264 [info]: Weighted P-Frames: Y:11.2% with aq-mode 2

Is this normal ?

[dylanza]

x264 [info]: Weighted P-Frames: Y:4.9% with aq-mode 0
x264 [info]: Weighted P-Frames: Y:11.2% with aq-mode 2

Is this normal ?

No, that seems wrong. Do you have the command line and a source to test with? Are you on r1342?
Maybe its another bug.

[juGGaKNot]

No, that seems wrong. Do you have the command line and a source to test with? Are you on r1342?
Maybe its another bug.

1342 jeeb 4.3.4 32 bit

AVIsource("C:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12()

--preset veryslow --level 3.2 --ref 5 --min-keyint fps --keyint fpsx10 --bframes 3 --merange 32 --aq-mode 0 --sar 1:1 --aud

128k net, can't upload, 1280x800 30 fps

[detmek]

1342 x264.nl 32-bit build works fine on my test clip with --preset medium --aq-mode 0 and 2.
Weigthp Y:2.5%.

[Boolsheet]

I think something's wrong with JEEB's latest builds. The checksums of imk's ICC builds and my own (mingw with gcc 3.4.5) are the same but all 3 JEEB builds get something different. And it's not fprofile this time, at least not for the gcc 3.4.5 version.

[JEEB]

Looking into it as we speak, have been a bit busy with looking at several scripts made for building a toolchain. Having trouble with building GCC 4.5 for testing and 4.3.X as well as 4.4.X for daily building :3 (all give different errors atm). To make all clear this stuff is being done on a completely different msys/mingw environment, the one I use for daily building I haven't touched for quite some time (touching as in adding/removing libraries/binaries).

Switching to a newer Komisar mingw toolchain version is possible for the moment until I get my own toolchain going.

EDIT:

Cannot reproduce this with foreman on the patched 32bit build when compared as well to a build done with the newest 4.5 gcc version (a completely different msys/mingw setup used as well):

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset slower --aq-mode 2 foreman_cif.y4m -o foreman_old
_aq2.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:21.15 size: 26827
x264 [info]: frame P:134 Avg QP:24.01 size: 4128
x264 [info]: frame B:164 Avg QP:28.51 size: 755
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.7% 40.5% 55.8%
x264 [info]: mb P I16..4: 0.2% 1.6% 0.8% P16..4: 46.4% 20.9% 19.0% 1.1%
.8% skip: 9.2%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 47.9% 3.6% 4.0% direct
3.5% skip:40.6% L0:45.2% L1:45.6% BI: 9.2%
x264 [info]: 8x8 transform intra:56.4% inter:52.2%
x264 [info]: direct mvs spatial:97.0% temporal:3.0%
x264 [info]: coded y,uvDC,uvAC intra: 90.0% 84.5% 54.5% inter: 22.6% 17.3% 2.9%
x264 [info]: i16 v,h,dc,p: 48% 16% 3% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 9% 3% 7% 20% 16% 17% 9% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 5% 7% 19% 13% 15% 9% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 56.6% 8.4% 17.6% 4.1% 3.0% 2.8% 3.1% 2.0% 2.4% 0
0%
x264 [info]: ref B L0: 69.0% 10.8% 7.5% 3.9% 3.2% 2.8% 2.8%
x264 [info]: kb/s:583.91

encoded 300 frames, 18.04 fps, 583.91 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset slower --aq-mode 0 foreman_cif.y4m -o foreman_old
_aq0.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:20.98 size: 27695
x264 [info]: frame P:134 Avg QP:23.89 size: 4623
x264 [info]: frame B:164 Avg QP:28.00 size: 947
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.9% 33.6% 62.5%
x264 [info]: mb P I16..4: 0.2% 1.5% 1.0% P16..4: 43.5% 19.5% 18.9% 1.6%
.3% skip:12.6%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 44.6% 4.6% 5.0% direct
4.3% skip:41.1% L0:43.9% L1:43.3% BI:12.8%
x264 [info]: 8x8 transform intra:48.7% inter:49.5%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 82.5% 58.2% inter: 24.7% 17.3% 4.1%
x264 [info]: i16 v,h,dc,p: 34% 25% 5% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 9% 3% 8% 19% 16% 16% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 12% 5% 7% 19% 12% 15% 8% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 55.5% 8.1% 18.1% 4.2% 3.3% 2.9% 3.3% 2.1% 2.5% 0
0%
x264 [info]: ref B L0: 69.2% 11.2% 7.3% 3.7% 3.0% 2.8% 2.8%
x264 [info]: kb/s:663.44

encoded 300 frames, 17.88 fps, 663.44 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-new-32bit.exe --preset slower --aq-mode 2 foreman_cif.y4m -o foreman_new
_aq2.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:21.15 size: 26820
x264 [info]: frame P:134 Avg QP:24.01 size: 4128
x264 [info]: frame B:164 Avg QP:28.51 size: 755
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.7% 40.5% 55.8%
x264 [info]: mb P I16..4: 0.2% 1.6% 0.8% P16..4: 46.4% 20.9% 19.0% 1.1%
.8% skip: 9.2%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 47.9% 3.6% 4.0% direct
3.5% skip:40.6% L0:45.2% L1:45.6% BI: 9.2%
x264 [info]: 8x8 transform intra:56.4% inter:52.2%
x264 [info]: direct mvs spatial:97.0% temporal:3.0%
x264 [info]: coded y,uvDC,uvAC intra: 90.0% 84.5% 54.5% inter: 22.6% 17.3% 2.9%
x264 [info]: i16 v,h,dc,p: 48% 16% 3% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 9% 3% 7% 20% 16% 17% 9% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 5% 7% 19% 13% 15% 9% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 56.6% 8.4% 17.6% 4.1% 3.0% 2.8% 3.1% 2.0% 2.4% 0
0%
x264 [info]: ref B L0: 69.0% 10.8% 7.5% 3.9% 3.2% 2.8% 2.8%
x264 [info]: kb/s:583.90

encoded 300 frames, 18.22 fps, 583.90 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-new-32bit.exe --preset slower --aq-mode 0 foreman_cif.y4m -o foreman_new
_aq0.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:20.98 size: 27688
x264 [info]: frame P:134 Avg QP:23.89 size: 4623
x264 [info]: frame B:164 Avg QP:28.00 size: 947
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.9% 33.6% 62.5%
x264 [info]: mb P I16..4: 0.2% 1.5% 1.0% P16..4: 43.5% 19.5% 18.9% 1.6%
.3% skip:12.6%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 44.6% 4.6% 5.0% direct
4.3% skip:41.1% L0:43.9% L1:43.3% BI:12.8%
x264 [info]: 8x8 transform intra:48.7% inter:49.5%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 82.5% 58.2% inter: 24.7% 17.3% 4.1%
x264 [info]: i16 v,h,dc,p: 34% 25% 5% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 9% 3% 8% 19% 16% 16% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 12% 5% 7% 19% 12% 15% 8% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 55.5% 8.1% 18.1% 4.2% 3.3% 2.9% 3.3% 2.1% 2.5% 0
0%
x264 [info]: ref B L0: 69.2% 11.2% 7.3% 3.7% 3.0% 2.8% 2.8%
x264 [info]: kb/s:663.42

encoded 300 frames, 18.30 fps, 663.42 kb/s


Will try with the 1280x720 sample I've got with the settings the original reporter used.

EDIT2:

Did not reproduce with the, granted, short saisoku.y4m that utilizes weightp.


jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset veryslow --bframes 3 --ref 5 --aq-mode 0 --sar 1:
1 --aud saisoku.y4m -o saisoku-old-aq0.mkv
yuv4mpeg: 1280x720@24/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:26.81 size: 9273
x264 [info]: frame P:53 Avg QP:28.47 size: 10545
x264 [info]: frame B:45 Avg QP:28.95 size: 5880
x264 [info]: consecutive B-frames: 21.4% 44.9% 21.4% 12.2%
x264 [info]: mb I I16..4: 63.8% 35.7% 0.5%
x264 [info]: mb P I16..4: 21.8% 12.2% 0.3% P16..4: 42.0% 4.1% 3.2% 0.0% 0
.0% skip:16.2%
x264 [info]: mb B I16..4: 2.8% 1.7% 0.0% B16..8: 36.0% 0.8% 1.0% direct:
6.9% skip:50.7% L0:53.4% L1:41.6% BI: 5.0%
x264 [info]: 8x8 transform intra:35.8% inter:96.3%
x264 [info]: direct mvs spatial:95.6% temporal:4.4%
x264 [info]: coded y,uvDC,uvAC intra: 18.4% 36.3% 6.0% inter: 11.8% 22.3% 1.3%
x264 [info]: i16 v,h,dc,p: 13% 21% 8% 58%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 14% 9% 10% 9% 14% 10% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 25% 11% 4% 9% 7% 11% 6% 12%
x264 [info]: Weighted P-Frames: Y:34.0%
x264 [info]: ref P L0: 34.6% 14.0% 25.3% 8.0% 5.2% 8.4% 4.6%
x264 [info]: ref B L0: 70.8% 13.5% 9.7% 6.0%
x264 [info]: kb/s:1618.28

encoded 101 frames, 2.08 fps, 1618.28 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset veryslow --bframes 3 --ref 5 --aq-mode 2 --sar 1:
1 --aud saisoku.y4m -o saisoku-old-aq2.mkv
yuv4mpeg: 1280x720@24/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:27.41 size: 8649
x264 [info]: frame P:53 Avg QP:29.82 size: 9181
x264 [info]: frame B:45 Avg QP:30.80 size: 4869
x264 [info]: consecutive B-frames: 21.4% 44.9% 21.4% 12.2%
x264 [info]: mb I I16..4: 65.9% 33.9% 0.2%
x264 [info]: mb P I16..4: 21.2% 11.9% 0.2% P16..4: 44.0% 3.5% 3.3% 0.0% 0
.0% skip:16.0%
x264 [info]: mb B I16..4: 2.6% 1.6% 0.0% B16..8: 36.8% 0.4% 0.7% direct:
5.2% skip:52.6% L0:54.1% L1:42.3% BI: 3.6%
x264 [info]: 8x8 transform intra:35.7% inter:97.4%
x264 [info]: direct mvs spatial:95.6% temporal:4.4%
x264 [info]: coded y,uvDC,uvAC intra: 16.9% 35.1% 4.4% inter: 9.3% 19.8% 0.6%
x264 [info]: i16 v,h,dc,p: 13% 21% 8% 58%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 13% 9% 11% 9% 15% 10% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 22% 10% 5% 11% 9% 12% 6% 12%
x264 [info]: Weighted P-Frames: Y:34.0%
x264 [info]: ref P L0: 35.0% 13.9% 24.9% 7.6% 5.4% 8.6% 4.6%
x264 [info]: ref B L0: 70.2% 13.6% 10.6% 5.5%
x264 [info]: kb/s:1390.87

encoded 101 frames, 2.56 fps, 1390.87 kb/s

[me7]

Revision 1369 just crashed on me for the second time. I started encoding the video with 1360 earlier today and after I saw 1369 with mbtree+b-pyramid support I restarted the encode and added "--b-pyramid normal" to my parameters. Because both crashes took place earlier then the progress I made during my 1360 encode and I still use the same source file and avs script I would guess that x264 is to blame.
Both crashes were 'silent' with no error messages from x264, I was just informed by Windows that x264.exe has crashed.

settings
x264.exe --rc-lookahead 60 --merange 24 --crf 19.0 --ref 8 --bframes 6 --b-adapt 2
--b-pyramid normal --direct auto --subme 10 --trellis 2 --partitions all --me umh --tune film
--threads auto --thread-input --output "output.mp4" "input.avs"

script
FFVideoSource("C:\enc\F1_T2_Video - .mkv")
crop( 0, 142, 0, -140)
Spline36Resize(1280,532)

[Selur]

@me7: might be a gcc problem,... run 'x264 --version' to check which gcc version was used and if it's an '(experimental)'-one try another build which uses e.g. gcc 4.3.

[Amefurashi]

Referring to the latest rev(1369)

Don't know if it's a bug or something, but if you don't specify "strict" or "normal" in b-pyramid option, an error occurs:

x264.exe --pass 1 --bitrate 3863 --stats "test.stats" --level 4.1 --keyint 240
--min-keyint 24 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-adapt 2 --weightb
--weightp 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1.0:0
--partitions all --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me tesa
--merange 32 --threads auto --thread-input --aq-strength 1.0 --no-dct-decimate
--rc-lookahead 60 --output NUL test.avs
x264 [error]: invalid argument: b-pyramid = --b-adapt

Please note that the "invalid argument" error occurs with any parameter put after --b-pyramid (I think x264 doesn't have a default option so it goes searching for a sub-parameter).

Regards,
AF

[Limit]

r1369 is crashing here with a segmentation fault. I'm running Ubuntu 9.10 x64 and using the standard Ubuntu GCC (Ubuntu 4.4.1-4ubuntu8) to compile x264 myself (no patches).

Input comes from Avisynth+avs2yuv with the following commandline (I'm using a self-made script to generate the cmd).

wine avs2yuv.exe andro.avs - | x264 - --stdin y4m -o andro.264 --sar 16/15 --threads auto --thread-input
--non-deterministic --crf 20 --threads auto --ssim --min-keyint 100 --keyint 500 --scenecut 80 --b-adapt 2
--bframes 6 --ref 3 --b-pyramid normal --me umh --subme 7 --merange 16 --partitions i8x8,p8x8,b8x8,i4x4
--trellis 1 --aq-mode 2 --aq-strength 1.000000 --psy-rd 1.000000:0.200000 --rc-lookahead 80 --nr 0 --direct auto
--qpmin 10 --qpmax 42 --vbv-bufsize 9000 --vbv-maxrate 3000

dmesg delivers the following lines after the crashes (I tested it 3 times):
x264[25644]: segfault at 7f761d87e22e ip 0000000000481a6e sp 00007f7612892098 error 4 in x264[400000+aa000]
x264[22732]: segfault at 7f2df0059147 ip 0000000000481a6a sp 00007f2df112c098 error 4 in x264[400000+aa000]
x264[32266]: segfault at 7f2e3c94ad9c ip 0000000000481a6e sp 00007f2e3da1d098 error 4 in x264[400000+aa000]

[Update] The non-fprofiled version seems to run without any problems.
[Update2] It happend again, but this time with the non-fprofiled version.

[LoRd_MuldeR]

Referring to the latest rev(1369)

Don't know if it's a bug or something, but if you don't specify "strict" or "normal" in b-pyramid option, an error occurs:

x264.exe --pass 1 --bitrate 3863 --stats "test.stats" --level 4.1 --keyint 240
--min-keyint 24 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-adapt 2 --weightb
--weightp 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1.0:0
--partitions all --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me tesa
--merange 32 --threads auto --thread-input --aq-strength 1.0 --no-dct-decimate
--rc-lookahead 60 --output NUL test.avs
x264 [error]: invalid argument: b-pyramid = --b-adapt

Please note that the "invalid argument" error occurs with any parameter put after --b-pyramid (I think x264 doesn't have a default option so it goes searching for a sub-parameter).

Regards,
AF

Of course writing "--b-pyramid" without a (valid) argument results in error, because that parameter does require exactly one argument. So if you write "(...) --b-pyramid --b-adapt 2 (...)", then "--b-adapt" is treated as the parameter for the preceding "--b-pyramid" command. Which of course isn't a valid value. Thus the error message. Also you'd get a lonesome "2" in the middle of nowhere...

[me7]

@me7: might be a gcc problem,... run 'x264 --version' to check which gcc version was used and if it's an '(experimental)'-one try another build which uses e.g. gcc 4.3.

It's the 'official' 32-bit build from x264.nl
C:\>x264 --version
x264 0.80.1369 ec8e586
built on Dec 9 2009, gcc: 3.4.6

[LoRd_MuldeR]

I got a crash with r1369 as well, last night. Didn't have time to reproduce or investigate. But will try to do so as soon as I return back home...

[Amefurashi]

Of course writing "--b-pyramid" without a (valid) argument results in error, because that parameter does require exactly one argument. So if you write "(...) --b-pyramid --b-adapt 2 (...)", then "--b-adapt" is treated as the parameter for the preceding "--b-pyramid" command. Which of course isn't a valid value. Thus the error message. Also you'd get a lonesome "2" in the middle of nowhere...

IIRC "older" builds of x264 (prior to mb-tree implementation) didn't need to specify an argument in b-pyramid. I must be mistaken.

:thanks:

[LoRd_MuldeR]

commit e2659dbdc0aed2d2cd4f6538faddf370e7740ada r1296
Author: Lamont Alston <wewk584@gmail.com>
Date: Mon Oct 12 23:32:16 2009 -0700

Make B-pyramid spec-compliant
The rules of the specification with regard to picture buffering for pyramid coding are widely ignored.
x264's b-pyramid implementation, despite being practically identical to that proposed by the original paper, was technically not compliant.
Now it is.
Two modes are now available:
1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.
This patch also adds MMCO support (necessary for compliant pyramid in some cases).
MB-tree still doesn't support b-pyramid (but will soon).

See:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=fc4e44f1739bca18e898dea385d8545f45ff47d3;hp=a440ab7f7b18d1ae4956d4b402e9c148ad07f1d7;hb=e2659dbdc0aed2d2cd4f6538faddf370e7740ada;hpb=b826fd5475a5e883f85e26cbf9d2c0acf5efcbd6

[MatLz]

r1369
No crashes, but I experience flickerings(again:D)

[me7]

It crashed again, Windows was "looking for a solution" and offered me to try to debug it with Visual Studio. Apparently the crash is caused by an unhandled win32 exception.

[[DB-FR] Nikko]

No problem with this version (r1369). I used these parameters for the first and second pass :

--pass 1 --bitrate 1000 --stats "analyses.stats" --level 4.1 --keyint 240 --min-keyint 24 --ref 9
--no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid normal --direct auto --deblock 1:1 --rc-lookahead 100
--subme 10 --trellis 2 --psy-rd 0.6:0 --partitions p8x8,b8x8,i4x4,i8x8 --qpmin 1 --ipratio 1.1 --pbratio 1.1
--vbv-bufsize 5000 --vbv-maxrate 5000 --me umh --thread-input --aq-mode 2 --psnr --ssim

Encode perfectly :)

Im on Windows Xp, and have Intel Core Duo proc..

[Rarsix]

It crashed and when i tried again, i got another problem :|

http://i664.photobucket.com/albums/vv2/Rarsix/abc-5.jpg

here is my setting

--profile high --level 4.1 --pass 2 --bitrate 1270 --stats ".stats" --thread-input --deblock 0:1 --keyint 240 --min-keyint 24 --bframes 6 --b-adapt 2 --b-pyramid normal --scenecut 50 --ref 9 --qpmin 8 --qpstep 16 --rc-lookahead 50 --merange 32 --me umh --direct auto --subme 10 --partitions all --trellis 2 --no-fast-pskip --psy-rd 1.00:0.40

[Jiyuu]

i was sure you were asked this all the time so i did a search for "cuda 3.0" and "fermi" but couldn't find anything.
not too long ago the specs of fermi were released(here's a link to one review on it http://www.anandtech.com/video/showdoc.aspx?i=3651 ) and from what i understood of them it made GPGPU much simpler then it is today.
now, i remember that when cuda first came out the one of the main issues raised in regards to using it in x264 was high latencies, and difficult\inefficient coding while actually using cuda, from the review i got the impression that cuda 3\fermi made coding for it a lot more flexible and similar to coding for a normal CPU, as well a lowered price for access to it.
so i wanted to see if this is likely to change anything in regards for implementing this in future versions of x264, and generally if you guys think those changes could be useful.

[Esurnir]

It crashed and when i tried again, i got another problem :|

http://i664.photobucket.com/albums/vv2/Rarsix/abc-5.jpg

here is my setting

What's your decoder?

[MatLz]

r1373
mbtree+bpyramid -> flickerings
Only mbtree -> flickerings
Only bpyramid -> good

Same results with different patched builds

[LoRd_MuldeR]

The same procedure as every year:

Provide the shortest possible unprocessed sample to re-produce the problem and tell us your complete commandline.

[Esurnir]

i was sure you were asked this all the time so i did a search for "cuda 3.0" and "fermi" but couldn't find anything.
not too long ago the specs of fermi were released(here's a link to one review on it http://www.anandtech.com/video/showdoc.aspx?i=3651 ) and from what i understood of them it made GPGPU much simpler then it is today.
now, i remember that when cuda first came out the one of the main issues raised in regards to using it in x264 was high latencies, and difficult\inefficient coding while actually using cuda, from the review i got the impression that cuda 3\fermi made coding for it a lot more flexible and similar to coding for a normal CPU, as well a lowered price for access to it.
so i wanted to see if this is likely to change anything in regards for implementing this in future versions of x264, and generally if you guys think those changes could be useful.

The problem with CUDA is that there are some application which run well on CPUs and other which perform very well on gpus, the one that perform well on GPU tend to have task which can be paralelised extremely well and are intensive.
For instance a pixel shader program on a video game must be run on -every- pixel to determine the final rgb value of it, a 1920*1200 screen got 23,040,000 pixels, so instead of running the pixel one at a time at fast speed (what a cpu would do) you can run your program on slower but far more numerous shader units (my card a 9600M got 32 shader units so you could theoretically run 32 pixel at a time).

A few problems can use such massively parallel computing power, they tend to be the same problem for which super computer are bought. Folding@home is extract a massive amount of computing power from the gpu because the gpu is ideal for it and the whole simulation is run from the gpu (the cpu is loaded at 3-10% max)

Now the problem with that approach if that if a decision inside any of the shader has to wait for another shader before it's possible to start calculating, your toast because you'll have a lot of shader which will have to pause a moment to wait for other shader to complete.

X264 is a video encoding software, in an intra frame you must wait for each macro block that it's neighbors is done before you can start predicting and/or making choice about the type of prediction.

The more "choice" that depends on another portion of the program the encoder has to take, the more "linear" the program will be, the more unsuited it is for a GPU, reducing the number of choice the software has to make would make it faster and more paralelisable but would inherently make the software less efficient (if the software has to make a choice, I assume it got a good reason to make it).

There are a few portion of x264 that can be run in paralel, for instance Motion Estimation. However if you decide to run a -portion- of the program on the GPU and the rest on CPU, instead of going full GPU (which for the reason I listed above would be crazy), once the task the GPU has been assigned has been completed, you would have to wait for the result to be ferried back from the video card ram where cuda execute it's operation, back to the main memory ram. It's not much a question of "how much of those data can be transfered back per second" but "how long do I have to wait between the moment I instruct the card to ferry those data back and when is it usable by the cpu", the link cpu ram - video ram on a nehalem is RAM -ddr2- CPU -QPI- Northbridge -pciex16- GPU the latency is quite big in term of clock cycle wasted doing -nothing- since the cpu need to have those data in order to start crunching each frame.

x264 is basicaly slow because : the software run a lot of cpu intensive dsp function, but since those dsp function are building blocks of higher level (read : C) function which themselves are called in a fairly serial way, you can't run much of the program in paralel, each frame (save I frame) must wait for their previous neighbour to be complete, each macroblock depends on the macroblock from the previous frame or from the current frame macroblock to be dealt with (if you don't wait for them and run them all at once, you have to kiss goodbye to intra blocks...)

Bottomline : a lot of operation can't be run in paralel, and the current threading mode make the thread "wait" for relevant portion of other frame to be dealt with.

Now I'm not a programmer, and I don't play one on TV, so don't hesitate to rip me a new one if there is any bullshit in this.

Edit: Realized he just fed a 1 post cuda troller.

[bob0r]

r1373
mbtree+bpyramid -> flickerings
Only mbtree -> flickerings
Only bpyramid -> good

Same results with different patched builds

Got result file of that?

[MatLz]

Sorry...

As I've a super fast uploading (5kbytes/s :D) and as I was able to reproduce with the simple "authors" avisynth script, here is all:

http://www.sendspace.com/file/2i2xvr

[Dark Shikari]

Looks perfectly normal to me. Without weighted prediction, there's a certain quantizer threshold beyond which you'll get false skips in that clip. MB-tree just happens to go above that threshold at that bitrate. That's how it's supposed to work.

[LoRd_MuldeR]

Fix two bugs in 2-pass ratecontrol
last_qscale_for wasn't set during the 2pass init code.
abr_buffer was way too small in the case of multiple threads, so accordingly increase its buffer size based on the number of threads.
May significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime.

Was that a regression with one of the recent changes/improvements or a longstanding bug?

[Dark Shikari]

Fix two bugs in 2-pass ratecontrol
last_qscale_for wasn't set during the 2pass init code.
abr_buffer was way too small in the case of multiple threads, so accordingly increase its buffer size based on the number of threads.
May significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime.

Was that a regression with one of the recent changes/improvements or a longstanding bug?The first part was a regression, but probably didn't actually affect much. The second is a longstanding bug, as old as 2-pass itself, AFAIK.

[LoRd_MuldeR]

Thx for clarification :)

[chipzoller]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?

[Dark Shikari]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?It's been threaded for a couple hundred revisions now. It's not multithreaded, but it is in a separate thread at least.

Multithreading it might be tricky, as the results of the b-pyramid changes proved that a large speedup is gained in the lookahead by not doing motion searches that aren't necessary. However, if the lookahead was split up and all the searches done separately, there would be no real way to take that shortcut.

Of course, in some cases, it may be worthwhile to do redundant work if it means better parallelism.

[kemuri-_9]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?

lookahead can have its own thread,
but as for multi-threading within it, no.

I've had ambitions of doing this for b-adapt 2, but the current framework is not very permitting for this kind of change.
I'd rather have threadpool get committed so i can utilize it here before attempting this again.

[chipzoller]

Sorry, I misspoke, I meant multithreaded, but DS answered my question. I suppose it isn't a huge loss not having it multithreaded, just that with more B-brames it becomes a significant bottleneck. If lookahead were multithreaded, what benefit, if any, would there be and at what cost?

[dwrbudr]

I was using very old x264 (r12xx) and before a couple of days I downloaded the latest r1376 from x264.nl and suddenly my encodes looks like this:

http://i.imagehost.org/0079/snapshot20091218131708.jpg (http://i.imagehost.org/view/0079/snapshot20091218131708)

x264.exe --pass 1 --bitrate 2368 --preset slow --threads auto --thread-input --tune film --sar 1:1 --output "C:\vts_11_1.h264" "C:\vts_11_1.avs"
x264.exe --pass 2 --bitrate 2368 --preset slow --threads auto --thread-input --tune film --sar 1:1 --output "C:\vts_11_1.h264" "C:\vts_11_1.avs"

The AVS is simple:

Mpeg2Source("c:\vts_11_1.d2v")
LanczosResize(720,400,0,0,-0,-0)

This happens to ALL encodes using different sources and resolutions.

I've tried to play it using CoreAVC 1.9.5 and KMPlayer's internal H264 decoder.

Since I don't use any fancy settings why is this garbled output from x264? Which older and stable version do you recommend?

[wyti]

you only need a updated decoder, try one of the latest ffdshow build, or wait for coreAVC 2.0

[Fr4nz]

[...]

Since I don't use any fancy settings why is this garbled output from x264? Which older and stable version do you recommend?

New x264 revisions work correctly, culprit are your old decoders that don't support correctly new x264 weight-p functionality.

Use an updated h264 decoder (for example, latest ffmpeg-tryouts works flawlessly).

[aegisofrime]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:

[LoRd_MuldeR]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:

It seems you totally missed those posts :p

http://forum.doom9.org/showpost.php?p=1356595&postcount=2833

http://forum.doom9.org/showpost.php?p=1358877&postcount=1

[aegisofrime]

It seems you totally missed those posts :p

http://forum.doom9.org/showpost.php?p=1356595&postcount=2833

http://forum.doom9.org/showpost.php?p=1358877&postcount=1

Actually I did see them :p Just wondering if there's anything else on the cards ;)

[Chengbin]

Actually I did see them :p Just wondering if there's anything else on the cards ;)

DS won't budge, as it would cause problems like "OMG, it's 2011 and xxx things are still not done". We've seen that with the weighted P frame project.

By not telling us the schedule allows them to be flexable. For example, if somebody paid them to do x project now, they can delay whatever it is they're working without "consequences". Or they feel that another project is more important, etc,etc.

Also, there is always a surprise factor!

[Dark Shikari]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:The biggest goal we have is to create a general-purpose ffmpeg replacement.

The goal is to make x264cli into a Just Works program that can take any input, deinterlace/ivtc it as necessary, resize it, and re-encode the audio and video. The plan is not to create something with the flexibility of ffmpeg, but rather something that Just Works as much of the time as possible. It will not be intended for the most advanced users.

The primary intended users here are threefold:

1. With an x264 that Just Works, making a good GUI becomes trivial.
2. With an x264 that Just Works, running massive batch encodes becomes far easier: Youtube-alike websites will love it.
3. With an x264 that Just Works, most "normal" users will be able to simply use "x264 inputfile -o outputfile" and get the results they want, even if the input file is interlaced or hybrid or whatnot.

[nakTT]

The biggest goal we have is to create a general-purpose ffmpeg replacement.

The goal is to make x264cli into a Just Works program that can take any input, deinterlace/ivtc it as necessary, resize it, and re-encode the audio and video. The plan is not to create something with the flexibility of ffmpeg, but rather something that Just Works as much of the time as possible. It will not be intended for the most advanced users.

The primary intended users here are threefold:

1. With an x264 that Just Works, making a good GUI becomes trivial.
2. With an x264 that Just Works, running massive batch encodes becomes far easier: Youtube-alike websites will love it.
3. With an x264 that Just Works, most "normal" users will be able to simply use "x264 inputfile -o outputfile" and get the results they want, even if the input file is interlaced or hybrid or whatnot.
That sounds like a very, very good new year resolution. Keep up the good work.

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively (without pipe or the like)?

[LoRd_MuldeR]

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively?

You can do that already with current x264! Either by using 64-Bit Avisynth or by using raw YUV files as input.

Also when piping the input data into 64-Bit x264 from a separate 32-Bit process, the 64-Bit x264 process still runs natively!

Anyway, with the upcoming changes you won't depend Avisynth anymore, so you can open the source file (e.g. MPEG or MKV files) with x264 (32-Bit or 64-Bit) directly.

Still you will need to use Avisynth for more advanced filtering/processing. So you cannot always get rid of Avisynth!

[Dark Shikari]

That sounds like a very, very good new year resolution. Keep up the good work.

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively (without pipe or the like)?Correct.

[nakTT]

You can do that already with current x264! Either by using 64-Bit Avisynth or by using raw YUV files as input.

Also when piping the input data into 64-Bit x264 from a separate 32-Bit process, the 64-Bit x264 process still runs natively!

Anyway, with the upcoming changes you won't depend Avisynth anymore, so you can open the source file (e.g. MPEG or MKV files) with x264 (32-Bit or 64-Bit) directly.

Still you will need to use Avisynth for more advanced filtering/processing. So you cannot always get rid of Avisynth!
Thanks Lord, for a very helpful explaination.

1) For me I just using resize function to downsize from 1080p to 720p and in rare cases I will use crop function. That is what I normally do.

2) As for 64bit thingy, actually I'm hoping to be able to enjoy full benefit (whatever it is) of x264 64bit over 32bit version.

3) Does Avisynth 64bit has what it takes (64bit filters and all) for me to accomplish (1) task?

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

Thank you in advance, Lord.

:thanks:

[nakTT]

Correct.
Thanks for the confirmation.

Looking at x264 git, we haven't seen any update for a while now. I just somehow knew that you are up to something special for the new year. Damn glad I was right. :D

:thanks:

[LoRd_MuldeR]

1) For me I just using resize function to downsize from 1080p to 720p and in rare cases I will use crop function. That is what I normally do.

2) As for 64bit thingy, actually I'm hoping to be able to enjoy full benefit (whatever it is) of x264 64bit over 32bit version.

3) Does Avisynth 64bit has what it takes (64bit filters and all) for me to accomplish (1) task?

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

1) It seems x264 will be able to accomplish those tasks without Avisynth in the near future (not at the moment).

3) Yes. But some more "exotic" plugins may not be available as 64-Bit versions, so you cannot use all plugins with 64-Bit Avisynth. All the basic stuff works, of course.

4) Yes. There's no "native" Avisynth on Linux yet, but because of (1) it will be more easy/convenient to use x264 on Linux (without Avisynth), I think.

[nakTT]

1) It seems x264 will be able to accomplish those tasks without Avisynth in the near future (not at the moment).

3) Yes. But some more "exotic" plugins may not be available as 64-Bit versions, so you cannot use all plugins with 64-Bit Avisynth. All the basic stuff works, of course.

4) Yes. There's no "native" Avisynth on Linux yet, but because of (1) it will be more easy/convenient to use x264 on Linux (without Avisynth), I think.
Thanks again for your (trademark) very informative explanation.

:thanks:

[nm]

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

What's stopping you now? I don't think that using x264 on Linux is particularly difficult if you only need simple resizing and cropping. Both ffmpeg and MPlayer/MEncoder do that and piping the video to x264 is pretty simple, if you don't want to use libx264 through ffmpeg or MEncoder. If you need AviSynth for some more complex processing, there's Wine and avs2yuv.

[nakTT]

What's stopping you now? I don't think that using x264 on Linux is particularly difficult if you only need simple resizing and cropping. Both ffmpeg and MPlayer/MEncoder do that and piping the video to x264 is pretty simple, if you don't want to use libx264 through the encoder frontend. If you need AviSynth for some more complex processing, there's Wine and avs2yuv.
Many thanks for the reply, nm.

I have heard about people using x264 on Linux but for me, I don't think I have technical prowess up to that level (it sounds a bit too challenging for me). Please note that I'm just a GUI user (MeGUI for my serious encoding and ASXGui for testing).

[aegisofrime]

Thanks for the reply Dark Shikari. What about improvements to speed and compressibility? I'm under the impression that the improvements you have started are on the usability front. Has x264 reached the boundaries of the H.264 specification?

[nm]

I have heard about people using x264 on Linux but for me, I don't think I have technical prowess up to that level (it sounds a bit too challenging for me). Please note that I'm just a GUI user (MeGUI for my serious encoding and ASXGui for testing).
How about HandBrake (http://handbrake.fr/) then?

[nakTT]

How about HandBrake (http://handbrake.fr/) then?
Thanks for the reply,

The main turn off for me to use Handbrake is because I can't use external audio encoder (in my case, nero AAC) for my video. Any idea on how to overcome this drawback? Thank you in advance.

:thanks:

P/S: Mod, please move my discussion (this one) to a new thread so that I won't disturb others in this thread.

[rallymax]

Hi All,
I hope this is the correct place to post.
Over in VideoHelp.com (Adobe Premiere - MainConcept's H.264 vs x264 open source encoder (http://forum.videohelp.com/topic372349.html#2000141)) I've been posting about how I'm making an Exporter for Adobe Premiere (since the bundled Main Concept (consumer level) H.264 encoder is AWEFUL - see example here - http://forum.videohelp.com/topic371339-120.html#1999573). Anyhow I'm using x264 and am very excited that you've added slice support since I started. - yippee legal AVCHD and Bluray!

I was planning on simply taking my gui settings of the "preset", "tuning", "profile", "datarate" etc etc etc and pushing them to a slightly modified x264.c's Parse( ) function and then implement the required inbound file functions...
/* input file operation function pointers */
int (*p_open_infile)( char *psz_filename, hnd_t *p_handle, x264_param_t *p_param );
int (*p_get_frame_total)( hnd_t handle );
int (*p_read_frame)( x264_picture_t *p_pic, hnd_t handle, int i_frame );
int (*p_close_infile)( hnd_t handle );
...to get the frames from Adobe but..... it seems easier for me to do the for(frame x to y) loop in Adobe and call the x264 encoder_encode function instead of being lazy with the use of Parse() and Encode(). But.... I don't know what "nal"s are or any of the other elements in Encode()'s for loop. I was hoping that someone could post a brief description of how to interface to the libx264 directly or Private Message me instead.

..or am I better off staying on the path I'm on and forcing a lot of colorspace conversion (RGBA4444 @ BT.601 -> BT.709 -> YUV12 MPG Planar) inside each p_read_frame( ) call?

Much appreciated.

I guess I'm asking how do I use the library directly instead of leaning on Encode() and Encode_frame()...


static int Encode( x264_param_t *param, cli_opt_t *opt )
{
...snip...
/* Encode frames */
for( i_frame = 0, i_file = 0; b_ctrl_c == 0 && (i_frame < i_frame_total || i_frame_total == 0); )
{
if( p_read_frame( &pic, opt->hin, i_frame + opt->i_seek ) )
break;

pic.i_pts = (int64_t)i_frame * param->i_fps_den;

if( opt->qpfile )
parse_qpfile( opt, &pic, i_frame + opt->i_seek );
else
{
/* Do not force any parameters */
pic.i_type = X264_TYPE_AUTO;
pic.i_qpplus1 = 0;
}

i_frame_size = Encode_frame( h, opt->hout, &pic );
if( i_frame_size < 0 )
return -1;
i_file += i_frame_size;

i_frame++;

/* update status line (up to 1000 times per input file) */
if( opt->b_progress && i_frame % i_update_interval == 0 )
{
int64_t i_elapsed = x264_mdate() - i_start;
double fps = i_elapsed > 0 ? i_frame * 1000000. / i_elapsed : 0;
double bitrate = (double) i_file * 8 * param->i_fps_num / ( (double) param->i_fps_den * i_frame * 1000 );
if( i_frame_total )
{
int eta = i_elapsed * (i_frame_total - i_frame) / ((int64_t)i_frame * 1000000);
sprintf( buf, "x264 [%.1f%%] %d/%d frames, %.2f fps, %.2f kb/s, eta %d:%02d:%02d",
100. * i_frame / i_frame_total, i_frame, i_frame_total, fps, bitrate,
eta/3600, (eta/60)%60, eta%60 );
}
else
{
sprintf( buf, "x264 %d frames: %.2f fps, %.2f kb/s", i_frame, fps, bitrate );
}
fprintf( stderr, "%s \r", buf+5 );
SetConsoleTitle( buf );
fflush( stderr ); // needed in windows
}
}

[Dark Shikari]

If you're looking to write a demuxer/input module for x264, you should drop by #x264dev on Freenode; we've basically rewritten the entire input framework so it would be a bit silly to try to write one for the old framework now.

Also, in the meantime, you could just export to a HuffYUV AVI file and then encode with x264 after that.

[creamyhorror]

Good to see you here, rallymax. Hope you don't have to discard too much of your work :S

[Dark Shikari]

OK, this will be more complicated. To make a plugin, you can't extend the CLI, you have to write your own code.

If you want to be able to export both video and audio muxed to a file, you'll need:

libswscale (RGB->YUV conversion)
libx264 (h264 encoding)
libavcodec, libvorbis, libmp3lame, or some other audio encoder
libavformat, gpac, or some other muxer

It wouldn't be too hard--just a game of tying together a bunch of existing libraries--and would probably be a good introduction to them in general.

[rallymax]

Thanks Dark'.
I didn't know about libswscale so that will help a lot.
I'm going to skip audio for now. Muxing it doesn't really help the workflow because you can export audio only from Premiere already. The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.

My challenge now is to understand what is required to take the H.264 stream and put it into the most basic of containers.

From what you wrote it looks like I should use libavformat to make it into an AVI etc.

thanks for the help over on the IRC and here.

[Dark Shikari]

Thanks Dark'.
I didn't know about libswscale so that will help a lot.
I'm going to skip audio for now. Muxing it doesn't really help the workflow because you can export audio only from Premiere already. The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.Wait, if you don't intend to include audio, why do you need to mux the H.264 at all?My challenge now is to understand what is required to take the H.264 stream and put it into the most basic of containers.

From what you wrote it looks like I should use libavformat to make it into an AVI etc.H.264 doesn't go in AVI. I'd use one of the following:

libavformat for mkv or mp4s
gpac for mp4 (see x264's mp4 output module for an example)
x264's matroska.c for mkv (see x264's mkv output module)
libmp4v2 for mp4

[rallymax]

I guess I'm confused then - re no need to mux.
I was of the understanding that if I take the output stream of libx264 and dump it into a file that it would not be openable by most programs. It would need to be containered in something like mp4 first.

[Dark Shikari]

I guess I'm confused then - re no need to mux.
I was of the understanding that if I take the output stream of libx264 and dump it into a file that it would not be openable by most programs. It would need to be containered in something like mp4 first.This is true, it would be a nice convenience to mux it first, even though the user will have to remux it with the audio himself later.

[kieranrk]

The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.


Couldn't you do the audio first then let your plugin read that in for muxing? (I assume you can't access the audio exporting from the plugin API?) Also the ts muxer I'm writing could easily write the AVCHD structure (not sure about Blu-ray though) whereas the one in libavformat is very broken.

[rallymax]

kieranrk, thanks for the offer (ie AVCHD file structure).
I know that I'm going to use Encore to make my menus etc so I'm happy to have the plugin only output H.264 for now.

The Adobe API does provide audio as well, I was simply ignoring it because the provided MP3 or Dolby Digital exporters work fine. It's the Main Concept H.264 encoder that is so horrible that I've decided to put the time in to make a new Export plugin using x264. As many have said, I could simply export to an intermediate like HuffyYUV but I'd like to make the workflow for myself (and the less-technical friends that I'll give the plugin to), as simple as possible.

If I can add a plugin that has a dialog box with basic buttons for AVCHD or BluRay legal output as well as a file size estimate as a % of the disc space then it's basically idiot proof. I'm not going to take care of things like resize since you should do that in the project itself.

Unfortunately having just looked at the libswscale libarary it doesn't look like there is a RGB->YUYV->YUV12planar conversion path. I'll keep looking.

I also just looked at the libavformat and it doesn't seem very easy to understand how you take the output of the encode and stuff it into that library to get a mux'ed mp4 file. I'll keep looking though.

Sure is a shame that the x264VfW project died - they have done this all already and more generically. I'm only doing it a dedicated plugin because I know the Adobe API quite well (vs VfW or DirectShow or Media Foundation).

[Dark Shikari]

Unfortunately having just looked at the libswscale libarary it doesn't look like there is a RGB->YUYV->YUV12planar conversion path. I'll keep looking.There's an RGB->YV12 planar conversion path, unless you meant "RGB is planar too".

[rallymax]

can you point me to it. I found the declaration

rgb2rgb.c # 74
void (*rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
long width, long height,
long lumStride, long chromStride, long srcStride);
but couldn't find the implementation anywhere. Is it created as a part of the template magic that's happening in rgb2tgb_template.c (I haven't got my head around all that name casting yet).

[rallymax]

never mind. grep'ed and found all the references. I'll try to get my head around all that renaming stuff

[Dark Shikari]

can you point me to it. I found the declaration

rgb2rgb.c # 74
void (*rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
long width, long height,
long lumStride, long chromStride, long srcStride);
but couldn't find the implementation anywhere. Is it created as a part of the template magic that's happening in rgb2tgb_template.c (I haven't got my head around all that name casting yet).Again, like with x264, you don't seem to understand the concept of an external API.

You only call swscale though the swscale functions in swscale.h. You should never look at any code inside swscale for any reason.

The functions you need are:

sws_getContext
sws_scale
sws_freeContext

Nothing else.

[rallymax]

Thanks Dark. wise words.
You just saved me A LOT of time :)
you wouldn't happen to know which of the many functions you need to use in avformat.h would you?
It seems that it's similar needing
avformat_alloc_context
but then it gets a little blurry about what you would do next. - And I can't seem to find an example.

[rallymax]

I found a swscale and avformat example. I should be good to go now.
ffmpeg\output_example.c

[rallymax]

Hi all,
if I'm supposed to use encoder_encode() and the x264 example shows in Encode() and Encode_frame() that after the encoder_encoder() it then calls the encoder_nal_encode()..... then..... can someone explain to me what a "nal" is? It's a little hard to get over the learning curve/hump when you suggest I don't look at the src doing the actual work and only use/look at the external api. It's really hard coz there are no docs or newbie-level commented examples on what required to use the library. x264 isn't the only culpret. the libavformat is equally as confusing. 'fortunately the output example using swscale and avformat gives up most of the secrets.
sorry if it sounds like I'm complaining. I'm just frustrated.

[LoRd_MuldeR]

I don't think you are supposed to call encoder_nal_encode() from "outside" when using the libx264 library.

At least not in up-to-date x264. It used to be a "public" function, but it is no longer after this API change was applied:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=031e25d8cc909af2d138f9fedc8252961f34a6ac

"NAL" refers to "Network Abstraction Layer". The H.264 specs say:
NAL unit: A syntax structure containing an indication of the type of data to follow and bytes containing that data in the form of an RBSP interspersed as necessary with emulation prevention bytes.

[rallymax]

I'm getting the feeling that I should "borrow" from the Encode() / Encode_frame() example since it shows how to open the encoder then process pictures and then dump the *pic to whatever you want. I want mp4 container so I'm going to use the implementation that's already there.

[Dark Shikari]

I'm getting the feeling that I should "borrow" from the Encode() / Encode_frame() example since it shows how to open the encoder then process pictures and then dump the *pic to whatever you want. I want mp4 container so I'm going to use the implementation that's already there.You should look at the changes in the latest lavf/ffms patch (see the relevant thread), as the easiest way to use the API with mp4 is to:

1) set b_repeat_headers to 0
2) set b_annexb to 0
3) call x264_encoder_headers to get the headers
4) send these off to the muxer
5) call x264_encoder_encode for each frame, sending them off to the muxer

This method is used in x264 with said patch applied, so you can use it as an example.

[rallymax]

A stupid question to be sure but I'm going to ask it anyway.
Are the bit rates & buffer size in the params.rc byte or kbytes and is it per frame or per second?
I ask because the FFmpeg avcodec shim (libx264.c) is dividing the number by 1000.
x4->params.rc.i_bitrate = avctx->bit_rate / 1000;
x4->params.rc.i_vbv_buffer_size = avctx->rc_buffer_size / 1000;
x4->params.rc.i_vbv_max_bitrate = avctx->rc_max_rate / 1000;
I wonder because I used the x264_param_default and bypassed pretty much everything in the above file and my 1440x1080 5 second machbeth chart video with a burnt in time code is only 45k! (don't get me wrong, I'm thrilled that my Premiere plugin is working, but there is something definitely amiss with my datarate! :D )
'pointers appreciated.

[rallymax]

kinda offtopic: RE: libavcodec & libavformat
What container (mpeg-2, other) is it ok to mux a H.264 and a AC3 stream?
Using the FFmpeg output_example.c as a reference I've not been able to get avformat/avcodec to open a legal audio stream yet. It's fine opening a mpeg-2 container and putting a video stream of H.264 in it.
thx.

[Blue_MiSfit]

If by MPEG-2 you mean MPEG Program Stream or Transport Stream, then yes both can hold H.264 just fine, though the latter is more common IME.

H.264 + AC3 is compatible with almost every container, including TS, PS/MPG, MKV, MP4, M2TS, etc... It's not compatible with ASF/WMV last I checked, and AC3 doesn't play nice with MOV last I checked either. Hell, you can probably bastardize AVI into doing it as well ;)

~MiSfit

[creamyhorror]

By the way, rallymax, DebugMode Frameserver apparently now supports Premiere CS4: http://www.debugmode.com/frameserver/newin27.php and it's been open-sourced.

So Premiere CS4 users have a serviceable x264 option now.

[Lam3rD]

If by MPEG-2 you mean MPEG Program Stream or Transport Stream, then yes both can hold H.264 just fine, though the latter is more common IME.

MPEG-PS can hold h.264? Can you share your source, as this isn't mentioned in wikipedia or anywhere I could find.
http://en.wikipedia.org/wiki/Comparison_of_container_formats
(I'm not saying that wikipedia is the most correct source of information that exist)

Why do they need to combine new technology with obsolete technology, when there are better alternatives? Where is it used and how could one multiplex them?

[kieranrk]

kinda offtopic: RE: libavcodec & libavformat
What container (mpeg-2, other) is it ok to mux a H.264 and a AC3 stream?
Using the FFmpeg output_example.c as a reference I've not been able to get avformat/avcodec to open a legal audio stream yet. It's fine opening a mpeg-2 container and putting a video stream of H.264 in it.
thx.

You might well have some problems with libavformat's ts muxer because it has a lot of deficiencies.

[sneaker_ger]

MPEG-PS can hold h.264? Can you share your source, as this isn't mentioned in wikipedia or anywhere I could find.

mkv2vob (http://www.mkv2vob.com) and ffmpeg can mux H.264 into PS AFAIK(which can be played on the PS3 for example), but I don't know if it's allowed by any standard or some kind of "hack".

[CruNcher]

last time i tested it was far away from ISO interoperable, also it is nice to have H.264 in PS seeking is very fast and complexity isn't really high :D
Personally i find it perfect for H.264 with AC3 as audio, but that's only my personal view :)

[Blue_MiSfit]

I do wish for better seeking performance with H.264 in MKV or MP4 :(

[nurbs]

Try shorter keyframe intervals.

[Blue_MiSfit]

Well sure, that's always an option, but how come other containers seek better, even with default keyints?

[nurbs]

What other conatainers? The only container apart from mp4 and mkv people normally use for AVC is m2ts and then the streams are mostly limited to a 1 or 2 second keyint to be blu-ray/avchd compliant.

edit:
I'm genuinely interested. Reading my own post it sounds a bit provocative although it's not meant to be.

[Elbart_]

Personally, I only had seeking issues with h264 and MP4 when I set MPC to use its internal MP4-splitter. I disabled it, e voila, with using Haali's splitter, seeking works instantly.

[LoRd_MuldeR]

When I try to compile the latest x264 GIT version (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=9899cd539f738ad12750683e4079f08ee32ccc0d), I get this error:

ar rc libx264.a common/mc.o common/predict.o common/pixel.o common/macroblock.o
common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/m
date.o common/set.o common/quant.o common/vlc.o encoder/analyse.o encoder/me.o e
ncoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/
cavlc.o encoder/encoder.o encoder/lookahead.o common/x86/mc-c.o common/x86/predi
ct-c.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86
/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x8
6/quant-a.o common/x86/sad-a.o common/x86/cpu-a.o common/x86/dct-32.o common/x86
/pixel-32.o
ranlib libx264.a
gcc -o x264.exe x264.o input/yuv.o input/y4m.o input/thread.o output/raw.o outpu
t/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o input/a
vs.o input/thread.o libx264.a -lpthreadGC2 -lwsock32 -s
input/thread.o:thread.c:(.data+0x0): multiple definition of `thread_input'
input/thread.o:thread.c:(.data+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

:confused:

[kemuri-_9]

gcc -o x264.exe x264.o input/yuv.o input/y4m.o input/thread.o output/raw.o outpu
t/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o input/a
vs.o input/thread.o libx264.a -lpthreadGC2 -lwsock32 -s
input/thread.o:thread.c:(.data+0x0): multiple definition of `thread_input'
input/thread.o:thread.c:(.data+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1[/code]

:confused:

r1415 was a wrong commit as it added input/thread.o to the x264.exe link again (so it's on there twice and causes that multiple definition error), revert back to r1414 which works fine.
the GIT has already reset back to r1414.

[LoRd_MuldeR]

r1415 was a wrong commit as it added input/thread.o to the x264.exe link again (so it's on there twice), revert back to r1414 which works fine

Okay. Thanks for clarification. Seems it was removed from GIT in the meantime :)

[skottish]

I'm getting a segfault trying to encode from png frames:

x264 --version
x264 0.84.1414 63b74d8
built on Jan 30 2010, gcc: 4.4.3

Platform: X86_64
System: LINUX
asm: yes
avs input: no
lavf input: yes
ffms input: no
mp4 output: no
pthread: yes
debug: yes
gprof: no
PIC: yes
shared: yes
visualize: no

ffmpeg -version
FFmpeg version SVN-r21544, Copyright (c) 2000-2010 Fabrice Bellard, et al.
built on Jan 30 2010 10:35:01 with gcc 4.4.3
configuration: --prefix=/usr --enable-gpl --enable-libx264 --enable-shared --disable-static --enable-pthreads --enable-network --enable-x11grab --enable-postproc --enable-avfilter --enable-avfilter-lavf
libavutil 50. 7. 0 / 50. 7. 0
libavcodec 52.49. 0 / 52.49. 0
libavformat 52.48. 0 / 52.48. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.17. 0 / 1.17. 0
libswscale 0. 9. 0 / 0. 9. 0
libpostproc 51. 2. 0 / 51. 2. 0


gdb x264
GNU gdb (GDB) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/x264...done.
(gdb) run ./kali_%06d.png --preset veryslow --threads 0 --fps 9.9 -o 4.mkv
Starting program: /usr/bin/x264 ./kali_%06d.png --preset veryslow --threads 0 --fps 9.9 -o 4.mkv
[Thread debugging using libthread_db enabled]
[image2 @ 0x6a33b0]MAX_READ_SIZE:5000000 reached
lavf [warning]: converting from rgb24 to YV12
lavf [info]: 720x576p 0:1 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
[New Thread 0x7ffff574a710 (LWP 22789)]
x264 [info]: profile High, level 4.0

Program received signal SIGSEGV, Segmentation fault.
0x000000000040cfd6 in x264_nal_encode (dst=0xfffffffff574b015 <Address 0xfffffffff574b015 out of bounds>, b_annexb=0,
nal=<value optimized out>) at common/common.c:735
735 common/common.c: No such file or directory.
in common/common.c
(gdb) where
#0 0x000000000040cfd6 in x264_nal_encode (dst=0xfffffffff574b015 <Address 0xfffffffff574b015 out of bounds>,
b_annexb=0, nal=<value optimized out>) at common/common.c:735
#1 0x0000000000415f1b in x264_encoder_encapsulate_nals (h=0xa1d7b0) at encoder/encoder.c:1183
#2 0x00000000004160c6 in x264_encoder_headers (h=0xa1d7b0, pp_nal=0x7fffffffe0d0, pi_nal=0x7fffffffe0ec)
at encoder/encoder.c:1221
#3 0x00000000004074d6 in Encode (param=<value optimized out>, opt=0x7fffffffe7e0) at x264.c:1514
#4 0x0000000000408e78 in main (argc=<value optimized out>, argv=<value optimized out>) at x264.c:127

[kemuri-_9]

I'm getting a segfault trying to encode from png frames:

you'll get a seg fault encoding anything on any system that formerly had -DHAVE_MALLOC_H in the gcc CFLAGS, which includes linux.
r1413 broke a number of things,
we're working getting a fix committed.
for the time being revert to r1412 if you don't want to wait for it.

[skottish]

you'll get a seg fault encoding anything on any system that formerly had -DHAVE_MALLOC_H in the gcc CFLAGS, which includes linux.
r1413 broke a number of things,
we're working getting a fix committed.
for the time being revert to r1412 if you don't want to wait for it.

Yikes!

Thanks for the response. I don't need x264 right now; I was just testing to see if I could lose mjpegtools once and for all (png2yuv).

[Dark Shikari]

Fixed.

[skottish]

Fixed.

Yes it is. Very, very nice!

[Snowknight26]

Fixed.

Now how about that other one (http://forum.doom9.org/showthread.php?p=1366915#post1366915)? :)

[LoRd_MuldeR]

Is it intensional that b_intra_refresh isn't initialized in x264_param_default() (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/common.c;h=6d1d7f06392b6bd2d8d7abd64d94c1b389e9b531;hb=fcf70c2f9853d74ac077a7af016e28eef05e2f5a#l39) ?

[Dark Shikari]

Is it intensional that b_intra_refresh isn't initialized in x264_param_default() (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/common.c;h=6d1d7f06392b6bd2d8d7abd64d94c1b389e9b531;hb=fcf70c2f9853d74ac077a7af016e28eef05e2f5a#l39) ?Should be in theory, but it's memsetted to zero to begin with.

[b66pak]

@Dark Shikari it is possible to implement a cutting process for raw output when encoding with a qpfile?

example: qpfile.txt


100 I -1
200 I -1 new
300 I -1
400 I -1 new
500 I -1


an the output will be:

output.264 (with frames 000 to 199)
output(2).264 (with frames 200 to 399)
output(3).264 (with frames 400 to end)
_

[me7]

I grabbed x264 r1419 from x264.nl a few hours ago, now the site has r1416 only. Was 1419 pulled for being broken?

[Dark Shikari]

I grabbed x264 r1419 from x264.nl a few hours ago, now the site has r1416 only. Was 1419 pulled for being broken?There was never an r1419. It was an x264.nl build error due to a broken merge. It didn't differ from r1416.

[b66pak]

@Dark Shikari it is possible to implement a cutting process for raw output when encoding with a qpfile?

example: qpfile.txt


100 I -1
200 I -1 new
300 I -1
400 I -1 new
500 I -1


an the output will be:

output.264 (with frames 000 to 199)
output(2).264 (with frames 200 to 399)
output(3).264 (with frames 400 to end)
_


or may be a "--cutfile" option (reading from a cutfile.txt)?
_

[rallymax]

Hi Dark',

I noticed that you were the last person to checkin changes to libavcodec/libx264.c in the FFmpeg project.

Update libx264.c to use new libx264 features
With b_keyframe instead of IDR for detecting keyframes, ffmpeg should now
support periodic encoding with periodic intra refresh (although there is no
interface option for it yet).
Set the new timebase values for full VFR input support.
Bump configure to check for API version 83.

What do these changes do to the default values?
My goal here is AVCHD and Blu-ray legal output and want to work out what I need to tweak from the default init of the oc-> struct.

[Dark Shikari]

Blu-ray legal output is not possible through libavcodec currently.

The default values did not change.

[rallymax]

can you elaborate on that. ie - can I make changes that will make it legal?

[Dark Shikari]

can you elaborate on that. ie - can I make changes that will make it legal?Not easily. You need a patched x264, and you'll find it much easier to use (lib)x264 directly.

[Snowknight26]

Any chance of differing the FFMS2 DLL name between 32-bit and 64-bit builds? Can't seem to have both x264 versions in the same directory otherwise.

[kemuri-_9]

Any chance of differing the FFMS2 DLL name between 32-bit and 64-bit builds? Can't seem to have both x264 versions in the same directory otherwise.

put the DLLs elsewhere?
windows does have syswow64 and system32 for this...
or you could make your own directory <somedir> underneath each and add system32\<somedir> to the PATH
to have window's automatic syswow64 -> system32 mapping (for x86) do the right thing (x64 would already be correct in this situation).

[LoRd_MuldeR]

Can't it be linked statically to remove the DLL dependency and avoid possible confusion?

With the "put the DLL in your system folder" method you will run into the "DLL Hell" problem, as soon as you want to test different x264 builds that expect different FFMS2 versions...

[rallymax]

Not easily. You need a patched x264, and you'll find it much easier to use (lib)x264 directly.

Well, I'm hacking on libavformat anyhow because the m2tsenc doesn't have BDAV/BDMV support. (not that it's a hard thing to do to put a 4 byte TP_extra_header on front of the 188byte packet).

I'm also not a huge fan of how ffmpeg passes params to x264 so I'm modifying the struct directly.
Consequently - I can therefore treat my use of x264 as a direct libx264 usage.

So, if you can point me to the exact patch I need and a comprehensive list of what needs to change in the x264_param struct I'll be able to get it going.

much appreciated.

btw, can someone send me a message as to how I get a username on the SVN repos for FFmpeg so that I can check in the feature add of the BDAV/BDMV support?

[Dark Shikari]

Well, I'm hacking on libavformat anyhow because the m2tsenc doesn't have BDAV/BDMV support. (not that it's a hard thing to do to put a 4 byte TP_extra_header on front of the 188byte packet).

I'm also not a huge fan of how ffmpeg passes params to x264 so I'm modifying the struct directly.
Consequently - I can therefore treat my use of x264 as a direct libx264 usage.

So, if you can point me to the exact patch I need and a comprehensive list of what needs to change in the x264_param struct I'll be able to get it going.

much appreciated.The NAL HRD patch. Use search!btw, can someone send me a message as to how I get a username on the SVN repos for FFmpeg so that I can check in the feature add of the BDAV/BDMV support?You don't "get a username". You submit your patch to the mailing list and follow the guidelines for patch submission.

[kemuri-_9]

Can't it be linked statically to remove the DLL dependency and avoid possible confusion?

A) MinGW: yes
B) ICL:
- I) x86: with a lot of annoying workarounds
- II) x86_64: absolutely not


With the "put the DLL in your system folder" method you will run into the "DLL Hell" problem, as soon as you want to test different x264 builds that expect different FFMS2 versions...
sure, but seeing at how little the FFMS2 API changes, I don't really care.

[Brother John]

I recently stumbled across a minor inconsistency between the --psy-rd settings given at the command line and the user data x264 writes to the stream. Both these command lines
x264 test.avs -o test15.264 --psy-rd 1.0:0.15
and
x264 test.avs -o test20.264 --psy-rd 1.0:0.20
according to MediaInfo produce identical user data containing
psy=1 / psy_rd=1.0:0.2
(tested with x264 r1416 win32 from x264.nl)
The file sizes are slightly different though, so I guess the encoding itself is fine and the second decimal gets lost on its way to the user data string.

It happens consistently for me. Can anyone confirm this behaviour?

[Underground78]

It happens consistently for me. Can anyone confirm this behaviour?

Yes but it's the normal behaviour (cf this (http://forum.doom9.org/showthread.php?p=1359071#post1359071)) ...

[Underground78]

Hello,

Is it possible that some recent changes in mp4 output have made mp4 files created by x264 incorrectly decoded by VLC (screenshot (http://img10.hostingpics.net/pics/2097bug_mp4.png) - video.mp4 (http://www.mediafire.com/?w0jlmzlzb5g)) ? The same file is correctly played by MPC-HC and is correctly played by VLC after remuxing it to MKV.

Thanks

[Dark Shikari]

Hello,

Is it possible that some recent changes in mp4 output have made mp4 files created by x264 incorrectly decoded by VLC (screenshot (http://img10.hostingpics.net/pics/2097bug_mp4.png) - video.mp4 (http://www.mediafire.com/?w0jlmzlzb5g)) ? The same file is correctly played by MPC-HC and is correctly played by VLC after remuxing it to MKV.

ThanksVLC has always sucked with MP4 files. I've seen that problem for years.

[Underground78]

Ok, thank you.

[Sharc]

I recently stumbled across a minor inconsistency between the --psy-rd settings given at the command line and the user data x264 writes to the stream. Both these command lines
x264 test.avs -o test15.264 --psy-rd 1.0:0.15
and
x264 test.avs -o test20.264 --psy-rd 1.0:0.20
according to MediaInfo produce identical user data containing
psy=1 / psy_rd=1.0:0.2
(tested with x264 r1416 win32 from x264.nl)
The file sizes are slightly different though, so I guess the encoding itself is fine and the second decimal gets lost on its way to the user data string.

It happens consistently for me. Can anyone confirm this behaviour?
MediaInfo displays only 1 digit after the decimal, i.e. it rounds 0.15 to 0.2.

[LoRd_MuldeR]

MediaInfo displays only 1 digit after the decimal, i.e. it rounds 0.15 to 0.2.

Nope. MediaInfo shows the x264 settings string as stored in the file. x264 will round Psy RDO/Trellis to one digit when writing that info, so it cannot be read out at a higher precision later:

/****************************************************************************
* x264_param2string:
****************************************************************************/
char *x264_param2string( x264_param_t *p, int b_res )
{
int len = 1000;
char *buf, *s;
if( p->rc.psz_zones )
len += strlen(p->rc.psz_zones);
buf = s = x264_malloc( len );
if( !buf )
return NULL;

[....]

s += sprintf( s, " psy=%d", p->analyse.b_psy );
if( p->analyse.b_psy )
s += sprintf( s, " psy_rd=%.1f:%.1f", p->analyse.f_psy_rd, p->analyse.f_psy_trellis );

If you want x264 to store those values at a higher precision, you need to change exactly two characters ;)

[Sharc]

Ah, good to know, thanks.

[hajj_3]

x264.nl site has been down for a few days, is there server problems or something?

[mariush]

Yeah... if you guys need some temporary host let me know, I'm willing to help you out

[sneaker_ger]

It's probably just a temporary issue. Use http://mirror01.x264.nl for now.

[aegisofrime]

The latest revision, 1442 has this feature:

iPhone compilation support

:D

Does that mean x264 encoding on the iPhone? I'm really looking forward to seeing what speeds it can do.

[Dark Shikari]

The latest revision, 1442 has this feature:

iPhone compilation support

:D

Does that mean x264 encoding on the iPhone? I'm really looking forward to seeing what speeds it can do.It can do realtime (~30fps) 320x240 on an iPhone 3GS with ~ultrafast to ~veryfast. It's probably good for realtime ~15fps full-screen video calls.

[hajj_3]

huge changelog in 1442 compared to 1416, great job by all of you :)

[CpT]

HOly crap:cool: Thanks guys!

[moviefan]

It can do realtime (~30fps) 320x240 on an iPhone 3GS with ~ultrafast to ~veryfast. It's probably good for realtime ~15fps full-screen video calls.

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.

[aegisofrime]

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.

This is probably a question for Apple rather than anyone else. :D Unless you were being sarcastic of course :p

I guess it can be used to replace the current H.264 encoder that the movie recorder current uses; I doubt it's using x264 (since r1442 is the first that can run on the iPhone?). Although GNU licensing issues will probably prevent Apple using it officially?

[Dark Shikari]

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.Obviously we need to add a mirror ;)

[alexVS]

Thanks a lot for x264.exe! This encoder is just great!
Could you please clear up some questions to me:
1. I have not very fast CPU: AMD Athlon64 X2 4000+. Is there a version of x264.exe optimized for this CPU?
2. How much faster x264 64bit works relatively to x264 32bit on the same computer?
3. In megui\tools\x264 folder there is another file "x264..exe" (with dot after filename). What is this file?
Thanks again!

[nurbs]

1) Doesn't matter, you can use any version. The speed differences are minimal.
2) x264 itself will be about 10% faster, but depending on how much time is spent on decoding, resizing and filtering the gain you'll experience will be lower.
3) There isn't in mine, so it's probably a file you accidentally renamed.

[LoRd_MuldeR]

I have not very fast CPU: AMD Athlon64 X2 4000+. Is there a version of x264.exe optimized for this CPU?

Well, if "version" refers to the revision of x264, then one should always pick the latest revision available, because the speed of x264 is constantly improved by the developers.

But if you are referring to "CPU optimized" builds, then picking a build that was optimized for your CPU will only give a minor speed-up - compared to a "generic" build of the same x264 revision.

That's because those compiler-optimizations only effect the plain C code in x264, not the hand-optimized assembler code. And all the speed-critical functions in x264 are assembler code!

(Oh, and note that "amdfam10" optimized builds will NOT work correctly on your CPU! You probably should use a "athlon64-sse3" optimized build. Or simply a "generic" one)

[me7]

Is there a reason why the x64 builds on x264.nl are often outdated? Is there a better place to get x64 builds?

[bob0r]

They are compiled by JEEB.
And by outdated you mean a couple of hours/days behind the 32bit version?

Compiling 64bit requires some manual patching.
Fixes are present, but getting opensource people to do something they hadn't planned.... good luck James!

You must be glad you are getting them this fast at all, because i am too lazy to ever update my XP-32bit.

[JEEB]

Is there a reason why the x64 builds on x264.nl are often outdated? Is there a better place to get x64 builds?
You can always see my page if it's any faster than the update script on bob0r's site.

I think the 64bit builds have been online for... at least four or so hours, while because of revision numbers etc. as well as the updating script it took a few hours to get to the site (git hashes don't seem to be easy enough to bring info to users it seems ;) -- but that's already automatized at the moment).

Granted, I only woke up 6 or so hours ago, so yes -- the builds were a few hours late since I wasn't up n' running at the moment of the pushes. Also, I'm looking forward to actually automatizing this win64 patching of ffmpeg here by using git commit in order to keep the change there :3

Building just the 64bit x264 wouldn't be as problematic if we wouldn't have ffmpeg in there, but I guess that's something that you can deal with it if you try enough :3

Edit: Of course, you could always check out if anyone's doing builds without ffmpeg/ffms2, since that can be automated quite well. I might actually try doing that some day if I feel the need.

[LoRd_MuldeR]

Just for info, another source for pre-compiled x264 CLI for Windows (32-Bit and 64-Bit) is here:
http://www.xvidvideo.ru/x264-video-codec/

[me7]

Thanks for the insight, didn't know that ffmpeg complicates the process.
And yes, a few hours behind isn't too bad, I just didn't know that the 64-bit version requires some additional patching and I wondered if someone thinks "Alright, I just did the x84 compile but I will delay the x64 one, just to keep 'em waiting a bit longer".

Keep up to good work :thanks:

[bob0r]

Additional info: x264.nl checks for updates 24/7 again.
The script also auto mirrors the same rev from JEEB's site.

However since i can't code, the last mirror took a while again.

Let me show you part of the fail script:


revs_dir=/home/xuser/revs/64bit/revision$rev/

if [ ! -d $revs_dir ]; then mkdir -p $revs_dir; fi

if [ -d $revs_dir ]; then
echo ------------------------------------------------;
echo - no new updates, current 64bit revision: $rev ;
echo ------------------------------------------------;
exit 0;
fi


That's why it failed! :o

[LoRd_MuldeR]

I'm encountering reproducible crashes right at the beginning of the second pass with libx264 r1680:

Encoding Video codec : x264: 00:00:00
Encoding Phase : 2nd Pass

Program received signal SIGSEGV, Segmentation fault.
0x03cc7953 in x264_load_deinterleave_8x8x2_fenc_ssse3 () from D:\Avidemux 2.5\libx264-102.dll
(gdb) bt

#0 0x03cc7953 in x264_load_deinterleave_8x8x2_fenc_ssse3 () from D:\Avidemux 2.5\libx264-102.dll
#1 0x03c9aff9 in x264_ac_energy_mb (h=<incomplete type>, mb_x=0, mb_y=0, frame=0x863c440) at encoder/ratecontrol.c:227
#2 0x03c9b5fa in x264_adaptive_quant_frame (h=<incomplete type>, frame=0x863c440, quant_offsets=0x0) at encoder/ratecontrol.c:330
#3 0x03c9b97a in x264_macroblock_tree_read (h=<incomplete type>, frame=0x863c440, quant_offsets=0x0) at encoder/ratecontrol.c:389
#4 0x03cb8305 in x264_encoder_encode (h=<incomplete type>, pp_nal=0x28fab4, pi_nal=0x28fab0, pic_in=0x3c365c8, pic_out=0x28fa30) at encoder/encoder.c:2334
#5 0x03bb2352 in x264Encoder_encodeFrame () from D:\Avidemux 2.5\plugins\videoEncoder\libADM_vidEnc_x264.dll
(gdb)

Single-Pass encoding runs through just fine. Any ideas? :confused:

[Dark Shikari]

That sounds rather unlikely, becase r1680 is 104, not 102.

[LoRd_MuldeR]

That sounds rather unlikely, becase r1680 is 104, not 102.

Had to change that, as the calling app still expects 102. I also compensated the changes between 102 and 104, hopefully :)

Furthermore, as always, you've given absolutely no information I could possibly use to debug any problem.

Here are the settings I used:

#options: 352x288 fps=25/1 timebase=1/25 cabac=1 ref=1 deblock=1:-1:-1 analyse=0x1:0 me=dia subme=2 psy=1 psy_rd=0,00:0,00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=8 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=750 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=abr mbtree=1 bitrate=500 ratetol=1,0 qcomp=0,60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1,40 aq=1:1,00

If you need any more information, please tell me what you need exactly.

[Dark Shikari]

That's going to be hard to "compensate" for, given the fact that the NV12 change was a rather large API change. You can't just flip the number back and expect it to work!

Fix the bloody calling application.

Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

[LoRd_MuldeR]

That's going to be hard to "compensate" for, given the fact that the NV12 change was a rather large API change. You can't just flip the number back and expect it to work!

To my surprise it seems to work pretty well :eek:


Fix the bloody calling application.

Of course that is the "proper" solution, but it cannot always be done immediately. So I try to use a temporary workaround, until the calling app is updated.


Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

:thanks: I will check this as soon as possible...

[LoRd_MuldeR]

Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

:thanks: I will check this as soon as possible...

Yup, I can confirm it works now. Thanks for the quick fix! :)

[LoRd_MuldeR]

Is anybody else experiencing crashes of 'x264.exe' during the profiling when trying to build r1722 ???

http://img706.imageshack.us/img706/1518/x264r1722fprofilecrash.th.png (http://img706.imageshack.us/img706/1518/x264r1722fprofilecrash.png)

gcc version 4.5.1 (x86.generic.Komisar) (GCC)

Apparently there's no crash with an "--enable-debug" build, so I cannot debug this :rolleyes:

[LoRd_MuldeR]

Small update:

I made a non-debug and non-fprofiled build, then tested it with all the various parameters combinations that are used in fprofile. No crash...

[MasterNobody]

LoRd_MuldeR
Can't replicate it here. Not with GCC 4.4.3 not with 4.5.1 (http://komisar.gin.by/mingw/cross-mingw.gcc451.generic.20100731.7z). Try with another sample for fprofiling.

[LoRd_MuldeR]

LoRd_MuldeR
Can't replicate it here. Not with GCC 4.4.3 not with 4.5.1 (http://komisar.gin.by/mingw/cross-mingw.gcc451.generic.20100731.7z). Try with another sample for fprofiling.

Doesn't make a difference. I still get a crash as soon as the first test run starts.

My source AVS looks like this:
FFVideoSource("..\Samples\Lossless\crew.704x576.avi")
AssumeFrameBased()

Tried Komisar's GCC 4.5.1 as well as TDM's and also GCC 4.5.2 from Xvidvideo.ru, but the issue is always the same :(

[Boulder]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

[LoRd_MuldeR]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

I don't compile with MP4 support either. Also I don't include lavf/ffms. I'm mainly interested in the "plain" DLL ;)

[MasterNobody]

Doesn't make a difference. I still get a crash as soon as the first test run starts.
As I can't replicate it than only I can suggest is to try configure without --enable-debug and then modify config.mak by removing '-s' for CFLAGS and LDFLAGS and adding '-g' in CFLAGS. Or the other way configure with --enable-debug and then patch config.mak by replacing '-O1' with '-O3' and may be adding '-fomit-frame-pointer'. Then try to run build for fprofiling in gdb.

[LoRd_MuldeR]

Okay, here's the result:

CFLAGS=-Wshadow -O3 -ffast-math -Wall -I. -I../pthreads -march=i686 -mfpmath=sse -msse -std=gnu99 -g -fomit-frame-pointer -fno-tree-vectorize -fprofile-generateD:\x264\x264-src>E:\MinGW.451-TDM\bin\gdb.exe --args d:\x264\x264-src\x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac
--direct temporal --ssim --no-weightb --threads 1 ../sample.avs -o NUL
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from d:\x264\x264-src\x264.exe...done.
(gdb) run
Starting program: d:\x264\x264-src\x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac --direct temporal --ssim --no-weigh
tb --threads 1 ../sample.avs -o NUL
[New Thread 4364.0x13c8]
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0

../../gdb-7.1/gdb/dbxread.c:1337: internal-error: Section index is uninitialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

I don't think this is a GDB issue, as the GDB works with other programs:
http://pastie.org/1168163

[Chikuzen]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

libgpac is in the state that cannot be compiled with mingw since rev2040.
bob0r said that mp4 output support will remove from x264.nl's build until libgpac comes to be good again at the build with mingw.
(I have complained about GPAC several hours ago. (https://sourceforge.net/projects/gpac/forums/forum/287547/topic/3857579))

[LoRd_MuldeR]

Just to be sure, I just reverted to x264 r1713 and built it in the identical build environment. Everything ran through fine!

So something between r1713 and r1722 must make a difference.

Either there's some bug in x264 r1722 that only shows up under certain circumstances or there's a bug in GCC that is triggered now and wasn't triggered in previous x264...

Thoughts?

[MasterNobody]

LoRd_MuldeR
Without the binary which crash and hopefully with debug info it is problematic to say what is wrong (may be you upload such build or better full x264 compilation directory). Also I hope you test not patched version.

[kemuri-_9]

I've been able to get gdb to get seg faults while as not using it does not get the seg faults, all without profiling.

removing -fomit-frame-pointer stopped the crashing.
this would coincide with --enable-debug not crashing as it does not add -fomit-frame-pointer
oh and i'm using gcc 4.4.4

[LoRd_MuldeR]

LoRd_MuldeR
Without the binary which crash and hopefully with debug info it is problematic to say what is wrong (may be you upload such build or better full x264 compilation directory).

Will do so, stay tuned...

Also I hope you test not patched version.

Usually I include custom patches, but for debugging purposes I of course work with "vanilla" builds ;)

[LoRd_MuldeR]

Here is an exact copy of my build folder as it was when "fprofile" was running, right when 'x264.exe' crashed:
http://mulder.brhack.net/temp/x264_r1722_fprofile_crash.7z

The 'trigger_crash.bat' reliably triggers a crash on my system. You may need to adjust the path inside 'sample.avs' though.

[rack04]

I am using 4.5.2 and I haven't experienced any crashes.

[aegisofrime]

I compiled 1722 successfully just now using instructions from here:

http://doom10.org/index.php?topic=26.0

Plain build, 64-bit without MP4 or FFMS input. Fprofiled too, no problems. Fprofile video is the bridge(far) video from here:

http://trace.kom.aau.dk/yuv/index.html

[MasterNobody]

LoRd_MuldeR
Try with this patch: http://pastie.org/1168299

[LoRd_MuldeR]

LoRd_MuldeR
Try with this patch: http://pastie.org/1168299

It seems that one did the trick!

http://forum.gleitz.info/images/smilies/cheers.gif


[EDIT]

Commited:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=b02df7b3b3b8616078851aab65d77ca435e2ff93;hp=e757d68b1a7f75de97cc472206cae52b770eeefb

Strange that apparently nobody else encountered problems with the regression :confused:

Anyway, thanks for the quick fix :)

[roozhou]

There are tons of work to do to add support for MSVC. If you need to include lavf input support, you still have to use MinGW to compile ffmpeg.

[schweinsz]

I downloaded the x264 version (http://www.xvidvideo.ru/x264-video-codec)to encode raw .yuv to lossless .264 using the following cmd:

D:\sequences\CIF>x264 --partitions "all" --qp 0 --keyint 2 --input-res 352x288 -o frmanls.264 foreman_cif.yuv (http://di-avc.com/x264_lossless.7z)
yuv [info]: 352x288p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.3, bit depth 8
x264 [info]: frame I:150 Avg QP: 0.00 size: 71310
x264 [info]: frame P:150 Avg QP: 0.00 size: 54972
x264 [info]: mb I I16..4: 3.7% 11.8% 84.5%
x264 [info]: mb P I16..4: 0.1% 9.9% 4.6% P16..4: 51.8% 18.6% 9.5% 3.4% 2.1% skip: 0.0%
x264 [info]: 8x8 transform intra:18.9% inter:66.1%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 99.7% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 14% 76% 8% 2%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 55% 13% 1% 2% 2% 2% 1% 2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 37% 7% 3% 11% 5% 6% 4% 4%
x264 [info]: i8c dc,h,v,p: 7% 40% 52% 1%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: kb/s:12628.21

encoded 300 frames, 27.08 fps, 12628.21 kb/s


Then I use the jm17.2 to decode the frmanls.264 to raw .yuv, but I found the reconstructed .yuv is corrupted. There is red blocks and corrupted bottom borders.
Is it a bug in x264 or a bug in jm17.2?


Edit1: I download the official x264 (http://mirror02.x264.nl/x264/revision1724/x264.exe) and find the same problem.

[kieranrk]

I downloaded the x264 version (http://www.xvidvideo.ru/x264-video-codec)to encode raw .yuv to lossless .264 using the following cmd:


JM doesn't support lossless.

[schweinsz]

JM doesn't support lossless.

I suspect your opinion. I ever explored the jm code and found many code related to lossless with the following style:

if(currMB->is_lossless)
{
if ((currMB->c_ipred_mode == VERT_PRED_8)||(currMB->c_ipred_mode == HOR_PRED_8))
Inv_Residual_trans_Chroma(currMB, uv) ;
else
{
for(j=0;j<p_Vid->mb_cr_size_y;j++)
for(i=0;i<p_Vid->mb_cr_size_x;i++)
currSlice->mb_rres [uv+1][j][i]=currSlice->cof[uv+1][j][i];
}
}

[kieranrk]

I suspect your opinion.

If I recall correctly it supports the old (I forget what it was called) lossless standard but not the new one (High 4:4:4 Predictive Profile Lossless).

[LoRd_MuldeR]

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...

[schweinsz]

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...
Yes, you are right. The JM doesn't support the new lossless mode. I have finished the lossless support of the DiAVC.

[Dark Shikari]

Yes, you are right. The JM doesn't support the new lossless mode.It does, but not for 4:2:0 (iirc) for some stupid reason.

[rallymax]

Hi team,

I did an update of the libav* codebase to get some new features - which in turn required a higher version of x264 so I updated that too. Not a problem I rebuilt libav* and libx264.

The x264_validate_parameters() is failing. I've seen this before and last time I simply commented the libx264.c x4->param changes out and used the x264 defaults instead. I also commented out the x264_validate_parameters#76 score code because I was more worried about getting the thing to run. But.... I know that's not the right thing to do since it's there, most likely, for a very good reason.

What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

I actually need the parameters to make it a legal BluRay stream.

When I commented out the code (above) that changed the parmeters and left it as defaults it processed fine and made a playable stream but Adobe Encore wouldn't recognize it as a legal stream and wanted to re-encode it and thus defeated the whole purpose of making a program using the BEST ENCODER IN THE WORLD!!! :thanks: to ditch the AWEFUL encoder bundled from Adobe.

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

thanks,
Rallymax


Here is the output of the out-of-box libavformat/output-example.c using the libav*.DLLs and libx264-105.DLL...

$ ./output-example xxx.h264
Output #0, h264, to 'xxx.h264':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 003e1100] broken ffmpeg default settings detected
[libx264 @ 003e1100] use an encoding preset (vpre)
could not open codec


just saw this above "Authoring Professional Blu-Rays with x264" so I'm going to take those parameters and feed them into the x4->param and see how we go with the score.

[LoRd_MuldeR]

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505 ;)


What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

(FFmpeg is known to set rather "bizarre" default settings for x264, so x264 will detect "broken" FFmpeg default settings to protect the user. Don't know if FFmpeg ever fixed their x264 default settings)


I actually need the parameters to make it a legal BluRay stream.

The commit message shows an example on how to configure x264 for BluRay compatibility...

[rallymax]

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505 ;)


re BluRay - Awesome work LM and others.


Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

The commit message shows an example on how to configure x264 for BluRay compatibility...

Init with.... hmm it already has the init call...
static av_cold int X264_init(AVCodecContext *avctx)
{
X264Context *x4 = avctx->priv_data;

x4->sei_size = 0;
x264_param_default(&x4->params); <---------------

x4->params.pf_log = X264_log;
x4->params.p_log_private = avctx;

ok... so based on the git commit comments and the ones from kieranrk's google doc page I should be able to get this to go now.

thanks.

[LoRd_MuldeR]

re BluRay - Awesome work LM and others.

Not my work though ;)


Init with.... hmm it already has the init call...
static av_cold int X264_init(AVCodecContext *avctx)
{
X264Context *x4 = avctx->priv_data;

x4->sei_size = 0;
x264_param_default(&x4->params); <---------------

x4->params.pf_log = X264_log;
x4->params.p_log_private = avctx;

Obviously the x264 defaults are still overwritten by FFmpeg (libavcodec) with their own "broken" defaults - after the defaults have been initialized by x264 itself.

As far as I understand, you use libx264 indirectly, through libavcodec. Why not call libx264 directly ???

[rallymax]

Not my work though ;)
Why not call libx264 directly?

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

oh, I also use libswscale and the RGB -> YUV planar conversion functions so it's just easier to call the libavformat front end based off of the output-example and have it then call the x264 library for me.

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray (http://en.wikipedia.org/wiki/MPEG_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29) is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

[LoRd_MuldeR]

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray (http://en.wikipedia.org/wiki/MPEG_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29) is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

[rallymax]

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in x264_paramt_t after the x264_param_default() call, except for those you really need?)

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.

[rallymax]

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

'just home, pulled everything out except the size and SAR and tried it... and it worked! :thanks:

Now to pop in the BluRay values...

$ ./output-example.exe xxx.h264
Output #0, h264, to 'xxx.h264':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 00544500] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
[libx264 @ 00544500] profile High, level 1.3
[libx264 @ 00544500] non-strictly-monotonic PTS
Last message repeated 49 times
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
Last message repeated 121 times
[libx264 @ 00544500] frame I:1 Avg QP:23.49 size: 2556
[libx264 @ 00544500] frame P:31 Avg QP:22.84 size: 903
[libx264 @ 00544500] frame B:93 Avg QP:29.04 size: 558
[libx264 @ 00544500] consecutive B-frames: 0.0% 0.0% 0.0% 100.0%
[libx264 @ 00544500] mb I I16..4: 78.3% 15.7% 6.1%
[libx264 @ 00544500] mb P I16..4: 77.2% 4.7% 0.3% P16..4: 17.1% 0.4% 0.2% 0.0% 0.0% skip: 0.0%
[libx264 @ 00544500] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 14.3% 0.2% 0.0% direct:25.0% skip:60.5% L0:57.1% L1:38.6% BI: 4.2%
[libx264 @ 00544500] 8x8 transform intra:6.1% inter:41.6%
[libx264 @ 00544500] coded y,uvDC,uvAC intra: 3.3% 27.8% 4.9% inter: 0.2% 42.2% 6.3%
[libx264 @ 00544500] i16 v,h,dc,p: 0% 0% 0% 100%
[libx264 @ 00544500] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 29% 3% 66% 0% 0% 0% 1% 0%
[libx264 @ 00544500] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 9% 20% 69% 0% 0% 0% 1% 1%
[libx264 @ 00544500] i8c dc,h,v,p: 0% 3% 7% 89%
[libx264 @ 00544500] Weighted P-Frames: Y:0.0%
[libx264 @ 00544500] ref P L0: 91.5% 0.7% 6.5% 1.2%
[libx264 @ 00544500] ref B L0: 66.4% 26.5% 7.1%
[libx264 @ 00544500] ref B L1: 97.9% 2.1%
[libx264 @ 00544500] kb/s:-0.00

[Dark Shikari]

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.ffmpeg has preset files (accessed with -vpre) that set the x264 default settings accordingly for various presets.

Of course, it's better to just do it right, and you'll have to modify the code if only because not all necessary options are exposed (e.g. NAL HRD).

[iwod]

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?

[Dark Shikari]

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?Well, if you paid attention to git or the weekly newsletter, we now have high bit depth support finished, among other things. I have about 8 local patches that'll go in soon, but nothing really big at the moment.

Also, there was no license change, only a license addition. It's still GPL.

[shon3i]

@Dark Shikari, is it possible in near future to make more friendly bitdepth, as single switch like Mainconcept, not at comple?

[Dark Shikari]

@Dark Shikari, is it possible in near future to make more friendly bitdepth, as single switch like Mainconcept, not at comple?That would involve compiling x264 twice and putting them both in the same application. That's probably what Mainconcept does.

Patches welcome; it'd require symbol versioning, at least, due to duplicate symbols.

[shon3i]

i don't know what they do, but i have one cli exe (standalone) or one directshow fiter that can choose bithdepth, which is more friendly to me, and i hope for other users too. I hope will someone help here and write patch :) or make webpage with compiled builds.

[Dark Shikari]

i don't know what they do, but i have one cli exe (standalone) or one directshow fiter that can choose bithdepth, which is more friendly to me, and i hope for other users too.Why not make a 5-line shell script that chooses between two executables if you're going to do that?

[shon3i]

Why not make a 5-line shell script that chooses between two executables if you're going to do that?
making front-end or script isn't problem, bigger problem is where to find(and download) >8bit builds, and keep it updated. I am not familiar with compiling x264

[Dark Shikari]

making front-end or script isn't problem, bigger problem is where to find(and download) >8bit builds, and keep it updated. I am not familiar with compiling x264Once we have a decoder ready and thus 10-bit becomes useful, it'll be easy to find such builds.

[Disabled]

the weekly newsletter
Is there a way to get the newsletter without joining the x264-dev mailinglist? (or manually searching the archives.)

[JoeH]

I think this issue is probably know to the developers by now, but just wanted to confirm that with recent builds (tested with 1724), the B-Pyramid strict option breaks compatibility with Panasonic Blu-ray players with the latest firmware (tested on BD60 with latest European firmware, v2.5, also with firmware v2.4 same problem). Disabling B-Pyramid enables playback.

Using MeGUI x264 profiles, I never saw this problem with build 1364 of x264 and previous, although I can't confirm for sure whether I was using the B-Pyramid strict option in those builds (I always use the MeGUI defaults if that is of any use).
----------------------------------------------------------------------------------------------------------------------
Just noted this thread is not for bug reports - feel free to move the message. Sorry about that.

[Trahald]

What do you mean breaks compatibility? Does the disk play, but plays corrupt? Does it not recognize the disk at all. Does it start to play but then stop? What authoring software do u use? Do your streams play properly on the pc? You are not clear if the problem has always been there for u with strict or did it just stArt with the firmware update. If not, why wait 400 revisions to report it?

[shon3i]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

[kieranrk]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

I would speculate tsmuxer is the problem.

[shon3i]

Once we have a decoder ready and thus 10-bit becomes useful, it'll be easy to find such builds.
I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

[Underground78]

I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

It is probably not just you, the asm for high bitdepth support has not been committed yet ...

[laserfan]

B-Pyramid strict option breaks compatibility with Panasonic Blu-ray players...
As an aside, b-pyramid also doesn't work with Sony DVD Architect. At least, while it APPEARS to work i.e. you can import and output/mux to BD, the result does not play-back all frames in the proper order. You have to leave this off if using x264 with DVDA.

[julius666]

I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

Could you post some comparison pictures please? I bet most of us on the forum don't have any 10-bit capable h264 decoder, but are interested in the quality gain that it gives.

[shon3i]

Could you post some comparison pictures please? I bet most of us on the forum don't have any 10-bit capable h264 decoder, but are interested in the quality gain that it gives.
Currently i am trying to find good source that easly produce banding. And i will post screens.

[Dark Shikari]

Currently i am trying to find good source that easly produce banding. And i will post screens.Here's one from a bit back:

8-bit (http://kuukunen.net/misc/banddenoise_8bit.png)

10-bit (http://kuukunen.net/misc/banddenoise_10bit.png)

[mariush]

why is the woman's face more pink on the 8bit version? consequence of 4:2:0 or something like that?

[Dark Shikari]

why is the woman's face more pink on the 8bit version? consequence of 4:2:0 or something like that?I think there was a BT.601/709 screwup somewhere in the process. Blame Kuukunen.

[JoeH]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

Sure. Here are the settings that work properly with the Panasonic Blu-ray players:
--preset slow --pass 2 --bitrate 16000 --stats ".stats" --b-pyramid none --level 4.1 --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 0 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --output "output" "input"

These are the settings I used which do NOT work:
--preset slow --pass 2 --bitrate 16000 --stats ".stats" --b-pyramid strict --level 4.1 --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 0 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --output "output" "input"

The only change is the bpyramid option. I have tested this many times with the same result each time.

I mux with TSMuxer. Here are the options I used. They were identical in both runs:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\Movie.mkv", fps=23.976, insertSEI, contSPS, track=1, lang=eng
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\EditedAudio.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\EditedAudio.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\Edited con cortes.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa

Here's what happens in the Panasonic Bluray Player when I insert a disk with bpyramid strict:
- The players LCD says "BD"
- On the display monitor I want to watch the BD it says "Reading"
- The LCD says 00:00:00
- It waits for a while trying to read it. It can't.
- The whole process repeats indefinitely.

This problem has been commented on here as well:
http://doom10.org/index.php?topic=324.0

I know for sure that previously when I had this problem and didn't know it was caused by the b-pyramid option I switched out x264 with the 1364 build and then it worked. I don't know if I made any additional changes to the command line that time.

[kieranrk]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)

Also remove insertSEI, contSPS,

I think tsmuxer will still try to "fix" bpyramid and this is why it fails.

[shon3i]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)That should not be problem even is higher than 1000ms, it's not by standard, but i think will not produce problem like here described.

@JoeH can you try to download x264 BluRay demo disc? and see is playing propertly. All clips on disc use bpyramid. That will be posibly eleminate is muxer or encoder problem.

[Trahald]

Just like the sync problem disappeared when ADDING b-frames. Yet it turned out mp4box was broken. Just because changing the option in x264 is fixing the issue doesn't mean it's x264s fault. Shoni uses professional muxers with x264 and makes valid BDs.

x264 uses more advanced h264 features when doing bpyramid than it used to. Tsmuxer is probably getting confused and puking on the stream. Submit a stream to the tsmuxer ppl and help them fix it. (if u want) If it were open source I'd try to write a patch but it's not. A complete playback failure is almost gauranteed to be the muxer especially factoring in b-pyramid works on other software/hardware players fine. Corrupted output then possibly encoder. For now u will have to turn off pyramid or use older revision.

[laserfan]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)
How'd you determine this? Can you explain please; I've never seen any posts about changing --vbv-len before.

[Underground78]

How'd you determine this? Can you explain please; I've never seen any posts about changing --vbv-len before.

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms.

[laserfan]

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms.
Ah, it was bufsize/bitrate that threw me off, thanks.

I hafta wonder still how critical/important (or not) this vbv-len setting is? I have never fiddled with it, though I do use 30000 & 40000 for BDs and 15000 & 15000 for DVD discs.

[sneaker_ger]

It mustn't be greater than 1 second to meet the Blu-Ray specifications. (i.e. bufsize mustn't be larger than maxrate)

[shon3i]

After bit researching, i found two thing that can break playback on Panasonic players.

First is if user use MKV or MP4 output instead raw 264. That will tell tsmuxer to break original AUD data and make broken stream. outputing to raw 264 is strongly recommend and outputing to MKV or MP4 is impossible for BD, we already haved simmilar situation in BD-Rebulder, which make same behavior with Panasonic players
Second is insertSEI, contSPS options in tsmuxer, but they are should no effect on stream if everyting is right but for sure (especialy on raw 264 stream), disabling them is strongly recommend.

@JoeH if you will try these combinations

Thanks

EDIT: And as i can see in your TSMuxer cmd you use MKV as video input, and that will not go. TsMuxer definitly break your stream.

[laserfan]

It mustn't be greater than 1 second to meet the Blu-Ray specifications. (i.e. bufsize mustn't be larger than maxrate)
Thank you for this. :)
:thanks:

[JoeH]

Thanks for the ideas. I'll try these suggestions out in the next few days and report back. I can't get to it today.

Is there a link to download the X264 Bluray demo disk which does not use torrent? My companies firewalls block torrent.

As far as the muxer goes, are there any real alternatives (free or at least cheap) to TSMuxer?

Here's an idea - even though TSMuxer isn't open source, an alternative GUI could be built, which might be able to get around these problems. The TSMuxer command line I copied is simply created by the GUI.

[JoeH]

I'll have some test results tomorrow for sure.

[DanielSun]

intel new sandy bridge processor will have a video transcode engine build into the cpu die, so will this feature be supported by X264?

[Blue_MiSfit]

DanielSun: If you do some research into this kind of thing, you'll see that hardware encoding solutions - be it on a GPU or special portion of a CPU - never have application when it comes to x264, and this is a good thing.

GPU accelerated transcoding is always slower and/or worse quality than x264. Usually both. This is because video encoding algorithms aren't easily parallelizable to the scale that's necessary to take advantage of GPU architecture.

The Sandy Bridges transcode engine (as far as I understand) is a fixed function piece of hardware that can't simply be used to accelerate portions of x264 or other H.264 encoders. It is in fact a full hardware encoder. I'm not 100% certain of this, but I'm sure I'm close to the mark :)

Not to say that these types of encoders won't have their purposes. Consider a notebook user with a fairly slow dual core CPU. Imagine the user has a piece of content they want to put on their mobile phone or other media player. They want it right now, but have to transcode it. Therefore, they want the transcode completed as quickly as possible. With the encoder in Sandy Bridge, they can probably get a usable file quicker than any software encoder, even including x264 (which is by far the best / fastest software encoder out there). Sure, they might have to double or triple the bitrate to get something that's watchable, but they get their TV show on their phone very quickly. They delete it after watching, so who cares?

Definitely a corner case, especially to the average doom9 user, but it's something I've run up against plenty of times. Sure, I have a (relatively) fast Q6600 CPU that can tear through SD H.264 encoding VERY VERY VERY quickly when using x264's ultrafast or superfast preset. Unfortunately not everyone has that kind of CPU power to throw at the problem, though.

I see Sandy Bridges as being an interesting option for these types of cases. I'm definitely going to get my hands on a slow dual core version, and see how the quality/speed ratio of its encoder compares to x264 on ultrafast, at fairly high bitrates (i.e. 20-30mbps for HD and 5-10mbps for SD)

Derek

[mariush]

Is there a link to download the X264 Bluray demo disk which does not use torrent? My companies firewalls block torrent.



Here you are: http://mplayer.savedonthe.net/test_files/download.php?dir=BluRay+DVD%2F

[JoeH]

I've done two tests so far, both with PTI/SPS/PPS turned off and buffer size of 750ms. One test was with an MKV, the other with H264 stream for the video. Unfortunately both gave the same result as my previous BPyramid -strict tests - the Panasonic would not get past 00:00:00.

Here are the TSMuxer configurations:

With MKV video:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=750
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\Movie-BPyramid-Strict.mkv", fps=23.976, track=1, lang=eng
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\New\Edited.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa

With H264 video:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --cut-end=2min --vbv-len=750
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\New\Edited.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\T1_Video - .h264", fps=23.976

I am downloading the X264 demo video right now (thanks Mariush!), but it won't finish for another 6 or 7 hours. I'll post results with it tomorrow.

[shon3i]

OK, since Panasonic players follow strict BD Specification, and while you wait for Demo disc, can you try this also, since i am not saw --sar in your commandlines, and sar should be present in stream, in your case --sar 1:1.

Second thing, when you make raw 264 encode, did you encode from scratch or you just demuxed your previous maked MKV? i ask because demuxing is not fix things, and stream is still "broken"?

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms. To be more precise, sine x264's --vbv-init is by default on 0.9 so in this case is not 750ms, because

(30000*0.9)/40000=0.675 which is 675ms, and more correct value :), easly can be checked with Elecard Buffer Analyser.

or vbv-init can be safetly set to 1.0 :)

[kieranrk]

To be more precise, sine x264's --vbv-init is by default on 0.9 so in this case is not 750ms, because

(30000*0.9)/40000=0.675 which is 675ms, and more correct value :), easly can be checked with Elecard Buffer Analyser.

or vbv-init can be safetly set to 1.0 :)

This is incorrect. vbv-size refers to the size of the WHOLE buffer in ms, not just the initial fill.

[shon3i]

This is incorrect. vbv-size refers to the size of the WHOLE buffer in ms, not just the initial fill.
Hmm, i am not sure, how x264 calculate size of buffer, but during verifying process, verifyer show that size of buffer is ~0.6 not 0.75. Same what elecard show, and generaly other encoders use init buffer 1

[kieranrk]

Hmm, i am not sure, how x264 calculate size of buffer, but during verifying process, verifyer show that size of buffer is ~0.6 not 0.75. Same what elecard show, and generaly other encoders use init buffer 1

They are then talking about the initial buffer fullness.

[shon3i]

They are then talking about the initial buffer fullness.
Yep, you right, my bad.

[JoeH]

Good news - the Panasonic reads the X264 Bluray demo disk just fine. So, definitely some sort of muxing issue then, or maybe as you suggest the BPyramid Strict option works on Panasonic only when combined with some other option like SAR.

OK, since Panasonic players follow strict BD Specification, and while you wait for Demo disc, can you try this also, since i am not saw --sar in your commandlines, and sar should be present in stream, in your case --sar 1:1.

Second thing, when you make raw 264 encode, did you encode from scratch or you just demuxed your previous maked MKV? i ask because demuxing is not fix things, and stream is still "broken"?

I just demuxed the previous MKV. I'll reencode and include the --sar 1:1 option and let you know how things go!

I'm also going to try remuxing a stream from the Bluray demo disk with TSMuxer, burn, and see what happens.

[shon3i]

Good news - the Panasonic reads the X264 Bluray demo disk just fine. So, definitely some sort of muxing issue then, or maybe as you suggest the BPyramid Strict option works on Panasonic only when combined with some other option like SAR.SAR is MANDATORY option for blu-ray, look here at 2.1 chapter http://forum.doom9.org/showthread.php?t=154533, for all mandatory options for BD, they should be always used when encoding for BD. SAR should not fix b-pyramid problem, but i suggest you to use it, since panasonic is very strict, and one of player that really follow BD specs. You should use b-pyramid always if you get some quality gain.

I just demuxed the previous MKV.That is same as directly encode to MKV. So this option definitly will not work as i said. You need to encode directly to raw 264, otherwise, x264 will calculate differenet AUD for target container, which after Tsmuxer completly broke, demuxing mkv to elementary (raw 264) will not change that calculations, and stream practically is useless, and make unplayable on panasonic players.

I'm also going to try remuxing a stream from the Bluray demo disk with TSMuxer, burn, and see what happens. It will work, since all calculations are ok, unless you use MKV or other container in that process as intermediate file, that will rush compatibility, and make stream unplayable.

[JoeH]

First test:
Remuxed x264 demo file 0003.m2ts using all of TSMuxer's default settings. The Panasonic played it just fine.

MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", fps=24, insertSEI, contSPS, track=4113
A_DTS, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", track=4352, lang=eng

[JoeH]

Second test

I've output 4 different streams - 2 are .MKV, 2 are .264. One of each container type has SAR set, the other does not.

Just tested .MKV with no SAR - this is identical to what didn't work before. As expected, it did not work. I ran this just as a control.

[JoeH]

Third test

.264 stream without SAR set. It works just fine in the Panasonic.

Fourth test

.MKV stream with SAR set. Does not play.

Fifth test

.264 stream with SAR set.

Results summary - Panasonic players will play streams from TSMuxer using BPyramid --strict option as long as the original input is a .264 stream and not an MKV stream. This will work with default TSMuxer options, and works regardless of whether the SAR option is correctly configured or not.

[rack04]

Results summary - Panasonic players will play streams from TSMuxer using BPyramid --strict option as long as the original input is a .264 stream and not an MKV stream. This will work with default TSMuxer options, and works regardless of whether the SAR option is correctly configured or not.

I wouldn't summarize this as all Panasonic's. My BD-35 doesn't have any problem playing back remuxed mkv's with --strict.

[shon3i]

I wouldn't summarize this as all Panasonic's. My BD-35 doesn't have any problem playing back remuxed mkv's with --strict.
Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.

[rack04]

Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.

Actually that is exactly the question. JoeH said that Panasonic's do not play files that have been remuxed from mkv and I stated that my BD-35 will.

[shon3i]

Well it's not question since is not legal operation, end of story. In past we have people with BD-35 which have exactly same problem (in BDrebuilder thread). From this point maybe panasonic update their software, but still why we should expect something to work, when is come broken.

[JoeH]

I also have a BD35, and the playback problems are identical on it as on the BD60 with the rendering / muxing method I use.

[laserfan]

I continue to struggle with understanding the tsMuxeR setting of --vbv-len wrt the --vbv-init (default 0.9) setting in x264, along with bufsize and maxrate:

--vbv-len - The length of the virtual buffer in milliseconds. The default value is 500. Typically, this option is used in conjunction
with --cbr. The parameter is similar to the value of vbv-buffer-size in the x264 coder, but is set not in kbit, but in milliseconds (with
constant bitrate they can be counted at each other). If you have self-encoded a x264 file with constant bitrate, for more smooth
broadcasting to the network you are encouraged to make the same (or less) setting than in the x264. On virtual buffer overflow relevant
errors are written in the log.
Under what circumstances (if any) should the --vbv-len parameter in tsMuxeR be altered from default 500ms? Any reason to alter it, or the 0.9 default of vbv-init if my output is to BD standard?

[kieranrk]

I continue to struggle with understanding the tsMuxeR setting of --vbv-len wrt the --vbv-init (default 0.9) setting in x264, along with bufsize and maxrate:


Under what circumstances (if any) should the --vbv-len parameter in tsMuxeR be altered from default 500ms? Any reason to alter it, or the 0.9 default of vbv-init if my output is to BD standard?

(bufsize/bitrate)*1000

vbv-init is not relevant

[shon3i]

As in readme written that is used only in conjunction with -cbr, don't touch it, because has no effect.

[Sharc]

Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.
Does stream damage come with mkv/mp4 muxing or with demuxing?

[shon3i]

Does stream damage come with mkv/mp4 muxing or with demuxing?
tsmuxer is that who will broke stream, but MKV or MP4 muxer will strip/revrite AUD when mux, and will not revert back on demux. And since Tsmuxer have some not perfect mechanism to restore all need information for bd, instead that will violate all aud data.

[Sharc]

@shon3i
Thank you. A new revision of TSMUXER would be nice ....

[shon3i]

Yep, long time, tsmuxer currently have problem with pulldown streams, an who know what else, i think we can make pretty list of bugs. I think is time for new muxer, opensource idealy to be easily maintained :D.

Anyway, mkv or mp4 output is not for BD, only raw 264 or maybe ts/mpg. So any aplication that mux mkv/mp4 into BD structure, definitly use some (ugly) hack.

[JoeH]

OK, I just ran another test that I think is very important to note.

I muxed the .264 output with BPyramid Strict into an MKV container, remuxed with TSMuxer into Bluray folders and burnt. It plays perfectly.

So, that means that BPyrmaid -Strict only causes problems with Panasonics when X264 outputs MKV format directly. As long as you output .264 from X264, you can then remux into MKV and eventually later into Bluray without problems.

[bob0r]

So,
x264.exe .264 > .mkv > .m2ts = ok
x264.exe .mkv > .m2ts = bad?

What did you use to .264 > .mkv ?

[shon3i]

So,
x264.exe .264 > .mkv > .m2ts = ok
x264.exe .mkv > .m2ts = bad?

What did you use to .264 > .mkv ?
No :)

x264.exe .264 > BD = OK
x264.exe .mkv/.mp4 > BD = bad
x264.exe .264 > .mkv/.mp4 > .264 > BD = bad

@JoeH, yes it because x264 automaticly calculate what need for target container. But still your combination beside playing will never pass verification, and remuxing raw stream to container and back is not good combination, it maybe work with tsmuxer because use some hacks, but will never pass with comercial muxers. Don't do that.

[bob0r]

x264.exe .264 > BD

"because it is the only way to get correct AUD and HRD info"

That's why. (Asked in #x264)

[burfadel]

For the resizing filters, what usefulness would spline100 and spline144 functions from the splineresize filter for avisynth http://www.geocities.com/wilbertdijkhof have when compared to the standard spline64resize, in terms of quality? If they do prove useful is it possible to be included in the x264 filters as well? they are afterall, essentially just an extension of the current spline16/36/64 filters, so shouldn't take much codespace.

[Dark Shikari]

You probably won't get significantly better than a basic Lanczos or Spline36 without doing edge-directed interpolation (EEDI, NNEDI, etc).

[Gser]

So I gather that the more sample points - the more sharper the resize. The pdf nicely explained the mathematical principles of it but not its effect on picture quality.

[Dark Shikari]

So I gather that the more sample points - the more sharper the resize.No; sharpening is generally done by choosing sharper filter coefficients.The pdf nicely explained the mathematical principlesThe problem with the mathematical principles is that they assume that the source is band-limited. This is true in the case of audio, and complete nonsense in the case of images.

[burfadel]

You probably won't get significantly better than a basic Lanczos or Spline36 without doing edge-directed interpolation (EEDI, NNEDI, etc).

Ah ok :) maybe a new optimised combination filter lol.

[kemuri-_9]

the resize filter in x264cli is based off of libswscale which does not have the concept of a bazillion varieties of spline like avisynth does.

[JoeH]

No :)

x264.exe .264 > BD = OK
x264.exe .mkv/.mp4 > BD = bad
x264.exe .264 > .mkv/.mp4 > .264 > BD = bad

@JoeH, yes it because x264 automaticly calculate what need for target container. But still your combination beside playing will never pass verification, and remuxing raw stream to container and back is not good combination, it maybe work with tsmuxer because use some hacks, but will never pass with comercial muxers. Don't do that.

The test I was speaking of is this one:
x264.exe .264 > .mkv > BD = OK (even with BPyramid -Strict on Panasonics)

[shon3i]

The test I was speaking of is this one:
x264.exe .264 > .mkv > BD = OK (even with BPyramid -Strict on Panasonics)
However, maybe play on your player, but may not on other, because that option still is not full BD compatible, it's just "work" now, maybe not tomorrow, is too risk and is not for backup or any serious usage.

x264.exe .264 > BD is only way to go.

[JoeH]

What about x264.exe .264 > M2TS > BD? Is that safe?

I ask because sometimes it is helpful to have a muxed video file before outputting the BD in order to finish editing subtitles, check out the video quality, etc.

[kieranrk]

What about x264.exe .264 > M2TS > BD? Is that safe?

I ask because sometimes it is helpful to have a muxed video file before outputting the BD in order to finish editing subtitles, check out the video quality, etc.

As long as the muxer doesn't mangle the stream (i.e tsmuxer) then it's ok.

[video_magic]

As long as the muxer doesn't mangle the stream (i.e tsmuxer) then it's ok.

Sorry to ask, but that is not clear to me. Are you saying there that tsmuxer does, or does not, mangle the stream? Thanks.

[shon3i]

Sorry to ask, but that is not clear to me. Are you saying there that tsmuxer does, or does not, mangle the stream? Thanks.
In most cases tsmuxer will try to change stream and replace by it's own hack. To prevent this you can try disabling insertSEI and contSPS options.

[JoeH]

OK. Honestly I haven't had any problems so far with TSMuxer that I haven't been able to solve somehow or another, but just in case, are there any reasonably priced / free muxers available that don't have this problem?

[schweinsz]

Is the B picture not supported by the x264 lossless mode?
I use the following cmd to encode the lossless bitstream using the x264 and get the following output:
D:\sequences\CIF>x264 --partitions "all" --qp 0 --keyint 10 --bframes 5 --input-res 352x288 -o frmn
_2bac.264 foreman_cif.yuv
yuv [info]: 352x288p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.3, bit depth 8
x264 [info]: frame I:30 Avg QP: 0.00 size: 71208
x264 [info]: frame P:270 Avg QP: 0.00 size: 54093
x264 [info]: mb I I16..4: 2.8% 12.3% 85.0%
x264 [info]: mb P I16..4: 0.1% 9.4% 4.5% P16..4: 49.3% 23.3% 8.9% 2.7% 1.8% skip: 0.0%
x264 [info]: 8x8 transform intra:42.9% inter:70.6%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 99.7% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 15% 66% 16% 3%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 56% 15% 1% 2% 2% 2% 1% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 38% 8% 3% 10% 5% 6% 3% 4%
x264 [info]: i8c dc,h,v,p: 9% 41% 50% 1%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 60.0% 11.5% 17.3% 11.2% 0.0%
x264 [info]: kb/s:11160.97

encoded 300 frames, 29.18 fps, 11160.97 kb/s

[Underground78]

See here : http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=6a4a9beae060d69bbeaeb8c1c3056fb6ae6765f6

[kemuri-_9]

I need some guinea pigs on windows platforms to help me on something:
I'm working on a patch to x264 to utilize native windows threading API rather than having to rely on pthread-win32 for threading.
so I need others to confirm that deadlocking and corruption do not occur.

Something important to know about this patch is that the code takes different paths for Vista/7 vs XP/2000.
(It shouldn't work on pre-2000 windows machines either, so don't even bother trying)

so i'll need victims from both sets of platforms (more worried about the XP & 2000 group tho)

build here (http://kemuri9.net/dev/x264/experimental/x264_w32thread.7z)

[Underground78]

It seems to work well here on XP SP3, output seems to be identical. Should we expect a (little) speed increase (I see something like a 2 or 3% speed gain) ?

[kemuri-_9]

It seems to work well here on XP SP3, output seems to be identical. Should we expect a (little) speed increase (I see something like a 2 or 3% speed gain) ?

No, I'm not particularly expecting that there should be any speed gains or losses for XP/2000... it should be just about the same as pthread-win32.
I would expect a very slight gain for Vista/7 though, as the patch uses some API exclusive to Vista/7 that pthread-win32 doesn't use.

[easyfab]

Ok here with xp sp3 and AMD II X4 620.

Same SSIM and bitrate and a little bit faster than the X264.nl version.

[shroomM]

Will test tomorrow and let you know of the results.

[MatLz]

XP32 SP2 here.
No problem.
Files are identical (the 'M' exepted)

[mariush]

Windows 2003 R2 32bit... SD 760x568, 25fps...q6600 overclocked to about 3Ghz, 4GB ram... it's slower but otherwise I don't notice anything wrong with the video itself.

x264_default.exe --frames 5000 --preset slower --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 5000 frames, 77.24 fps, 920.67 kb/s

x264_wthread.exe --frames 5000 --preset slower --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 5000 frames, 76.76 fps, 920.67 kb/s

But it was actually more like 74 fps throughout the first 4000 frames

x264_default.exe --frames 2000 --preset veryslow --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 2000 frames, 31.11 fps, 934.50 kb/s

x264_wthread.exe --frames 2000 --preset veryslow --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 2000 frames, 30.57 fps, 934.50 kb/s

The values reported after encoding were the same, in this case the following:

Second pass on the first 500 frames was 0.01 fps higher with the wthread version, 7.95 vs 7.96 fps.. but that may be just a fluke, due to the low number of frames.

[Usedocne]

@ kemuri-_9
No problems encountered here. (tested both 2pass and CRF)

[jpsdr]

On last git there is :

Improve quantizer handling
The default value for i_qpplus1 in x264_picture_t is now X264_QP_AUTO. This is currently 0, but may change in the future.
qpfiles no longer use -1 to indicate "auto"; QP is just omitted. The old method should still work though.


Actualy, i have all my qpfiles on the following format (exemple) :
1000 -1 I
2000 -1 I

Do i need to change all my files, or is the old format still compatible, but value not used ?

Is now the new format like :
1000 I
2000 I

this ?

[Dark Shikari]

On last git there is :


Actualy, i have all my qpfiles on the following format (exemple) :
1000 -1 I
2000 -1 I

Do i need to change all my files, or is the old format still compatible, but value not used ?

Is now the new format like :
1000 I
2000 I

this ?

The old method should still work though. 5chars

[jpsdr]

But, you said 'should still work', not '100% certain backward compatibility warrant'. So, i'm... well... a little... ....

Sorry, i don't know the meaning of '5chars'...

[sneaker_ger]

A post needs at least 5 characters in this forum, it's just a filler.

[MatLz]

Is theoricaly possible to have a knob (centered by default at 1.0) to control the amount of bits allocated for Bframes by mbtree ?
Thx

[kemuri-_9]

thanks for all the testing on the previous build XP users!

however, now i need your stashed away PCs once again for a new build (http://kemuri9.net/dev/x264/experimental/x264_w32thread_other.7z) that utilizes the condition variable API for pre-vista machines that a certain company developed.

this build should be compared against the standard pthread-win32 build, we'll be making a decision to drop pthread-win32 support depending on the benchmarks.

[MatLz]

Xp32 sp2
No problem
Identical files


But as my posts seem invisible...you won't care, right ?

[LigH]

@ MatLz:

No, your posts are not invisible, at least not to me (but I am no developer).

Maybe try IRC #x264 on FreeNode too.

[kemuri-_9]

But as my posts seem invisible...you won't care, right ?

your posts are not invisible, but i would like if you reported benchmarks comparing this last build against the standard pthread-win32 build.

both normal (frame-based) threading and sliced-threading should be benchmarked.

[mariush]

Can you give some command line to test for slice threading... never tried it so I don't know how it's done.

windows 2003 r2 , 32 bit. 30sec mpeg2 video


--preset medium --tune film --bitrate 1024 -o film.mkv "Video1108-2159(TV35).mpg"
ffms [info]: 768x576p 1:1 @ 25/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:9 Avg QP:24.50 size: 19309
x264 [info]: frame P:636 Avg QP:26.00 size: 5636
x264 [info]: frame B:137 Avg QP:29.16 size: 1556
[...]
x264 [info]: final ratefactor: 24.58
x264 [info]: Weighted P-Frames: Y:3.1%
x264 [info]: ref P L0: 54.3% 12.7% 22.9% 10.0% 0.2%
x264 [info]: ref B L0: 76.8% 22.3% 0.8%
x264 [info]: ref B L1: 96.6% 3.4%
x264 [info]: kb/s:1015.79


1745 default: encoded 782 frames, 51.23 fps, 1015.97 kb/s
1745 patch : encoded 782 frames, 50.76 fps, 1015.97 kb/s


--preset slow --tune film --bitrate 1024 -o film.mkv "Video1108-2159(TV35).mpg"
ffms [info]: 768x576p 1:1 @ 25/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:7 Avg QP:24.57 size: 23178
x264 [info]: frame P:244 Avg QP:25.71 size: 8813
x264 [info]: frame B:531 Avg QP:26.83 size: 3194
[...]
x264 [info]: final ratefactor: 24.31
x264 [info]: Weighted P-Frames: Y:7.0%
x264 [info]: ref P L0: 43.7% 11.8% 21.8% 8.1% 9.0% 5.5% 0.2%
x264 [info]: ref B L0: 66.5% 21.6% 9.3% 2.6%
x264 [info]: ref B L1: 89.3% 10.7%
x264 [info]: kb/s:1025.13


1745 default: encoded 782 frames, 28.71 fps, 1025.31 kb/s
1745 patch : encoded 782 frames, 28.63 fps, 1025.31 kb/s

update sliced threads


--preset slow --sliced-threads --tune film --bitrate 1024 -o film1.mkv "Video1108-2159(TV35).mpg"
ffms [info]: 768x576p 1:1 @ 25/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:7 Avg QP:24.69 size: 23125
x264 [info]: frame P:243 Avg QP:25.87 size: 8809
x264 [info]: frame B:532 Avg QP:26.99 size: 3223
[...]
x264 [info]: final ratefactor: 24.50
x264 [info]: Weighted P-Frames: Y:5.8%
x264 [info]: ref P L0: 43.6% 12.0% 21.3% 8.3% 9.1% 5.6% 0.2%
x264 [info]: ref B L0: 66.9% 21.1% 9.3% 2.7%
x264 [info]: ref B L1: 89.5% 10.5%
x264 [info]: kb/s:1027.34


1745 default: encoded 782 frames, 20.49 fps, 1027.53 kb/s
1745 patch : encoded 782 frames, 20.31 fps, 1027.53 kb/s

the patch is consistently slower than the default one. Not sure the fps is correct on the patched version as fps in the last case was for 90% of time at about 17-8.5% and at the end goes up to 20% and then at the end shows 20.31 fps.

files on the patched version are 6 bytes longer in all cases as far as I see.

[Dark Shikari]

--sliced-threads (surprise!)

[Underground78]

Windows XP SP3 (32 bits)
--no-progress --output NUL test.avs
avs [info]: 688x368p 0:0 @ 25/1 fps (cfr)

default build:
encoded 1000 frames, 30.70 fps, 874.79 kb/s
encoded 1000 frames, 30.68 fps, 874.79 kb/s

w32thread build:
encoded 1000 frames, 30.89 fps, 874.79 kb/s
encoded 1000 frames, 30.78 fps, 874.79 kb/s

--sliced-threads --no-progress --output NUL test.avs
avs [info]: 688x368p 0:0 @ 25/1 fps (cfr)

default build:
encoded 1000 frames, 27.15 fps, 885.06 kb/s
encoded 1000 frames, 27.25 fps, 885.06 kb/s

w32thread build:
encoded 1000 frames, 26.81 fps, 885.06 kb/s
encoded 1000 frames, 26.85 fps, 885.06 kb/s

It looks like your test build is slightly slower with sliced-threads enabled.

[kemuri-_9]

It looks like your test build is slightly slower with sliced-threads enabled.

there does seem to be a growing consensus on this...
tho frame-based threading still seems to be rather inconclusive.

[jpsdr]

I've encoded several files with last version (1766), with QP file like this :

2172 I
16309 I
32532 I
48514 I
62530 I
77288 I
92527 I
108749 I
122511 I
136382 I
152510 I
154670 I
155375 I

What was my surprise when i've tried to make chapters with scenarist, with a lot of warning for each chapters saying that frame wasn't an I frame !
Encoding with previous version (1745) worked fine. It seems that QP file are somehow broken.
I'm using Jeeb's version, with following commande line :

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=15000

REM Set of Buffer (ici le buffer)
set BUF_BR=15000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --subme 7 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

Note : Tune was animation.

[Dark Shikari]

Seems I didn't actually fully fix it to make the qpfile work without the -1s. Use the -1s like before in the meantime, I'll fix it in the next push.

[jpsdr]

Argh... 48h of encoding wasted...:(

[Dark Shikari]

Argh... 48h of encoding wasted...:(Sorry, I fail extremely badly. Not only did I screw it up, but I'm so bad at string parsing I can't actually get it to work now either.

[jpsdr]

Do you mean with -1 it's still not working with 1766 release ?
If it's the case, please tell me, i'll stop the encoding i've restarted, there no point letting my PC run if it's "for nothing"...

[Underground78]

Do you mean with -1 it's still not working with 1766 release ?
If it's the case, please tell me, i'll stop the encoding i've restarted, there no point letting my PC run if it's "for nothing"...

I am quite sure it still does not work in 1766 but it should be fixed in r1768 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=39787c80bdd5992935c480a8eedcfb6d50625334).

[jpsdr]

I've just checked with one of my encoded files, with -1 added it was working fine.
But it seems that there is a new version on it's way with some other fixes (at least something on HRD), so i'll wait next Jeeb release.

[Underground78]

I've just checked with one of my encoded files, with -1 added it was working fine.
But it seems that there is a new version on it's way with some other fixes (at least something on HRD), so i'll wait next Jeeb release.

Yes, my bad, I misread your post ... :o

[rack04]

Is anyone able to download the latest git? Maybe the site is having problems because I get an error at http://git.videolan.org/

[aegisofrime]

Is anyone able to download the latest git? Maybe the site is having problems because I get an error at http://git.videolan.org/

It was broken a while back but ok now. Got me worried that the x264 project might be dead :(

Edit: I noticed that the latest revision features improvements regarding high bit depth. For the noobs among us (me), does this refer to 10-bit output and if so, how's the speed relative to 8-bit?

[burfadel]

Just wondering whether the following AMD programmers manual (including AVX, XOP, FMA4 etc) is of any use:
http://support.amd.com/us/Processor_TechDocs/26568.pdf

[thegame]

I am confused on the format for the qp file, is this right

1212 I

or is this right

1212 I -1

Thanks

and is there a way to verify your I-Frame placement once x264 MeGUI encoded?

[Dark Shikari]

The quantizer (rightmost value) is optional.

[thegame]

The quantizer (rightmost value) is optional.

OK so -1 or no -1 it is all good either way, but is there a way to check the I-Frames in the raw AVC x264 encoded file afterwords? is there anything that will let you check and make sure they are correct?

OH and Thank you by the way for the quick response.

[Dark Shikari]

OK so -1 or no -1 it is all good either way, but is there a way to check the I-Frames in the raw AVC x264 encoded file afterwords? is there anything that will let you check and make sure they are correct?

OH and Thank you by the way for the quick response.The statsfile from a multi-pass encode, or a stream analyzer.

[mariush]

AMD’s software optimization guide for their upcoming Bulldozer processor: http://support.amd.com/us/Processor_TechDocs/47414.pdf

It seems that AMD has released almost all of the details of it’s new architecture to the world and after quickly skimming it some of the features are mildly impressive.
Let’s hope AMD matches it’s new chip with a decent marketing campaign, maybe something like this video: http://www.youtube.com/watch?v=usGkq7tAhfc

(copy/pasted from semiaccurate.com, added links)

DS, any interesting stuff there that would encourage one to choose 2/4 socket AMD systems for their next encoding system instead of Intel?

[aegisofrime]

AMD’s software optimization guide for their upcoming Bulldozer processor: http://support.amd.com/us/Processor_TechDocs/47414.pdf

It seems that AMD has released almost all of the details of it’s new architecture to the world and after quickly skimming it some of the features are mildly impressive.
Let’s hope AMD matches it’s new chip with a decent marketing campaign, maybe something like this video: http://www.youtube.com/watch?v=usGkq7tAhfc

(copy/pasted from semiaccurate.com, added links)

DS, any interesting stuff there that would encourage one to choose 2/4 socket AMD systems for their next encoding system instead of Intel?

Thanks for that question, I was thinking of that as well.

[burfadel]

Revision 1936 seems to try to use internal FFMS etc even if specified to use avisynth input. It therefore crashes.

This is using x264 from www.x264.nl (had to use the second mirror).

[burfadel]

Anyone had the same issue? running rev 1924 work perfectly fine, but 1936 returns the input error regardless of the avisynth source filter used (ffvideosource, mpeg2source etc). Is related to the way the version of x264.nl is compiled (and related to why its not listed on mirror01, so mirror02 etc has to be used), or is this an error that also affects other build environments?

[kemuri-_9]

what issue are you trying to report, exactly?

first you say that you can't force avisynth input with --demuxer avs, but that is working.

and then you come back and say you get an error, without posting any useful information about it.

[burfadel]

Sorry, was in a rush earlier!

It was probably why I missed the fact the command line options have changed again, and I was using Staxrip (for easy batch processing). I had --open-gop normal set, which has been changed to --open-gop and with --b-pyramid now having the 'normal' setting which is set as default.

If anyone else is caught out by this, its easy enough to change in staxrip, just set open-gop to none (so it doesn't appear in the command line down the bottom) and then on the 'command-line' tab, enter --open-gop

[Dark Shikari]

Whoops, should have warned the GUI authors I was changing one of the options ;)

[upyzl]

Re #1377

Maybe this is the reason?
commit f9e7f531048df7219a44203031c8f79bae6170d0 r1935
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Wed Apr 6 17:15:50 2011 -0700

Consolidate Blu-ray hacks into --bluray-compat
This option is now required for Blu-ray compatibility.
--open-gop bluray is now gone (using bluray-compat and open-gop implies a Blu-ray compatible open-gop).
This option doesn't automatically enforce every aspect of Blu-ray compatibility (e.g. resolution, framerate, level, etc).

[CruNcher]

Wow at last, i remember when we had this discussion you where against device specific profiles inside the CMD Encoder and said that's the job of the GUI guys and libx264 implementer, seems that thinking changed finally, though looking in what the CMD Encoder has changed into over the years it was just a logic decision :D

[Dark Shikari]

Wow at last, i remember when we had this discussion you where against device specific profiles inside the CMD Encoder and said that's the job of the GUI guys and libx264 implementer, seems that thinking changed finally, though looking in what the CMD Encoder has changed over the years it was just a logic decision :DActually, nothing changed at all. --bluray-compat DOES NOT set all options for Blu-ray compatibility. It simply enables Blu-ray-specific hacks.

It will not set the resolution for you, or your framerate, or your bitrate, or any other things required by Blu-ray.

[Midzuki]

Hummmm, x264 is getting better and better...

and somewhat fatter :devil: as well :D

@burfadel: don't use GUIs for x264.exe :p

[Groucho2004]

Hummmm, x264 is getting better and better...
Yep.

and somewhat fatter :devil: as well :D

Really? Haven't noticed. Mine is still at ~778K.

[shon3i]

Actually, nothing changed at all. --bluray-compat DOES NOT set all options for Blu-ray compatibility. It simply enables Blu-ray-specific hacks.

It will not set the resolution for you, or your framerate, or your bitrate, or any other things required by Blu-ray.
Can you be more specific what hacks? what settings is affected, beside opengop why b-piramid is not in this aslo since strict is de facto name for bluray

[Dark Shikari]

Can you be more specific what hacks? what settings is affected, beside opengop why b-piramid is not in this aslo since strict is de facto name for blurayStrict is useful for temporal scalability in general, not just Blu-ray.

Blu-ray hacks:

1) min-CR + level 4.1 hack
2) Special b-pyramid SEI
3) B-frames cannot reference frames outside their minigop
4) Open-GOP keyframe interval hack

[sneaker_ger]

1) min-CR + level 4.1 hack

What's that?


In general I must say I don't like these "half-assed" options. It's sane to force any Blu-Ray specific hacks with an additional parameter, but overall the x264 options don't follow any straight line:

--profile is forced, overriding any explicit options
--level sets the level flag + reduce number of ref frames, but only if not explicitly forced by the user, meaning that you can falsely flag your files. It also doesn't care for frame sizes or vbv.
--bluray-compat now limits e.g. ref frames to 6, which will work for 720p, but not for 1080p etc.

This inconsistency of the options leads to confusion and the fact that these things are not documented in --fullhelp, but have to be read on doom9 or the git, doesn't really help either.

[Dark Shikari]

What's that?Blu-ray spec specifies a different MinCR than the H.264 spec for level 4.1.

In general I must say I don't like these "half-assed" options. It's sane to force any Blu-Ray specific hacks with an additional parameter, but overall the x264 options don't follow any straight line:

--profile is forced, overriding any explicit options
--level sets the level flag + reduce number of ref frames, but only if not explicitly forced by the user, meaning that you can falsely flag your files. It also doesn't care for frame sizes or vbv.
--bluray-compat now limits e.g. ref frames to 6, which will work for 720p, but not for 1080p etc.

This inconsistency of the options leads to confusion and the fact that these things are not documented in --fullhelp, but have to be read on doom9 or the git, doesn't really help either.In short: Blu-ray compat limits analysis options, not bitrate/resolution/fps. Is that simple enough for you?

If you want to help, you can work on cleaning up and finishing the --device/autolevel patch, which will simplify and clean up all this.

[sneaker_ger]

Blu-ray spec specifies a different MinCR than the H.264 spec for level 4.1.

Ah, I just recalled reading about that before. Thanks.

In short: Blu-ray compat limits analysis options, not bitrate/resolution/fps. Is that simple enough for you?

Don't get me wrong. I was and will be able to put up correct and sane command lines for x264cli. I just feel that inconsistency leads to confusion (not of me, who spends lots of time on doom9) but of others, and that things should be done right or not at all.

If you want to help, you can work on cleaning up and finishing the --device/autolevel patch, which will simplify and clean up all this.

I'm afraid I'm not qualified for that, but it's good to know that some of the devs might feel similar and that x264 gets more refined every day.

[burfadel]

@burfadel: don't use GUIs for x264.exe :p

lol! not a bad point, unfortunately thats easier said than done! Now if there were a x264 specific gui that was easy to use allowed for batch processing, easy settings adjustment, external audio encoders, cutting for personal tv recorded episodes/movies, including outputting the cut info to an external audio encoder, output to mkv, parallel batch encoding (there's a way to do that in Staxrip), 'segmented single file encoding', and other useful things then I'd be using that instead :D

What I meant by 'segmented file encoding', is scanning around halfway in a file to be encoded for a keyframe change, then encoding the first half of the file to that keyframe change and the second half of the file from that keyframe change in parallel, at low priority, which will allow for full cpu use across all CPU's (even 8 logical/physical such as in Intel 'Sandy Bridge' or AMD 'Bulldozer'), whilst not impending on normal computer use. The two halves can then be appended at the end of the encode, much like you can do in mkvtools except operating on the raw streams. The audio stream could even be added whilst doing the append :).

[CruNcher]

burfadel you want a professional solution like Cinevision or CCE-HD, Blu-Code ect that though yet doesn't exists with x264 @ its core the most pro solution is Pegasys Masterworks which in some parts fails in its framework entirely compared to what you can achieve manually with the right tools ;)

[laserfan]

Blu-ray hacks:

1) min-CR + level 4.1 hack
2) Special b-pyramid SEI
3) B-frames cannot reference frames outside their minigop
4) Open-GOP keyframe interval hack
So apart from --open-gop bluray being moved into this, the --bluray-compat option includes 3 other new features that did not heretofore exist with the base builds of x264? :confused:

[J_Darnley]

Except for 2 and 3 they did. Read the changes to see how they were activated.

[CruNcher]

Is it known what the compression loss and or win in encoding speed/decoding of --bluray-compat will be compared to leaving it out and if their could be other interoperability problems occurring with that option for non Blu-Ray scenarios, will it be significant @ all also PSNR/SSIM and PSY ?

[shon3i]

--bluray-compat should has no impact on quality or de/encoding speed. min-CR + level 4.1 hack is need to accomplish bd specs, and is not need for level 4.0 and lover, and others are just pure hacks to meat exact bd specification and pass verifiers.

[Dark Shikari]

--bluray-compat should has no impact on quality or de/encoding speed. min-CR + level 4.1 hack is need to accomplish bd specs, and is not need for level 4.0 and lover, and others are just pure hacks to meat exact bd specification and pass verifiers.The B-frame reference crippling costs a non-trivial amount of compression.

[rallymax]

Strict is useful for temporal scalability in general, not just Blu-ray.

Blu-ray hacks:

1) min-CR + level 4.1 hack
2) Special b-pyramid SEI
3) B-frames cannot reference frames outside their minigop
4) Open-GOP keyframe interval hack

Hi Dark',

does 1) imply that it sets the level at 4.1 too? (ie can you have --bluray-compat and a --level xx setting on the command line?

[sneaker_ger]

Hi Dark',

does 1) imply that it sets the level at 4.1 too? (ie can you have --bluray-compat and a --level xx setting on the command line?

If I'm not mistaken it does not.

Also the code (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=encoder/ratecontrol.c;h=6726fbd1f6e39dd53df2cc149c54e01de38d5915;hp=ce9a93effee77ca5d666b80cc0ba606fab798fb7;hb=f9e7f531048df7219a44203031c8f79bae6170d0;hpb=f422ec93254ed3f9883acac0bb3f67e3b4ea960c) doesn't seem to be caring about the level at all, which makes me wonder if this is correct for levels other than 4.1. :confused:

/edit:
seems that this has already been discussed:
2011-04-07 00:29:22 < kierank> line 1211 the mincr thing is only for level 4.1
2011-04-07 00:29:32 < Dark_Shikari> yes because all the other levels already have mincr 4
2011-04-07 00:29:33 < Dark_Shikari> right?
2011-04-07 00:29:45 < kierank> can't remember
2011-04-07 00:29:46 < Dark_Shikari> or is it ,in the spec, only for level 4.1?
2011-04-07 00:29:47 < Dark_Shikari> check it
2011-04-07 00:32:23 < kierank> yeah all the other levels that are used in blu-ray have mincr=4

[shon3i]

imply that it sets the level at 4.1 too?No. If you use --level 4.1 and --bluray-compat then x264 will use MinCR that accomplish bd specs, otherwise will use AVC spec

[rallymax]

No. If you use --level 4.1 and --bluray-compat then x264 will use MinCR that accomplish bd specs, otherwise will use AVC spec

For clarity... what happens if the level is 4.0 or lower?

[shon3i]

Nothing since level 4.0 and lower use same as avc specs, only for level 4.1 bd specs describe that different mincr is required.

[ajp_anton]

Why does it feel like the development of the actual encoder has kind of stopped...
Are there still improvements planned?

[Dark Shikari]

Currently there's about 25-30 MBAFF patches queued up waiting for final review. Patience is a virtue!

[simonhorlick]

Other things to look out for are hopefully Trellis ME (summer of code) and energy preserving quant. Both of which look like they'll be really good for compression.

[LoRd_MuldeR]

Other things to look out for are hopefully Trellis ME (summer of code) and energy preserving quant. Both of which look like they'll be really good for compression.

I can't see those on the list of projects palnned for SoC 2011 :confused:
http://wiki.videolan.org/SoC_x264_2011

[Mr VacBob]

Trellis ME is "Non-local RD optimization". Energy-preserving quant is a side project by saintdev (psy-trellis already behaves sort of like this).

[jpsdr]

It seems that bluray-compat put weigthp to 1 ? If i add a command line to put weightp to 2, will it work ?
I don't understand this choice. I thought weigthp 2 was bluray compliant according the specs, and problem was only because of some broken chipset ?
In the same good way, bluray-compat seems to put pict-struct only on interlaced content, and not on progressive content, wich seems to be strictly compliant to the spec, even if some people suggest to always put pict-struct, because some authoring software required it.
So, why chose to strictly follow the spec in one case, and not in the other ?
(Unless i am mistaken and understood things wrongly).

[skampy]

Has anyone ever had problems with the --zones function when the beginning frame is set to when the screen is blank (black)? Say at the very beginning of a video/movie (frame 0), or a few frames after a fade-to-black?

The problem is that, when that beginning frame of the set zone is reached, there is a 'gray' screen displayed for about a second or two, then the video resumes normally. The gray screen doesn't flash, it's simply static gray screen displayed in lieu of what is meant to be, in this case, a black screen.

This has happened with two seperate encodes with two different video sources, with x264 revisions of r1913 and r1924 respectively. Both gray screens occurred when the zone started during a black screen (intro/credits). The zones in this case were nothing special; the only setting used was a bitrate multiplier. I've used zones successfully many times without any problems, but now that I think about it, the start frame for the zone didn't happen to start on a black screen.

I am using the x264 CLI with the lastest x264 revision. The 1st and 2nd passes used exactly the same settings (I am aware that unless --slow-firstpass is specified, the 2nd pass settings aren't used for the 1st pass), and that includes the zone settings. The decoder I use is ffdshow w/ mpc-hc.

Any ideas? Is this a bug, or have I done something wrong?

PS- I don't think posting my x264 cl is relevant in this case, as I cannot fathom how any setting could cause such a weird bug.

[shon3i]

It seems that bluray-compat put weigthp to 1 ? If i add a command line to put weightp to 2, will it work ?
I don't understand this choice. I thought weigthp 2 was bluray compliant according the specs, and problem was only because of some broken chipset ?
In the same good way, bluray-compat seems to put pict-struct only on interlaced content, and not on progressive content, wich seems to be strictly compliant to the spec, even if some people suggest to always put pict-struct, because some authoring software required it.
So, why chose to strictly follow the spec in one case, and not in the other ?
(Unless i am mistaken and understood things wrongly).
It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

pic-struct is not mandatory for progressive content in specs, only for (fake)interlaced and pulldown. But verifiers complain about (probably due bad interpretation of specs)

D_S already update x264 to use pic-struct on (fake)interlaced and pulldown in case bluray compat, we now just wait for next revision.

[Sharc]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

Good to know. That's different then compared to the earlier strategy when later settings in the command line overwrote the preceeding ones.

[Dark Shikari]

weightp 2 gives relatively little compression benefit over 1 (since the modification I made). If you really want to force it, modifying the code is trivial.

[Sharc]

weightp 2 gives relatively little compression benefit over 1 (since the modification I made). If you really want to force it, modifying the code is trivial.
Little compression benefit yes, but I had in mind that the main benefit of weightp 2 was an improvement for fading scenes.

[Dark Shikari]

Little compression benefit yes, but I had in mind that the main benefit of weightp 2 was an improvement for fading scenes.weightp 1 does that now.

[Sharc]

weightp 1 does that now.
Excellent, thanks.

[Sharc]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.

Will it also overwrite the --slices parameter?
I am asking because the --slices are still included here (http://sites.google.com/site/x264bluray/home/720p-encoding)

[shon3i]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr

[Sharc]

Thank you. All clear now.

[Dark Shikari]

It doesn't force anything that isn't global to all Blu-ray profiles.

[Sharc]

It doesn't force anything that isn't global to all Blu-ray profiles.
I see. And because it is executed after user parameters it does a clean up of non-compliant user settings :cool:

[jpsdr]

It seems that bluray compat is executed after user params, and all non bd compatible switches are reduced, so weightp 2 is not possible anymore with blu-ray.


So, does it mean that finaly weightp 2 was not bluray compliant strictly speaking of bluray spec, leaving aside all problem concerning crapy broken chipset ?? :confused:

[sneaker_ger]

So, does it mean that finaly weightp 2 was not bluray compliant strictly speaking of bluray spec, leaving aside all problem concerning crapy broken chipset ?? :confused:

No. There's even a comment in the source that this is only to care for broken player, not for Blu-Ray compliance.

[sneaker_ger]

ref=4 for 1080

I don't think this is true, it limits to 6 regardless of resolution.

[mp3dom]

No. There's even a comment in the source that this is only to care for broken player, not for Blu-Ray compliance.

It's indeed true that all the other 'proencoders' out there that made use of weightp doesn't create any problems even on 'crappy chipset' like old mediatek. I think that if x264 is intended to be used not only for custom user who wants BD compatibility for their player but also for professional who wants to create 'commercial' bd compatible with the vast majority of the players out there, this is the right decision (force weightp 1 with bluray-compat). We have already see that BD specs are not so 100% clear and some manufacturer can misinterpret. For mass-replication the highest compatibility comes before highest quality... it's no secret.

[laserfan]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr
So with --bluray-compat I can remove aud and nalhrd from my command line?

It might have been nice if this was in the fullhelp, vs. having to pick-thru these threads (or interpret program code)...

[sneaker_ger]

So with --bluray-compat I can remove aud and nalhrd from my command line?

Yes.

It might have been nice if this was in the fullhelp, vs. having to pick-thru these threads (or interpret program code)...

I agree. There's a lot of things not covered in fullhelp.

[jpsdr]

It's indeed true that all the other 'proencoders' out there that made use of weightp doesn't create any problems even on 'crappy chipset' like old mediatek. I think that if x264 is intended to be used not only for custom user who wants BD compatibility for their player but also for professional who wants to create 'commercial' bd compatible with the vast majority of the players out there, this is the right decision (force weightp 1 with bluray-compat). We have already see that BD specs are not so 100% clear and some manufacturer can misinterpret. For mass-replication the highest compatibility comes before highest quality... it's no secret.

It's a little dictatorship in that specific case... :mad:
Now i'm screwed, and can't set it anymore to 2 despite the fact it's compliant to the bluray spec !!!!
Even if quality improvement is little, i still would like to kept it... It's one thing to put out of spec value in spec, but here it's different...
Big big disapointment...

[mp3dom]

It's a little dictatorship in that specific case... :mad:
Now i'm screwed, and can't set it anymore to 2 despite the fact it's compliant to the bluray spec !!!!

You can still edit & compile a build that doesn't force a weightp<2 with bluray-compat

[shon3i]

I don't think this is true, it limits to 6 regardless of resolution.
You must use level 4 or 4.1 and level limit will down to 4 so it's true, on 720 will down from 9 to 6 because bluray limit. Only 576p25@L3.0 need to set to 5 because that is max.

[sneaker_ger]

You must use level 4 or 4.1 and level limit will down to 4 so it's true, on 720 will down from 9 to 6 because bluray limit. Only 576p25@L3.0 need to set to 5 because that is max.

Yes, but we were talking about the --bluray-compat option.

[jpsdr]

You can still edit & compile a build that doesn't force a weightp<2 with bluray-compat

Easy to say...

[Selur]

okay, trying to wrap my head around it, so I can modify Hybrid accordingly (tomorrow), I try to sum it up:

--bluray-compat
enforces:
- 3 or less bframes
- bpyramid=strict (when bframes are used and bypramid is enabled, or does it always enforce bpyramid even when --b-pyramid none was set?)
- 4/6 max key frames depending on resolution
- weightp=1 (since this is forced, weightp 2 can't be used)
- aud=1
- nalhrd=vbr

Cu Selur

[laserfan]

no just reduce bframes=3, ref=4 for 1080, ref=6 for 720/576/480, bpyramid=strict, weightp=1, aud=1, nalhrd=vbr

So with --bluray-compat I can remove aud and nalhrd from my command line?

Yes. I agree. There's a lot of things not covered in fullhelp.
Thanks for answering. I wondered if --b-pyramid none still worked (for Sony DVDAP) using --bluray-compat and it does.

As a point of interest, I noticed that aud does not appear in the header info/MediaInfo. Maybe it never has, I dunno.

[laserfan]

--bpyramid=strict (when bframes are used and bypramid is enabled, or does it always enforce b_pyramid even when --b-pyramid none was set?)I just tried --b-pyramid none and it worked/is not overridden, get b_pyramid=0

[mp3dom]

Easy to say...
I think you just need to comment line 610 in encoder.c

h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE );

[nurbs]

- 4/6 max key frames depending on resolution

The limit is 6 regardless of resolution.
h->param.i_frame_reference = X264_MIN( h->param.i_frame_reference, 6 );
Since you need to set the level anyway it can be lower depending on input resolution, i.e. 4 for 1080p.

[sneaker_ger]

weightp is also only limited to 1, not forced.
Better see for yourself:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=encoder/encoder.c;h=b0fc7b907ea55e93ab2903a06e48ba02d71db4bb;hp=fd2c877373a72497e7ee0fe1462b48f547cbbc18;hb=f9e7f531048df7219a44203031c8f79bae6170d0;hpb=f422ec93254ed3f9883acac0bb3f67e3b4ea960c

[shon3i]

Yes, but we were talking about the --bluray-compat option.
You can't use use bluray compat without setting proper level, it's pointless, so de facto it's based on resolution, except 576@25 L3.0 where maximum references is 5.

Other settings like bframes, bpyramid, weightp are maxed to bd specs, and can be lowered or switched off.

[jpsdr]

I think you just need to comment line 610 in encoder.c

h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE );


I was thinking more on the following part :
Install ALL the tools/program/etc... needed to compile your own version, follow all the updates, the patches, etc...
And when i see all the troubles people have when you're noob on making your own x264 version.
No thanks !!!!!!! I don't have time for this, and don't want to spend on it.
I use the Jeeb's versions, wich are perfect for me because having the fade compensate patch.
I personnaly realy deeply regret this decision, of not allowing a still bluray compliant option, but i'll survive...

[mp3dom]

If the problem is only fades, I think that the fade-compensate already do its job quite nicely (it's also a method to improve fades without using weightp2).
Regarding fades, there are example out there that demonstrate that it's possible to have a very good result with the (equivalent) weightp=1 (sometimes even better results than x264's weightp2)
Regarding weightp2 probably it comes in a gray zone with free interpretation. If it's clear that weightp2 is in specs, all the players would have supported it and all pro-encoders would use it. Instead, some decoder chipset doesn't support it and pro-encoders doesn't use it.

[kieranrk]

Regarding weightp2 probably it comes in a gray zone with free interpretation. If it's clear that weightp2 is in specs, all the players would have supported it and all pro-encoders would use it. Instead, some decoder chipset doesn't support it and pro-encoders doesn't use it.

What you're saying doesn't even make any sense.

[mp3dom]

Is there a reason why some decoder chipset (players) have problems handling duplicates while (as far as I know) the same players doesn't exhibit the problem with other commercial titles (that still uses weighted prediction for P frames but supposedly doesn't use dupes?). Probably in the BD specs there isn't a clearly statements about this, because in the other case all players would have decoded the stream with dupes correctly (from the beginning or via a firmware upgrade)

[kieranrk]

Is there a reason why some decoder chipset (players) have problems handling duplicates while (as far as I know) the same players doesn't exhibit the problem with other commercial titles (that still uses weighted prediction for P frames but supposedly doesn't use dupes?). Probably in the BD specs there isn't a clearly statements about this, because in the other case all players would have decoded the stream with dupes correctly (from the beginning or via a firmware upgrade)

Well they can't just mention every single H.264 feature in the Blu-Ray spec. There's only a dozen or so pages about H.264.

[sneaker_ger]

The problem wasn't only in Blu-Ray players, but also software non-Blu-Ray specific players. And both hardware and software manufactors have acknowledged their mistake and have fixed the problem in newer products (and some of them fixed it with firmware updates for older products). It's just that no encoder made use of it until it was implemented in x264, so manufactors didn't have any such stream for their product testing and were thus unaware of the problem.

[sneaker_ger]

You can't use use bluray compat without setting proper level

Of course I can. 1080p24:
x264 --bluray-compat --vbv-maxrate 24000 --vbv-bufsize 24000 --keyint 24 --sar 1:1 -o out.264 input.file

100% Blu-Ray compliant.

But that wasn't even my point - it's that we were talking about the bluray-compat option which limits ref frames to a maximum of 6. period. We shouldn't mix things up to prevent confusion. Selur already was. But maybe I'm just splitting hairs...

[rallymax]

so... let me get this right...

Some of you are complaining about a command line switch (--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself). A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

These are the same people that are using x264 for FREE, and don't contribute to the coding effort.

If you MUST have a patch that differs from the mainline development of x264 then do the 5 or so steps to get MSYS, GIT the repos, SVN things like ffmpeg, do "configure ...;make install" for ffmpeg then "configure ...;make install" for x264. If that's too much why don't you go and whine to that PATCH feature developer to get them to change --bluray-compat to your interpretation.

How about showing some appreciation for the volunteer effort that the x264 Dev's give EVERY DAY FOR FREE.

To devs - you rock. I'm excited and appreciative every day of your gift to the community.:thanks:

[sneaker_ger]

(--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself).

You can't, some of the options are only available through --blueray-compat

A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

The x264 devs also regard it as spec compliant. It's only to care for older, buggy players.

If you MUST have a patch that differs from the mainline development of x264 why don't you go and whine to that branch developer to get them to change --bluray-compat to your interpretation.

That developer is active here, so whining here is an option. Patching is also trivial (delete a single line), but setting up a compiling environment is not and doing regular compiles is a lot of work.

To devs - you rock. I'm excited and appreciative every day of your gift to the community.:thanks:

This.

[Selur]

summing the feedback my last post got up:

--bluray-compat

enables a bunch of 'Blu-ray hacks':
- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames cannot reference frames outside their minigop
- Open-GOP keyframe interval hack
renders '--open-gop' parameters obsolete:
- now: --bluray-compat + --open-gop <> old version: --open-gop bluray
- now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD
enforces:
- aud=1
- nalhrd=vbr
(-> these are not needed in the command line when using '--bluray-compat')
restricts:
- bframes to: 3 or less
- bpyramid to: strict or none
- max references to: 6 or less
- weightp to: 1 or 0

[Dark Shikari]

It doesn't enforce nalhrd=vbr, it restricts nalhrd >= vbr.

[iSeries]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?

[Dark Shikari]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?It's not.

[Sharc]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?
I use this site (http://sites.google.com/site/x264bluray/home) as a reference. It appears to be well maintained and corresponds with the latest version from http://x264.nl.

... and the information given here (http://forum.doom9.org/showthread.php?t=154533) in the first post (sticky).

[shon3i]

But that wasn't even my point - it's that we were talking about the bluray-compat option which limits ref frames to a maximum of 6. period. We shouldn't mix things up to prevent confusion. Selur already was. But maybe I'm just splitting hairs...I told you several times it work in conjunction with other parameters, and there is no confusion if i say that bluray compat will limit up to 4 references with 1080 L4 or 4.1, that will happen, that is whole point.

And in addition to Selur post

bluray compat will enable pic-struct for interlaced, fake-interalced, pulldown, and not for progressive. Because that required by BD specs.

[Selur]

bluray compat will enable pic-struct for interlaced, fake-interalced, pulldown, and not for progressive. Because that required by BD specs.
Oh, I thought that interlaced, fake-interlaced and pulldown had already enforced pic-struct before bluray compat was around, but it could be that I just did that in my code. :)

Cu Selur

[shon3i]

Oh, I thought that interlaced, fake-interlaced and pulldown had already enforced pic-struct before bluray compat was around, but it could be that I just did that in my code. :)

Cu Selur
It's been mandatory for interlaced and pulldown, but for fake interlaced not. Now situation stay same except for fake interlaced in conjunction bluray compat use pic-struct, because is need for blu-ray. fake interlaced itself not use pic-struct because have other cases where need to signal frame differently.

[Selur]

Thanks for clearing that up. :)

[Mug Funky]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.

i encoded a 2000 frame 3:2 video (some old anime that was on the system) without IVTC using --tff on the regular compile and Simon Horlick's git. i then IVTC'd the result and PSNR'd them against the source (with IVTC).

i got an overall PSNR increase of just under 2dB. not too shabby.

i couldn't really see any difference, but this monitor is crap.

take it with a grain of salt of course :)

[Sagittaire]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.

i encoded a 2000 frame 3:2 video (some old anime that was on the system) without IVTC using --tff on the regular compile and Simon Horlick's git. i then IVTC'd the result and PSNR'd them against the source (with IVTC).

i got an overall PSNR increase of just under 2dB. not too shabby.

i couldn't really see any difference, but this monitor is crap.

take it with a grain of salt of course :)


2 dB is actualy the difference bettween MPEG4 ASP and MPEG4 AVC. MBAFF is extremely high gain performance for interlaced source!

it's Blu Ray compliant?

[Mug Funky]

well, that's on the first source i checked.

i'm going to play a bit more in the coming days and use some more realistic sources and see how it goes.

my methodology is probably full of holes, but of course it's a promising result either way.

[thegame]

Hi, I just want to apologize up front if this question seems pretty dumb LOL, but how in the world do you open and look at your statsfile? and should there be a statsfile and mbtree file? or are these the same thing? I try to open with notepad and all it does is freeze, I am still fighting what I asked about on page 69 regarding the qpfile and I-Frames, I did this and my file encoded but when authored in up most chapters were still off, there HAS to be a way to get these chapters to place correctly.

Thanks in advance

[laserfan]

Hi, I just want to apologize up front if this question seems pretty dumb
It's not dumb, but neither is it a topic for this developers thread. Try starting a new thread in the Blu-ray Authoring subforum and maybe you will get more looks/responses.

If you do, you'll have to provide more details about what exactly you are trying to do (than you have so far).

[thegame]

Sorry about posting here, the reason I did is because a few pages back(page 69) I was asking about the qpfile and forced I-Frame placement and got help on that and I asked how could I verify the placement and was told to look at the statsfile, well as I asked above, how in the world do you open it to view it?

http://forum.doom9.org/showpost.php?p=1490953&postcount=1371

[J_Darnley]

You should be able to open the stats file in any text editor. Perhaps it is too large for notepad, use something better. You won't be able to see much in the mbtree file because it is a binary file.

[ajp_anton]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.
How recent? Can't find any MBAFF-related in the x264.nl changelog.

[sneaker_ger]

How recent? Can't find any MBAFF-related in the x264.nl changelog.

He's probably talking about the dev git (https://github.com/DarkShikari/x264-devel/commits/master), but it looks like the mbaff additions got removed again.

[upyzl]

About r1944

why not turn off psy-rd <RD:Trellis> when set subme<6 or trellis=0 as before?
I think that's the right info for users... even I want to advise deleting deadzone info when used trellis=2 at the same time...

and also about merange on umh/esa/tesa (http://forum.doom9.org/showthread.php?p=1497461#post1497461)
maybe 4~256 is a good valid range

[MasterNobody]

About r1944

why not turn off psy-rd <RD:Trellis> when set subme<6 or trellis=0 as before?
I think that's the right info for users... even I want to advise deleting deadzone info when used trellis=2 at the same time...
Did you read the commit message (this part "Also avoid encoder_reconfig turning off psy_rd/trellis.")? That was made because --subme and --trellis can be changed later by reconfiguration (for example --zones) and so if user explicitly didn't disabled them they should be enabled. Btw internally they of course disabled with subme<6 or trellis=0 but parameters not reseted. As for deadzone they still have effect even with --trellis 2 also again reconfiguration allow changing trellis.
and also about merange on umh/esa/tesa (http://forum.doom9.org/showthread.php?p=1497461#post1497461)
maybe 4~256 is a good valid range
It would be 4..1024 range (https://github.com/DarkShikari/x264-devel/commit/492f744a97ab1a6d796c9cecf1efa8a90d64e3b4)

[upyzl]

@MasterNobody

Thanks very much for the explanation
Now I understand...

[MrVideo]

renders '--open-gop' parameters obsolete:


It makes them a little more than obsolete. It causes x264 to fail with an error that it can't open the option. Because --open-gop no longer has options, the very next word in the line is considered the file to open because it doesn't start with --.

I got caught with that and couldn't figure out why it couldn't open "none" when it was an option for --open-gop. I removed "none" as a test and discovered that it now worked.

It would have been nice if x264 still looked for a potential option and if so, spit out a warning that it is now obsolete and reference --bluray-compat in the warning.

After the failure, I started digging and a posting over on Doom10 pointed to this thread. That resulted in my changing some more stuff in my CLI (adding the --bluray-compat option and removing two others).

[MrVideo]

Below is the CLI I use for encoding video so that I can edit it with VRD:

x264 --pass 2 --profile high --level $LEVEL --bitrate $BITRATE --ref $REF \
--deblock 1:-1:-1 --me umh --subme 10 --psy-rd 1.00:0.15 --merange 24 \
--trellis 2 --deadzone-inter 21 --deadzone-intra 11 --fast-pskip \
--threads 12 --slices 4 --nr 0 --bframes 3 --b-pyramid strict \
--b-adapt 2 --b-bias 0 --direct auto --weightp 0 --keyint $KEYINT \
--min-keyint 1 --scenecut 40 --rc-lookahead 60 --ratetol 1.0 \
--qcomp 0.60 --qpmin 10 --qpmax 51 --qpstep 4 --cplxblur 20.0 \
--qblur 0.5 --vbv-maxrate $MAXBITRATE --vbv-bufsize $BUFSIZE \
--ipratio 1.40 --aud --nal-hrd vbr --open-gop $INTERLACED \
--sar $SAR --qpfile "${DIRNAME}/${NAME}_qpfile.txt" \
--input-res $RES --stats "${DIRNAME}/${NAME}.stats" \
--output "${DIRNAME}/${NAME}.264" \
"tmp.fifo.yuv"

If the video is interlaced, the $INTERLACED variable will be set to --tff.

Before the recent changes, the --open-gop had none as its option.

What the above did for me is create IDR frames at the locations where I frames are normally placed and at locations set in the qpfile.

But now, instead of IDR frames, it is only I frames.

How do I get IDR frames back? Why was the functionality of IDR frame generation removed, or was it an error in the first place and I stumbled upon it?

[sneaker_ger]

If you use "K" it will depend on your open-gop setting - you can still force "I" or "i". Or does this not work for you?

/edit:
To make sure I get you straight:
1.) Before, you had open-gop deactivated ("--open-gop none")
2.) Now you have open-gop activated ("--open-gop")

and you're wondering why x264 behaves differently?

[MrVideo]

If you use "K" it will depend on your open-gop setting - you can still force "I" or "i". Or does this not work for you?

/edit:
To make sure I get you straight:
1.) Before, you had open-gop deactivated ("--open-gop none")
2.) Now you have open-gop activated ("--open-gop")

and you're wondering why x264 behaves differently?

Yes. Why, because the rules of the game have changed in the middle of the game. There isn't a changelog with the source distribution. Is there a place that lists major operational changes like this and explains what the changes affect and what the CLI settings should be? Maybe a separate thread, that doesn't allow discussion, that lists functional changes to the options and fully explains the previous setting combinations and what the new settings are to match the old.

Doing a little digging, a posting over on Doom10 (think it is a page back here as well) indicates that without --bluray-compat the --open-gop acts as it was --open-gop cbrHD under the old code. But, cbrHD was not an option, as they were none, normal and bluray. Because the posting didn't make sense, it was shoved aside.

While the developers understand what is going on with the changes, we poor users are sorta left out in the cold. I'd like to see a dedicated thread, as described above, as that would really help us users.

[sneaker_ger]

Yeah, such a place does not exist.
The only thing you can do is to watch the changelog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) every time a new version gets released.

[Astrophizz]

The mailing list sends out batch changelogs with commentary.

[MrVideo]

The mailing list sends out batch changelogs with commentary.

Thanks. Where does one sign up?

[Astrophizz]

Thanks. Where does one sign up?

http://mailman.videolan.org/listinfo/x264-devel
A small warning though. When a new update batch is pushed out every couple of weeks, you'll get an email with a newsletter summarizing what changed plus and email for each change.

[MrVideo]

A small warning though. When a new update batch is pushed out every couple of weeks, you'll get an email with a newsletter summarizing what changed plus and email for each change.

That's OK. It will be a drop in the bucket, compared to the rest of what I get on a daily basis.

Thanks for the info.

[3ds]

If i see it right, the minimal encoding arguments for 1080p23.976 / 1080p24 bluray compatibility are :
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4

But why must i add vbv-maxrate, vbv-bufsize, keyint and slices? x264 can calculate them from the given resolution/fps, isn't it?

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

[LigH]

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

:goodpost: I agree.

[nurbs]

Even knowing that your target is Blu Ray there are two possible vbv values for 1080p. This also affects the number of slices. Depending on that there are also two different keyint parameters that are valid. Just by that commandline x264 can't know which of the two you want. See the Blu Ray encoding sticky.

[sneaker_ger]

Is there any reason to use --b-pyramid strict outside of Blu-Ray? I'm asking because its parameters didn't got removed, unlike with --open-gop.

[3ds]

Even knowing that your target is Blu Ray there are two possible vbv values for 1080p. This also affects the number of slices. Depending on that there are also two different keyint parameters that are valid. Just by that commandline x264 can't know which of the two you want. See the Blu Ray encoding sticky.
We have two choices for level 4.1 and level 4.0, if i look to Primary Video Rules from: http://forum.doom9.org/showthread.php?t=154533

So x264 must know witch level should be used. Idea: --bluray-compat used highest level (--level 4.1) as default, but the user can add --level 4.0

So there are any information to calculate all needed restrictions values (e.g. max bitrate, buffer size etc.)

btw. is there ever a reason to use a smaller level than 4.1? All bluray players should play level 4.1, isn't it?

[mp3dom]

btw. is there ever a reason to use a smaller level than 4.1? All bluray players should play level 4.1, isn't it?
Standard Def video doesn't need 40 Mbps to be encoded, even for max bitrate. In general level 3.2 or 4.0 is enough (maxrate is 24 Mbps) and this allows to have 1 slice only. It can be a matter of taste, you can encode anyway a standard def. video with level 4.1 and 4 slices.

[nurbs]

When you want to put a Blu Ray structure on DVD using level 4.0 is also better since you can use longer GOPs and don't need slices, so you get a little better compression.

[QBhd]

When you want to put a Blu Ray structure on DVD using level 4.0 is also better since you can use longer GOPs and don't need slices, so you get a little better compression.

In this scenario, the only difference would be the # of slices... What is the benefit of going with slices 1 over slices 4 from a quality stand point?

QB

[nurbs]

VBV would also be different in that scenario since DVDs usually don't have high enough transfer speed to support the full level 4.0 bitrate. Since you have lower bitrate you can also use 2 second GOPs. Going from 4 slices to 1 won't give much benefit, I'd guess way less than 1%, but every bit helps.

[burfadel]

The new rev 1995 builds on x264.nl are 25.4mb... To me thats just a little large? 25.4MB! I didn't bother downloading it since there's something wrong with it.
(mirror01 didn't seem to respond, the other mirrors all came up with 25.4mb)...

[Dark Shikari]

jarod forgot to strip his builds.

[Boulder]

Is Simon Horlick's work on MBAFF now finished or are there any new things (except from optimizations and fine-tunings) expected?

[upyzl]

It seems that I don't need to deint NTSC-30i any longer when see the changes of MBAFF if I encode just for myself by r1995...

[laserfan]

Is Simon Horlick's work on MBAFF now finished
Having followed the commit history (https://github.com/DarkShikari/x264-devel/commits/master) for a little while now I'd been amazed at the output of this individual, and with the recent release (and an interlaced project I'll be interested to try with r1995) I had to look him-up. Apparently one of the things one has to do these days is keep a blog journal. (http://simonhorlick.blogspot.com/2010/04/diary-of-x264-mbaff-developer.html)

Altho I can bearly spel MBAFF ;) I appreciate all the work! :)

[Brazil2]

on x264.nl
mirror01 didn't seem to respond
Mirror01 seems to be down for several weeks.

[IgorC]

Are there any x264's benchmarks of ARM Cortex-A9 and Atom?
What is the state of omptimizations for ARM's SIMD extension NEON vs Atom and performance per watt?

Google search doesn't return much on it.

[Blue_MiSfit]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.

[Boulder]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.Can you post some test results? I've got a pile of DVD extras to encode as interlaced to add to my media jukebox, and I've been waiting for the feature to be finished :)

[Sharc]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.
What do you mean by "badass" (for us non-native English speakers)? Google didn't translate "badass" for me .....
Is MBAFF generally poor (in x264)? Or dou you mean that it is now much better in x264 than Mainconcepts hence you can forget Mainconcept? I am still interested in doing interlaced (MBAFF) encodes.
Thanks for enlightening me :)

[nixo]

Badass = awesome, great.

--
Nikolaj

[Groucho2004]

Google didn't translate "badass" for me .....

You must be using the wrong Google. :)

Second link I got from Google:
http://www.urbandictionary.com/define.php?term=badass

Interpretations 2 and 4 on that page would be a match to what Blue_MiSfit meant.

[Sharc]

Thanks guys. Great to learn that its meaning is so positive for x264 MBAFF!

[Blue_MiSfit]

Correct. It's a substantial improvement in quality (or even metrics like psnr if you optimze for that).

Some random hard 3:2 content picked up about 1 db in psnr in my fairly restrictive tests: 1.2mbps cbr 480i, short GOPs and small buffers as required for a specific client. 1db of PSNR is quite substantial, to say nothing of the visual improvement when using psy optimizations.

Derek

[CruNcher]

Yeah especially for the user they don't have to care anymore if their content is progressive or interlaced content even both mixed on the same frame thus being macroblock adaptive will be equally well encoded that's a big plus of usability improvement in the encoding framework :)
MBAFF was the first step to have a Interoperability layer for old (analog TV age interlaced content) for moving on into the full progressive digital age without braking old analog concepts and still allow Broadcasters to save bandwidth if they want or need to put some more stations on the transponders :)
Nice finally to see it it arriving in x264 after so much years :)

[Boulder]

Did anyone test CRF mode yet? I did a very quick test and noticed that the previous build (without adaptive MBAFF) produced a smaller file with the same settings and CRF. So do we need to adjust CRF again to compensate for the changes?

[CruNcher]

MBAFF needs some more bits that's expected how much difference do you see ?

[aegisofrime]

Just to clarify, am I right to say that MBAFF is only useful for interlaced content? There's no reason to use it for pure progressive content?

[mp3dom]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

[aegisofrime]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

Thanks for the quick reply. I understand now :thanks:

[kieranrk]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

You should let the encoder decide this for you. Any other ways will almost certainly be based on conjecture.

[Boulder]

MBAFF needs some more bits that's expected how much difference do you see ?Oh, I thought that it was more efficient so it would require less:p

[mp3dom]

You should let the encoder decide this for you. Any other ways will almost certainly be based on conjecture.
Are there 'known' examples of true progressive clips that can be encoded in a better way with MBAFF than true progressive?

[CruNcher]

Oh, I thought that it was more efficient so it would require less:p
It depends on the content if you use mainly interlaced content it should save bits but if you do mixed content it depends on different factors also on how well its optimized obviously :)

[sneaker_ger]

Are there 'known' examples of true progressive clips that can be encoded in a better way with MBAFF than true progressive?

He probably meant the decision between MBAFF and PAFF, not between progressive and MBAFF.

[kieranrk]

He probably meant the decision between MBAFF and PAFF, not between progressive and MBAFF.

Yes, exactly. The next step for x264 is to have PAFF and decide between MBAFF and PAFF.

[Mini-Me]

Holy crap! I've been following Simon Horlick's git respository, doom10, and DarkShikari's blog, and none of them gave any indication that MBAFF was actually DONE. (Well, I did just notice that the MBAFF commits were merged into the main branch a couple days ago. Maybe that was the hint. ;))

Was any kind of announcement made anywhere? Reading the last few pages of this thread is a bit bizarre, because it seems like all of a sudden it's common knowledge that it's done. Is it really finished, or is there some kind of catch (i.e. it's sort of working but buggy/unreliable/not as efficient as it will be)?

[Dark Shikari]

Read the development newsletters, they're good for you.

[Mini-Me]

Read the development newsletters, they're good for you.

I must be looking in the wrong place, because the newest one I had seen was Volume 12 from February. Now that you brought it up, I just ran a search and found Volume 16 here (http://mailman.videolan.org/pipermail/x264-devel/2011-May/008508.html). Is there anywhere the newsletters are regularly announced, or do I just need to scan the mailing list archives for them?

[Dark Shikari]

Is there anywhere the newsletters are regularly announcedEr... the mailing list? Where they're sent out?

[ckmox]

any news on the audio encoding support of x264? is it still alive? what audio formats are gonna be included?

[sneaker_ger]

You can always get a patched build from http://x264.fushizen.eu. No idea about it getting committed, though.

[ckmox]

i hope it gets committed it will be awesome to see x264 having audio support, and i check JEEB's patches too although its glitchy when encoding at low bitrates

[burfadel]

How is the work going on psy-rd v2? still coming along, scrapped?

[laserfan]

Read the development newsletters, they're good for you.[x264-devel] x264 Development Newsletter: Vol 16 (MBAFF edition!)
Jason Garrett-Glaser jason at x264.com
Thu May 12 08:41:23 CEST 2011
...

Improvements:

MBAFF support is now in! Typical compression improvement is around
15% for an ordinary 1080i HDTV source.I'd just finished one of these using 1936 --tff so I did it again with 1995, and saw a 15% increase in speed for my 2-pass project, at least in one of the episodes (others as low as 6%).

Dunno how to determine "compression improvement" but visually it looked the same (or better i.e. how to improve on perfect?) so I'm very happy with it.

[Mini-Me]

Er... the mailing list? Where they're sent out?

I guess I was asking if they were announced anywhere that sets them apart from a sea of commits. ;)

[Lyris]

Just to satisfy my (justified) disc replication paranoia: the introduction of MBAFF doesn't do anything to break Blu-ray compliance, does it?

[kieranrk]

Just to satisfy my (justified) disc replication paranoia: the introduction of MBAFF doesn't do anything to break Blu-ray compliance, does it?

No it does not.

[Dark Shikari]

There might be bugs in the new x264 due to all the changes, which is why I recommend using the stable revision for anything mission-critical, but "supporting MBAFF" in and of itself is not a compliance issue.

[LigH]

I am not sure how much it says, and if these results are at all useful ... I just ran a quick test with revisions 1913 (used in the TechARP x264 bench 4.0 HD) and 1995 (currently available in MeGUI), simply a "x264.exe --crf 18 [--tff] -o *.264 *.avs", comparing the ten PAL snippets of the VQEG video test set. Looks like my expectations about the efficiency of MBAFF were a little wrong? Or where is the mistake in my assumptions?

The table lists file sizes in MiB.

VQEG src r1913 P r1913 I r1995 P r1995 I content description
01 0.30 0.31 0.30 0.30 Tree: still
02 12.26 13.52 12.26 12.45 Event: slow zoom-out; interlaced
03 10.21 8.82 10.21 10.07 Harp: slow zoom-in and regional motion; interlaced
04 2.18 2.43 2.18 2.18 Ant: CGI motion and vertical scrolling; interlaced
05 8.09 6.61 8.09 7.29 Kayak: heavy motion; interlaced
06 12.05 8.49 12.05 9.24 F1GP: heavy motion; interlaced
07 5.52 5.75 5.52 5.66 Fastfood: heavy motion + noise; progressive
08 3.06 2.68 3.06 3.01 Text: horizontal scrolling + background; interlaced
09 11.89 8.79 11.89 9.88 Rugby: heavy, unsteady motion; interlaced
10 8.65 8.29 8.65 8.80 Train: little, mainly steady motion; interlaced

P.S.:

r19xx P = progressive encoding mode
r19xx I = interlaced encoding mode (with "--tff")

[Dark Shikari]

You didn't keep quality constant. Constant CRF over multiple different revisions and prog vs interlaced isn't constant quality. Try at least keeping constant PSNR.

[Boulder]

How to adjust things compared to the situation without MBAFF, is it simply time to tweak CRF to taste when it comes to interlaced encoding?

[LigH]

Maybe not exactly what you said, but a bit closer, with --qp 18 instead of --crf 18 this time.

Now that looks more like success: As small as progressive encoding for mainly/nearly progressive content; only a little bigger than always-interlaced for clearly interlaced content.

VQEG src r1913 P r1913 I r1995 P r1995 I content description
01 0.32 0.34 0.32 0.32 Tree: still
02 22.96 25.48 22.96 22.94 Event: slow zoom-out, interlaced
03 18.49 17.52 18.49 17.90 Harp: slow zoom-in and regional motion, interlaced
04 3.49 3.94 3.49 3.41 Ant: CGI motion and vertical scrolling, interlaced
05 14.92 13.08 14.92 13.33 Kayak: heavy motion, interlaced
06 23.10 18.43 23.10 19.02 F1GP: heavy motion, interlaced
07 11.28 13.53 11.28 11.30 Fastfood: heavy motion + noise, progressive
08 6.09 5.69 6.09 5.67 Text: horizontal scrolling + background, interlaced
09 22.56 18.29 22.56 19.03 Rugby: heavy, unsteady motion, interlaced
10 16.54 17.11 16.54 16.49 Train: little, mainly steady motion, interlaced

Sum 139.76 133.42 139.76 129.41

If you have suggestions for different parameters, just tell me.

[Manao]

LigH : at least, print both PSNR difference and bitrate ratio. Bitrate ratio alone is meaningless. Or do as Dark_Shikari said and keep either bitrate or PSNR constant

[LigH]

If there is no way to have x264 encode with a fixed PSNR ratio, then I would have to keep the bitrate constant, which means that I have to encode in 2-pass mode and compare PSNR ratios afterwards. But that's not a "lunch-break job" anymore...
__

Concatenated VQEG PAL clips 01-10 and ran a 2-pass encode with 2000 kbps.

r1913 P: PSNR Mean Y:34.149 U:38.783 V:39.076 Avg:35.130 Global:34.351 kb/s:1994.17
r1913 I: PSNR Mean Y:34.496 U:38.723 V:38.984 Avg:35.418 Global:34.698 kb/s:1988.28
r1995 P: PSNR Mean Y:34.154 U:38.785 V:39.077 Avg:35.135 Global:34.356 kb/s:1994.40
r1995 I: PSNR Mean Y:34.891 U:39.276 V:39.589 Avg:35.839 Global:35.080 kb/s:1993.04
__

And because I was warned that the results would be invalid, again with "--tune psnr":

r1913 P: PSNR Mean Y:34.697 U:38.270 V:38.562 Avg:35.455 Global:34.748 kb/s:1989.88
r1913 I: PSNR Mean Y:34.960 U:38.108 V:38.401 Avg:35.642 Global:34.963 kb/s:1987.15
r1995 P: PSNR Mean Y:34.705 U:38.274 V:38.571 Avg:35.462 Global:34.754 kb/s:1989.69
r1995 I: PSNR Mean Y:35.414 U:38.689 V:39.014 Avg:36.125 Global:35.424 kb/s:1993.67

I'll relinquish the interpretation to you.

[Sagittaire]

MBAFF increase 0.6 dB for the same bitrate. Here it's certainely something like 10% gain for quality efficiency. Anyway 35 dB are really poor quality I think. Better to try with more usefull quality. Choose crf at 20 for your bitrate target reference and make encoding test for the 2 pass with this bitrate.

[IgorC]

It will be more interesting to see ssim results rather than psnr.

[Manao]

It will be more interesting to see ssim results rather than psnr. Or not. I don't really trust that much SSIM, so SSIM on interlaced content ? At least, PSNR doesn't care about the fact that the content is interlaced or progressive.

[LoRd_MuldeR]

Or not. I don't really trust that much SSIM, so SSIM on interlaced content ? At least, PSNR doesn't care about the fact that the content is interlaced or progressive.

For interlaced video, does x264 apply SSIM onto weaved frames consisting of two fields or on each field separately?

[LigH]

Choose crf at 20 for your bitrate target reference and make encoding test for the 2 pass with this bitrate.

http://www.cosmosfactory.org/images/aol/rocky/aol_riff3.jpg As you wish, master... ;)

7000 kbps this time. FRF from 1st pass, SSIM + PSNR from 2nd pass.

r1913 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732868 (15.733db) | PSNR Mean Y:41.500 U:43.317 V:43.768 Avg:41.973 Global:40.733 kb/s:6986.16
r1913 I: final ratefactor: 19.64 | SSIM Mean Y:0.9743073 (15.902db) | PSNR Mean Y:41.769 U:43.451 V:43.878 Avg:42.211 Global:40.888 kb/s:6981.45
r1995 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732895 (15.733db) | PSNR Mean Y:41.499 U:43.319 V:43.768 Avg:41.972 Global:40.732 kb/s:6985.28
r1995 I: final ratefactor: 19.43 | SSIM Mean Y:0.9759900 (16.196db) | PSNR Mean Y:42.089 U:43.864 V:44.323 Avg:42.554 Global:41.270 kb/s:6986.44

All runs with "--tune psnr"; you cannot tune for both PSNR and SSIM optimization at the same time (--aq-mode 0 vs. 2).

[CruNcher]

http://www.cosmosfactory.org/images/aol/rocky/aol_riff3.jpg As you wish, master... ;)

7000 kbps this time. FRF from 1st pass, SSIM + PSNR from 2nd pass.

r1913 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732868 (15.733db) | PSNR Mean Y:41.500 U:43.317 V:43.768 Avg:41.973 Global:40.733 kb/s:6986.16
r1913 I: final ratefactor: 19.64 | SSIM Mean Y:0.9743073 (15.902db) | PSNR Mean Y:41.769 U:43.451 V:43.878 Avg:42.211 Global:40.888 kb/s:6981.45
r1995 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732895 (15.733db) | PSNR Mean Y:41.499 U:43.319 V:43.768 Avg:41.972 Global:40.732 kb/s:6985.28
r1995 I: final ratefactor: 19.43 | SSIM Mean Y:0.9759900 (16.196db) | PSNR Mean Y:42.089 U:43.864 V:44.323 Avg:42.554 Global:41.270 kb/s:6986.44

All runs with "--tune psnr"; you cannot tune for both PSNR and SSIM optimization at the same time (--aq-mode 0 vs. 2).

looks good so far on paper :) what about the code complexity factor aka speed difference would be nice if you would include that too :)

[Sagittaire]

Good improvement but not 15% here like say the patch note. Perhaps that 15% is for more "realistic source" like movie or TV interlaced source.

15% for gain efficiency is enormous. For comparison difference between MPEG4 ASP and MPEG4 AVC for progressive source is something like 25%.

[LigH]

Of course, the VQEG test set contains academic samples. Realistic samples are *YOUR* task now (to anyone who reads here). ;)

[Didée]

What makes me wonder with your latest (2-pass) test is that there is some (small) improvement on the I frames, but basically no change at all on the P frames. (?!?)

[cyberbeing]

I was under the impression LigH did four tests. Is this wrong?

r1913 (P = Progressive)
r1913 (I = Regular Interlacing)
r1995 (P = Progressive)
r1995 (I = MBAFF Interlacing)

[LigH]

Oh darn, that's the detail I forgot to document ... you are perfectly right, cyberbeing. Sorry.

I compared the encoding of partially combed content between progressive encoding and interlaced encoding mode, not I-frames with P-frames.

[Didée]

(P = Progressive)
(I = Regular Interlacing)

Oh, of course!:o - I feel a little stupid now. :D

[kypec]

I feel a little stupid now. :D
Please don't. To err is human and we all been there few times :p

[IgorC]

For comparison difference between MPEG4 ASP and MPEG4 AVC for progressive source is something like 25%.
Depends of the bitrate. And it is still more safe to check the quality visually.

The difference between H.264 and ASP can be much more than >25%. Visually x264 is near twice or really twice (with highest possible quality preset) better than Xvid at low and middle bitrates where the quality is already great.

Metrics tell the same. It is worth to check the last MSU reports (especially subjective part).

[Sagittaire]

Depends of the bitrate. And it is still more safe to check the quality visually.

The difference between H.264 and ASP can be much more than >25%. Visually x264 is near twice or really twice (with highest possible quality preset) better than Xvid at low and middle bitrates where the quality is already great.

Metrics tell the same. It is worth to check the last MSU reports (especially subjective part).

Well it's not the case for metric. AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality). 50% gain it's for comparison for MPEG2 and H264.

Anyway % is relative. If H264 is your reference then it's 100% for MPEG2 improvement. If MPEG2 is your reference then it's 50% for H264 improvement. MSU use certainely best H264 reference for have more spectacular result. Anyway the reality is like that: if you want reproduce MPEG2 quality at 1500 Kbps, you must use ASP at 1000 Kbps and AVC at 700-750 Kbps.

[IgorC]

AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality).
Says who?

[Dark Shikari]

Well it's not the case for metric. AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality)Actually, that's exactly what the MSU tests show, using SSIM.*

*Note this is partially because x264 is a much better encoder than Xvid, not merely because AVC is better than ASP. But there never was an x264-class ASP encoder.

[nurbs]

Do you know when the new MSU test will be published? It still says May 12th on their page.

[Sagittaire]

Actually, that's exactly what the MSU tests show, using SSIM.*

*Note this is partially because x264 is a much better encoder than Xvid, not merely because AVC is better than ASP. But there never was an x264-class ASP encoder.

You are sure?

MSU say 40% in really best case (for Y-SSIM).

[nm]

You are sure?

MSU say 40% in really best case (for Y-SSIM).

Or slighly more with high quality presets. And that's just SSIM -- x264 also has better psy optimizations than current ASP encoders.

[LigH]

7000 kbps again, but this time a slightly longer video (3235 frames @ 25.0 fps = 2:09.4 min), taken with a rather low-quality HD Cam, anamorphic 1440x1080i.

Content: Zooming and panning around a woodworking machine, sometimes with flying wood shavings and moving grippers

I will upload the original later, because FFMS2 is unable to decode that correctly, the video jumps forth-and-back... tests were run using DGAVCDec. | 96.5 MB (http://www.holzon.de/PRIVAT/holzon_k2.m2ts)

r1913 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677229 (14.911db) | PSNR Mean Y:43.647 U:49.150 V:49.665 Avg:44.835 Global:44.680 kb/s:7031.11 | 13.04 fps
r1913 I: final ratefactor: 16.90 | SSIM Mean Y:0.9747748 (15.982db) | PSNR Mean Y:44.853 U:50.153 V:50.603 Avg:46.030 Global:45.902 kb/s:7013.13 | 8.84 fps
r1995 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677235 (14.911db) | PSNR Mean Y:43.648 U:49.151 V:49.663 Avg:44.836 Global:44.680 kb/s:7031.35 | 13.10 fps
r1995 I: final ratefactor: 17.14 | SSIM Mean Y:0.9723570 (15.584db) | PSNR Mean Y:44.387 U:49.944 V:50.474 Avg:45.599 Global:45.455 kb/s:7031.06 | 9.95 fps

x264 revisions 1913 (TechARP HD Bench 4.0) and 1995 (currently available in MeGUI); "P" = progressive, "I" = interlaced (--tff); FRF from 1st pass, SSIM + PSNR + fps from 2nd pass. All runs with "--tune psnr".

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks:

[Sagittaire]

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks:

You can create artificial interlaced source (resize 1080p24 to 1080i12). It's really artificial but it's just test.

[IgorC]

You are sure?
Are you sure?


MSU say 40% in really best case (for Y-SSIM).
So, now it is 40% instead of your 25%.

x264 had 60% of the Xvid´s size for the same quality.
Also MSU hasn´t used the best settings for x264 to keep it fast.

http://compression.ru/video/codec_comparison/h264_2010/appendixes.html#Appendix_5

[Dark Shikari]

You are sure?

MSU say 40% in really best case (for Y-SSIM).

"Average relative bitrate for the same quality" is 100% for Xvid, 52% for x264, in the 2011 MSU comparison.

[CruNcher]

Btw MSU does someone knows how well x264 was in the HDTV test (i guess first place seeing the football results), and will the upcoming include MBAFF evaluation as well, i really wonder if we might see Ateme coming back also ;) ?

[Mini-Me]

7000 kbps again, but this time a slightly longer video (3235 frames @ 25.0 fps = 2:09.4 min), taken with a rather low-quality HD Cam, anamorphic 1440x1080i.

Content: Zooming and panning around a woodworking machine, sometimes with flying wood shavings and moving grippers

I will upload the original later, because FFMS2 is unable to decode that correctly, the video jumps forth-and-back... tests were run using DGAVCDec. | 96.5 MB (http://www.holzon.de/PRIVAT/holzon_k2.m2ts)

r1913 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677229 (14.911db) | PSNR Mean Y:43.647 U:49.150 V:49.665 Avg:44.835 Global:44.680 kb/s:7031.11 | 13.04 fps
r1913 I: final ratefactor: 16.90 | SSIM Mean Y:0.9747748 (15.982db) | PSNR Mean Y:44.853 U:50.153 V:50.603 Avg:46.030 Global:45.902 kb/s:7013.13 | 8.84 fps
r1995 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677235 (14.911db) | PSNR Mean Y:43.648 U:49.151 V:49.663 Avg:44.836 Global:44.680 kb/s:7031.35 | 13.10 fps
r1995 I: final ratefactor: 17.14 | SSIM Mean Y:0.9723570 (15.584db) | PSNR Mean Y:44.387 U:49.944 V:50.474 Avg:45.599 Global:45.455 kb/s:7031.06 | 9.95 fps

x264 revisions 1913 (TechARP HD Bench 4.0) and 1995 (currently available in MeGUI); "P" = progressive, "I" = interlaced (--tff); FRF from 1st pass, SSIM + PSNR + fps from 2nd pass. All runs with "--tune psnr".

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks:

The first impressions I've seen with my 480i VHS captures are similar to this: The new build is a little bit faster, but the compression ratio (metrics vs. bitrate) is actually a little bit worse (encoding pure interlaced material as interlaced). This is really surprising to me in light of the 10-15% improvement claims. I know nothing about encoding or the H.264 standard, but what confuses me is that x264 was always said to encode interlaced video as an MBAFF stream, just without implementing the "adaptive" part. In that case, I'm not understanding why the overhead/extra metadata wasn't already present in the output of previous versions.

Is this about as good as it's going to get (i.e. the old builds are better for some sources), or will the interlaced/progressive selection heuristics be tweaked to make better decisions?

[LoRd_MuldeR]

Mini-Me, how exactly did you measure "metrics vs. bitrate"? And did you use the appropriate tunes (e.g. "--tune psnr" for PSNR comparison and "--tune ssim" for SSIM comparison)? Also remember that "metrics" cannot predict "visual quality" very accurately. The effect of Psy-optimizations is the best counterexample (and the reason why Psy-optimizations must be off for PSNR/SSIM measurement).

[Sagittaire]

Mini-Me, how exactly did you measure "metrics vs. bitrate"? And did you use the appropriate tunes (e.g. "--tune psnr" for PSNR comparison and "--tune ssim" for SSIM comparison)? Also remember that "metrics" cannot predict "visual quality" very accurately. The effect of Psy-optimizations is the best counterexample (and the reason why Psy-optimizations must be off for PSNR/SSIM measurement).

MBAFF don't introcuce another psy-optimizations. "MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison: a pure architectural optimisation for interlaced source. You can certainely discut the PSNR-SSIM accurancy to visual quality. But for MBAFF you can use PSNR-SSIM to measure exact improvement.

[kieranrk]

"MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison

No it isn't.

[LoRd_MuldeR]

MBAFF don't introcuce another psy-optimizations.

Well, I didn't want to imply that there are new MBAFF-specific psy-optimizations. However x264's exiting psy-optimizations, which are known to optimize against SSIM/PSNR, will still be enabled by default. Consequently any SSIM/PSNR measurement done without "--tune ssim" or "--tune psnr" (or the corresponding options set manually) will be tainted. MBAFF or not.

"MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison: a pure architectural optimisation for interlaced source. You can certainely discut the PSNR-SSIM accurancy to visual quality. But for MBAFF you can use PSNR-SSIM to measure exact improvement.

You can accurately measure the improvement of PSNR or SSIM, at a given (average) bitrate. But this doesn't say anything about how well this improvement in SSIM or PSNR correlates to the actual improvement in perceived quality. So one shouldn't blindly rely too much on these numbers...

[Sagittaire]

You can accurately measure the improvement of PSNR or SSIM, at a given (average) bitrate. But this doesn't say anything about how well this improvement in SSIM or PSNR correlates to the actual improvement in perceived quality. So one shouldn't blindly rely too much on these numbers...

MBAFF don't improve visual quality. MBAFF improve interlacing efficiency (like CABAC improve coding entropy efficiency if you compare with CAVLC). dev claim 15% gain for efficiency. For make this calcul dev simply compare bitrate reduction for the same PSNR-SSIM. Here it's just mathematic and it's easy to make direct comparison with and without MBAFF like it's easy to make comparison between CABAC and CAVLC (even if it's little more complex in reality because you have possible and particular pre-optimisation for CABAC and CAVLC compression)

[Dark Shikari]

Sagittaire is correct.

[LigH]

Unfortunately you can't optimize for both PSNR and SSIM comparison at the same time:

--tune <string> Tune the settings for a particular type of source
or situation
...
- psnr (psy tuning):
--aq-mode 0 --no-psy
- ssim (psy tuning):
--aq-mode 2 --no-psy
In my tests I preferred "--tune psnr"; still I reported SSIM values, but they are not accurate ... I believe, though, that their relation should be in a meaningful dimension.

[rallymax]

I've built x264 and ffmpeg hundreds of times from the checkouts but I can't get it to build right now.
I checked that ffmpeg (r26402) was installed to ../sharedbuild/include|lib and it is.
I can also confirm that HAVE_LAVF is on and it is pulling in the necessary header.... but it doesn't.
I can't work out for the life of me what's wrong.


/p/x264
$ uname
MINGW32_NT-6.1

/p/x264
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

/p/x264
$ ./version.sh
#define X264_VERSION ""
#define X264_POINTVER "0.115.x" (it's .1995)

/p/x264
$ head config.log -n 15
x264 configure script
Command line options: "--enable-debug" "--enable-shared" "--enable-static" "--enable-win32thread" "--prefix=../sharedbuild" "--extra-cflags=-I../sharedbuild/include" "--extra-ldflags=-L../sharedbuild/bin"

checking whether gcc works... yes
checking whether gcc supports for( int i = 0; i < 9; i++ ); with -std=gnu99... yes
checking whether yasm supports vpaddw xmm0, xmm0, xmm0... yes
checking whether gcc supports __asm__("pabsw %xmm0, %xmm0");... yes
checking for return log2f(2); in math.h... yes
checking for sws_getContext(0,0,0,0,0,0,0,0,0,0); in libswscale/swscale.h... yes
checking whether LIBSWSCALE_VERSION_INT >= AV_VERSION_INT(0,9,0) is true... yes
checking for enum PixelFormat pixfmt = PIX_FMT_YUV422P16LE; in libavutil/pixfmt.h... yes
checking for -lpostproc... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -Wall -I. -I../sharedbuild/include -march=i686 -mfpmath=sse -msse -std=gnu99 -lpostproc -L../sharedbuild/bin -Wl,--large-address-aware -o conftest

/p/x264
$ make
gcc -o x264.exe x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o input/lavf.o libx264.a -L. -lavformat -lavcodec -lavcore -lswscale -lavutil -lm -lavifil32 -lswscale -lavutil -L../sharedbuild/bin -Wl,--large-address-aware
x264.o: In function `print_csp_names':
p:\x264/x264.c:337: undefined reference to `av_pix_fmt_descriptors'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

[LigH]

Another test with a 7 minute TV report (containing interviews, TFT closeups, some CG, and semi-dramatical pans and zooms).

This time also with r1342 from the x264 HD benchmark v3.0; well, yes, it surely had different defaults, so don't compare between revisions too much, only between progressive and interlaced modes.

fps 1 fps 2 FRF 1 SSIM Y PSNR

r1342p 47.93 16.01 18.72 0.9774624 Y:43.689 U:46.320 V:47.125 Avg:44.424 Global:43.969
r1342i 43.03 11.81 18.39 0.9774914 Y:43.718 U:46.144 V:46.891 Avg:44.413 Global:43.989

r1913p 52.64 16.04 18.73 0.9778888 Y:43.791 U:46.322 V:47.123 Avg:44.507 Global:44.057
r1913i 47.66 11.10 18.38 0.9779887 Y:43.830 U:46.137 V:46.877 Avg:44.501 Global:44.105

r1995p 50.05 15.70 18.73 0.9778829 Y:43.790 U:46.320 V:47.124 Avg:44.506 Global:44.057
r1995i 41.76 12.94 18.34 0.9793411 Y:44.143 U:46.446 V:47.234 Avg:44.813 Global:44.398

Uuuhm ... :eek: -- now that looks like an efficiency boost! :cool:

[Phil_L]

Hi

I'm having issues with 2 pass encoding where in a couple of complicated scenes the bottom row of pixels around 30-50 in height are glitching every few seconds causing a sort of vertical stretching. This is repeatable every time. First noticed in a 20 minute film, and cutting and testing just the troublesome segments shows the same problem. The original footage has no problem.

The glitching is absent with ABR (single pass) encoding and only shows up on 2 (or 3) pass encodes. This is version 1995 but also affects version 1924, I've not tried other versions. The problem is also absent on a 2 pass encode with keyint set to 24.

Details:
AVI input via AVSynth script 1280x720 at 50fps encoding for Blu-ray 720p/50 on Windows 7 64bit but using the 32bit compiled x264. I've tried the compiled versions from www.x264.nl and from www.xvidvideo.ru, with the same results.

First pass:

x264.exe --bitrate 25000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000
--vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709"
--colormatrix "bt709" --sar 1:1 --pass 1 -o test.264 "test.avs"

Second pass:

x264.exe --bitrate 25000 --preset veryslow --tune film
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o test.264 "test.avs"

If I look at the output from the first pass no problem, but the output from the second pass has the issue.

If I can provide any more info let me know.

EDIT, looks like this problem is related to "Use MB-Tree", if I turn this off with --no-mbtree then 2 pass encodes stop having the issue. What is MB-Tree, is it required?

More info: Enabling mb-tree again the frequency of glitches is reduced with --qcomp set to 0.7 (from default of 0.6) and gone with qcomp set to 0.8, hopefully this info will help.

Regards

Phil

[CruNcher]

Another test with a 7 minute TV report (containing interviews, TFT closeups, some CG, and semi-dramatical pans and zooms).

This time also with r1342 from the x264 HD benchmark v3.0; well, yes, it surely had different defaults, so don't compare between revisions too much, only between progressive and interlaced modes.

fps 1 fps 2 FRF 1 SSIM Y PSNR

r1342p 47.93 16.01 18.72 0.9774624 Y:43.689 U:46.320 V:47.125 Avg:44.424 Global:43.969
r1342i 43.03 11.81 18.39 0.9774914 Y:43.718 U:46.144 V:46.891 Avg:44.413 Global:43.989

r1913p 52.64 16.04 18.73 0.9778888 Y:43.791 U:46.322 V:47.123 Avg:44.507 Global:44.057
r1913i 47.66 11.10 18.38 0.9779887 Y:43.830 U:46.137 V:46.877 Avg:44.501 Global:44.105

r1995p 50.05 15.70 18.73 0.9778829 Y:43.790 U:46.320 V:47.124 Avg:44.506 Global:44.057
r1995i 41.76 12.94 18.34 0.9793411 Y:44.143 U:46.446 V:47.234 Avg:44.813 Global:44.398

Uuuhm ... :eek: -- now that looks like an efficiency boost! :cool:

yep especially if you look @ the fps cost compared to paff its relatively low for the huge improvement :)

[Didée]

@Phil_L: You should show the Avisynth script, too. If it is "complex", and/or DirectShowSource is used, that could be the cause of the problem.

[Phil_L]

Hi

@Phil_L: You should show the Avisynth script, too. If it is "complex", and/or DirectShowSource is used, that could be the cause of the problem.

The Avisynth is really straight forward as the AVI is already in YV12 space and at 1280x720 @ 50fps

AVISource("source.avi", audio=false).AssumeFPS(50,1)


I've also tried the full HD file that is 1080/50p using the settings recommend for Blu-ray 50i and getting AVISynth to create 50i from 50p. I get the same problem on the exactly same scene when enabled for two pass, again it goes away disabling mb-tree or with mb-tree enabled and raising --qcomp to 0.8 the problem is gone, ABR (one pass encoding) is also glitch free but I assume that is because mb-tree isn't used.

It seems a very complicated scene causes the issue with mb-tree enabled, not sure what effect raising qcomp has but it also seems to fix it.

Regards

Phil

[LoRd_MuldeR]

Why do you need Avisynth at all, if you do not apply any filters? Can't x264 read your source directly, using FFMS2?

(BTW: You generally shouldn't overwrite "qcomp" manually. If you have problem with MB-Tree RC, you should provide a sample clip on which MB-Tree behaves bad)

[Phil_L]

Hi

Why do you need Avisynth at all, if you do not apply any filters? Can't x264 read your source directly, using FFMS2?

(BTW: You generally shouldn't overwrite "qcomp" manually. If you have problem with MB-Tree RC, you should provide a sample clip on which MB-Tree behaves bad)

Because the video is using the Lagarith codec, I don't think I could get that opened directly.

I'll sort out a sample clip and post where it can be found.

Many thanks

Phil

[nm]

Because the video is using the Lagarith codec, I don't think I could get that opened directly.

Libav/FFmpeg has a lagarith decoder these days and it's also supported by latest FFMS2 versions. Changelog (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-changelog.html) note:

FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)

[Phil_L]

Hi

Libav/FFmpeg has a lagarith decoder these days and it's also supported by latest FFMS2 versions. Changelog (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-changelog.html) note:

Experimental :confused: I'll stick with AVISynth as sometimes I need to do other things with the source.

I'm arranging a sample of the problem clip to be uploaded, who shall I PM with the link?

Regards

Phil

[MasterNobody]

Phil_L
We can't help you if you don't provide us with short source sample on which this problem will be reproducible.

[Phil_L]

Hi

Phil_L
We can't help you if you don't provide us with short source sample on which this problem will be reproducible.

As stated above I have now uploaded a sample, just wondering who I should send the download links to.

Regards

Phil

[MasterNobody]

As stated above I have now uploaded a sample, just wondering who I should send the download links to.
No need to PM, you can post it here. Short samples are fair use so I don't see legal issues. But if you so concerned about it, than at least PM link to me. But may be somebody other are also interested in sample.

[Phil_L]

Hi

No need to PM, you can post it here. Short samples are fair use so I don't see legal issues. But if you so concerned about it, than at least PM link to me. But may be somebody other are also interested in sample.

I've put a very short clip (to keep file size small) up in the link below. It shows the glitch when encoded using the commands below in order to create 720/50p for Blu-ray:

--bitrate 25000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o test.264 input.file

The first pass is glitch free, the second pass has the glitch, I get the second pass using the same but with --pass 2. There were two scenes this glitch occurred flicking throughout every couple of seconds.

Turning off mb-tree and there is no glitch on the second pass.

The short video clip is here (only a few seconds long), it is lagarith compressed 1280x720 @ 50fps: http://www.megaupload.com/?d=25TW03J3

A picture of how the glitch manifests itself: http://www.megaupload.com/?d=1ZY88FZU

Hope that helps.

Regards

Phil

[Dark Shikari]

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

[LoRd_MuldeR]

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

His source is mod16, so there shouldn't be any padding/cropping :confused:

[Phil_L]

Hi

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

I have absolutely no issues if a use ABR and/or view the output of the first pass. It is only when the second pass is performed with mb-tree enabled this glitch appears and then it's only on two scenes in a 20 minute video, where those 'stretched' pixels flicker in and out continually across those two scenes. Both scenes I suspect are challenging the x264 as they contain lots of detail.

I don't see how it can be the decoder given the first pass is fine, would the decoder even know or care how many passes there were?

Something is troubling the 2 pass encoding in some complicated scenes by the looks of things.

I hope the developers can identify and fix it, the encoding is super quality otherwise.

Regards

Phil

[Didée]

It's still possible that the usage of MB-tree causes a frame access pattern that brings up a bug in Lagarith. Not necessarily, but possibly.

To rule this out, you should convert the whole clip to an uncompressed YCbCr avi file, then do the same 2-pass scenario with this uncompressed avi as input.
- Artifact gone => Lagarith is to blame.
- Artifact still present => x264 is to blame.

That easy. ;)

[MasterNobody]

Phil_L
I reproduced and hopefully fixed problem (it was problem with VBV and MinCR limit) with your short sample. Try this build (http://www.mediafire.com/?ibmrxzfu368y4s4) with longer sample and check that problem was really fixed.

P.S. Patch (http://privatepaste.com/3017602c58)

[Phil_L]

Hi MasterNobody

Tried your patched version and can confirm that the problem is gone. I've rendered both full scenes that had the glitches and they are perfect now:thanks:

Many thanks for the quick investigation and turn around.

Regards

Phil

[Phil_L]

Hi

Some slight bad news, I've since watched through the entire video I re-encoded and found the same glitches appear but now in a different scene (this scene was not affected originally), just a couple of flickers of the same repeated pixels at the bottom of the frame. I've tried to isolate just this clip and re-encode it again, however the glitch didn't repeat.

So some progress, it is definitely an improvement but perhaps it needs tweaking a bit more?

I get trouble free encodes if I disable mbtree, use only 1 pass, or up qcomp to 0.8. Not sure what is so troubling about my footage, perhaps it just contains a lot of detail being first generation from an HD camera?

Regards

Phil

[Dark Shikari]

Hi

Some slight bad news, I've since watched through the entire video I re-encoded and found the same glitches appear but now in a different scene (this scene was not affected originally), just a couple of flickers of the same repeated pixels at the bottom of the frame. I've tried to isolate just this clip and re-encode it again, however the glitch didn't repeat.

So some progress, it is definitely an improvement but perhaps it needs tweaking a bit more?There is no such thing as "tweaking". There is either a bug (it is broken) or it is fixed (it works). Your source is not at blame for magically creating a bug in x264, unless it has psychic powers and the ability to cause developers to make mistakes.

[jpsdr]

If problem is not reproductible with short clip, i'm afraid the only solution at this stage is to provide the full file to x264 developers and the exact precise command line you used for them to analyse and solve this problem, wich is somehow not little.
One possible thing also, you can try to get some previous versions here (http://x264.fushizen.eu/) (maybe 2 or 3 last versions), and test them to see if the problem is also occuring with them. It also can help x264 developers if you find out for exemple, that v1995 produce problem but not v1947.

[Dark Shikari]

If problem is not reproductible with short clip, i'm afraid the only solution at this stage is to provide the full file to x264 developers and the exact precise command line you used for them to analyse and solve this problem, wich is somehow not little.
One possible thing also, you can try to get some previous versions here (http://x264.fushizen.eu/) (maybe 2 or 3 last versions), and test them to see if the problem is also occuring with them. It also can help x264 developers if you find out for exemple, that v1995 produce problem but not v1947.This bug dates back 500+ revisions, so that's highly unlikely to be useful.

[Sagittaire]

AQ for x264 seem not really flexible. Some user (and some compressionist) report visible artefact in dark area for example even at very high bitrate.

I will try to write patch for AQ with same parameters than Mainconcept for have really flexible AQ:
- Complexity, strength [-100;+100]
- Luma, strength [-100;+100]
- Contrast, strength [-100;+100]

I think that these parameters will be more clear than actual AQ parameters. I think that I know x264 very well but I never understand how work the actual AQ. There are already patch for AQ here to have reference patch to work ... ???

[shon3i]

AFAIK x264 AQ is only Complexity mask, and lowering AQ on higher bitrates (which is probably recommended) will reduce that blocking, but sound to me is like Psy Trellis blocking. Anyway there is some OreAQ/MixAQ patches around there that use several AQ methods.

[Phil_L]

Hi

There is no such thing as "tweaking". There is either a bug (it is broken) or it is fixed (it works). Your source is not at blame for magically creating a bug in x264, unless it has psychic powers and the ability to cause developers to make mistakes.

Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

Phil

[Dark Shikari]

Hi



Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

PhilThere's absolutely zero chance the problem will be fixed unless you can provide a sample that triggers it.

Changing qcomp doesn't "resolve" anything; it's just throwing things at the wall in the hopes of fixing something unrelated.

Please post a sample that produces a problem with the patched build posted above, along with settings and so forth.

[MasterNobody]

Phil_L
If you can't provide sample than at least run this build (http://www.mediafire.com/?7zb5wda3g8z2947) with stdout redirecting to file (>log.txt) on your sample. And post resulted file with used command line.

P.S. Patch with debug info (http://privatepaste.com/692433d71e)

[Phil_L]

Hi

There's absolutely zero chance the problem will be fixed unless you can provide a sample that triggers it.

Changing qcomp doesn't "resolve" anything; it's just throwing things at the wall in the hopes of fixing something unrelated.

Please post a sample that produces a problem with the patched build posted above, along with settings and so forth.

I did provide a sample originally, however this is essentially uncompressed video and the recent glitch I couldn't get to happen on just a tiny sample and the whole video weighs in at 100GB. I would if I could :)


If you can't provide sample than at least run this build with stdout redirecting to file (>log.txt) on your sample. And post resulted file with used command line.


I will do this, might be tomorrow now.

Regards

Phil

[Phil_L]

Hi

A log is attached. I only seemed to get a log with the 2 pass, not sure if this is correct or not.

I checked the scene that showed the glitch last time but it hasn't appeared this time around, at least not at the same location. This might be because I've gone for medium speed to get this run through in a more reasonable time. If the log isn't of use let me know and I'll run a "slow" pass.

Command used:

--level 4.1 --preset medium --tune film --pass 1 --bitrate 25000
--stats "test.stats" --keyint 50 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --sar 1:1
--bluray-compat --open-gop --slices 4 --colorprim "bt709"
--transfer "bt709" --colormatrix "bt709" --output "test.264" test.avs > "log.txt"

Hope that helps.

Regards

Phil

[MasterNobody]

I checked the scene that showed the glitch last time but it hasn't appeared this time around, at least not at the same location.
Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

[burfadel]

Hi

Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

Phil

Have you tried AQ-mode 2 (Auto-variance AQ)?

[Dark Shikari]

Have you tried AQ-mode 2 (Auto-variance AQ)?AQ is unrelated to the problem.

[burfadel]

My mistake, in my haste I used the wrong quote. I was meaning to use this one:

AQ for x264 seem not really flexible. Some user (and some compressionist) report visible artefact in dark area for example even at very high bitrate.

I will try to write patch for AQ with same parameters than Mainconcept for have really flexible AQ:
- Complexity, strength [-100;+100]
- Luma, strength [-100;+100]
- Contrast, strength [-100;+100]

I think that these parameters will be more clear than actual AQ parameters. I think that I know x264 very well but I never understand how work the actual AQ. There are already patch for AQ here to have reference patch to work ... ???

Your statement probably still applies though! and I do realise aq-mode 2 isn't perfect either :) ...

[Phil_L]

Hi

Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

Thank you again, I will test the patched version out later today and let you know. I'll also check out those frames for the problem.

Regards

Phil

[jpsdr]

I did provide a sample originally, however this is essentially uncompressed video and the recent glitch I couldn't get to happen on just a tiny sample and the whole video weighs in at 100GB. I would if I could :)
Phil

Have you try to use losless codec ?
The both i know (maybe there is also others), wich are free, have a good speed, have YV12 support and exist in both x86 and x64 version are Lagarith and UT Video.
Lagarith produce a little smaller files than UT Video, but is slower. Nevertheless, it's speed is problably not a issue compared to speed of x264.
I don't remember precisely the size difference between both, but it was around 10%. Speed was more (100fps for UT Video vs 40fps for Lagarith on my PC on 1080p YV12 video).

[Phil_L]

Hi

Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

Not good news I'm afraid. I've run through again using your latest version and logging the output and very similar debug output has been written to the log file, and at the locations of the frames indicated (which are pretty much the same as the first log) the glitches are there. The log file is pinpointing the problem frames pretty much exactly.

I've attached the second log, please note I cancelled the encoding once it was apparent there were glitches being logged again so it may not be as long as the first one.

The most recent exe I downloaded has hashes of:
MD4: 2dd29ea685ce5ca92a1998727abd5ca7
MD5: e2f366b83cc266fb790ec87c7394cfa0
SHA-1: fc630981abec36452526d2359300e3d159c7ccfe

This is different to the first EXE that contained logging, so I think I did get the newest one.

Regards

Phil

[MasterNobody]

Phil_L
The latest version (from the link above) was with:
MD5: dcc6721a4e1b1bb8c576005077f0f72d
SHA-1: 59bbffd4348bae2d3bd4f51fd331f19d129d1f82

And it doesn't have any debug logging in it. So you probably tested incorrect build.

[Phil_L]

Hi

I did wonder, I've downloaded again and the hash values match yours now.

Many thanks, I will update you once completed another run through.

Regards

Phil

[MasterNobody]

Phil_L
If you want debuging info (for easy bad frames founding) here is build x264dgb.exe (http://www.mediafire.com/?gb99v7wic4sflxg) (I renamed it to don't confuse with other builds).

P.S. But if it really fixed problem then result log file must be empty

[Phil_L]

Hi

I've run through with the debug version and nothing logged, and checking the problem scenes they are all okay, so looks like all fixed.

I take it this fix will find it's way into the usual builds at some point and until then is there any reason I can't use the fixed version you've sent?

Thanks again for your time on this.

Regards

Phil

[jpsdr]

Will this fix be included in the next commit ?

[LoRd_MuldeR]

Will this fix be included in the next commit ?

Have a look here for upcoming commits:
https://github.com/DarkShikari/x264-devel/commits/master

[burfadel]

I apologise if this has already been in some way answered, I did search but might have used the wrong search terms.

Are the FMA4 and XOP instructions introduced with the upcoming AMD FX processors useful? if so, what benefit could they potentially bring (I realise the answer would be hypothetical)? If they are potentially useful, any plans on implementing them and if so what timeframe?

I'm just curious at this stage, if I did get a FX-8150P or FX-8170P later in the year it would be nice to fully utilise it!

[Dark Shikari]

I apologise if this has already been in some way answered, I did search but might have used the wrong search terms.

Are the FMA4 and XOP instructions introduced with the upcoming AMD FX processors useful? if so, what benefit could they potentially bring (I realise the answer would be hypothetical)? If they are potentially useful, any plans on implementing them and if so what timeframe?

I'm just curious at this stage, if I did get a FX-8150P or FX-8170P later in the year it would be nice to fully utilise it!XOP: possibly, but I need SSH access to a Bulldozer to do such optimizations.

[Didée]

Ha, the $64 question of BD - will it burn x264 due to the doubled integer units, or will it not ... We won't know until it's there.

[unix_sansei]

How about incorporating the meta-data into the files so that they will stream properly without having to post-hack them with other tools?

[CAFxX]

Haswell+AVX2 (http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/) :eek:

Gather
Useful for vectorizing codes with nonadjacent data elements. Haswell gathers are masked for safety, (like the conditional loads and stores introduced in Intel® AVX) , which favors their use in codes with clipping or other conditionals.

Bit manipulation instructions
Useful for [compression] and a variety of general purpose codes.

AVX2 - Integer data types expanded to 256-bit SIMD.
AVX2’s integer support is particularly useful for processing visual data commonly encountered in consumer imaging and video processing workloads. With Haswell, we have both Intel® Advanced Vector Extensions (Intel® AVX) for floating point, and AVX2 for integer data types.

[Dark Shikari]

http://i.imgur.com/REy9M.jpg

[iwod]

Integer Performance related. May be major improvement for x264?

[aegisofrime]

Integer Performance related. May be major improvement for x264?

DS did say that AVX1 was mostly useless because it's mostly floating point. Guess AVX2 would be more useful.

However, Haswell is still quite far off in the horizon. We still have Ivy Bridge to get through first :(

[imcold]

More useful? You bet!

[Biggiesized]

Well, I decided to wait on Haswell anyway (from Conroe). I'm glad things are going to get exciting.

[CAFxX]

http://i.imgur.com/REy9M.jpg

ymmd :D

[iwod]

No more Xvp8? Latest newsletter doesn't have a word for it.

[Dark Shikari]

No more Xvp8? Latest newsletter doesn't have a word for it.As usual, the prospect of the existence of xvp8 disappeared when Ronald was absorbed into the Google hive-mind. Ask him about it, and he'll apparently have forgotten the project ever existed, let alone the fact that he promised to do it.

If a few tens of thousands of dollars came my way, I'd do it instead.

[iwod]

As usual, the prospect of the existence of xvp8 disappeared when Ronald was absorbed into the Google hive-mind. Ask him about it, and he'll apparently have forgotten the project ever existed, let alone the fact that he promised to do it.

If a few tens of thousands of dollars came my way, I'd do it instead.

Which basically means Google paid him to shut him up or not working on it.

Oh Well..

As much as i hate patents, I hate vp8. I love x264, but i hate MPEG LA. I guess just like everything in this world nothing is perfect.

[Dark Shikari]

Which basically means Google paid him to shut him up or not working on it. Or he's a lazy bum :p

[CruNcher]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)

[Dark Shikari]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)He's not working on that either :p

[CruNcher]

He's not working on that either :p

So hes working entirely on the Decoder ?

Btw Decoder
Is there a known bug with interlaced Studio Mpeg-2 input (on the internal decoder side) on the chroma layer --tff ?
i get strange chroma distortions and much different (better quality) results from Mainconcepts Decoder as Input.
Though it seems to be more a general libav/ffmpeg interlace 4:2:2 decoder issue it seems.


EDIT needs further evaluation

I can change settings on the FFMpeg decoder side like crazy (ffdshow) it has 0 effect Dscaler does better but it uses another field and overwriting doesn't seem to work so you have very hardly visible motion issues in some scenes (strange blending @ object edges, slightly visible on bright colors for the background object, the foreground object is moving on (like a head moving fast on a full blue background the head gets strange black blending edges in motion after deinterlacing) ). Though i heavily doubt a untrained eye would see both of those effects (chroma off,edge issues) in motion :)

[mandarinka]

Its not a big difference if he writes the vp8 encoder with x264 terminology from scratch or if he improves the existing one the result matters ;)

However the result everyone was expecting was to come entirely from the "x264 terminology" :devil:

[HJRodrigo]

He is too involved in the petty squabble of libav versus FFmpeg to focus on xvp8. I will be honest though, I way prefer the name libva over FFmpeg. I wish he would make peace and just work from the inside to fix problems with the management, rather than create this confusion of libav.

[CruNcher]

is it possible to disable the indexing of ffms i see only a --index option but nothing like --no-index or is --demuxer lavf thought to be used without indexing ?

[kemuri-_9]

is it possible to disable the indexing of ffms i see only a --index option but nothing like --no-index or is --demuxer lavf thought to be used without indexing ?

ffms mandatorily requires indexing.
use --demuxer lavf if you don't want to index.

[CruNcher]

ffms mandatorily requires indexing.
use --demuxer lavf if you don't want to index.

ok i thought that just wanted to be sure so both fail with the above result though ffms with indexing seems to create even funnier issues with indexing in some camera motion sequences resulting in jumping forward and backwards (changing the field order for several frames ?, doesn't happen with --demuxer lavf ) :( Might be a build issue though, i better try several ones.

[Thunderbolt8]

when just caring about quality and not about filesize, is GOP size = 1 then the best solution? same question for number of b-frames = 0?

[Dark Shikari]

when just caring about quality and not about filesize, is GOP size = 1 then the best solution? same question for number of b-frames = 0?If you care just about quality, use lossless mode.

[Thunderbolt8]

hm the problem is I use x/h264 within TMPGEnc and they dont have such a setting. best I can do is constant quality at 62.500 kbbs

I guess its also not possible to exchange their x264 dlls with more recent ones from regular x264 binaries?

edit: as I see it I can select 1 pass constant quantization. but I cannot choose a general quantizier like 0,0, I can only set Quantization for I-picture B-picture and P-picture. so when setting all three of them to 0, would this equal lossless mode?

would the quality in this case by definition (at least theoretically) be better than choosing a constant bitrate of 62500? (here in case of a source of ~30.000 kbbs average, 50.000max)

edit²: lol, my computer cannot play 152.000 kbps compression smoothly. will have to stick to those high bitrates like 62500 then. so coming back to my initial question, if I have to specify a size for GOP and number of b-frames are 1 and 0 respectively the best settings then for quality?

[xv]

Great that there is 4:4:4 support soon in x264!
For me it already produces watchable output with I-frame only (a lot of frames do no not work or are not coded at all, the percentages in the statistics also do not sum to 100%).

For lossless RGB encoding (screen capture for example) it actually needs to encode the RGB data without any YUV conversion. I´m not sure if it´s useful at this stage, but I made a patch for that (against 4:4:4 part 13):
It adds a function to convert packed rgb to planar rgb (picture->frame copy), automatically sets colormatrix to RGB (GBR) and turns fullrange on (can be overridden by command-line). I think it´s quite clean, except for this VFLIP flag. It makes x264 crash, so I removed it and made the flip in the packed->planar conversion. Probably some internal RGB->YV12 conversion does not work correctly anymore.

Unfortunately ffmpeg ignores the colormatrix flag and treats the RGB as YUV, resulting in a completely wrong colored picture. Adding RGB support there does not seem to be that simple, because ffmpeg does not have any planar RGB colorspace.

[mandarinka]

It should be at least possible to test compression in lossless stil image coding now, for example against jpeg2k :)

[upyzl]

when seen the posts by CruNcher and kemuri-_9 before

As far as I know, most useful info is in the header of a media file (for h264, that is SEI in h264 stream header, right?), and ffms index is aiming to find that (so we need not to manual such as --fps, right?).
so, isn't there any method to force ffms do just header index to save time??

[kemuri-_9]

when seen the posts by CruNcher and kemuri-_9 before

As far as I know, most useful info is in the header of a media file (for h264, that is SEI in h264 stream header, right?), and ffms index is aiming to find that (so we need not to manual such as --fps, right?).
so, isn't there any method to force ffms do just header index to save time??

ffms's indexing is more targeted towards accurate seeking in the video than just plainly reading the header of whatever file you have.
this seeking feature is more primarily useful in avisynth than in x264cli.

[upyzl]

ffms's indexing is more targeted towards accurate seeking in the video than just plainly reading the header of whatever file you have.
this seeking feature is more primarily useful in avisynth than in x264cli.

It explains the matter...thanks

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?

[LoRd_MuldeR]

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?

It depends solely on the individual DirectShow source filter (splitter) how seeking is implemented internally.

There's nothing that would prevent a DirectShow source filter from creating its own index (either in memory or in a file), I think.

After all DirectShow is mainly targeted at playback, not at frame-accurate editing. Quite often it won't be frame-accurate...

[Atak_Snajpera]

BTW, DirectShow should be also accurate seeking (depend on splitter which user uses), why doesn't it need index? or I'm wrong?
If you want accurate seeking you should use DSS2() instead.

[upyzl]

@ LoRd_MuldeR & Atak_Snajpera

Thank you for the explanation/advice
In fact I always choose the most suitable demuxer I think...luckily there's no anomaly with it :)

then wait for x264 4:4:4 support version release...:D

[xv]

It seems Dark Shikari completed 4:4:4 in x264. I´ve updated and improved my patch for that.
Added:
-Add support for BGRA and RGB (only BGR before)
Fixed:
-Removed some debug lines included in previous patch
-Removed original code instead commenting
-VFLIP bug fixed (was caused by x264_frame_internal_csp) and support for not-flipped RGB colorspaces
-Found code where x264 lowers quality of U/V planes for I444 input, but not for YV24. Changed to I444/YV24, but not RGB.

4:4:4 works great for me, but I won´t upload a binary, because I don´t know if Dark Shikari likes the idea to have binaries of his development branch here (if he says it´s ok I´ll post a link). Also current ffdshow builds crashes on 4:4:4 files, you can use latest ffmpeg to decode.

[Dark Shikari]

Binaries are okay, but please submit these patches on IRC; my 4:4:4 has lots of bugs and fixes/improvements are welcome.

By the way, G should probably be in the Y plane, for purposes of motion estimation.

[xv]

Link to binary: http://www.mediafire.com/?xagqd6o6t026o7y (most likely buggy! Use it for testing only!)
By the way, G should probably be in the Y plane, for purposes of motion estimation.
Yes, it is Y=G, Cb=B and Cr=R. It´s defined in E.2.1 VUI Parameter Semantics (page 379 in 3/2010 standard).

There is also a very interesting system for lossless RGB->YCoCg transform, but it does not work with x264 (yet?), because it needs 1 bit more chroma precision than luma (8 Bit RGB will be converted lossless to 8 Bit Y, 9 Bit Co and 9 Bit Cg). The YCoCg colorspace is similar to normal YCbCr, but designed for better compressibility instead of being based on analog PAL/NTSC transforms, and there is the option of lossless RGB conversion that needs increased chroma precision.

[Dark Shikari]

Can you come on IRC (x264-devel on Freenode) to discuss and submit your patches?

[Anakunda]

I have a feature request, called AUTORESUME. I had several long runs (counting tens of hours in total) whose some of them were interrupted by system crash. A facility to periodically save state to some temporary file and enabling to fully resume on broken process would spend much time in such a cases. If the encoder builds encoding on previous frames it wouldnot be problem to go that amount of frames back , still better than start again from scratch.

[mandarinka]

1) Mux the result to mkv.
2) Cut off the part from last keyframe till end. (Use mkvmerge splititng after timecode for this. You can look up the keyframe in f.e. aegisub or guess based on scenechanges).
3) Encode the mising part using crf (use raw .264 as output or demux afterwards).
4) Demux first streams to raw ES.
5) copy /B part1_crashed.264+part2.264 combined.264
6) mux...

[jpsdr]

If you have crashes, you may have a problem somewhere else. I often make encodes wich takes days, and never had any trouble, neither less crashes.

[LigH]

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

:goodpost: I still agree....

http://paste.frubar.net/13902 -- probably not yet valid. Please check.

[DVD Logic]

Hi all!

Can anybody please provide detailed B-pyramid structure description or AVC specification with such description ?

Send please to support@dvd-logic.com

Thanks,
Valery.

[kieranrk]

Hi all!

Can anybody please provide detailed B-pyramid structure description or AVC specification with such description ?

Send please to support@dvd-logic.com

Thanks,
Valery.

This isn't actually answering your question, but for Blu-Ray you shouldn't care much about that - you should just follow the information in the picture_timing_sei for muxing.

[DVD Logic]

Ok. Thanks!

Anyway, just interesting where I can find detailed and accurate description of B-Pyramid for x264?

Regards,
Valery.

[burfadel]

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious :)

[Dark Shikari]

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious :)Output should not change at all; this is part of my regression-testing.

It will probably be marginally slower. I templated all the parts of the code that had significant slowdowns (CABAC, macroblock_encode) to avoid significant speed loss.

[burfadel]

I guess marginally slower and a slight change in output wouldn't matter as long as its not a drop in quality :) Its quite an impressive amount of code! If it is a little slower, would probably be a good time to release any speed improvements there might be at the same time to help cancel it out. I'm just thinking on the spot here of course, but I'm thinking if people notice a slowdown this thread might get bombarded! Alternatively, if there are any quality tweaks/improvements, that would also help to cancel peoples opinions :)

That said, thankyou for the work and effort put into x264, its easy to see its a great quality program (the code, quality and speed of results etc) and I personally don't think there are too many programs that would even come close to x264's all-round level when you consider every factor of the program.

[DVD Logic]

This isn't actually answering your question, but for Blu-Ray you shouldn't care much about that - you should just follow the information in the picture_timing_sei for muxing.

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help, dear developers, what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

[kieranrk]

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

Don't do this...If the encoder does not set correct values then you should fail and tell the user to encode using Blu-Ray settings. Silly hacks like this will not work properly as seen by tsmuxer.

[DVD Logic]

tsMuxer works fine with B-pyramids.

[kieranrk]

tsMuxer works fine with B-pyramids.

The hacks it uses fail with pulldown though.

[dstln]

I think I've told this to you guys before when I had similar problems, but directly encoding from .avi fraps is again broken in x264. Now it even manages to crash x264 after indexing :O Using avisynth as the intermediary instead of ffms/lavf again works fine. I'm not sure of exactly the point that it's crashing when I try directly.

Using the latest x264 along with fraps 3.40. I'm guessing fraps updates their codec fairly regularly...

[Snowknight26]

Works fine here using latest x264 revision/Fraps. Update your Fraps.

[Chikuzen]

@dstln
Lavf was broken immediately after r2008 was released.
http://forum.doom9.org/showthread.php?p=1508934#post1508934

After a day, this bug was fixed, and x64 binary redistributed by x264.nl was replaced.
Download x264.exe again, and test it.

[dstln]

Thanks for the replies, I'll try again. Guessing I got the early one.

edit: still happening after updating x264 (ffms appears to start), I'll try recording with newer fraps when I get a chance. It looks like they've fixed some recording bugs recently.

[Atak_Snajpera]

How to enable multithreaded decoding in Lavf ? Unfortunately ffms is useless for .mts so I can't use it.

[Chikuzen]

How to enable multithreaded decoding in Lavf ? Unfortunately ffms is useless for .mts so I can't use it.

http://komisar.gin.by/old/2008/p/x264_demuxer_threads.1995.diff

[Atak_Snajpera]

--demuxer-threads <integer> Force a specific number of threads for demuxer (lavf, ffms)

Thanks

[upyzl]

Excuse me
r2037 is released right now on git.videolan.org
commit 9977b595fb7591e3616fa98677baf6e84e0f7029 r2036
Author: Dan Larkin <danielhlarkin@gmail.com>
Date: Wed Jul 13 12:45:23 2011 -0500

Add --subme 11, which disables all early terminations in analysis
Necessary for a future trellis mode decision/motion estimation patch.
Also add the slowest presets to the regression test.
Does it mean that subme 11 is incomplete now?

and
commit 3765dfdd27bd206a800a61c38c0a6639d762db3b r2022
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Jul 15 15:06:37 2011 +0400

Fix use of deprecated libavcodec functions
Replace avcodec_open with avcodec_open2. Now requires libavcodec 53.6.0 or newer.

x264.nl builds
x264 -V
x264 0.116.2037 f8ebd4a
(libswscale 2.0.0)
(libavformat 53.3.0)
(ffmpegsource 2.15.4.1)
built on Jul 23 2011, gcc: 4.5.3 (x86_64.multilib.Komisar)
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 3 or later
maybe lavf should be updated?

[Boulder]

I don't think it's incomplete itself. It seems to be enabled if you set --preset placebo, at least according to the full help.

[Selur]

small question regarding "--subme 11": Does it like --subme 10 require trellis=2 and aq-mode>0, or does it require something else?

[LoRd_MuldeR]

small question regarding "--subme 11": Does it like --subme 10 require trellis=2 and aq-mode>0, or does it require something else?

787 if( h->param.analyse.i_subpel_refine >= 10 && (h->param.analyse.i_trellis != 2 || !h->param.rc.i_aq_mode) )
788 h->param.analyse.i_subpel_refine = 9;

[Selur]

Thanks! :)

[Snake91]

How much gain can we get from subme11? And what about future trellis (mmm maybe it's too early:p)?

[Selur]

it's a placebo setting, so probably nothing visible to the human eye. ;)

[Target Practice]

How much gain can we get from subme11?I did a test: subme 10 (http://www.mediafire.com/file/35y7y4t25kr8jaj/subme10.mkv), subme 11 (http://www.mediafire.com/file/vm62iud3wgb76q7/subme11.mkv)

http://img685.imageshack.us/img685/6130/subme11psnrdifference.png

[Snake91]

Thanks ;), imho only for video maniacs! (and with an ancient q6600 I can't join the party:p)

[upyzl]

@Boulder
Yes, it is available...maybe new Trellis (will)do improve it

@Target Practice
use SSIM is better...because both subme 10 & 11 need AQ on

This is my draft test

Clip A Clip B
1 2 3 Avg fps SSIM 1 2 3 Avg fps SSIM
umh+subme10 29.70 29.66 29.72 29.693 0.9942365 17.00 16.99 17.01 17.000 0.9742235
umh+subme11 18.59 18.59 18.60 18.593 0.9943463 11.06 11.06 11.07 11.063 0.9745654
tesa+subme10 24.22 24.03 24.20 24.150 0.9943326 12.79 12.81 12.81 12.803 0.9745798

paras: --seek 500 --frames 900 --vf resize:768,432 -p2 --stats "tmp.stat" -B 500 --me umh/tesa -t 2 -m 10/11 --tune ssim --ssim

[jpsdr]

In one of the last updates of x264, there is subme=11 added for a future treillis patch.
Is it possible to have some informations about this future patch ?
(Is it a new treillis mode or improvement of actual mode ? What average % improvement can be achieved ? A rought ETA, are we talking about weeks or months ?)

[cyberbeing]

The future trellis patch is Dan Larkin's (dlarkin) Google Summer of Code Project, Trellis Motion Estimation (http://wiki.videolan.org/SoC_2011/x264_Trellis_Motion_Estimation). If you are curious about specifics, you could probably go on IRC and ask him.

[mandarinka]

Currently, he's probably on the verge of madness from all the work though, because the program is near the finish. IMHO it's better to stay patient here at the forums, and don't hamper the actual development being done.

[schweinsz]

Does the current x264 support 10bits encoding for interlace?

[kieranrk]

Does the current x264 support 10bits encoding for interlace?

Yes it does.

[rallymax]

Hi all,
with the following line I'm getting playback at half speed from my bgra4444 src.
In Windows Media Player it plays at half speed but the progress bar is at 100% after the first frame.
In Adobe Premiere CS5 it will only play the first 2 frames.

I can't work out how to fix it.

Any pointers greatly appreciated. :thanks:
(I've tried -tff etc and it's the same.)

x264 --quiet --profile main --stdin raw --input-csp bgra --input-res 720x480 --fps 29.970 --level 4.1 --bitrate 8000 --vbv-maxrate 9000 --sar 40:33 -o 480p29.97.264 -

My source is a raw stream of BGRA4444 (8bit). Unfortunately I can't work out how to put that into a file so I can't post an example. But I can tell you it's the x264 example output with a timecode burnt into it for 10 seconds.

One again, thank you for pointers as to why it's wrong.

Here is the output MediaInfo
General
Complete name : M:\My Videos\480p29.97.264
Format : AVC
Format/Info : Advanced Video Codec
File size : 11.9 MiB

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Bit rate : 10 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Bits/(Pixel*Frame) : 0.965
Writing library : x264 core 116
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=tff / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=10000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

[J_Darnley]

My source is a raw stream of BGRA4444 (8bit). Unfortunately I can't work out how to put that into a file so I can't post an example. But I can tell you it's the x264 example output with a timecode burnt into it for 10 seconds.

You're piping it into x264, redirect into a file instead. Something like: whatever > file

As for the too slow problem, are you setting the right framerate?

[JEEB]

Due to the two patches I got onto le x264 development tree, I'd like to post a test build that should help us see how badly I failed: It contains the 'color matrix and range from lavf/ffms' as well as the 'use simple bit shift for 8bit->x264 output bitness conversion in case of limited range' patches put onto 2074. Enjoy.

32bit Build, 10bit output (http://x264.fushizen.eu/files/dev/2074_range_matrix_and_8to10.7z)

Disclaimer: The latter patch is knowingly unoptimized and I was surprised it went through as quickly as it did to the development repo, as it isn't templated yet. Also, the limited range higher bit depth dithering algorithm was shamelessly taken off of 06_taro's patch, so I have no idea if it's completely correct (I had pinged irock about it, but I have yet to have gotten any response on that). The limited range 8->output bit depth conversion does now use a simple bit shift, though -- which should be the correct way. Thus, I am enthusiastic in hearing of results with this fix in place.

Edit: Binary overwritten by a newer one, completely let the high bit depth -> 16bit converter slip my mind in input/raw.c .

[mandarinka]

Cool! Thanks.

[rallymax]

You're piping it into x264, redirect into a file instead. Something like: whatever > file

As for the too slow problem, are you setting the right framerate?

OK I recompiled my program to pipe the raw stream of BGRA4444 to a file instead of to x264 and then used that file as the input to x264. I get the same result.
I also confirmed that my output loop was called 300 times (30 fps x 10 seconds) which is correct.... so it begs the question with the above command line (specifically --fps 29.970) why does it play back at half speed in Windows Media Player and in Premiere CS5.5 it detects it as being 1 frame long????
I'm starting to think it is a .264 decoder thing - I'll use something to encapsulate it in a mp4 container (coz x264 doesn't support that right???)

[nm]

I'm starting to think it is a .264 decoder thing

Definitely! We didn't even imagine you were trying to use the elementary stream directly.

I'll use something to encapsulate it in a mp4 container (coz x264 doesn't support that right???)

x264 does support MP4 output when built with GPAC and pretty much all the binaries people are sharing do have that support. If you use a self-compiled version and don't want to go through all the trouble, just use MP4Box.

[G_M_C]

I see that 4:2:2 has been comitted recently (http://repo.or.cz/w/x264.git), but no post in the 'development' thread yet. This post is to let everybody wanting to work with 4:2:2 know.

But also for a short question of mine, on 10bit: When i use an 8-bit source on 10-bit x264. When does x264 do the converting from 8-bit to 10-bit ? Is that done before the filtering stage or after ?
( ex:8bit input -> conversion to 10bit -> resize -> encoding stage )

[aegisofrime]

I saw that XOP and FMA support has been added.

I'm curious as to how much of a speedup these instruction sets provide. I'm building a new encoding rig soon, and such information would be helpful as to whether to get an i7-2600K now or hold out for Bulldozer. Given AMD's recent habit of delaying, I'm not exactly sure when it will be launched.

According to this supposed marketing slide from AMD (http://img.donanimhaber.com/images/haber/amdfxpressdeck_12a_dh_fx57.jpg), Bulldozer is only slightly slower than the i7-2600K. I'm wondering if the new instruction set support will change this, and if so by how much.

Thanks!

[MasterNobody]

But also for a short question of mine, on 10bit: When i use an 8-bit source on 10-bit x264. When does x264 do the converting from 8-bit to 10-bit ? Is that done before the filtering stage or after ?
( ex:8bit input -> conversion to 10bit -> resize -> encoding stage )
After. Depth filter is the last in chain (before sending data to libx264).

[G_M_C]

After. Depth filter is the last in chain (before sending data to libx264).

K, thx :)

But doesnt conversion to 10-bit, before resizing theorethically lead to better quality ?

[sneaker_ger]

The problem is probably that all of the filters are 8 bit only.

[Soliloquy]

as to whether to get an i7-2600K now or hold out for Bulldozer.

I don't think AMD will be beating intel anytime soon, so the 2600K will probably be your best bet if you want the faster cpu. I don't have any hard data to back that up though.

[aegisofrime]

I don't think AMD will be beating intel anytime soon, so the 2600K will probably be your best bet if you want the faster cpu. I don't have any hard data to back that up though.

Do click on the slide that I linked to.

Granted that it is a marketing slide, but if true then it means that Bulldozer is awfully close to 2600K.

I'm guessing that the x264 developers probably have access to a Bulldozer CPU. I'm hoping they can release performance details after the NDA is lifted :p

[Dark Shikari]

Indeed, I have SSH access to a bulldozer. Unfortunately I can't say much~

[LigH]

Indeed, I have SSH access to a bulldozer.

LigH imagines the consequences if that was not a CPU but road-paving equipment... :p

[hajj_3]

nice to see that you have got your hands on a bulldozer cpu. Will there be new optimisations for bulldozer within a few weeks of bulldozer's release?

Can't wait to see the speed of bulldozer compared to intel.

I saw some benchmarks yesterday that show the highend bulldozer 8 core (£200) is about the same speed with x264 as the highend intel core i7 990x which is £800. It is supposed to be around 20% faster than the core i7 2600k SKT1155 (£240) too.

Have you got your hands on the bulldozer 16 core server cpu too?

[Selur]

little question:
Since x264 supports 4:2:2/4:4:4 is there anything missing to make x264 High 4:2:2/4:4:4 compatible? If not will there be a High422/High444 '--profile' option in the near future?

Cu Selur

[sneaker_ger]

Currently 4:2:2 will always be Hi422P and 4:4:4 always be Hi444PP AFAIK, to control you set --output-csp iXXX. I don't think it currently offers Hi444PP for 4:2:2 content. :confused:

[Midzuki]

LigH imagines the consequences if that was not a CPU but road-paving equipment... :p

The *compression-efficiency* would be much higher, granted. :D

[Ice009]

I'm building a new encoding rig soon, and such information would be helpful as to whether to get an i7-2600K now or hold out for Bulldozer. Given AMD's recent habit of delaying, I'm not exactly sure when it will be launched.


I want to build an encoding rig too with either a 2600K or Bulldozer 8150. I'm in no hurry though so I'll wait until Bulldozer is out before making a decision. Are you in a hurry? If you're not, you may as well wait and see how Bulldozer performs.

[rallymax]

I want to build an encoding rig too with either a 2600K or Bulldozer 8150. I'm in no hurry though so I'll wait until Bulldozer is out before making a decision. Are you in a hurry? If you're not, you may as well wait and see how Bulldozer performs.

w.r.t. your Intel choice: Are you going for the "K" version because of the Intel HD 3000 vs 2000 GPU? Because if you're not then this "Intel Core i7-2600 vs 2600K" (http://ark.intel.com/compare/52213,52214) comparison on the Intel website shows you might as well get the 2600 coz it's exactly the same in all other categories, is cheaper and has things like Vpro that the 2600K does not.

Also at The Intel Developer's Forum ("IDF") (http://www.intel.com/idf/) last week I saw the new Sandy Bridge CPU & chipset that's coming out in NOVEMBER '11 with 4x 1600MHz DDR3 Memory Busses vs the 2600's 2 BUSSES. If memory throughput is important to you then you may want to wait for 2 months.

My 2c.

[Dark Shikari]

nice to see that you have got your hands on a bulldozer cpu. Will there be new optimisations for bulldozer within a few weeks of bulldozer's release?

Can't wait to see the speed of bulldozer compared to intel.

I saw some benchmarks yesterday that show the highend bulldozer 8 core (£200) is about the same speed with x264 as the highend intel core i7 990x which is £800. It is supposed to be around 20% faster than the core i7 2600k SKT1155 (£240) too.

Have you got your hands on the bulldozer 16 core server cpu too?I have access to a 2x16 core Bulldozer server, plus AMD is mailing us a physical system.

Yes, there will be XOP optimizations. Yes, they will help, at least a % or 2.

[vivan]

rallymax,
"K" = unlocked multiplier.

[Ice009]

w.r.t. your Intel choice: Are you going for the "K" version because of the Intel HD 3000 vs 2000 GPU? Because if you're not then this "Intel Core i7-2600 vs 2600K" (http://ark.intel.com/compare/52213,52214) comparison on the Intel website shows you might as well get the 2600 coz it's exactly the same in all other categories, is cheaper and has things like Vpro that the 2600K does not.

Also at The Intel Developer's Forum ("IDF") (http://www.intel.com/idf/) last week I saw the new Sandy Bridge CPU & chipset that's coming out in NOVEMBER '11 with 4x 1600MHz DDR3 Memory Busses vs the 2600's 2 BUSSES. If memory throughput is important to you then you may want to wait for 2 months.

My 2c.

I'm looking for a good value solution so that rules out socket 2011, which will probably be as expensive as X58 was on release. The main reason I'd choose the K model is for unlocked multipliers. I think either the 2600K or Bulldozer 8150 would be the best value for money for an encoding box.

[rallymax]

rallymax,
"K" = unlocked multiplier.

ah.
thx for the education.

[mandarinka]

In other words, not a very good value for the money if you aren't willing to go overclocking.

[Blue_MiSfit]

Woooow.... 2x 16 core. That sounds like an awful lot of fun to me!

[G_M_C]

[...]But also for a short question of mine, on 10bit: When i use an 8-bit source on 10-bit x264. When does x264 do the converting from 8-bit to 10-bit ? Is that done before the filtering stage or after ?
( ex:8bit input -> conversion to 10bit -> resize -> encoding stage )

After. Depth filter is the last in chain (before sending data to libx264).

K, thx :)

But doesnt conversion to 10-bit, before resizing theorethically lead to better quality ?

The problem is probably that all of the filters are 8 bit only.

Expanding on this short discussion;
I see a lot of 1080p ->720p encodes in the wild. For myself i have some captures in 1080i that I deinterlace and resize to 720p.

Concluding; x264's build in resizing-filter/crop-filter is used relatively often.

Would i be correct in thinking that making x264's resize/crop filters able to work in higher bitdepth (*) could help further improve x264 overall quality (as perceived by people that watch the encodes).

(*) i.e. moving the 8->10bit conversion to the beginning, in stead of it beeing the last step before encoding, and making the pipeline in between abble to process in a higher bit-depth (16-bit integer or something ?).

[MasterNobody]

Would i be correct in thinking that making x264's resize/crop filters able to work in higher bitdepth
x264's resize/crop filters already can work with high bit depth (you can use 'csp' param of resize filter and specify depth=16). The question is, are this official filters enough for you or not (and is this worth it).

[G_M_C]

x264's resize/crop filters already can work with high bit depth (you can use 'csp' param of resize filter and specify depth=16). The question is, are this official filters enough for you or not (and is this worth it).

For basic resizing it is good enough i think. Avisynth doesnt work in higher bitdepth yet afaik.

[Cman21]

question: will there be any quality gain encoding a 4:2:0 Blu-Ray to 4:2:2 or does the source need to be 4:2:2 to retain quality? i dont fully understand how the chroma sampling works so thought i would just ask.

[rallymax]

question: will there be any quality gain encoding a 4:2:0 Blu-Ray to 4:2:2 or does the source need to be 4:2:2 to retain quality? i dont fully understand how the chroma sampling works so thought i would just ask.

no gain. the damage is done to the src footage already.
This Wikipedia YUV (http://en.wikipedia.org/wiki/Yuv#Luminance.2Fchrominance_systems_in_general) page is an ok description of 4:4:4, 4:2:2 and 4:2:0

[Cman21]

no gain. the damage is done to the src footage already.
This Wikipedia YUV (http://en.wikipedia.org/wiki/Yuv#Luminance.2Fchrominance_systems_in_general) page is an ok description of 4:4:4, 4:2:2 and 4:2:0

ya i figured as much from what i could kinda put together from my own research, thanks anyway i guess.

[ajp_anton]

If you downsample it to 720p or even smaller, you might gain something.
1080p has 960x540 of chroma resolution, keep as much of it as you can =).

[hajj_3]

Now that the NDA for bulldozer is over and is available for pre-order will you be releasing an updated version of x264 with bulldozer optimisations anytime soon?

Would be nice to see benchmarks of an optimised x264 compared to v2085 build.

[the_weirdo]

Now that the NDA for bulldozer is over and is available for pre-order will you be releasing an updated version of x264 with bulldozer optimisations anytime soon?


You might find the answer here:
http://forum.doom9.org/showthread.php?p=1530754#post1530754

[rallymax]

If I'm feeding i444 to x264 is there any upside in feeding in 10bit vs 8bit if the output is Bluray (ie i420 8bit)?
x264 is doing no scaling or cropping.
thx

[rallymax]

is x264bluray.com's x264 for bluray settings accurate these days?
specifically the
--open-gop
--pulldown double and 32
--fake-interlaced

thx

[sneaker_ger]

Yes, it is.

[rallymax]

Yes, it is.

thx!! :thanks:

[benwaggoner]

If I'm feeding i444 to x264 is there any upside in feeding in 10bit vs 8bit if the output is Bluray (ie i420 8bit)?
x264 is doing no scaling or cropping.
thx
In theory, a codec could make use of the 10-bit luma range in figuring out how to most efficiently preserve gradients etectera, instead of the codec-blind brute-force dithering that normally happens. Basically it would do a rate-distortion optimization finding the 8-bit output that would best match the 10-bit input. In a lot of cases, I bet the codec could discover that adjoining pixels could be more similar than a typical dithering algorithm, reducing low amplitude high frequencies a bit.

I don't know if x264 does that, but it sure would be cool if it did :). But it probably not the kind of feature one would knock off in a weekend.

[kieranrk]

In theory, a codec could make use of the 10-bit luma range in figuring out how to most efficiently preserve gradients etectera, instead of the codec-blind brute-force dithering that normally happens. Basically it would do a rate-distortion optimization finding the 8-bit output that would best match the 10-bit input. In a lot of cases, I bet the codec could discover that adjoining pixels could be more similar than a typical dithering algorithm, reducing low amplitude high frequencies a bit.

I don't know if x264 does that, but it sure would be cool if it did :). But it probably not the kind of feature one would knock off in a weekend.

I thought about doing this at VDD but Dark_Shikari said it wouldn't help much

[Dark Shikari]

Well, we can't be quite sure without trying, but more practically there's the issue that 10-bit sources are incredibly rare, so it wouldn't affect the vast majority of users.

[wlee15]

AMD has publicly posted the BIOS and Kernel Developer’s Guide for Bulldozer. I imagine that the performance monitoring section might be useful for x264 development (although I hope that AMD had already provided the documents).

http://support.amd.com/us/Processor_TechDocs/42301.pdf

[Biggiesized]

In theory, a codec could make use of the 10-bit luma range in figuring out how to most efficiently preserve gradients etectera, instead of the codec-blind brute-force dithering that normally happens. Basically it would do a rate-distortion optimization finding the 8-bit output that would best match the 10-bit input. In a lot of cases, I bet the codec could discover that adjoining pixels could be more similar than a typical dithering algorithm, reducing low amplitude high frequencies a bit.

I don't know if x264 does that, but it sure would be cool if it did :). But it probably not the kind of feature one would knock off in a weekend.

What do professional MPEG-2 broadcast encoders do?

[kieranrk]

What do professional MPEG-2 broadcast encoders do?

Most organisations using an MPEG-2 broadcast encoder would not be using a "true" 10-bit playout system - the playout system would be based on MPEG-2 intra most likely and not be 10-bit.

[Blue_MiSfit]

Indeed. All of the playout servers I work with use some form of "long" GOP MPEG-2. XDCAM HD422, generic MPEG-2, Omneon etc... it's all 8 bit. Of course, it gets played out over (10 bit) HD-SDI, so I would imagine the extra bits simply become padding? Assuming this, a downstream broadcast encoder would simply ignore the top bits? Things could get more complex with graphics devices between the playout server and the broadcast encoder, since these could possibly produce true 10 bit video...

I imagine some facilities playout 10 bit (DNxHD maybe, or AVC Intra), but I doubt most would have the budget for the storage this would entail...

Derek

[benwaggoner]

Well, we can't be quite sure without trying, but more practically there's the issue that 10-bit sources are incredibly rare, so it wouldn't affect the vast majority of users.
It depends on where you are in the production chain. Most TV and movies are produced in >8-bit, and lots of production codecs (Cineform, DNxHD, ProRes) can operate in 10-bit or even 12-bit modes. If there were encoders that could improve efficiency by using 10-bit sources directly, they would be used with 10-bit sources in many professional workflows.

[jpsdr]

Any status about the future treillis patch for witch subme=11 has been added ?
A very very rough ETA ?
Just to be clear : I'm not asking to push or anything, i'm not in a hurry, i'll wait the needed time, but i just would like to eventualy know how about to plan my jobs.
If you said : Maybe in one month or two, i'll may halt what i have to do, waiting for it, allowing me to do better quality encodes. If you said : Probably not before 6 months, i'll arange and plan things differently.
But not knowing and being in the fog...

[hajj_3]

v2106 has just been released, it contains the bulldozer improvements.

Hope someone with a bulldozer cpu can do some benchmarks of 720p and 1080p encodes with the v2085 and v2106 builds to compare the speed.

[TheRyuu]

v2106 has just been released, it contains the bulldozer improvements.

Hope someone with a bulldozer cpu can do some benchmarks of 720p and 1080p encodes with the v2085 and v2106 builds to compare the speed.

anandtech did. (http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/7)

[Dark Shikari]

anandtech did. (http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested/7)No they didn't. They did a review with an extremely old build of x264, and a new one, but didn't list the actual revision numbers, and claimed the only difference was that the new one was "AVX-enabled". In reality, AVX doesn't help on Bulldozer because Bulldozer already has move-elimination (except indirectly by saving code size, which helps marginally): the difference was because the versions they used were years apart.

They're incompetent at best, and I wouldn't trust their other benchmarks either.

[CruNcher]

Yep many of their tests are flawed in terms of Multimedia best example see their GPU encoding test where they make conclusions based on different vendor frameworks :(

when the first x264 benchmarks came into public it was clear a bulldozer system isn't as efficient but i wouldn't have thought its this of a heavy system difference like these 3 screen let you conclude from the Power Consumption behavior ?

http://images.anandtech.com/graphs/graph4955/41715.png
http://images.anandtech.com/graphs/graph4955/41697.png
http://images.anandtech.com/graphs/graph4955/41717.png


PS: AMD released their first Bulldozer benchmarks (aside of IDF running some blocks down @ a Press conference called Fussion Zone http://nl.hardware.info/nieuws/24619/eerste-officiele-benchmarks-amd-fx-processor ) and surprise surprise they used X264 in form of Handbrake for Benchmark winning it by 19% with 4 modules vs 4 cores , and surprise surprise Anandtech was not reporting about this but kept straight focused onto IDF and Ivy Bridge .
Though you can most probably guess that this win is bought @ almost the full 125W scale (though nothing really was revealed about the benchmark itself just the result) which everyone knows is not hard to win vs Intels more efficient 95W output driving your max Power to the EDGE.
At least it seems they reach almost Intels Efficiency now and don't hang 2 Generations behind anymore which already is a good sign they are back in a fully recovered state (after all the Fusion investment including ATI)

And i guess you can currently take only Annandtechs test as reference here i saw no others comparing power consumption on x264 vs Intel Sandy Bridge :(
unfortunately there is no Power Consumption result of the newer AVX Build for both (fail again) :(

@Dark Shikari
Is it really like this somehow it's hard to believe or are you able to improve this further down (Consumption) or eh up (Speed) for Bulldozer ?

[aegisofrime]

Hopefully somebody competent can do a proper benchmark then. I'm kinda bored with my i7-2600K. :p

Also I wish somebody would do a CRF benchmark.

[noee]

^^
I hacked up this batch runner (http://www.techarp.com/showarticle.aspx?artno=520) to use the new x64 10bit and changed it to CRF22 medium and a 4100 did about 10-12% better than a 3.5Ghz Propus box I have. Not really a benchmark, fwiw, but a quick look.

[Atak_Snajpera]

Hopefully somebody competent can do a proper benchmark then. I'm kinda bored with my i7-2600K.

Also I wish somebody would do a CRF benchmark.

Convince them to use my benchmark ;)
http://i.imgur.com/lq6Bi.gif

Download
http://www.mediafire.com/?mcic8cupimcy4fm

[mandarinka]

^^
I hacked up this batch runner (http://www.techarp.com/showarticle.aspx?artno=520) to use the new x64 10bit and changed it to CRF22 medium and a 4100 did about 10-12% better than a 3.5Ghz Propus box I have. Not really a benchmark, fwiw, but a quick look.

offtopic, but could you perhaps benchmark the performance of nnedi3 (or other significant avisynth filters - nnedi3 is well multithreaded though, so a good test)?

[noee]

offtopic, but could you perhaps benchmark the performance of nnedi3 (or other significant avisynth filters - nnedi3 is well multithreaded though, so a good test)?

It's not my machine, but the dude helping out is willing to test anything except 64bit AVISynth. ;)

It's on AMDZone.com, under the "Fusion, etc." forum board (http://www.amdzone.com/phpbb3/viewtopic.php?f=532&t=138886)....If you wanted to post a script or offer a particular example.

I can help make it work with the batch runner, if needed.

[aegisofrime]

Convince them to use my benchmark ;)
http://i.imgur.com/lq6Bi.gif

Download
http://www.mediafire.com/?mcic8cupimcy4fm

For some reason your benchmark recognizes my i7-2600K as a 8C/16T CPU :p

[Midzuki]

BTW, animated GIFs are pesky and annoying. :mad: :p :D

[jpsdr]

My I7@980 was recognized as 16C/32T CPU. Result was 25.1.

[epitaxial]

Indeed. All of the playout servers I work with use some form of "long" GOP MPEG-2. XDCAM HD422, generic MPEG-2, Omneon etc... it's all 8 bit. Of course, it gets played out over (10 bit) HD-SDI, so I would imagine the extra bits simply become padding? Assuming this, a downstream broadcast encoder would simply ignore the top bits? Things could get more complex with graphics devices between the playout server and the broadcast encoder, since these could possibly produce true 10 bit video...

I imagine some facilities playout 10 bit (DNxHD maybe, or AVC Intra), but I doubt most would have the budget for the storage this would entail...

Derek

Yes, servers are one of the places where 10 bit sources become 8 bit and for the reason you note. Most production (live) is actually 10 bit and if this is delivered (backhauled) using MPEG2 then - 8 bit however J2K and AVC 10 bit solutions are becoming prevalent so the 10 bits are carried through. And most devices in a broadcast plant now process 10 bit.

When 10 bit is converted (brute force) to 8 bit the LSBs are chopped off.

As for the availability of 10 bit source material - my Decklink Extreme HD capture card does a very nice job of capturing raw 10 bit from cameras, TSGs, etc... so there's plenty available.

Greg

[rallymax]

For AVC 10 Intra do you have any preferred settings?
I like the idea of standardizing on i444 10bit as a digital intermediate permanent storage type.
thx

[hajj_3]

@Dark Shikari: I don't know if this is news for you or not but there are some ways to get 10% more out of bulldozer cpu's by changing some scheduling things in win7, see this info: http://techreport.com/articles.x/21865

Maybe x264 already does this I don't know, thought i'd let you know anyway.

[mandarinka]

It probably won't help if all the cores are already utilized.
Maybe for 1st pass, IF the scheduler is clever enough to shut some idle module or two to get headroom for turbo and put the critical lookahead thread onto the turbo-boosted module while fully dedicating it just to the 1 thread. Lots of ifs...
Whether I am right here or not, one thing is certain: don'T expect any miracles anything significant there.

[kieranrk]

For AVC 10 Intra do you have any preferred settings?
I like the idea of standardizing on i444 10bit as a digital intermediate permanent storage type.
thx

Well Panasonic are pushing 12-bit 4:4:4 as their new format. I had a long discussion about it with the people at IBC.

[MetalPhreak]

Is there any ETA on when we can expect the 10-bit color shift bug to be resolved?

[mandarinka]

You can at least use patched builds in the meantime: http://x264.fushizen.eu/

[Dark Shikari]

Is there any ETA on when we can expect the 10-bit color shift bug to be resolved?When kemuri9 finishes the range patch.

[rallymax]

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

[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.

[dado023]

i need some advice.
How does this:
--min-keyint 0 --ref 8 --rc-lookahead 60 --bframes 6 --b-adapt 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1:0.15 --partitions all --me esa --merange 24 --aq-mode 2
compare to --preset veryslow ? I am interested in quality, but placebo is crazy slow, so i need your opinion for quality.

Question number two:
What will happen if i include --preset veryslow like this:
--preset veryslow --min-keyint 0 --ref 8 --rc-lookahead 60 --bframes 6 --b-adapt 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1:0.15 --partitions all --me esa --merange 24 --aq-mode 2

Thanks

[sneaker_ger]

Preset veryslow is this (see x264 --fullhelp):
--b-adapt 2 --bframes 8 --direct auto --me umh --merange 24 --partitions all --ref 16 --subme 10 --trellis 2 --rc-lookahead 60

Manual parameters override preset options.

[dado023]

@sneaker
thanks for the info regarding override, but what do you think about output quality between those two?

[sneaker_ger]

Should be almost identical, just like the parameters are. Stick to the preset, unless you really know what you are doing.

[jpsdr]

I've some questions.
- Is there different qmatrix in x264, and choice is selected by --tune or is there only one standard defined ?
- In what file(s) are the matrix defined and used/selected ? I want to see if i can "easely" implement (if not done) a tune of qmatrix according the selection of --tune.

:thanks:

[MasterNobody]

I've some questions.
- Is there different qmatrix in x264, and choice is selected by --tune or is there only one standard defined ?
- In what file(s) are the matrix defined and used/selected ? I want to see if i can "easely" implement (if not done) a tune of qmatrix according the selection of --tune.

:thanks:
As I understand you meaned CQMs by "qmatrix". --tune option doesn't change used CQM. There is 2 predifined CQMs: flat (default) and JVT. Also custom CQMs are possible with --cqmfile option.

P.S. Anything except flat CQM is rarely used in x264 because most features (like AQ) are tuned for using it.

[burfadel]

I was looking online and came across a patch for x264 for K-means weightp: https://github.com/astrataro/x264_tMod/commit/dbbd7a15b1c7f040f329cd9ec7d9a13a9e84bc89

Obviously the patch requires at least minor alterations for non-multipatched x264, but that is not the reason of my question. I was wondering what K-means Weightp is, and whether it is of any actual benefit?

On a separate note, do people find http://komisar.gin.by/old/2245/p/x264_aq3.2208.diff of any benefit in terms of AQ mode 3 over AQ mode 2?

[LoRd_MuldeR]

I was looking online and came across a patch for x264 for K-means weightp: https://github.com/astrataro/x264_tMod/commit/dbbd7a15b1c7f040f329cd9ec7d9a13a9e84bc89

Obviously the patch requires at least minor alterations for non-multipatched x264, but that is not the reason of my question. I was wondering what K-means Weightp is, and whether it is of any actual benefit?

AFAIK this was never really finished. At least it's still on the "TODO" list:
http://wiki.videolan.org/X264_TODO#Weighted_Prediction

On a separate note, do people find http://komisar.gin.by/old/2245/p/x264_aq3.2208.diff of any benefit in terms of AQ mode 3 over AQ mode 2?

See here:
http://forum.doom9.org/showpost.php?p=1607941&postcount=6

[burfadel]

About K-means, even thought it isn't finished, I am curious about what it actually is, and what it does in terms of quality improvement?!

I was thinking even if it's not part of x264, it doesn't mean aq-mode is any less as good as aq-mode 2. I believe it may somewhat overcome the shortcomings of aq-mode 2?

[JEEB]

About K-means, even thought it isn't finished, I am curious about what it actually is, and what it does in terms of quality improvement?!
K-means weightp was tried a few times, and this patch that f.ex. astrataro uses is an updated version of the k-means weightp feature that was started quite some time ago.

It was found out to be rather useless, results wise, by the original creator as well as the one who updated it to current x264 code if I recall correctly.
< dj_tjerk> JEEB > seems like it (is my patch).. not sure why anyone would be interested in Kmeans though
< dj_tjerk> odd indeed
< dj_tjerk> "must add extra features!" or something
< dj_tjerk> yet
< dj_tjerk> I will not support that patch :P
< dj_tjerk> anyhow, as I said before, I wanted it to be a stepping stone to explicit b-weighting... but with kmeans not really helping at all, and me finally getting something to do again at my job at the time, I didn't move on to that part of my 暇つぶし activities

Explicit b-weighting might be useful, but as such k-means weightp hasn't really shown any real results. I also added it on top of the patches on my patched x264 build for laughs, and it seems to break with no mbtree. Might be my mistake in something, but it clearly is just a patch created for testing/research, without support from its creator :) .

[burfadel]

Ah ok, thankyou! :)

[06_taro]

K-means weightp is not finished, and possibly would never be, since it seems that no one is working on it any more. Some people want its "magic" seriously, so it is served, without being mentioned in the blog because it's not for general use, and not even ready for tests. It crashes with no-mbtree, and in some (if not all) cases gives rubbish results in multi-pass encoding. However, one of those brave users, who in my personal opinion is quite addicted to transparent encoding with no tolerance for even a loss in noises and is keen on picking up several single frames to do frame-by-frame comparisons even in 2x size, claimed that it does avoid ruining lines and edges by current mbtree mechanism, such as hair in static animation scenes, while no one else has ever confirmed that. If you are also mbtree haters like him, feel free to take a try, with absolutely NO WARRANTY what it does.

[Stereodude]

Has the "veryslow" preset received the majority of the tuning and tweaking in x264 (or at least more than "placebo)? In my testing it seems to give lower bitrates than "placebo" at the same CRF and slightly better visual quality too.

[Dark Shikari]

Placebo is only marginally different if you look at the settings. Measuring a visual quality difference of the sort I'd expect between veryslow and placebo (under 1%) is for all intents and purposes physically impossible.

[Stereodude]

Placebo is only marginally different if you look at the settings. Measuring a visual quality difference of the sort I'd expect between veryslow and placebo (under 1%) is for all intents and purposes physically impossible.
Well there must be some infrequent circumstances where differences are visible otherwise it's a pointless setting to have right?

[Dark Shikari]

Well there must be some infrequent circumstances where differences are visible otherwise it's a pointless setting to have right?Placebo largely exists to give obsessive encoders something to waste CPU time on (hence the name! ;) )

But the idea that "1% isn't visible, so it doesn't matter" is a dangerous fallacy. By that logic, you could repeatedly lower the bitrate by 1%, and each time, it wouldn't be visible, so it wouldn't matter. Eventually, by induction, you could reach 0kbps and the video would look fine. Of course this doesn't actually work, since those little 1%s accumulate over time into something quite visible.

[xooyoozoo]

Placebo largely exists to give obsessive encoders something to waste CPU time on (hence the name! ;) )

It's winter around here. Might as well make your heater multipurpose :D.

By the way, AVX2 should be out and about in several months. Are there any hypothetical estimations on how beneficial that would be to x264's performance in the medium run (once the obvious optimizations are done with)? I'm just mulling over potential upgrades.

[Dark Shikari]

Let's try some proper math here (read: slightly informed guessing) instead of my usual total guessing.

In a quick test on preset medium on a Sandy Bridge, about 2.5% of x264's time is spent in CABAC asm (not SIMD), 5% in trellis asm (largely not SIMD), and ~40% in C code. So that rules out roughly 47.5% of x264 for speed improvements.

For the sake of clarity here, "50% faster" is defined to mean "takes 50% less time" (i.e. "twice as fast").
Keep in mind these numbers are high estimates: AVX2's badly designed "way" system might make it more difficult than expected to get reasonable speed increases. I'm also assuming that AVX2 can actually do every single 32-byte op we care about just as fast as a 16-byte op; if there are some where it simply splits it into 2 16-byte ops internally, we obviously won't get any more speed out of it.

52.5% remains:
8.0%: qpel functions. These may get faster due to faster unaligned loads, but AVX2 itself isn't useful here because the functions are purely load-bound.
7.0%: width 8 SATDs and Hadamard AC: ~25-35% faster
6.5%: width-16 SADs. If Haswell can do 2x16-byte unaligned loads per cycle, width-16 SADs could probably get ~30-40% faster.
4.5%: chroma MC. Thanks to the NV12 changes giving us twice the width to work with, we can probably get this ~30-40% faster.
4.0%: width-8 SADs. AVX2 won't help us here; there's just not enough width.
3.5%: width 16 SATDs: ~30-40% faster
2.0%: quant/dequant: ~20-30% faster

Everything else is mixed; AVX2 will probably help quite a bit on hpel filter for example but probably not on zigzags. So let's say it helps 15% on all the other assembly code combined.

This puts the overall gain, optimistically, at ~10% from AVX. Keep in mind though that Haswell itself may be quite a bit faster even before any AVX2 code is written.

[rallymax]

Hi Dark,
seeing as 40% of the code is in C land that would suggest that the quality of the C compiler could make a significant difference.

Do you have any metrics between the speed quality output by Intel C Compiler (ICC) vs GNU (gcc)?

[Dark Shikari]

Pretty much zero difference as far as I know, possibly ICL being worse, since it can't handle any of the inline assembly.

[Boulder]

Is there still no performance difference between the various GCC releases (4.x)?

[LigH]

The criterion is not the size of the source, but the time the code is executed. Most of the C code is only executed once, to make it an application at all (you wouldn't want to write a user interface, even for the command line, in Assembler). The really relevant code – which is executed over and over in loops for possibly hours – is highly CPU optimized Assembler code. No C compiler could optimize the execution of these routines any further.

[Dark Shikari]

The criterion is not the size of the source, but the time the code is executed. Most of the C code is only executed once, to make it an application at all (you wouldn't want to write a user interface, even for the command line, in Assembler). The really relevant code – which is executed over and over in loops for possibly hours – is highly CPU optimized Assembler code. No C compiler could optimize the execution of these routines any further.Where are you getting this from? This isn't true at all. Again, 40% of x264's time is spent in C code that is run billions of times, whether it's motion estimation, RDO, or a host of other things.

[LigH]

:o You winnel... (Hot Shots 2 - walnut scene) — I'll better leave that topic to those who know what they are talking about.

[Groucho2004]

Is there still no performance difference between the various GCC releases (4.x)?
I was bored a while ago and compared the speed of 4.5x and 4.6x. It turns out that you get about 2-3% more speed with 4.6x. However, this is not representative at all since I had only one CPU at my disposal (i5 2500k). With other processors, results may vary.

Edit: To avoid confusion: "Speed" refers to the encoding speed of the x264 binary, not the compilation process.

[xooyoozoo]

Is there still no performance difference between the various GCC releases (4.x)?

I think phoronix.com had a comparison using GCC 4.2-4.7.x some time ago. x264's performance barely drifted, regardless of compiler.

I prefer that over apps such as GraphicsMagick, where binary performance drifts by several factors if you so much as sneeze the wrong way.

[Stereodude]

Back in March of 2012 I did a speed benchmark of the 64bit and 32bit versions of x264 (2164) using the following command lines:

x264 --bitrate 25000 --fps 24000/1001 --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 -o NUL "park_joy_1080p50.y4m"
x264 --bitrate 25000 --fps 24000/1001 --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 -o PJx86.264 "park_joy_1080p50.y4m"

I found that while the 64bit version was much faster the QP's were very close:

2164 x86:[info]: frame I:23 Avg QP:25.04 size:561813
[info]: frame P:126 Avg QP:26.88 size:246702
[info]: frame B:351 Avg QP:31.26 size: 60159
2164 x64:[info]: frame I:23 Avg QP:25.09 size:558465
[info]: frame P:126 Avg QP:26.88 size:247294
[info]: frame B:351 Avg QP:31.25 size: 60392

I reran the same test today with 2245 and found the QP's for both are lower than they were with 2164. I guess x264 still continues to get more efficient with bitrate.

2245 x86x264 [info]: frame I:23 Avg QP:23.98 size:621297
x264 [info]: frame P:128 Avg QP:27.08 size:238940
x264 [info]: frame B:349 Avg QP:31.26 size: 58993

2245 x64[info]: frame I:23 Avg QP:23.99 size:620797
[info]: frame P:128 Avg QP:27.07 size:238938
[info]: frame B:349 Avg QP:31.27 size: 58793

[Dark Shikari]

If the output between the 32-bit and 64-bit versions is different at all, something is wrong.

[Stereodude]

If the output between the 32-bit and 64-bit versions is different at all, something is wrong.
Ooops, I found my mistake. I had accidentally copied the first pass data. I'll edit my post as to not mislead anyone

[pokazene_maslo]

I'm watching x264 development closely for quite some time now. Lately it seems like x264 development is pretty much dormant. Dark Shikari, are there any new features that are you working on? Or are you working on something else than x264.
Best regards.

[Dark Shikari]

I have a few nice patches coming up, but in general, there is far less low-hanging fruit than there used to be. It takes a lot more work to find something that can be improved relatively easily. One can also work on a larger project for something harder -- but as always, such ideas can take a lot of time and have a good chance of failing. And sometimes, even though we know the place where x264 is weak, we don't know any good solutions, or if one even exists.

I do have something else I'm working on, but it's rather personal and not programming-related.

[Atak_Snajpera]

does this mean that opencl will finally be avaliable in "official" builds?

[Dark Shikari]

OpenCL is still stalled because of a driver bug caused by AMD/Intel OpenCL drivers interacting, which caused it to silently break (and produce horribly wrong results) on machines that use AMD Enduro. I'm not involved in this, so I don't really know beyond that.

[pokazene_maslo]

I'm dreaming about cabac <-> cavlc converter for a long time. Is there any chance that someone from x264 development will implement this? This might be the low-hanging fruit you are looking for :-)

[jdobbs]

I looked a little and didn't see anything related to this. But I thought it odd so I thought I'd post it.

I'm doing some testing on r2245 (downloaded from www.x264.nl) with BD Rebuilder and got a failure when I tried to run it. I stepped back to r2230 and it worked again. So I pulled the command line and ran it from a DOS window. The error was "ratecontrol_init: can't open stats file". After a couple of tries I found that when running the command from a DOS window that was run as administrator, r2245 would run fine. A rights issue -- I guess -- but I don't see why. Why is it a rights issue with the new version but not with any of the older ones? The output folder has no special privileges.

Any help would be appreciated.

[Edit] Exact same peculiarity with the Komisar version

[LoRd_MuldeR]

If you are one Windows, I would suggest to use ProcessMonintor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and check which file/path exactly it tries to access and what operation exactly fails... (with what error)

BTW: Should be clear that if you install x264 to %PROGRAMFILES% or %PROGRAMFILES(X86)% (or a sub-folder thereof) you cannot create the stats files directly in the x264 "install" directory, unless you elevate the process (which is a bad idea). Instead you have to use %TMP% or %APPDATA% to store any "work" data.

[jdobbs]

If you are one Windows, I would suggest to use ProcessMonintor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and check which file/path exactly it tries to access and what operation exactly fails... (with what error)

BTW: Should be clear that if you install x264 to %PROGRAMFILES% or %PROGRAMFILES(X86)% (or a sub-folder thereof) you cannot create the stats files directly in the x264 "install" directory, unless you elevate the process (which is a bad idea). Instead you have to use %TMP% or %APPDATA% to store any "work" data. The stats file is in a user created folder. In fact BD Rebuilder creates it and creates several files in it just before it executes X264.EXE.

The important point is that the exact same command line works in that same folder without any additional privileges simply by renaming any of several previous versions of X264 to X264.EXE... so it's reasonable to assume that something in this version has changed that creates the issue.

[Dark Shikari]

Did you build both x264s in an identical build environment, with the same compiler and libraries?

[jdobbs]

Did you build both x264s in an identical build environment, with the same compiler and libraries? I didn't build them. I downloaded the builds from x264.nl and from the komisar site. Same for the older versions.

[jdobbs]

I looked a little and didn't see anything related to this. But I thought it odd so I thought I'd post it.

I'm doing some testing on r2245 (downloaded from www.x264.nl) with BD Rebuilder and got a failure when I tried to run it. I stepped back to r2230 and it worked again. So I pulled the command line and ran it from a DOS window. The error was "ratecontrol_init: can't open stats file". After a couple of tries I found that when running the command from a DOS window that was run as administrator, r2245 would run fine. A rights issue -- I guess -- but I don't see why. Why is it a rights issue with the new version but not with any of the older ones? The output folder has no special privileges.

Any help would be appreciated.

[Edit] Exact same peculiarity with the Komisar versionMark this up to voodoo. I downloaded again today after reinstalling the O/S. The new one ran, the old one failed. I did a compare, and it matched bit-for-bit. Anyway, I deleted the old copy and it works fine now.

[Selur]

I encoded a clip using "--ouput-csp rgb" and another using "--output-csp i444" and MediaInfo both times reports:
Color space : YUV
Chroma subsampling : 4:4:4

Is this a bug in x264, MediaInfo or am I missing something? (shouldn't the color space for the first one be RGB ?)

Cu Selur

[MasterNobody]

I encoded a clip using "--ouput-csp rgb" and another using "--output-csp i444" and MediaInfo both times reports:
Color space : YUV
Chroma subsampling : 4:4:4

Is this a bug in x264, MediaInfo or am I missing something? (shouldn't the color space for the first one be RGB ?)

Cu Selur
Both YUV 4:4:4 and RGB use same encoding tools in H.264 and the only difference are actual component values (GBR or YUV) and specified colormatrix in VUI. For RGB one mediainfo will report also:
Matrix coefficients : RGB

[Selur]

Ah, okay totally overlooked the 'Matrix coefficients', thanks for clearing that up. :)

[sl1pkn07]

one little question (i dont know is answer before), why not enabled make 8 and 10 depth bit in the same executable?

greetings

[Selur]

why not enabled make 8 and 10 depth bit in the same executable?
Because there is no option to compile x264 with 8 and 10bit support at the same time.
I asked quite some time ago about this and from what I remember one of the x64 developer replied (from memory) that the code paths are quite different and that it a would be a hassle to build a binary that supports both. (it would basically be a wrapper around the two versions)

[sl1pkn07]

I already knew it the flag, without flags (or --bit-depth=8) to 8 bits, or --bit-depth=10 for 10 bits

but did not know what the code paths you comment

and anhoter question, if build ffmpeg with x264 support (shared/static linked), need build ffmpeg two times, one enable for 8bits and other for 10bits?

[Selur]

afaik: yes (not sure if for a dynamically linked version just switching the x264 library would work)

[xooyoozoo]

I'm getting 'lossless' 10bit files that are larger than the 8bit version. Maybe I have a fundamental misunderstanding of qp=0 or 8 vs 10 bit x264, but shouldn't it be the other way around, or shouldn't the difference be at least closer to the 25% gap in channel information between 8b and 10b?

veryslow qp0 8bit:
yuv [info]: 1024x768p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:0 8-bit
x264 [info]: frame I:2 Avg QP: 0.00 size:303568
x264 [info]: frame P:498 Avg QP: 0.00 size:186531
x264 [info]: mb I I16..4..PCM: 39.4% 13.1% 47.4% 0.0%
x264 [info]: mb P I16..4..PCM: 25.0% 7.5% 9.0% 0.0% P16..4: 29.3% 7.0% 11.0% 2.4% 1.3% skip: 7.5%
x264 [info]: 8x8 transform intra:18.0% inter:43.6%
x264 [info]: coded y,uvDC,uvAC intra: 98.2% 66.9% 66.2% inter: 74.2% 60.4% 60.1%
x264 [info]: i16 v,h,dc,p: 14% 86% 0% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 69% 2% 1% 1% 0% 1% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 59% 2% 3% 3% 2% 3% 1% 1%
x264 [info]: i8c dc,h,v,p: 25% 55% 20% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 63.1% 7.1% 14.3% 4.6% 4.5% 1.6% 1.4% 0.6% 0.9% 0.3% 0.4% 0.3% 0.3% 0.2% 0.3% 0.2%
x264 [info]: kb/s:44879.78

veryslow qp0 10bit:
yuv [info]: 1024x768p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:0 10-bit
x264 [info]: frame I:2 Avg QP: 0.00 size:450184
x264 [info]: frame P:498 Avg QP: 0.00 size:299578
x264 [info]: mb I I16..4..PCM: 42.9% 15.6% 41.2% 0.3%
x264 [info]: mb P I16..4..PCM: 23.8% 8.7% 9.6% 0.0% P16..4: 23.8% 4.9% 13.0% 5.0% 3.7% skip: 7.5%
x264 [info]: 8x8 transform intra:20.5% inter:33.2%
x264 [info]: coded y,uvDC,uvAC intra: 98.0% 68.2% 67.4% inter: 73.5% 63.1% 62.9%
x264 [info]: i16 v,h,dc,p: 12% 88% 0% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 70% 1% 0% 0% 0% 0% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 59% 1% 1% 1% 1% 1% 0% 1%
x264 [info]: i8c dc,h,v,p: 20% 58% 22% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 63.5% 15.8% 6.2% 5.3% 2.1% 1.8% 0.9% 1.2% 0.5% 0.6% 0.4% 0.4% 0.3% 0.3% 0.3% 0.3%
x264 [info]: kb/s:72043.18

x264 r2245. Source is yuv420 8 bit.

[kypec]

I'm getting 'lossless' 10bit files that are larger than the 8bit version. Maybe I have a fundamental misunderstanding of qp=0 or 8 vs 10 bit x264, but shouldn't it be the other way around, or shouldn't the difference be at least closer to the 25% gap in channel information between 8b and 10b?
x264 r2245. Source is yuv420 8 bit.

You have artificially expanded 8-bit data into 10-bit (without any meaningful information added) and then want to have those 10-bit stored losslessly in video stream. It's pretty obvious to me that the result of 10-bit lossless storage space occupation must be larger than the space that the same original occupies at 8-bit data width.

[xooyoozoo]

You have artificially expanded 8-bit data into 10-bit (without any meaningful information added) and then want to have those 10-bit stored losslessly in video stream. It's pretty obvious to me that the result of 10-bit lossless storage space occupation must be larger than the space that the same original occupies at 8-bit data width.

There's a 60% increase in size between the artificially padded file and the normal file, which is just straight-up odd. My own intuition suggests that modern compression should and does* efficiently handle extra 'fake' information, the massive gap in my situation above just screams that there's a regression in the code somewhere.

I'm not exactly invested in 10bit lossless. I just bring this up in case it *is* a bug and to inform people because the large swings in bitrates here seem like something that should be in the fine print.

*Case in point:
7zipped 8bit YUV: 126.5 MB
7zipped FFMPEG'ed fake 10bit: 132.9 MB
Base on everything I know, the extra precision 10bit x264 would give to prediction should more than make up that ~5% gap. At the very least, predictive lossless shouldn't be worse than a zip file.

[Dark Shikari]

I'm surprised it's only 60%, I would have expected it to be more, given how H.264's entropy coding works.

H.264 isn't LZMA; it can't and isn't designed to absorb arbitrary redundancies in the source -- only those it's designed to compress. It's also a few hundred times faster.

[xooyoozoo]

I'm surprised it's only 60%, I would have expected it to be more, given how H.264's entropy coding works.

H.264 isn't LZMA; it can't and isn't designed to absorb arbitrary redundancies in the source -- only those it's designed to compress. It's also a few hundred times faster.

So just to make sure I get it right, somewhere between "normal" QPs and lossless QP, fake-10bit hurts more than helps?

[Dark Shikari]

So just to make sure I get it right, somewhere between "normal" QPs and lossless QP, fake-10bit hurts more than helps?No; it always helps for lossy at the same bitrate.

It's just that 10-bit adds 12 more QPs below the lowest possible QP in 8-bit, representing the possibility of up to 4 times greater precision. This represents more precision than is in the source in an 8-bit video; there is no equivalent QP in 8-bit encoding.

[BugiBugBug]

I don't know if this is the right place to ask, but I figured a small question like this is not worth a separate thread :)
I encode primarily with the same or similar settings, and I was wondering if it is possible or makes sense to use these particular settings (simple --preset medium or slow with b-adapt2, ref 3 and bframes 3 or 4, sometimes trellis2) in fprofiling my x264 binary?
Or more in general, does it make sense to delete OPT.. in the makefile that will never be used, or some options in it like --ssim in OPT1? Could be that I'm misunderstanding the way fprofiled works, of course - I'm kind of a newby at the game.
Maybe I could create my own OPT.. lines?

[Groucho2004]

I don't know if this is the right place to ask, but I figured a small question like this is not worth a separate thread :)
I encode primarily with the same or similar settings, and I was wondering if it is possible or makes sense to use these particular settings (simple --preset medium or slow with b-adapt2, ref 3 and bframes 3 or 4, sometimes trellis2) in fprofiling my x264 binary?
Or more in general, does it make sense to delete OPT.. in the makefile that will never be used, or some options in it like --ssim in OPT1? Could be that I'm misunderstanding the way fprofiled works, of course - I'm kind of a newby at the game.
Maybe I could create my own OPT.. lines?
Been there, done that (when I was really bored). Even profiling for a specific source didn't increase performance more than 1-2 %.
I don't use profiling any more - not worth it (at least with GCC).

[schweinsz]

How to use the x264 to encode the bitstreams using arbitrary hierarchical B coding.
For example, the display sequence is: B0 B1 B2 B3 B4 B5 B6 B7, the encoding sequence is: B0 B7 B2 B4 B1 B3 B5 B6.

If there is not this function., could somebody add it, it's not a big patch if only poc based ref. is used, but it perhaps gives a real gain perhaps big on coding efficiency.

[rack04]

summing the feedback my last post got up:

--bluray-compat

enables a bunch of 'Blu-ray hacks':
- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames cannot reference frames outside their minigop
- Open-GOP keyframe interval hack
renders '--open-gop' parameters obsolete:
- now: --bluray-compat + --open-gop <> old version: --open-gop bluray
- now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD
enforces:
- aud=1
- nalhrd=vbr
(-> these are not needed in the command line when using '--bluray-compat')
restricts:
- bframes to: 3 or less
- bpyramid to: strict or none
- max references to: 6 or less
- weightp to: 1 or 0


I want to make sure I understand this correctly. I have been backing up my Blu-ray collection for quite awhile using the following command line:

Encoding Pass 1 with I-Frame Chapters ...
"%x264_PATH%" --preset %PRESET% --tune %TUNE% --pass 1 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --bluray-compat --level 4.1 --keyint 48
--vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --sar 1:1 --b-pyramid strict --open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709
--output NUL "%INPUT_VIDEO%" --qpfile "%QPFILE_PATH%"

Encoding Pass 2 with I-Frame Chapters ...
"%x264_PATH%" --preset %PRESET% --tune %TUNE% --pass 2 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --bluray-compat --level 4.1 --keyint 48
--vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --sar 1:1 --b-pyramid strict --open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709
--output "%SOURCE_FOLDER%\%SOURCE_FILENAME%-output.264" "%INPUT_VIDEO%" --qpfile "%QPFILE_PATH%"

According to the quoted post above, since I'm using both --bluray-compat and --open-gop x264 applies --open-gop bluray?

[LoRd_MuldeR]

According to the quoted post above, since I'm using both --bluray-compat and --open-gop x264 applies --open-gop bluray?

The "--open-gop" option doesn't have a parameter anymore. So there is no "--open-gop bluray" in current x264.

However using "--open-gop" together with "--bluray-compat" enables the BluRay-safe variant of OpenGOP, so it's effectively the same as "--open-gop bluray" in older version.

(Though "--bluray-compat" does much more things than "--open-gop bluray" used to do)

[iSunrise]

Introduction to AVX2 optimizations in x264 (http://www.scribd.com/doc/137419114/Introduction-to-AVX2-optimizations-in-x264)

Looks pretty tasty!

[MaistroX]

Hi, anyone able to explain the following VARNINGS "x264 [warning]: non-strictly-monotonic pts at frame" & "x264 [warning]: MB rate (391288) > level limit (245760)" for me?

F:\_BD3D2MK3D\JP3D_48FPS\00023_m2ts>"C:\BD3D2MK3D v0.17\toolset\stereoplayer.ex
e\avs2yuv.exe" "_ENCODE_3D_MOVIE.avs" -o - | "C:\BD3D2MK3D v0.17\toolset\stereoplayer.exe\x264_x64
.exe" --bitrate 10000 --pass 1 --stats "00023_m2ts.stats" --preset medium --profile high10 --level 4.
1 --video-filter resize:1920,1080,method=bicubic --qpfile chapters_3D.qpfile --output "00023_m2ts.26
4" --frames 364870 --demuxer y4m --stdin y4m -
_ENCODE_3D_MOVIE.avs: 3840x1080, 48000/1001 fps, 364873 frames
y4m [info]: 3840x1080p 0:0 @ 48000/1001 fps (cfr)
resize [info]: resizing to 1920x1080
x264 [info]: using SAR=2/1
x264 [warning]: MB rate (391288) > level limit (245760)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile Main, level 4.1
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
[0.0%] 121/364870 frames, 0.83 fps, 28471.29 kb/s, eta 122:46:40
"

Wonder what it means and what it can make for faults + what I can do to make them go away ? :)

Regards MaistroX

[nhakobian]

The warning:
x264 [warning]: non-strictly-monotonic pts at frame
is telling you that the input pts timestamps are messed up in some way. In fact it looks like the timestamp is set to 0 for each of them (0 < 1 notations, etc.). Unless your source is variable frame rate, I don't think this should make a difference since you are forcing a frame rate.

x264 [warning]: MB rate (391288) > level limit (245760)
This is telling you that your resolution+fps setting exceeds the specified level limits. In this case, you are asking for level 4.1 and 1920x1080@48fps. This isn't allowed in level 4.1 (but is in 4.2). See http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels for more info.

[MasterNobody]

MaistroX
x264 shouldn't give "x264 [warning]: non-strictly-monotonic pts at frame ..." with y4m input. So its look like miscompiled build of x264. What build did you used exactly? Have you compiled it yourself or this http://x264.nl/ build (then which version)?

[Fishman0919]

I'm getting an error compiling the latest daily tarball (x264-snapshot-20130424-2245.tar.bz2) or git. A perl.exe.stackdump error.

NM, got it.... "which perl" showed pointing to perl.exe in git... renamed. alset

http://i467.photobucket.com/albums/rr37/fishman0919/perlerror_zpseafbc357.png (http://s467.photobucket.com/user/fishman0919/media/perlerror_zpseafbc357.png.html)

[LoRd_MuldeR]

If you don't need OpenCL support, you can use "--disable-opencl", but you probably have read that yourself ;)

Anyway, I usually use Strawberry (http://strawberryperl.com/) if I need Perl on the Windows platform...

[MaistroX]

I use:

x264 version:

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

http://komisar.gin.by/


MaistroX
x264 shouldn't give "x264 [warning]: non-strictly-monotonic pts at frame ..." with y4m input. So its look like miscompiled build of x264. What build did you used exactly? Have you compiled it yourself or this http://x264.nl/ build (then which version)?

[Fishman0919]

If you don't need OpenCL support, you can use "--disable-opencl", but you probably have read that yourself ;)

Anyway, I usually use Strawberry (http://strawberryperl.com/) if I need Perl on the Windows platform...

Yes, thank you LoRd_MuldeR... but for some reason when I did "which perl" it was pointing to the "perl.exe" in the Git installation instead of the one in Strawberry.

[LoRd_MuldeR]

Yes, thank you LoRd_MuldeR... but for some reason when I did "which perl" it was pointing to the "perl.exe" in the Git installation instead of the one in Strawberry.

It's probably because MSYS will insert its own "bin" directory (as well as the "bin" directory of the associated MinGW/GCC) into its PATH variable before anything else that it inherited from your systems PATH environment variable. Or you have a separate Git installed that happened to end up in your PATH before the entry of Strawberry. MSYS Git comes with its own MSYS stuff, which can cause trouble.

Try something like "export set PATH=/c/strawberry/bin:$PATH" before you execute "./configure".

[MasterNobody]

I use:

x264 version:

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

http://komisar.gin.by/

I tried this (clear x86_64) komisar's build and couldn't reproduce issue with your command line (obviously I had to use another avisynth script for avs2yuv and different qp-file but all other was the same). So may be it is problem with something other on your system (non standard AviSynth version or dunno)?

[LoRd_MuldeR]

I noticed that latest x264.exe will now depend on OpenCL.dll, if compiled with OpenCL lookahead support.

Correct me if I'm wrong, but I think this means that now a graphics card with OpenCL support plus an up-to-date display driver, that provides an OpenCL.dll is required to run x264.

If so, I guess a lot of users will run into issues with "standard" builds now. Wouldn't it be possible to detect and load the OpenCL.dll at runtime, only if available?

[filler56789]

I noticed that latest x264.exe will now depend on OpenCL.dll, if compiled with OpenCL lookahead support.

O_o

Correct if I'm wrong, but I think this means that now a graphics card with OpenCL support plus an up-to-date display driver, that provides an OpenCL.dll is required to run x264.

I haven't yet run a test encode with the latest x264, but so far it seems the DLL is required only for making x264.exe S.T.F.U. :p

And oh BTW, is that DLL freely-redistributable? :confused:
Yes, I've found it and downloaded it, but this is not the point, of course.

EDIT:
Just confirming, r2309 does work normally IF you have OpenCL.dll in the same folder as x264.exe.

EDIT 2:
By "x264 works normally", I mean I didN'T use the the --opencl option.

[Dark Shikari]

Eesh, I wonder if there's a better way to go about this (dlopen?)

[mariush]

Hmm... I just downloaded the 64bit 8bit version and it says "x264 [warning]: OpenCL: not compiled with OpenCL support, disabling"

The 32bit version says "x264 [warning]: OpenCL: Unable to find a compatible device" ... though I don't have an opencl.dll in the folder, I suspect my radeon 4850 is just not supported.

Should the 64bit version support opencl or...

Maybe I'm just stupid at 7am now after a night of no sleep.

later edit: How could I determine if an OpenCL device would be supported by x264? The only mention I see is something about cl_image in the git log

With Aida64 I see in "Device Features" at Radeon 4850 that "Images" is not supported. Is that the thing to look for? Because I have OpenCL entry for the fx-8320 which says it supports Images but x264 says "no device"

[Sparktank]

Nothing worked for 8 bit: x86/x64 (10 bit not supported :erm: )
I tried using with Avisynth for a conversion and also directly from file using --demuxer.
Still got errors and it seemed to really choke up the system until I terminated process.
For a few minutes after, the system ran very slowly. :S


"GPU Caps Viewer 1.18.0" detects OpenCL 1.2 on my laptop.
Detected Nvidia OpenCL on desktop.

x86/8 version: (x264.nl)
x264 0.132.2309 3b1f1f7
(libswscale 2.2.100)
(libavformat 55.3.100)
(ffmpegsource 2.17.4.0)
built on Apr 24 2013, gcc: 4.7.3
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Laptop: (store bought HP Paviliopn G series)
Windows 7 (x64)
Intel HD 3000 (QuickSynch) (can't update! custom build from HP :/) so only have...
Intel(R) SDK for OpenCL Applications 2013 (with runtime installed) OpenCL 1.2

Desktop: custom build from a friend
Windows XP (x86)
Nvidia GeForce 8400 GS (old!!) updated to latest driver (includes OpenCL)

Without OpenCL.dll in same folder as x264...

--opencl
Desktop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x528p 0:0 @ 2500000/104271 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 8400 GS
x264 [info]: Compiling OpenCL kernels...
x264 [warning]: OpenCL: kernel build errors written to x264_kernel_build_log.txt
>>x264_kernel_build_log.txt
(0) Error: unsupported operation

Laptop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x544p 0:0 @ 10000000/416667 fps (cfr)
avs [info]: color matrix: undef
x264 [debug]: using mv_range_thread = 40
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [warning]: OpenCL: Unable to find a compatible device

--opencl --opencl-device 1
Desktop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x528p 0:0 @ 2500000/104271 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [warning]: OpenCL: Unable to find a compatible device

Laptop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x544p 0:0 @ 10000000/416667 fps (cfr)
avs [info]: color matrix: undef
x264 [debug]: using mv_range_thread = 40
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [warning]: OpenCL: Unable to find a compatible device

x64/8 --demuxer lavf for lossless video codec: Utvideo. (inside AVI)
Laptop:
--opencl & With/without --opencl-device 1
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

I even tried a custom build from tmod.nmm-hd.org and still no OpenCL support.
x264_rev2309+704_tMod

I will try with copying opencl.dll to x264 directory.
I think separate folders:
C:\Windows\SysWOW64\OpenCL.dll -> x64 bit x264
C:\Windows\System32\OpenCL.dll -> x86 bit x264

EDIT:
Nope. Isolating x264 and OpenCL.dll into a single folder didn't fix problem.
x264 [warning]: OpenCL: Unable to find a compatible device

[jpsdr]

I used to compile my own build with some patches added. Until the last commit, everything was fine, but now, i'm unable to compile if i keep the "Film grain optimization" patch.
I'm unable to figure out precisely what's wrong. Error messages are related to x264_pixel_### functions. It seems to be linked with the DECL_PIXELS, but i've not been able to figure out...
If by any luck someone can help.
Thanks.

[filler56789]

FWIW, at least two patches from Komisar's site (L-Smash muxer and avi muxer) do not work with the latest git :eek:
Apparently he still hasn't updated the .diff files in his homepage...
nor managed to compile the VfW codec as well.

[Selur]

regarding openCl, would be cool if x264 has some sort of --check-opencl which, could be called without starting an encode and would return the compatible cards detected or a message like 'OpenCL: Unable to find a compatible device' and 'OpenCL: Unable to find a opencl.dll'

[Sparktank]

regarding openCl, would be cool if x264 has some sort of --check-opencl which, could be called without starting an encode and would return the compatible cards detected or a message like 'OpenCL: Unable to find a compatible device' and 'OpenCL: Unable to find a opencl.dll'

Agreed. I googled last night to see if there was any undocumented switch for x264 to do a check.
In the mean time, I jut added --frame 20 to do a short test with log-level at debug to see what's going on.

I read somewhere on a German forum (I don't think it was gleitz) that between the last stable version and current one, the only ones with OpenCL support were made and patched by users as test builds.

I have not since been able to find that forum again.

[komisar]

FWIW, at least two patches from Komisar's site (L-Smash muxer and avi muxer) do not work with the latest git :eek:
Apparently he still hasn't updated the .diff files in his homepage...
nor managed to compile the VfW codec as well.
all patches apply clearly in my kMod build...
VFW is waiting while refactor config form...

[LoRd_MuldeR]

Eesh, I wonder if there's a better way to go about this (dlopen?)

Yup, I think dlopen+dlsym or its Windows equivalents LoadLibrary+GetProcAddress would be the usual approach.

Though, from what I see, there are quite a number of functions we need to lookup from OpenCL.dll :o

On Windows (MSVC) we could also use "DLL Delay Loading", but I have no idea if that is supported in Linux or MinGW.

(BTW: I think a lot of similar stuff already happens in the Avisynth code in x264)

[mastrboy]

Has any AMD FX 8150/8350 users been able to do some benchmarking on rev 2309?
I'm curious about the new AVX2 optimizations that made it into x264 between r2273 and r2309...

[nevcairiel]

Has any AMD FX 8150/8350 users been able to do some benchmarking on rev 2309?
I'm curious about the new AVX2 optimizations that made it into x264 between r2273 and r2309...

How are these two things related?
Only Intels upcoming Haswell CPU has AVX2 (so far)

[mastrboy]

How are these two things related?
Only Intels upcoming Haswell CPU has AVX2 (so far)

You're right, I misread the wiki article: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

Then, never mind my previous post...

[filler56789]

all patches apply clearly in my kMod build...
VFW is waiting while refactor config form...

Thanks for answering, I will try to find out what was my mistake, then. :o

[LoRd_MuldeR]

UPDATE: Latest x264 will now only try to load OPENCL.DLL, if you really used the "--opencl" option. Thus, the "dummy" DLL is not required anymore!

I will not delete the attachment for now, but you really should NOT download or use that file anymore. Instead just update your x264 :)

FWIW, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)

Warning: If you actually want to use "--opencl", then this DLL is not for you!

[dbtayag]

Okay, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)Thank you very much for this. x264 works again!

[filler56789]

^
^
:thanks: too :)

[Snowknight26]

x264 [error]: clSetKernelArg error '-49'
x264 [error]: clSetKernelArg error '-49'
x264 [error]: clSetKernelArg error '-49'

Can you not Ctrl+C/SIGINT encoding successfully anymore?

[mogobime]

just loaded the rev2309 8-bit x64 from x264.nl and got this message when setting --opencl:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

[JEEB]

just loaded the rev2309 8-bit x264 from x264.nl and got this message when setting --opencl:
That's because the OpenCL SDK finding code fails if you give the configuration script a cross-prefix (like I do when compiling the 64bit builds), and thus it didn't get enabled :P . A fix for that is being reviewed on #x264dev.

[pepelugil]

Hello,

Is it safe to use r2309 without tweaking slices?

I'm worried after looking this: Fix two bugs in slice-min-mbs and slices-max (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65)

[JEEB]

Hello,

Is it safe to use r2309 without tweaking slices?

I'm worried after looking this: Fix two bugs in slice-min-mbs and slices-max (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65)
Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

[pepelugil]

Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

Thank you!!!

And sorry, but I don't really understand what the problem was: If I didn't use --slices-max parameter I would have problems?

[mogobime]

still got the same problem with v2310:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

The x264_r2274+opencl.7z (http://tmod.nmm-hd.org/x264/test/) from Tmod works perfekt on my system, dxdiag output:
ftp://x-quasat.redirectme.net/public/DxDiag.txt

[jdobbs]

still got the same problem with v2310:


The x264_r2274+opencl.7z (http://tmod.nmm-hd.org/x264/test/) from Tmod works perfekt on my system, dxdiag output:
ftp://x-quasat.redirectme.net/public/DxDiag.txtSo LoRd_MuldeR's fix in this post (http://forum.doom9.org/showthread.php?p=1625943#post1625943) doesn't work for you?

[LoRd_MuldeR]

So LoRd_MuldeR's fix in this post (http://forum.doom9.org/showthread.php?p=1625943#post1625943) doesn't work for you?

It seems that he is using an x264 build that simply was not compiled with OpenCL support, which can only be fixed by re-compiling. And, according to JEEB, a new/fixed build is on the way.

On the other hand, my "fix" is intended to make x264 (if compiled with OpenCL support) work on systems without OpenCL hardware/drivers.

That's because, even if you don't want to use the new OpenCL functions of x264, it still needs an OpenCL DLL now! Without such DLL, current x264 won't even start. The "dummy" DLL fixes that.

Of course the OpenCL functions of x264 will not work at all with that "dummy" DLL ;)

The "proper" way to handle this would be detecting the OpenCL DLL at runtime and simply disable OpenCL, if the DLL can not be loaded, but that needs modifying x264 code.

[mogobime]

I thought --opencl won't work with this fake-dll?
It should be clear, that any OpenCL-specific functions will not actually work with this DLL.
I have no problem to run x264, but it doesn't use opencl lookahead...

EDIT:
LoRd_MuldeR was faster ;)

[jdobbs]

It seems that he is using an x264 build that simply was not compiled with OpenCL support, which can only be fixed by re-compiling. And, according to JEEB, a new/fixed build is on the way.

On the other hand, my "fix" is intended to make x264 (if compiled with OpenCL support) work on systems without OpenCL hardware/drivers.

That's because, even if you don't want to use the new OpenCL functions of x264, it still needs an OpenCL DLL now! Without such DLL, current x264 won't even start. The "dummy" DLL fixes that.

Of course the OpenCL functions of x264 will not work at all with that "dummy" DLL ;)Ahhh... I thought he was getting the same error as the earlier posters -- I should have looked closer.

[CarlPig]

Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

No changelog??

[cyberbeing]

No changelog??
Changelogs can always be found on x264.nl

The only change from r2309 to r2310 was this (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65) as mentioned in the previous post.

[CarlPig]

Changelogs can always be found on x264.nl

The only change from r2309 to r2310 was this (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65) as mentioned in the previous post.

Thanks.

[Nazgul]

FWIW, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)

Weird, I'm still getting the error after installing this. The system getting the error is running Radeon HD 4550 graphics, with the "legacy" Catalyst 13.1 driver suite, which according to AMD's website DOES include OpenCL support. My other system which is running Cat13.5beta on a Radeon HD7950 is working just fine without the dummy .dll. Gonna try re-installing the Cat13.1 and see if that clears it up. Seems odd this wasn't caught.

[LigH]

So it was not clear that you should not use the dummy OpenCL DLL if your system does support OpenCL?

[Nazgul]

So it was not clear that you should not use the dummy OpenCL DLL if your system does support OpenCL?

Apologies, I should have been clear as well. I got the error BEFORE I tried using the dummy .dll file, suggesting that whatever OpenCL support this computer has, x264 wasn't seeing it. So I tried putting in the dummy .dll file, to see if that would do the trick. It didn't. I have managed to get it working, however. I had to blow the video drivers off the system and reinstall them, and now x264 seems to be finding the system's OpenCL driver.

[Selur]

Just trying to get a little overview over the current state:

current x264 version 'r2310 (JEEB)' requires a OpenCL.dll to work at all.
to make it work on systems which do not support OpenCL and therefore don't have a OpenCL.dll one can use the dummy .dll posted by LoRd_MuldeR (http://forum.doom9.org/showthread.php?p=1625943#post1625943)
even with the OpenCL.dll, the 64bit version of x264 will not be able to use --opencl due to some cross-prefix problem which JEEB uses with the 64bit-builds and the OpenCL SDK.
if you want to use --opencl you need to either use the 32bit build or in example an older version from http://tmod.nmm-hd.org/x264/test/ . (with the 64bit builds you will get a 'x264 [warning]: OpenCL: Unable to find a compatible device'- or 'x264 [warning]: OpenCL: not compiled with OpenCL support, disabling '-warning)

is this about right or did I miss something?

Cu Selur

[schweinsz]

Is there the new x264 profiling results? I want to know which modules take most of the time.

[Dark Shikari]

Sorry for all the OpenCL mess; Bugmaster's written up a patch to mostly clean up the problems in the original MultiCoreWare work. It'll be in the next release.

Here's some profiling results if you want them (http://s000.tinyupload.com/index.php?file_id=42451580428007968204).

[LoRd_MuldeR]

You refer to this one?
https://github.com/DarkShikari/x264-devel/commit/520ac11909fcdfd439af376cfd2f27d3e6646dae

Looks like runtime loading of the OpenCL library is implemented now, which should make any hacks (like the dummy DLL) obsolete.

:thanks:

[Selur]

Nice, thanks for the info.

[laserfan]

And thank You, Selur! I wanted to ask "why is --opencl in the Help file but it doesn't appear to be implemented anyway" and your/Dark's posts have cleared-away the fog.

:)

[Selur]

That's because the OpenCL SDK finding code fails if you give the configuration script a cross-prefix (like I do when compiling the 64bit builds), and thus it didn't get enabled :P . A fix for that is being reviewed on #x264dev.
Any news on the fix?

[sneaker_ger]

See post #1908.

[Selur]

ah, okay :D

[LigH]

So we just need a binary release with enabled OpenCL support to test it. I believe those on x264.nl did not enable it...

Ah, no, Rev. 2310 apparently supports OpenCL in the 8-bit x86 build. But it seems to have some issues with either my card or my drivers (314.22 W7/64b)...

x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 9600 GT
x264 [info]: Compiling OpenCL kernels...
x264 [warning]: OpenCL: kernel build errors written to x264_kernel_build_log.txt
__

(0) Error: unsupported operation

Well, according to the description in the changelog, it may not even speed up things in general, but rather limit the quality. I will probably avoid it.

[Atak_Snajpera]

I think you need GPU which supports latest OpenCL version (for example my R4850 supports only OpenCL 1.0) also 1GB is considered as minimum memory size. In order to avoid crashes people recommend even 2GB.

[Video Dude]

Quick question about OpenCL and the current x264.nl (x86) build:

I have a video card that supports OpenCL, but I do not want x264 to use OpenCL.

Is OpenCL enabled by default and if it is, is there a switch to disable it? Doing a forum search I found reference to a "--no-opencl" parameter. Is this correct?

[the_weirdo]

Is OpenCL enabled by default and if it is, is there a switch to disable it? Doing a forum search I found reference to a "--no-opencl" parameter. Is this correct?

OpenCL isn't enabled by default. To enable it, you have to add "--opencl" to settings.

[Stereodude]

Any hints of what Haswell brings to the table for x264 encoding in terms of real world performance increases over Ivy Bridge or Sandy Bridge?

It seems from the profile information that Dark Shikari uploaded he's got a Haswell system.

[the_weirdo]

Any hints of what Haswell brings to the table for x264 encoding in terms of real world performance increases over Ivy Bridge or Sandy Bridge?

It seems from the profile information that Dark Shikari uploaded he's got a Haswell system.

Maybe this: http://mailman.videolan.org/pipermail/x264-devel/2013-May/010049.html

[Dark Shikari]

That's just the gain from AVX2 though; I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).

[Stereodude]

I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).You'll be allowed to post them after a certain date though right?

[filler56789]

Regarding the openCL thing,
has anybody already tested r2334? :)

[Selur]

yes, 64bit build works fine here:
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660 Ti
x264 [info]: Compiling OpenCL kernels...

[MetalPhreak]

The 8 bit depth builds from x264.nl work fine but it seems OpenCL is not enabled in the 10 bit depth builds.

[mandarinka]

It's not that it is disabled, the OpenCL lookahead simply isn't made to work with 10-bit encoding, AFAIK.

[jpsdr]

Has anyone encounter with 64bits r2334 version the issues i've described here (http://forum.doom9.org/showthread.php?p=1628697#post1628697) (issues with devel version : wrong fps and warning).

[koliva]

Small question.
Would openCL support mean that I will have hardware acceleration without the need of changing/adding extra code in my encoder code part where I use libx264?

[Stereodude]

I'm still not allowed to post actual benchmarks (i.e. gain from Ivy Bridge -> Haswell).Are you allowed to post benchmarks now? I see many of the major computer centric tech sites have their Ivy Bridge intro reviews with benchmarks posted.

[Dark Shikari]

I suppose!

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%

[hajj_3]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

[CarlPig]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

Check this mirror: http://mirror01.x264.nl/

[LoRd_MuldeR]

what happened to the x264.nl site? I wanted to see the changelog for the latest stable build.

See here :rolleyes:
http://forum.doom9.org/showthread.php?p=1630666#post1630666

Also this has never been an "official" x264 web-site.

If you are looking the changelog, just see the official x264 Git repository:
http://git.videolan.org/?p=x264.git;a=shortlog

Or, if you prefer a plain text file:
git clone git://git.videolan.org/x264.git x264-src
cd x264-src
git log > CHANGELOG.txt

Win32 builds can be found, for example, at Komisar's site:
http://komisar.gin.by/

[Stereodude]

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%Thanks!

When is that performance gain realized? Is it in the first pass, second pass, both passes, a single pass CRF encode?

[Dark Shikari]

That was just a medium-preset CRF encode, and while it'll vary a little bit between presets and the like, I really doubt there's a huge difference.

[Audionut]

Sandy Bridge -> Haswell: 28%


Hmm, might be time to part with some cash.

[Reino]

I have no idea whether this is the right to report (small) issue or not, but when I tell x264 to convert the framerate, it doesn't report it's actually doing so, eventhough the endresult is correct.
When I deliberately omit the offset, at least it reports an error:
x264.exe ... --vf resize:960,540/select_every:2 -o NUL "input"
...
ffms : 1920x1080p 1:1 @ 50/1 fps (vfr)
resize [info]: resizing to 960x540
[I]select_every [error]: no offsets supplied...but when I add the offset:
x264.exe ... --vf resize:960,540/select_every:2,0 -o NUL "input"
...
ffms : 1920x1080p 1:1 @ 50/1 fps (vfr)
resize [info]: resizing to 960x540...there's no [I]"select_every [info]: converting to 25fps" to be seen anywhere.

[benwaggoner]

Performance gain in x264, per clock (roughly):

Ivy Bridge -> Haswell: 17% (~5 of which is from AVX2)
Sandy Bridge -> Haswell: 28%
Nehalem -> Haswell: 39%
Was there much Haswell-specific optimization outside of adding AVX2 support? Or are you just leaving that to the compiler and the chip's microarchitecture improvements?

Also, are the AVX2 etcetera optimizations relatively "done" at this point, or can we expect further relative improvements for Haswell in the short-medium term?

[Dark Shikari]

Haswell is not really very different from Nehalem/Sandy Bridge/Ivy Bridge architecture-wise, besides of course the larger datapaths and wider SIMD.

There'll probably be a lot of room to improve things in 10-bit, but 8-bit is probably close to done.

[J_Darnley]

there's no "select_every [info]: converting to 25fps" to be seen anywhere.

Why would there be? The filter doesn't print a line like that.

[Reino]

It should if you ask me. Printing information about framerate conversions is just as important as changing resolutions.

[denkr]

It will be great if anybody clarify me scenecut_internal detection in x264.
It uses
int icost = frame->i_cost_est[0][0];
int pcost = frame->i_cost_est[p1-p0][0];
What are values of abovementioned i_cost_est elements (SATDs between some 4x4 blocks? Which blocks?).

Thanks.

[Dark Shikari]

They represent the approximate SATD cost of the entire frame (for those choices of B-frame placement).

[Stereodude]

If I have multiple OpenCL capable display adapters in my system, how does x264 decide which one to use, or is there a way to force it to use a certain one?

For example, my PC has the Intel integrated Haswell HD4600 graphics and an Nvidia GeForce GT 440 can I force it to use one or the other for OpenCL?

[LoRd_MuldeR]

If I have multiple OpenCL capable display adapters in my system, how does x264 decide which one to use, or is there a way to force it to use a certain one?

Isn't --opencl-device exactly for that purpose?

[Stereodude]

Isn't --opencl-device exactly for that purpose?Okay, that's how you can force it to use one device over another. How does x264 decide which one to use? Does it just pick the lowest number?

Does the OpenCL performance of the video adapter make much difference in the speed of the x264 encoding? ie: should I care which one it uses?

[LoRd_MuldeR]

I guess you want it to use the fastest device. Also I guess you want to use the dedicated GPU, not the "CPU graphics", in order to keep the CPU's thermal budget free for the actual CPU calculations...

[Stereodude]

I guess you want it to use the fastest device. Also I guess you want to use the dedicated GPU, not the "CPU graphics", in order to keep the CPU's thermal budget free for the actual CPU calculations...I'm not aware that using the HD4600 integrated graphics in the Intel Haswell CPU slows it down for CPU related tasks.

[LoRd_MuldeR]

Well, modern CPU's regulate the clock speed dynamically ("turbo boost"), depending on the thermal budget. And I'm pretty sure the "processor graphics" contributes to the thermal budget. So if you put load on the "processor graphics", the CPU probably has to reduce the clock speed earlier. Also, the performance of dedicated GPU's still is much superior to the "processor graphics". And that's for "cheap" graphic cards, let alone the "high end" models. Finally, the CPU and the "processor graphics" share a single L3 cache and a single memory controller, which means that putting load on the "processor graphics" will likely hurt the memory bandwidth available to the CPU cores...

(On the other hand, the delays for uploading/downloading the data to/from the GPU, which can be quite problematic with dedicated GPU's, should pretty much fall when using the "processor graphics")

[Stereodude]

Well, modern CPU's regulate the clock speed dynamically ("turbo boost"), depending on the thermal budget. And I'm pretty sure the "processor graphics" contributes to the thermal budget. So if you put load on the "processor graphics", the CPU probably has to reduce the clock speed earlier.Perhaps, but there is thermal overhead with the heatsink/fan I'm using, so there is no reduction in clock speed.
Also, the performance of dedicated GPU's still is much superior to the "processor graphics". And that's for "cheap" graphic cards, let alone the "high end" models.Perhaps, but according to these benchmarks the HD4600 bests the GT 440 in some OpenCL tests and the GT 440 bests the HD4600 in others. GT 440 (http://clbenchmark.com/device-info.jsp?config=11983241) vs. i7-4770k (http://clbenchmark.com/device-info.jsp?config=15525698) Of course I have no idea which if any of those test are representative of the OpenCL processing done by x264.

[Stereodude]

Can I use OpenCL on the 2nd pass and not use it on the 1st pass of a 2 pass encode or will that create a problem?

OpenCL doesn't work with the Intel integrated HD 4600 graphics in my system for whatever reason, and using OpenCL on the GeForce GT 440 slows down the first pass significantly (like from 72FPS to 20-25FPS). Then again, I don't know if it will speed up the 2nd pass any.

[Dark Shikari]

OpenCL is only used on the lookahead, which is only used on the first pass.

The HD4600 and GT440 are both likely at least one order of magnitude too slow to be useful for OpenCL lookahead, which is very inefficient.

[Stereodude]

OpenCL is only used on the lookahead, which is only used on the first pass.

The HD4600 and GT440 are both likely at least one order of magnitude too slow to be useful for OpenCL lookahead, which is very inefficient.Thanks for the clarification and answers. I guess that explains why my first pass FPS went from 73 to 24 when I enabled it using the GT440. I can't get it to work on the HD4600 (thread here (http://forum.doom9.org/showthread.php?t=168168)), but it sounds like it's not worth messing with.

[CarlPig]

I have a little problem with OpenCL:

why say x264 this: x264 [info]: OpenCL: unable to open clbin file for writex264 [info]: profile Main, level 3.1

see here:
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 560 Ti
x264 [info]: Compiling OpenCL kernels...
x264 [info]: OpenCL: unable to open clbin file for writex264 [info]: profile Main, level 3.1

[Romario]

Excuse me, I have a question for x264 devs.

What's happening with x264 development and optimisations specificaly for Haswell ? Can we expect news, soon ?

[MasterNobody]

Look at x264's changes (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog). All commits that have AVX2 in the name can be categorized as "optimizations specifically for Haswell". So I am not sure about which news your are talking as it is already there (i.e. not news).

[nhakobian]

Excuse me, I have a question for x264 devs.

What's happening with x264 development and optimisations specificaly for Haswell ? Can we expect news, soon ?

Search is your friend. Or in this case, just some browsing in the current thread >.<

http://forum.doom9.org/showthread.php?p=1631310#post1631310

[burfadel]

Intel are talking about AVX3.2 on Skylake (successor to Broadwell, which succeeds Haswell). The question is, what it brings? Also, where does AVX3 and AVX3.1 come into play? It could be that there is no AVX3, just AVX3.1, but still, is AVX3.1 coming with Broadwell? Any theoretical advantages gained from it for encoding (if anyone knows what instructions are involed)?

[mastrboy]

Has anything changed in the recent revisions for the scene change detection code or key frame code?

Just encoded a series and seems like there's almost no key frames at scene-changes, noticed when trying to time some subs with Aegisub, already tried increasing scenecut from default 40 up to 100, but no difference on those particular scenes, also checked the scenes transition and there's really no good reason why those scenes shouldn't be detected as scenechanges, the luma difference on the transitions is quite high.

(I know I can force a keyframe with a qpfile, but x264 is supposed to put a key frame on all scene changes it detects automatically, right?)

Tried both 2334 and 2345 builds (using 64bit, 10bit)

[aldix]

I have a little problem with OpenCL:

why say x264 this: x264 [info]: OpenCL: unable to open clbin file for writex264 [info]: profile Main, level 3.1

see here:
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 560 Ti
x264 [info]: Compiling OpenCL kernels...
x264 [info]: OpenCL: unable to open clbin file for writex264 [info]: profile Main, level 3.1

Having the exact same thing. What's this about?

Nvidia Geforce GT 650M, 2GB VRAM

[LigH]

x264 seems to have no permission to write a file which is related to OpenCL processing. I wonder which file it is, and in which directory it shall be written...

[MasterNobody]

x264 seems to have no permission to write a file which is related to OpenCL processing. I wonder which file it is, and in which directory it shall be written...
The file that controlled by --opencl-clbin option and defaults to "x264_lookahead.clbin" i.e. in the current working directory.

[LigH]

So if that is in "C:\Program Files\MeGUI", then the UAC may not grant writing rights there. It should be relocated to the directory where the video file is.

[aldix]

Okay but does it mean that additional speed via OpenCL works or not?

[LigH]

If this file can't be created, OpenCL lookahead is probably disabled. But it may not be a massive speedup anyway, except your GPGPU is exceptional.

[MasterNobody]

If this file can't be created, OpenCL lookahead is probably disabled. But it may not be a massive speedup anyway, except your GPGPU is exceptional.
Wrong. OpenCL still works (it has info level not warning or error). This file is only used as cache i.e. to not compile OpenCL functions every run i.e. to speed up start up time.

[LigH]

Sorry, then... :o -- But it would be interesting to know your GPU model and your speedup.

[LoRd_MuldeR]

Even if the warning causes no harm, it worries some users.

And since, on Windows, programs will almost always installed under "C:\Program Files\Something" (and since that directory is protected by UAC), most users will need to use "--opencl-clbin" manually in order to avoid the warning.

What about changing the default to "/tmp/x264_lookahead.clbin" on Unix-like systems. And to "%TMP%\x264_lookahead.clbin" on Windows?

[MasterNobody]

Even if the warning causes no harm, it worries some users.

And since, on Windows, programs will almost always installed under "C:\Program Files\Something" (and since that directory is protected by UAC), most users will need to use "--opencl-clbin" manually in order to avoid the warning.

What about changing the default to "/tmp/x264_lookahead.clbin" on Unix-like systems. And to "%TMP%\x264_lookahead.clbin" on Windows?
Where I said the directory "where x264.exe is"? Current working directory don't have to be the same directory (look at any link-file or in the case when x264 is called from cmd by full path current working directory will be current one in cmd). Also same directory is used for 2pass files by default so I don't see the reason while clbin should be special case (if GUIs want they can change this path by --opencl-clbin option).

[LoRd_MuldeR]

Where I said the directory "where x264.exe is"? Current working directory don't have to be the same directory (look at any link-file or in the case when x264 is called from cmd by full path current working directory will be current one in cmd). Also same directory is used for 2pass files by default so I don't see the reason while clbin should be special case (if GUIs want they can change this path by --opencl-clbin option).

You didn't. And I didn't say you did.

However, if you run x264 from the command-line, you will usually navigate to the directory "where x264.exe is" and then type "x264 [parameters]", so this directory will end up to be your working directory most of the time.

GUI's could work around this, by explicitly setting the working directory for the x264 process to %TMP%, indeed. But that's one more thing the caller/application has to know and take care of.

Attached is a simple patch to set the default clbin directory to %TMP%, if available, or to "/tmp" otherwise. It's untested, because I haven't managed to compile x264 with OpenCL yet. But the idea should be clear...

(BTW: For the 2-Pass stats file I would actually prefer, if it did default to the directory where the selected output file is located)

[MasterNobody]

However, if you run x264 from the command-line, you will usually navigate to the directory "where x264.exe is" and then type "x264 [parameters]", so this directory will end up to be your working directory most of the time.
I am not sure that this common scenario usage of x264 cli (it is simpler to add x264.exe to %PATH% and call it from anyway). Also I mostly sure users who use x264 cli do NOT install it to Program Files (as if they normal users they don't have rights to write it there and x264 cli doesn't have installer to install it there). The only one who install it to Program Files are probably GUI's installers. Dunno about Linux users.

P.S. All I have written is only my opinion and I am dunno what other developers think about that. i.e. if you want to change this behaviour you need to convince someone other from developers.

[Marin85]

I think most users who use x264 cli actually use batch files for it. So, the working directory usually ends up being the current directory of the batch file/source files/wherever you put the batch file.

[LigH]

Either a batch file, or a user interface (e.g. MeGUI, StaxRip, ...) with their installation directory being the default, if they don't relocate the "current directory" to the one where the source is located just before calling the encoder.

Like many things, this applies to directories as well: The less you assume, the less you assume wrong... ;) — I hope GUI authors will specify most file locations explicitly, but if they don't, a default location with probable write permission is certainly useful.

[LoRd_MuldeR]

Nice to see that the x264 devs have changed their mind and Unicode support for Windows finally seems to be on the way:
https://github.com/DarkShikari/x264-devel/commit/ae1008d58a895b174e8007896ec98c75f419221d

About 2 years ago, when I suggested adding Unicode support for Windows and provided a very similar patch (https://github.com/lordmulder/x264-utf8/commit/67d3cfef6b3c0266b19ff0bb3d66f13f04d1988c), the answer was "just rename the input file" ;)

[Selur]

" Unicode support for Windows "
NICE!

[Chumbo]

" Unicode support for Windows "
NICE!
+100. :D

Nice to see that the x264 devs have changed their mind and Unicode support for Windows finally seems to be on the way:
https://github.com/DarkShikari/x264-devel/commit/ae1008d58a895b174e8007896ec98c75f419221d

About 2 years ago, when I suggested adding Unicode support for Windows and provided a very similar patch (https://github.com/lordmulder/x264-utf8/commit/67d3cfef6b3c0266b19ff0bb3d66f13f04d1988c), the answer was "just rename the input file" ;)
Yeah, I was a recipient of the "rename the file" answers. LOL

[Chumbo]

I wanted to try the opencl flags to see what kind of performance gains I can get, if any, but when I use the following flags:--opencl --opencl-clbin "c:\temp\SYSTEM\x264_lookahead.clbin"I get a fatal application exist dialog withclGetPlatformIDs is unimplemented. Sorry about that!
Any ideas? Am I missing an opencl SDK or something like that? That was my initial thought. My x264 info:x264 0.135.2345 f0c1c53
(libswscale 2.1.2)
(libavformat 55.1.0)
built on Jul 8 2013, gcc: 4.6.3
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: LGPL version 2.1 or later

[EDIT] Forgot to add that my video card is a Sapphire (AMD) HD5670.

[MasterNobody]

Chumbo
Try to update drivers for video card to the latest. But I doubt you get any speed up (I guess it would speed down really) with such old video card even if you will be able to run with OpenCL.

[Chumbo]

Chumbo
Try to update drivers for video card to the latest. But I doubt you get any speed up (I guess it would speed down really) with such old video card even if you will be able to run with OpenCL.
Yeah, I was just curious to see if there are any improvements. I do have the latest drivers by the way. I think I may have to install the Intel OpenCL SDK. Probably not worth the hassle in the end.

[Selur]

when I use:
x264 --pass 1 --bitrate 1500 --profile high --level 5.1 --keyint infinite --bframes 16 --open-gop --b-bias 20 --direct auto --b-adapt 2 --lookahead-threads 0 --no-mbtree --rc-lookahead 60 --ipratio 1.5 --pbratio 2 --qpmax 21 --qpstep 8 --aq-mode 2 --aq-strength 0.5 --nr 1000 --non-deterministic --stats "C:\temp\07_25_46_5310_01.stats" --fps 30000/1001 --input-res 1920x1080 --output NUL -

x264 --preset placebo --pass 2 --bitrate 1500 --profile high --level 5.1 --keyint infinite --open-gop --b-bias 20 --lookahead-threads 0 --no-mbtree --ipratio 1.5 --pbratio 2 --qpmax 21 --qpstep 8 --me umh --subme 9 --trellis 0 --psy-rd 1:0.0 --aq-mode 2 --aq-strength 0.5 --vbv-maxrate 300000 --vbv-bufsize 300000 --nr 1000 --non-deterministic --colormatrix bt470bg --stats "C:\temp\07_25_46_5310_01.stats" --fps 30000/1001 --input-res 1920x1080 --output "C:\temp\07_25_46_5310_02.264" -
I end up with:
Bit rate : 6 405 Kbps
Nominal bit rate : 1 500 Kbps
Maximum bit rate : 8 604 Kbps
when I use:
x264-10bit --pass 1 --bitrate 1500 --profile high10 --level 5.1 --keyint infinite --bframes 16 --open-gop --b-bias 20 --direct auto --b-adapt 2 --lookahead-threads 0 --no-mbtree --rc-lookahead 60 --ipratio 1.5 --pbratio 2 --qpmax 81 --qpstep 8 --aq-mode 2 --aq-strength 0.5 --nr 1000 --non-deterministic --stats "C:\temp\07_28_32_5210_01.stats" --fps 30000/1001 --input-res 1920x1080 --output NUL -

x264-10bit --preset placebo --pass 2 --bitrate 1500 --profile high10 --level 5.1 --keyint infinite --open-gop --b-bias 20 --lookahead-threads 0 --no-mbtree --ipratio 1.5 --pbratio 2 --qpmax 81 --qpstep 8 --me umh --subme 9 --trellis 0 --psy-rd 1:0.0 --aq-mode 2 --aq-strength 0.5 --vbv-maxrate 720000 --vbv-bufsize 720000 --nr 1000 --non-deterministic --colormatrix bt470bg --stats "C:\temp\07_28_32_5210_01.stats" --fps 30000/1001 --input-res 1920x1080 --output "C:\temp\07_28_32_5210_02.264" -
(only difference es are: the profile, the vbv and qpmax values and that the second encode is 10bit)
I end up with:
Bit rate : 1 500 Kbps
Maximum bit rate : 2 674 Kbps
which is more of what I expected, when specifying an average bit rate of 1500.
(source was: http://forum.videohelp.com/attachments/19486-1377217794/rws_asa.avi ; 8 and 10bit x264 core 135 r2345 was from komisar's site)

Is there some simple explanation why x264 totally fails to hit the target bit rate (1500kBit/s, aiming for 3MB) when using 8bit (ending up with 12.7MB) , but hits it quite well with 10bit (3.01MB)?
(I redid this a few times to make sure this was not something that 'just' happened.)

for completeness, here's also the decoder call I used for this:
mencoder -lavdopts threads=2 -really-quiet -of rawvideo -o - -ovc raw -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\Users\Selur\Desktop\rws_asa.avi"

The settings I choose may all be 'strange', but shouldn't these two both hit the target size?

Cu Selur

Ps.: I uploaded both reencodes to: http://www.embedupload.com/?d=8GIKSUGBVO
(would be nice if some one else could also try to reproduce this so that I know if my system is somehow at fault; which I doubt, but you never know)

[vivan]

--qpmax 21, that's why. Actually x264 throwed warning:
x264 [warning]: Error: 2pass curve failed to converge
x264 [warning]: target: 1500.00 kbit/s, expected: 6017.52 kbit/s, avg QP: 21.0000
x264 [warning]: try increasing target bitrate or increasing qp_max (currently 21)

[Selur]

Argh, totally overlooked that!! Thanks, should have been 51. ;)

[sneaker_ger]

--qpmax 51 is an outdated default value, btw.
1. it is not x264's default anymore
2. it never was the maximum qp for 10 bit encoding in the first place
3. even higher values are allowed for the vbv emergency mode, i.e. you turned it off

[Selur]

@sneaker_ger: I know :)

[LoRd_MuldeR]

FFMS2 input seems to be broken with latest x264. I get a deadlock with x264 r2358 and a command-line like this:

"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --crf 20.0 --preset medium
--output C:\Temp\Out.mkv --index C:\Temp\foo.ffindex E:\Samples\Lossless\crew.704x576.avi

x264 will hang before even printing out anything to the console, so I suspect something gets locked up in the new Win32 Unicode support code, maybe when processing the CLI argument? :confused:

Avisynth or VapurSynth input works fine though.

http://i.imgur.com/Z7z1L4ds.jpg (http://i.imgur.com/Z7z1L4d.jpg)


[UPDATE]

This problem seems to be related to the "--index" argument! As soon as I exclude that one from the above command-line, it won't deadlock anymore.


[UPDATE 2]

Just noticed that a fix which most likely relates to this problem is on the way:
https://github.com/DarkShikari/x264-devel/commit/dfdb6465dea2990a4531d076ed2644c8ccb0f3a9

Now that I see the fix, I remember that I came across the very same bug in FFMS2 about two years ago, when I implemented Unicode support for x264.

Also, back at that time, I came up with the same workaround (https://github.com/lordmulder/x264-utf8/commit/67d3cfef6b3c0266b19ff0bb3d66f13f04d1988c#diff-6) :)


[UPDATE 3]

Fix for the actual bug in FFMS2 was provided by Komisar here:
http://komisar.gin.by/x.patch/check_idx_file.diff

Hopefully this will finally be committed into FFMS2, after all the time this nasty bug is around...

[Selur]

*gig* I totally missed the "--index <string> Filename for input index file" option to begin with. :)

[mastrboy]

Henrik Gramner [Mon, 8 Jul 2013 21:06:42 +0200 (12:06 -0700)]
Transparent hugepage support

Combine frame and mb data mallocs into a single large malloc.
Additionally, on Linux systems with hugepage support, ask for hugepages on
large mallocs.

This gives a small performance improvement (~0.2-0.9%) on systems without
hugepage support, as well as a small memory footprint reduction.

On recent Linux kernels with hugepage support enabled (set to madvise or
always), it improves performance up to 4% at the cost of about 7-12% more
memory usage on typical settings..

It may help even more on Haswell and other recent CPUs with improved 2MB page
support in hardware.

Will Windows take advantage of this by default? Or do I need to adjust the GPO setting "Lock Pages in Memory" ?

[Selur]

anyone got some overview what '--acvintra-compat' enforces, restricts ?

from a first look it seems to enforce:

--bframes 0 (-> no bpyramid, intra refresh, weigthed bframes,...)
--ref 1 (-> no mixed ref)
--weightp 0
--keyint 1
--aud
some custom quantizer matrices
--stitchable

since this is probably not all it does, I wanted to as if someone can post some sort of 'proper' overview which normally available settings are restricted or 'removed' by '--avcintra-compat' ?

[LoRd_MuldeR]

For a complete list, you probably should look at the code, as it does quite a lot.

This should be the interesting part:
http://pastie.org/private/pmu6fxzte34ihtl0sdzfuw

Note, however, that "param.b_avcintra_compat" is used directly in a few other places too (e.g. analysis.c and ratecontrol.c), not only in the parameter verification function.

So this is not limited to adjusting the existing options, like a simple "preset" would do. It also seems to influence things that are not exposed by any other options.

[Dark Shikari]

avc-intra enables a horrible set of internal hacks that can't be emulated using external parameters.

[Selur]

To be frank I'm not really interested into all the internal hacks but more about what is external accessible parameters are restricted (or forced into a specific value) by it.

[LoRd_MuldeR]

As said before, you best look at the code that verifies/updates the parameters.

I'd say it does (at least) the following:
- Works only with 10-Bit x264
- Force key-frame interval to 1 (not really surprising ^^)
- Force intra refresh to off
- Force weight-p to off
- Force number of reference frames to 1
- Force BluRay compatibility to off
- Force support for VFR to off
- Force access unit delimiters to on
- Force signal HRD information to off
- Force deblocking filter to off
- Force 8x8dct to on
- Force rate-control mode to 1-Pass ABR
- Force VBV to enabled, with specific parameters
- Force sliced threads, if used, to 2 (for 1080p) or to 1/5 (for 720p)
- Force using a specific custom quantization matrix

[Selur]

Works only with 10-Bit x264
I read it that it would also work with normal 8-Bit encoding, but that not many applications support this king of AVC-Intra :D

Force support for VRR to off
what's VRR ?

Cu Selur

[LoRd_MuldeR]

I read it that it would also work with normal 8-Bit encoding, but that not many applications support this king of AVC-Intra :D

Regardless of whether it would work in theory, x264 currently refuses to encode AVC-Intra as anything but 10-Bit.

Note the return statement.

what's VRR ?

That was a typo. Should read "VBR", of course ;)

[MasterNobody]

That was a typo. Should read "VBR", of course ;)
Probably still typo and you really meaned disable VFR (Variable Frame Rate) and not VBR (Variable Bit Rate). But you can say VBR is also disabled because it use CBR.

[LoRd_MuldeR]

Probably still typo and you really meaned disable VFR (Variable Frame Rate) and not VBR (Variable Bit Rate).

Argh, I need some sleep :scared:

[Selur]

Thanks for clearing that up :)

[Thalyn]

I don't mean to derail the conversation here, but just out of curiosity... has there been any additional work on adding MVC support to x264? The last content I can find on the subject is nearing its second birthday, and that's a long time in development.

I do recall reading that it wasn't being seriously looked at for a time due to it compressing roughly the same as frame-interleaved 3D. But I'm hoping that was reconsidered given the lack (absence?) of interleave-aware players and the greater legacy compatibility of MVC (ie Watch it in 2D if the player doesn't recognise MVC, instead of it staggering back and forth).

[Sharc]

I don't mean to derail the conversation here, but just out of curiosity... has there been any additional work on adding MVC support to x264? The last content I can find on the subject is nearing its second birthday, and that's a long time in development.

I do recall reading that it wasn't being seriously looked at for a time due to it compressing roughly the same as frame-interleaved 3D. But I'm hoping that was reconsidered given the lack (absence?) of interleave-aware players and the greater legacy compatibility of MVC (ie Watch it in 2D if the player doesn't recognise MVC, instead of it staggering back and forth).
MVC support would be awesome as tsMuxeR now seems to develop into the same direction.

[jdobbs]

MVC support would be awesome as tsMuxeR now seems to develop into the same direction.Add me to the list of people who would love to see it.

[benwaggoner]

Is much happening with x264 development? The last checkin was three months ago.

Perhaps x265 is getting a lot of attention from the core devs :)?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog