x264 development

[nhakobian]

Originally Posted by 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...git;a=shortlog

There appears to have been some things done since then that are listed on Dark Shikari's github:

https://github.com/DarkShikari/x264-...commits/master

[iwod]

The latest newsletter from 30th of Oct.

This is the fortieth x264 development newsletter. This is a regular
email containing updates on fixes and improvements in the most recent
x264 push, along with updates on what's coming next. Previous
versions can be found in the mailing list archives.

Fixes:

Work around an FFMS bug with empty index files.

Fix INSTALL in configure on Solaris systems.

Fix possible crashes in resize/crop filters on high bit depth input.

Fix shared library compilation on the original Windows MinGW toolchain.

Fix compilation in the case that the HAVE_LOG2F check fails spuriously.

Include dependency libraries in pkg-config generation.

Don't try to generate a .git version number on build if .git isn't
present (e.g. in snapshots)

Update code to the current libav/ffmpeg API.

Improvements:

Don't warn in non-verbose mode if VBV underflow occurs with CRF-max
(since the user likely wanted it to occur).

Slight speedup in chroma BI analysis.

Make encoder_reconfig more threadsafe: fixes some rare crash issues
with reconfiguring with frame threads.

Add a --filler option to generate streams with filler without using NAL HRD.

Add AVC Intra 1080p50/60 Class 100 parameters and some further AVC
Intra compatibility hacks/fixes.

Add L-SMASH support as a preferred alternative to GPAC for mp4 muxing.

Remove the --visualize option, as it is very old cruft and probably
does not work with many combinations of settings anymore (as it hasn't
been maintained).

Jason Garrett-Glaser

The x264 Team

Well at least we know DS is alive and well. I wonder if he had stop writing code for x264 and move on.

[LigH]

A newsletter or blog entry won't appear with each commit. Probably only when something "revolutionary" happens. Or when silent evolution progressed long enough. Following the commit log is certainly more reliable.

[ NO PANIC ]

And not all x264 developers are part of the x265 development too, I believe.

[MasterNobody]

Originally Posted by LigH

And not all x264 developers are part of the x265 development too, I believe.

I would say even more. Almost zero x264 developers (I don't know anyone) are part of active x265 developers (which are mostly MulticoreWare workers). This doesn't mean that we don't support/help them to understand and adapt x264 algorithm but that is almost only this.

[Sharc]

No plans to support MVC with x264 in near future?

[LoRd_MuldeR]

Originally Posted by Sharc

No plans to support MVC with x264 in near future?

See here:
https://www.leffster.se/showthread.php?t=168010

Also, FWIW, the MVC patch can still be found at:
http://pastebin.com/qZ1xSmuc

[Sharc]

Originally Posted by LoRd_MuldeR

See here:
https://www.leffster.se/showthread.php?t=168010

Also, FWIW, the MVC patch can still be found at:
http://pastebin.com/qZ1xSmuc

These activities look a bit orphaned. Has anyone tried?
CoreCodec offerings apply to the MVC Decoder only it appears ....

[pistacho]

Originally Posted by iwod

The latest newsletter from 30th of Oct.

Well at least we know DS is alive and well. I wonder if he had stop writing code for x264 and move on.

Bump dates to 2014…

https://github.com/DarkShikari/x264-...commits/master

[Selur]

when using:

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -vf scale,format=i420,scale,format=444p -forcedsubsonly -nosub -nosound -mc 0 "H:\Temp\encodingTempAvisynthSkript_08_44_17_5010.avs" | x264 --preset ultrafast --tune fastdecode --qp 0 --profile high444 --no-psy --sar 32:27 --non-deterministic --colormatrix bt470bg --input-csp yv24 --fps 30000/1001 --input-res 720x480 --output "H:\Temp\lossless_08_44_17_5010_03.264" -

why does x264 convert to yuv420?

raw [info]: 720x480p 32:27 @ 30000/1001 fps (cfr)
resize [warning]: converting from yuv444p to yuv420p
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High 4:4:4 Predictive, level 3.0, 4:2:0 8-bit
x264 [info]: frame I:3 Avg QP: 0.00 size: 77126
x264 [info]: frame P:705 Avg QP: 0.00 size: 83652
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 70.9% 0.0% 0.0% P16..4: 28.7% 0.0% 0.0% 0.0% 0.0% skip: 0.3%
x264 [info]: coded y,uvDC,uvAC intra: 89.6% 83.0% 82.6% inter: 93.6% 88.2% 87.9%
x264 [info]: i16 v,h,dc,p: 65% 35% 0% 0%
x264 [info]: i8c dc,h,v,p: 17% 34% 48% 1%
x264 [info]: kb/s:20049.75
encoded 708 frames, 14.21 fps, 20049.75 kb/s

mencoder converted to 4:2:0 to 4:4:4, the profile is High444 -> why does x264 revert the 4:2:0 to 4:4:4 conversion?

Cu Selur

Ps.: I used:

x264 0.142.2389 956c8d8
(libswscale 2.5.101)
(libavformat 55.25.101)
(ffmpegsource 2.17.4.0)
built by Komisar on Jan 22 2014, gcc: 4.8.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

[nevcairiel]

You need to set --output-csp, or it'll always encode 420.

[Selur]

Thanks for clearing that up.

[mastrboy]

Regarding qpfiles, is the 2 following "statements" threated as the same?
"50 K"
and
"50 K -1"

And does qpfiles support comments within the file? with for example a "#" or "//" pre-sign?

[MasterNobody]

Originally Posted by mastrboy

Regarding qpfiles, is the 2 following "statements" threated as the same?
"50 K"
and
"50 K -1"

yes

Originally Posted by mastrboy

And does qpfiles support comments within the file? with for example a "#" or "//" pre-sign?

no

[mastrboy]

Thanks for the fast and precise answer

[Selur]

Seems like the sample is too short for 10bit rate control to work properly:

Avisynth script used:

SetMemoryMax(768)
SetMTMode(6,0) # change MT mode
LoadPlugin("G:\Hybrid\avisynthPlugins\DGDecodeNV.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\TIVTC.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\mt_masktools-26.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\DctFilter.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\deblock.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\flash3kyuu_deband.dll")
Import("G:\Hybrid\avisynthPlugins\Deblock_QED.avs")
# loading source
DGSource(dgi="H:\Temp\1452664460mkv_deb1536f480475f7d593219aa1afd74c_18716.dgi",fieldop=0)
RequestLinear(rlim=50,clim=50)
# deblocking
SetMTMode(2) # change MT mode
Deblock_QED(quant1=24,quant2=26,aOff1=1,bOff1=1,aOff2=2,bOff2=2,uv=3)
# deringing
MosquitoNR(strength=16,restore=128,radius=2,threads=0)
# debanding
f3kdb(range=15,sample_mode=2,dither_algo=3,grainY=64,grainC=64,dynamic_grain=true,Y=64,Cb=64,Cr=64,blur_first=true,keep_tv_range=false)
return last

2pass target bit rate failing on me on short sample:
1st pass:

"G:\Hybrid\x264-10bit.exe" --pass 1 --bitrate 2889 --profile high10 --level 4.1 --direct auto --b-adapt 2 --rc-lookahead 60 --qpmax 81 --deblock -1:-1 --non-deterministic --stats "H:\Temp\DeblockQED, Flash 3k Deband, MosquitoNR_10bit_10_16_58_5710_03.stats" --output-csp i420 --input-res 1280x672 --output NUL -

output:

raw [info]: 1280x672p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High 10, level 4.1, 4:2:0 10-bit
x264 [info]: cabac=1 ref=1 deblock=1:-1:-1 analyse=0x1:0 me=dia subme=2 psy=1 fade_compensate=0.00 psy_rd=1.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=12 lookahead_threads=5 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=abr mbtree=1 bitrate=2889 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=81 qpstep=4 ip_ratio=1.40 aq=1:1.00
x264 [info]: frame I:1 Avg QP:17.00 size:211322
x264 [info]: frame P:41 Avg QP:35.77 size: 25045
x264 [info]: frame B:77 Avg QP:35.93 size: 25327
x264 [info]: consecutive B-frames: 5.9% 5.0% 55.5% 33.6%
x264 [info]: mb I I16..4: 99.0% 0.0% 1.0%
x264 [info]: mb P I16..4: 46.4% 0.0% 0.0% P16..4: 11.8% 0.0% 0.0% 0.0% 0.0% skip:41.8%
x264 [info]: mb B I16..4: 15.4% 0.0% 0.0% B16..8: 10.9% 0.0% 0.0% direct: 2.9% skip:70.8% L0:32.6% L1:56.8% BI:10.5%
x264 [info]: final ratefactor: 16.97
x264 [info]: direct mvs spatial:79.2% temporal:20.8%
x264 [info]: coded y,uvDC,uvAC intra: 47.9% 52.1% 44.3% inter: 2.8% 5.0% 0.2%
x264 [info]: i16 v,h,dc,p: 24% 15% 48% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 2% 68% 4% 7% 3% 5% 4% 3%
x264 [info]: i8c dc,h,v,p: 81% 9% 5% 5%
x264 [info]: Weighted P-Frames: Y:7.3% UV:7.3%
x264 [info]: kb/s:5358.60
encoded 119 frames, 18.53 fps, 5358.61 kb/s, duration 0:00:06.42
finished after 00:00:06.498

2nd pass:

"G:\Hybrid\x264-10bit.exe" --preset slower --tune film --pass 2 --bitrate 2889 --profile high10 --level 4.1 --ref 3 --qpmax 81 --vbv-maxrate 150000 --vbv-bufsize 187500 --non-deterministic --colormatrix bt709 --stats "H:\Temp\DeblockQED, Flash 3k Deband, MosquitoNR_10bit_10_16_58_5710_03.stats" --output-csp i420 --input-res 1280x672 --output "H:\Temp\DeblockQED, Flash 3k Deband, MosquitoNR_10bit_10_16_58_5710_04.264" -

output:

raw [info]: 1280x672p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High 10, level 4.1, 4:2:0 10-bit
x264 [info]: cabac=1 ref=3 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=9 psy=1 fade_compensate=0.00 psy_rd=1.00:0.15 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-3 threads=12 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=2889 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=81 qpstep=4 cplxblur=20.0 qblur=0.5 vbv_maxrate=150000 vbv_bufsize=187500 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00
x264 [info]: frame I:1 Avg QP:26.00 size: 11415
x264 [info]: frame P:41 Avg QP:35.69 size: 73080
x264 [info]: frame B:77 Avg QP:38.49 size: 47455
x264 [info]: consecutive B-frames: 5.9% 5.0% 55.5% 33.6%
x264 [info]: mb I I16..4: 99.8% 0.2% 0.0%
x264 [info]: mb P I16..4: 12.1% 25.4% 1.5% P16..4: 17.8% 0.6% 5.7% 0.0% 0.0% skip:37.0%
x264 [info]: mb B I16..4: 3.8% 5.1% 1.6% B16..8: 21.5% 1.3% 0.5% direct: 1.6% skip:64.7% L0:38.8% L1:55.1% BI: 6.0%
x264 [info]: 8x8 transform intra:57.2% inter:55.7%
x264 [info]: direct mvs spatial:80.5% temporal:19.5%
x264 [info]: coded y,uvDC,uvAC intra: 60.4% 65.4% 61.0% inter: 2.3% 6.1% 1.8%
x264 [info]: i16 v,h,dc,p: 9% 15% 33% 43%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 5% 47% 6% 6% 6% 6% 6% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 5% 23% 11% 12% 11% 11% 11% 12%
x264 [info]: i8c dc,h,v,p: 73% 12% 2% 13%
x264 [info]: Weighted P-Frames: Y:7.3% UV:7.3%
x264 [info]: ref P L0: 48.3% 27.4% 23.9% 0.3%
x264 [info]: ref B L0: 68.2% 21.8% 9.9%
x264 [info]: ref B L1: 85.5% 14.5%
x264 [info]: kb/s:11196.12
encoded 119 frames, 11.33 fps, 11196.12 kb/s, duration 0:00:10.50
finished after 00:00:10.566

Using 8bit everything seems fine.

I used:

x264 0.142.2389kMod 956c8d8
(libswscale 2.5.101)
(libavformat 55.25.101)
(ffmpegsource 2.17.4.0)
built by Komisar on Jan 22 2014, gcc: 4.8.2 (multilib.generic.Komisar)
configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Cu Selur

Ps.: I know the clip is really short and mainly contains of black frames, but I thought I should report it since 8bit encoding worked fine and only 10bit encoding fumbled.

[Selur]

got it, using a larger "--rc-lookahead" solved the problem with the clip

[MasterNobody]

Selur
1) if you going to make bug reports than use clean version of x264 (no patched one).
2) why do you use so different params for 1-st and 2-nd pass?
3) use source directly or provide already filtered source because developers not going to install all needed plugins and scripts only to find out that they can't reproduce your bug.

P.S. I can't reproduce it with clean build + your sample without any filtering + your command lines. 2-nd pass gives 2799.90 kb/s here (while 1-st pass gives 16670.55 kb/s).

[Selur]

regarding
1.: used clean build first
2. What parameter do you think has changed? All differences should be due to the normal 'fast 1st pass' adjustments
3. also happened with the filtered source

I can't reproduce it with clean build + your sample without any filtering + your command lines. 2-nd pass gives 2799.90 kb/s here

will look into it some more tomorrow (you did use a 10bit build right?)

[LigH]

You should probably use the same preset and tuning for both 1st and 2nd pass, because you may collect statistics for a different complexity than you intend to encode with. Except you really know that the "fast 1st pass" would reset just the same basic options as omitting the preset and tuning.

[Selur]

Except you really know that the "fast 1st pass" would reset just the same basic options as omitting the preset and tuning.

I hope I do. Otherwise I made a mistake I'm not aware of.