x264 development

[nhakobian]

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

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

https://github.com/DarkShikari/x264-devel/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]

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]

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]

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]

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-devel/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]

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

yes
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 (http://www.multiupload.nl/CAS9LDCIVI) 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. :)

[benwaggoner]

I note a ton of commits have been coming in; 15 in the last two days!

github.com/DarkShikari/x264-devel/commits/master (https://github.com/DarkShikari/x264-devel/commits/master)

It's nice to see some new stuff coming in!

[Dark Shikari]

The dates are misleading; they're not dates of authorship, but dates of last edit, and amending a commit causes all commits above it to be edited.

It's really roughly one month of commits.

[turbojet]

Any chance x264 officially adds support to prevent standby/sleep?

Standby/sleep breaks encoding with x264 but it keeps encoding the last frame it recieved until the framecount is reached, so it's not very obvious.

http://forum.doom9.org/showthread.php?p=1659494#post1659494 is a start. It only works on windows vista/7/8 though, pre-vista can be added with one line and then mac and linux would be a few more lines.

[Dark Shikari]

Any chance x264 officially adds support to prevent standby/sleep?

Standby/sleep breaks encoding with x264Do you have a specific test case that fails? Because it has always worked fine on my machine; I confirmed it works just now in a test and many times in the past I've used sleep to put an encode on hold while I carried my laptop elsewhere.

[turbojet]

Start a cli encode, send it into deep sleep (S3), when it wakes up x264 appears to keep encoding but the bitrate will continually drop because it's encoding the same frame.

On a laptop, it might be going into S1, mine does if I close the lid, power light blinks but it's set to S3 after 1 hour, the light stops blinking.

[Dark Shikari]

It works fine for me; are you sure it's not a problem with your input method, e.g. an Avisynth script/plugin with problems, or a bad DirectShow filter? I have never had an issue with sleep mode breaking encodes on multiple computers and operating systems in my entire history using x264.

[turbojet]

I'm pretty sure I've reproduced it numerous times with direct x264 but that was months ago, will test again in a few hours.

Most gui's work around this program by forciing no sleep. Others are working around it in batch scripts in the patch thread but that comes with some issues mentioned in the thread.

[mandarinka]

Sleeping (S3, S4) always worked for me with ffvideo/avisynth input (and dgdecode and ffvideosource in there). Even feeding via avs2yuv over - is working as far as I can see (Windows XP, Windows 8).

Do you use some unreliable sources, like directshowsource? Or something that uses GPU acceleration? Or does your harddrive or other storage has issues waking up /maybe file handles are broken after sleep - I've seen external HDDs having issues there/?

[turbojet]

You guys are right, I must have only been testing dss2 which is what I normally use. It makes sense to not always prevent sleep. Maybe a switch would be more appropriate?

A common situation for me is starting an encode and leaving the computer alone for hours. Upon returning I'd expect the encode to be done and computer sleeping but with a vanilla x264 build the result is a partial encode with computer sleeping.

[LigH]

Just what we keep preaching for what feels like "decades": Try to prefer Avisynth-native source plugins as long as they work correctly (which is much easier than ever before now with a wide selection: DGDec{NV|IM}, FFMS2, L-SMASH Works, DSS2Mod in native LAV Filters mode).

Remember, DirectShow is "like a box of chocolates": Always a surprise if you didn't select its content carefully.

[turbojet]

DSS2Mod is what I normally use with preroll otherwise there's video hiccups with interlaced ts files, occasionally lsmash when I need frame accurate, ffms2 detects weird fps with interlaced ts files, I forgot it can interact with lavfilters and just recently tried to figure out how to use cuda when encoding but not playback. Thanks for reminder!

[schweinsz]

I build the x264 using the following configuration using the MinGW:
./configure --enable-static --disable-opencl --enable-win32thread --disable-interlaced

I get the libx264.a and x264.exe, then I link the libx264.a into a vc project and get the following errors:
1>x264-test.c(31): warning C4244: 'initializing' : conversion from 'int' to 'float', possible loss of data
1>libx264.a(analyse.o) : warning LNK4229: invalid directive '/aligncomm:_x264_cabac_size_unary,5' encountered; ignored
1>libx264.a(analyse.o) : warning LNK4229: invalid directive '/aligncomm:_x264_cabac_transition_unary,5' encountered; ignored
1>libx264.a(cabac.o) : warning LNK4229: invalid directive '/aligncomm:_x264_cabac_contexts,5' encountered; ignored
1>libx264.a(vlc.o) : warning LNK4229: invalid directive '/aligncomm:_x264_run_before,5' encountered; ignored
1>libx264.a(vlc.o) : warning LNK4229: invalid directive '/aligncomm:_x264_level_token,5' encountered; ignored
1>libx264.a(encoder.o) : error LNK2001: unresolved external symbol _snprintf
1>libx264.a(ratecontrol.o) : error LNK2001: unresolved external symbol ___mingw_vfprintf
1>libx264.a(ratecontrol.o) : error LNK2001: unresolved external symbol ___mingw_vsprintf
1>libx264.a(ratecontrol.o) : error LNK2001: unresolved external symbol ___fpclassify
1>E:\prog\x264test\Release\x264test.exe : fatal error LNK1120: 4 unresolved externals

How can I link all the dependent functions into the libx264.a static just the vc does by enabling the option /MT?

[MasterNobody]

It is very bad idea to mix MinGW libraries (.a) and MSVS projects.
It would be easier and less hacky to use shared library instead of static library if you want to use mingw compiled libx264 in MSVS:
How to build x264 as DLL (http://doom10.org/index.php?topic=1876.0)
or
How to build x264/libx264.dll in Windows (http://www.ayobamiadewole.com/Blog/Others/x264compilation.aspx)
Other way is to compile static library by ICL but this is require you to have ICL.

[schweinsz]

It is very bad idea to mix MinGW libraries (.a) and MSVS projects.
It would be easier and less hacky to use shared library instead of static library if you want to use mingw compiled libx264 in MSVS:
How to build x264 as DLL (http://doom10.org/index.php?topic=1876.0)
or
How to build x264/libx264.dll in Windows (http://www.ayobamiadewole.com/Blog/Others/x264compilation.aspx)
Other way is to compile static library by ICL but this is require you to have ICL.
When I run the follows:
./configure --disable-cli --enable-shared --enable-win32thread --extra-ldflags=-Wl,--output-def=libx264.def
I get:
C99 compiler is needed for compilation.

So I delete the --disable-cli and it succeeds.
What does the --disable-cli mean?
And what does the --extra-ldflags=-Wl mean?

[microchip8]

When I run the follows:
./configure --disable-cli --enable-shared --enable-win32thread --extra-ldflags=-Wl,--output-def=libx264.def
I get:
C99 compiler is needed for compilation.

So I delete the --disable-cli and it succeeds.
What does the --disable-cli mean?
And what does the --extra-ldflags=-Wl mean?

afaik, --disable-cli disables the building of the x264 executable. The other option seems to imply that you pass it additional option for when linking

[LoRd_MuldeR]

And what does the --extra-ldflags=-Wl mean?

The complete option is:
--extra-ldflags=-Wl,--output-def=libx264.def

Which means that the extra flag "-Wl,--output-def=libx264.def" will be passed to GCC in the linking phase. Here "-Wl" is used to pass commands directly to the linker (see here (http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options) for details) and "--output-def=libx264.def" is the command being passed to the linker. It tells the linker to output a DEF for for the x264 library (DLL on Windows). The DEF file can be used to generate an import library (.lib) for the DLL using the "lib" tool of Visual Studio, as described here (http://www.fftw.org/install/windows.html) for FFTW.

I get:
C99 compiler is needed for compilation.

I would recommend you look at your "config.log" to see what exactly has failed and why.

[jpsdr]

Is there any dev who can answer this (http://forum.doom9.org/showthread.php?p=1691396#post1691396) ?

[dj_alek]

Hi!
Does anyone know the reason of hardcoded limit of RefPicList1 size?:

b_ref_reorder[2];
sps->vui.i_num_reorder_frames = param->i_bframe_pyramid ? 2 : param->i_bframe ? 1 : 0;
h->frames.i_max_ref1 = X264_MIN( h->sps->vui.i_num_reorder_frames, h->param.i_frame_reference );
etc

Is the increase in size will not improve the encoding quality? I mean, eg, redistribution of parameter i_frame_reference = 10 to num_ref_l0 = 5 & num_ref_l1 = 5 instead of the current num_ref_l0 = 8 & num_ref_l1 = 2 (to use 5 forward + 5 backward frames for reference rather than 2 forward + 8 backward)?

[kotuwa]

x264 supports raw-input of MKV files with x264/AVC video.
what is the difference using raw input vs. input via .AVS script that uses FFMS2 etc?
(Nothing else like resizing is used... Just input...)

[huhn]

nothing.
as far as i know x264 uses ffmpegsource2 to decode too or at least something based on the same decoder.

[LigH]

Rather the kernel of it: libav libraries. But only if the person who built a specific executable set it up to use it; it is not mandatory, some other builds may omit it.

By the way: "raw input" and "MKV input" are completely different things. MKV is a container, usually with compressed content. The term "raw" usually means uncompressed video without any container (means: pure video pixels or samples according to chroma subsampling, e.g. YUV 4:2:0 known by the VfW FourCCs I420 or YV12, depending on the order of chroma planes).

Files with raw YUV video data usually have the extension "*.yuv". And they have no information at all what kind of video format they contain, you have to know that, and you have to tell the encoder via parameters about "pixel format", sample bitdepth, width, height, and framerate. A compromise is the YUV4MPEG format (*.y4m) which has at least a header with the most important attributes, but the rest of this file is exactly the same as raw YUV without any header.

[kotuwa]

nothing.
as far as i know x264 uses ffmpegsource2 to decode too or at least something based on the same decoder.

Rather the kernel of it: libav libraries. But only if the person who built a specific executable set it up to use it; it is not mandatory, some other builds may omit it.

By the way: "raw input" and "MKV input" are completely different things. MKV is a container, usually with compressed content. The term "raw" usually means uncompressed video without any container (means: pure video pixels or samples according to chroma subsampling, e.g. YUV 4:2:0 known by the VfW FourCCs I420 or YV12, depending on the order of chroma planes).

Files with raw YUV video data usually have the extension "*.yuv". And they have no information at all what kind of video format they contain, you have to know that, and you have to tell the encoder via parameters about "pixel format", sample bitdepth, width, height, and framerate. A compromise is the YUV4MPEG format (*.y4m) which has at least a header with the most important attributes, but the rest of this file is exactly the same as raw YUV without any header.

My bad...
I used the term RAW, as x264 programs says MKV inputs as raw...
I mean when I tried without giving input resolution, it said raw input needs a resolution.. :)

And I am taking about encoders x264.nl gives in main page..
precisely http://mirror01.x264.nl/x264/32bit/8bit_depth/revision2334/x264.exe

How can we get the ones that uses lavf?

Thnak You Very Much All!...

[Selur]

How can we get the ones that uses lavf?
iirc the offical binaries from http://download.videolan.org/x264/binaries/ should be fine,..

[foxyshadis]

No newsletter yet, but a big series of updates committed today. Highlights include: Experimental AQ mode 3 now added to stable (affects dark areas more strongly); LOTS of ARM64 performance improvements; tiny x86 performance improvements; small bugfixes, included to HRD; some updates to AvxSynth wrapper and the included libx264 example.

[LoRd_MuldeR]

Does anybody know what happened to x264 development branch at:
https://github.com/DarkShikari/x264-devel

:confused:

[cyberbeing]

Does anybody know what happened to x264 development branch at:
https://github.com/DarkShikari/x264-devel

:confused:
It's been moved to:
http://git.videolan.org/?p=x264/x264-sandbox.git

[Selur]

Any new link for http://download.videolan.org/pub/videolan/x264/binaries/ (linked on http://www.videolan.org/developers/x264.html) in regard to Mac OS X binaries?
The old http://download.videolan.org/x264/binaries/ is still there, but doesn't have the new binaries (for any OS).

[LoRd_MuldeR]

It's been moved to:
http://git.videolan.org/?p=x264/x264-sandbox.git

:thanks:

[jpsdr]

Does anyone know with what option i have to build ffmpeg for generating libraries i can use to compile x264, and also avoiding message like "Programm cannot start becase avcodec-56.dll is not found" :confused:

[MasterNobody]

Any new link for http://download.videolan.org/pub/videolan/x264/binaries/ (linked on http://www.videolan.org/developers/x264.html) in regard to Mac OS X binaries?
The old http://download.videolan.org/x264/binaries/ is still there, but doesn't have the new binaries (for any OS).
I get info at IRC that server's hard disk died and all the URLs used by buildbot went 404 (more info (https://twitter.com/videolan/status/545620746505322496)). So no new builds there before it would be fixed (ETA for fix is 2 weeks or more). So for now you can use builds made by komisar (http://komisar.gin.by/) or others.