Current Patches, Where to get them, How they affect speed/output

[lexor]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

[kemuri-_9]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

A) the patch is purely cosmetic to avoid a warning when compiling x264 with lavf and/or ffms support
B) the issue is also fixed with the filtering patch.

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

I vaguely remember something along the lines of pengvado saying not all of the threading done in ffmpeg's decoders is stable.

[Blue_MiSfit]

Yes, from what I recall threads in ffmpeg is somewhat unstable with some codecs.

[bin_ch]

B) the issue is also fixed with the filtering patch.


Speaking of the filtering patch, any news on it?
Thanks.

[kemuri-_9]

Speaking of the filtering patch, any news on it?
Thanks.

Dark_Shikari is cracking the whip on me to get it committed before the first phase of the audio filtering/encoding patch.
the latter will try and get committed at GSOC midterms, which i heard is the 12th of july.

[D3C0D3R]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 :devil: revision change ))

[kemuri-_9]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 revision change ))

configuring with bit-depth 9 or 10 will cause x264 to output video with that bit depth, which will require the use of the High10 profile (outside of lossless)
naturally this will cause the generated videos to take slightly more space....

at the moment there isn't much of a practical use for it as
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
B) x264 still only accepts input that has a bit-depth of 8.
C) no free/popular decoder outside of JM seems to even decode High10 correctly - only some 'pro' ones do it seems

all of these issues will eventually need be fixed to have it be more practical for use,
the first 2 are already planned/in works for x264 but the 3rd is something outside of x264's hands.
and then it'll be primarily only useful for videos where the input is >8 bit depth

[D3C0D3R]

naturally this will cause the generated videos to take slightly more space....
hm, but quality is rises? extra precision never hurts.
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
i didnt scared sLOW speed, perhaps like many people on this forum i use placebo options ))
B) x264 still only accepts input that has a bit-depth of 8.
i understand that and interesting how 10 bit precision can help to improve 8-bit quality e.g. dealing with banding effect

[julius666]

naturally this will cause the generated videos to take slightly more space....

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

[lexor]

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

He didn't qualify this statement though. Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

[MasterNobody]

If judge by SSIM/PSNR than higher bit depth give higher quality on the same bitrate for 8-bit sources also.

[julius666]

Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

I'm pretty sure that the former. His statement doesn't make sense otherwise.

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

[LoRd_MuldeR]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

I doubt DXVA does handle the "High 10" profile of H.264...

[JEEB]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

Basically agreeing with LoRd_MuldeR here.

I would say that you'd be pressed to find decoders for 10bit H.264 at the moment, software and hardware-wise. DXVA and CoreAVC should be out for sure, as well as other GPU-based solutions ('out' as in 'out of the question').

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

[lexor]

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

Well, if it's true that we get a noticeable quality improvement even with 8bit source, I think we should all be interested in those rare decoders that can play it. In particular I am hoping higher bit depth will help with the banding (to smooth out gradients).

On a related note, what's the purpose of 9bit? Is it just to offer another performance grade for those who want better quality but can't wait for 10bit encoding? Seems an odd (literally) number, I mean I've seen 8, 10, and 12 bit video sources, but I've never heard of anything working in 9bits.

Speaking of which, why isn't there a 12 bit mode, since some pro-apps do output it (in their RAWish/uncompressed intermediate formats of choice, not h264)? Seems like it would be a perfect fit for x264 lossless to slide in there.

[mp3dom]

10bit could be useful for professional use (mainly if you capture in h264 rather than uncompressed yuv, but probably the decoding cycle of h264 will be larger without an hardware decoder). If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit). If you can hide/mask/fix color banding with avisynth then you can save it in lossless h264.
Actually it's not so useful to have a 10bit output if the source needs to be 8bit, anyway this could be a lot useful in future when x264 could support 10bit as input, or it could be VERY useful if it could dither a 10bit source to an 8bit output (IMHO the most useful option)

[Blue_MiSfit]

Yes, very!!

I would love to see 10 bit input support, possibly with an option to dither down to 8 bit as well.

Derek

[masterkivat]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

[rack04]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

Explain evil build.

[Midzuki]

Explain evil build.

r1666 :devil:

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24064 and libswscale SVN-r31639 (http://www.multiupload.com/FYKG5OL4OM)
ffms2 SVN-r317 (http://www.multiupload.com/LZMNP9BUB3)
x264 Builds:

x264_x64_r1666M (http://www.multiupload.com/CGB3AA0T60)
x264_x86_r1666M (http://www.multiupload.com/A5B34AL9QM)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

as i know divx d3c0d3r support High10 so can someone build 10bit :devil: build ?

2 komisar - your crazy devil x264vfw build sets mb-tree=0 when use Command line option is off.

[julius666]

If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit)

If the 8 bit source has banding, than the 10 bit output will obviously have it too. But if your source is dithered, than x264 will chop down the dither (especially at lower bitrates) and create banding. With more precision the banding could be less visible in this case.

[komisar]

D3C0D3R, yes... mb_tree=0 because [warning]: lookaheadless mb-tree requires intra refresh (http://sourceforge.net/projects/x264vfw/forums/forum/770225/topic/3759827)
if you known what you do -- add needed options to "Extra options:"-box...

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24069 and libswscale SVN-r31642 (http://www.multiupload.com/CHBOA7QFO8)
ffms2 SVN-r317 (http://www.multiupload.com/T24S6H1PPG)
x264 Builds:

x264_x64_r1666M_8bit (http://www.multiupload.com/LAXU555UTY)
x264_x86_r1666M_8bit (http://www.multiupload.com/VU3TNW6ZNA)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
x264_x64_r1666M_9bit (http://www.multiupload.com/7JYVOJ3E92)
x264_x86_r1666M_9bit (http://www.multiupload.com/08H0VT58B1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 9
x264_x64_r1666M_10bit (http://www.multiupload.com/HX4MVQA8C0)
x264_x86_r1666M_10bit (http://www.multiupload.com/660A5UNRH1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 10
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

2 rack04 thank you for 9,10 bit builds and off course BIG Respect to Oskar, who developed this patch.

2 komisar - i always place in extra textbox something like "--rc-lookahead 120" and had in 1659 mb-tree=1, but in 1666 i didnt see any warnings and mb-tree=0 :(
AFAIK this is no other way to turn on MB-Tree only to off it ))

[komisar]

D3C0D3R
http://forum.doom9.org/showthread.php?p=1414971#post1414971

[D3C0D3R]

2 komisar thanx 4 help - works

high 10: first impressions & quick tests 8,9,10 bits
http://forum.doom9.org/showthread.php?p=1415028#post1415028

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24248 and libswscale SVN-r31736 (http://www.mediafire.com/?kmwjmngj5yymgth)
ffms2 SVN-r318 (http://www.mediafire.com/?xlkzytwj1zjfznh)
x264 Builds:

x264_x64_r1675M (http://www.mediafire.com/?nzazgxz2jmmhwnm)
x264_x86_r1675M (http://www.mediafire.com/?yzjyztdmzmjmd2n)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/Sp5bLbhJ)

[Audionut]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

[rack04]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

What is your command line?

EDIT: This works for me. Windows 7 64bit Ultimate.

"C:\Program Files\x264\x264.exe" --preset veryslow --tune film --crf 18 --force-cfr --vf resize:1280,528,1:1 --aud --output "E:\Work\110902669-output.264" "E:\Work\110902669.mov"

BTW: Here is a new build.

x264_x64_r1677 (http://mfi.re/?itwkgmonrnnwz2m)

[Soichiro]

I have discovered that the current build of avs4x264 and vfw4x264 broke with the filtering patch (r1672). As such, I have created a fixed version for anyone using either of these for piping to 64-bit x264.

Updated vfw4x264+avs4x264 w/ source (http://www.megaupload.com/?d=NDPO6W7G)

[Audionut]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Any error message?

[Soichiro]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

[Audionut]

Yup, what ^^^^ he said.

rack04, are you on x264 irc to make debugging faster.

[rack04]

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

I don't know what to say. It works with the .mov that I have handy.

[Audionut]

Tried on mkv and avs source. Same problem.

[komisar]

problem in libswscale... win64 is bad friend for ffmpeg&co :(

[JEEB]

problem in libswscale... win64 is bad friend for ffmpeg&co :(
At least Dark_Shikari has shown interest in giving a try to fix it as soon as a real backtrace is gotten with other ffmpeg devs. Although yes, as win64 is not officially supported, a bug report would most probably otherwise be brushed off as "lol win64".

[Selur]

anyone building current 9/10bit builds for win32bit? (rack04?)

[rack04]

Currently I'm not on a 64bit machine. Once I get get off work I will attempt to provide a useful gdb backtrace. For those who may want to help please refer to the following links for debug builds.

x264_x64_r1677_debug (http://www.mediafire.com/?ysi24vmd5c83n1y)

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

[Audionut]

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

That works. Thanks.

Can you patch that with fade-compensate.

[RedDwarf1]

Why do recent builds, since mb-tree was introduced it might of been, produce files with an incorrect number of reference frames?

General
Complete name : L:\VIDEO_TS\test2.mkv
Format : Matroska
File size : 5.68 MiB
Duration : 40s 40ms
Overall bit rate : 1 190 Kbps
Writing application : x264 r1649 c54c47d
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@3.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 40s 40ms
Bit rate : 1 167 Kbps
Nominal bit rate : 1 149 Kbps
Width : 704 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.115
Stream size : 5.57 MiB (98%)
Writing library : x264 core 98 r1649 c54c47d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1149 / ratetol=4.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=8 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.20

And before you start claiming that MediaInfo is incorrectly reporting the number of reference frames, AVInaptic also shows an incorrect number of reference frames, there being one less than was used to encode.

So why are both these programs showing lower numbers of reference frames than the number set when encoding?

[Trahald]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

[rack04]

That works. Thanks.

Can you patch that with fade-compensate.

I'll post something later today.

[Audionut]

Sweet, thankyou sir.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24287 and libswscale SVN-r31748 (http://www.mediafire.com/?yt5i6uoalxeg4p4)
ffms2 SVN-r318 (http://www.mediafire.com/?4f5p6s6fbllfy3k)
x264 Builds:

x264_x64_r1677M (http://www.mediafire.com/?6qwhe8e513cqzjo)
x264_x86_r1677M (http://www.mediafire.com/?0vnny5ubtop37fg)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/5Xnfraqd)

[RedDwarf1]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.