x264 - Current patches discussion thread

[Dark Shikari]

Post and discuss current patches here.

JEEB's list.

[pkirill]

Can build authors provide their patch informations ?
And if it possible i`d like to view Dark Shikari comments on that patches.
Thanks

[froggy1]

I host some patches over at h264enc's site. I update them regularly (ie, when new version(s) of them come out)

http://h264enc.sourceforge.net/download.html

[bob0r]

Can someone upload a list of current patches:

- Used
- Needs to be updated for latest revision
- Experimental
- On wishlist/bring back from the dead 

+ Maybe some comments from the x264 developers why a patch is not added to GIT.
(still in developement, no specs given, not meeting x264 code standards... etc...)

Thanks!   

[JEEB]

Will get hunting the actual files later on, when I'm less tired, but here goes:

• The most used patch probably is the win_zone_parse_fix series, as it is needed for full (ab)use of the zoning functions in x264 under mingw/GCC (other compilers and OSs aren't affected). NOT NEEDED ANY MORE
• Another widely known patch is the one that adds the nal-hrd functions into x264. Has gone through way more than enough development loops (latest Trahald's and ZmGorynych's) and even the x264 developers think that a proper code review should take place on ZmGorynych's patch so this feature might get into the official x264 source tree.

These being the most known ones, we then have the somewhat-minor stuff (in no particular order).

• AQ Stuff
• • AQ3 (BugMaster ; Yet Another AQ edition by BugMaster)
  • AQ2mod (BugMaster ; Adds more control to AQ mode 2)
  • Experimental AQ (BugMaster ; newer than AQ mode 2, liked by Dark Shikari for its simplicity)
  • VAQ Mod. (BugMaster ; Extends VAQ)
  • VAQ Mod. 2 Minus (BugMaster/Seraphy ; Adds negative aq-strength values as possible and adds aq-sensitivity as a setting)
  • MixAQplus (Seraphy ; Experimental, combines Haali's AQ and the usual AQ, and then adds their results to each other with define'able strengths)
  • OreAQ (Seraphy (currently kept up-to-date by VFR Maniac) ; Some kind of AQ that changes values by the "brightness" of a part of a picture)
• Thread Pool patch (Pengvado / Bugmaster ; Adds a thread pool function)
• FGO (Dark_Shikari, later on modified by various builders ; Film Grain Optimization. This one hasn't been officially updated ever since psy-rd got out, but it's still being used somewhere)
• FP-ETA (morph166955 ; ETA of second pass from the first one (?))
• Fix Extended Zones (VFR Maniac)
• TS_CTRL (VFR Maniac ; Timescale and Timestamps control)
• Faster_NAL_Encode (VFR Maniac ; Faster NAL unit encoding)
• x264_log_file_k07.r1369.diff (Komisar ; Log file output for those who need it)
• x264 ffms / lavf patch + output muxer cleanup (Kierank ; Does what it says)
• Dead Wood
• • ME Prepass (Dark Shikari (?) ; Prepass feature in the motion estimation, later on updated by all kinds of people in order to patch onto a newer x264, but then died away with time from current builds)

Here's a small list of what's being used lately. Half of these were looked from VFR Maniac's builds' readme, but otherwise the usual stuff. Not all is very useful, but the patches do exist. Links to every patch are not provided as most of the patches mentioned are not distributed one-by-one in their currently patchable form (and because of this sweet little thing called sleepiness). Mistakes can very well be in the accreditation, and all kinds of errors might be there -- the list will be edited as people mention such.

[kemuri-_9]

The most used patch probably is the win_zone_parse_fix series, as it is needed for full (ab)use of the zoning functions in x264 under mingw/GCC (other compilers and OSs aren't affected as far as I know).

yes, the patch is only for mingw as it is the only used compiler that is missing the strtok_r API function used by x264.
and the reason this isn't committed is because it's a kludge fix for mingw only.

[VFR maniac]

• AQ Stuff
• • VAQ Mod. 2 Minus (BugMaster/Seraphy ; Adds negative aq-metric (?))

Support negative aq-strength and add aq-sensitivity.
Negative aq-strength is for lowering the qp of clear-cut areas like Anime.

• Faster_NAL_Encode (VFR Maniac ; Faster NAL unit encoding)

This patch is the fixed version of rev963 commit.
roozhou took it in his direct264.

FGO (Dark_Shikari, later on modified by various builders ; Film Grain Optimization. This one hasn't been officially updated ever since psy-rd got out, but it's still being used somewhere)

I added supporting of ssse3 and neon from the original.
The patch is here.
I think weak fgo + psy-rd keep constant grain well on Japanese Anime.

• TS_CTRL (VFR Maniac ; Timescale and Timestamps control)

This patch is for direct VFR MP4/MKV/FLV output with mkv timecode file, and eliminating initial decoding delay derived from B-frames with DTS hacking.
Algorithm of removing initial delay in MP4/FLV is the following.
1) Multiply 2*number_of_delay_frames by media timescale in MP4's spec. Similar is done for DTSs and CTSs. This is for keeping NTSC timestamps in DTS.
2) Set a value smaller than the small CTS in second on DTS during output frame number is smaller than number of delay frames. (DTS hacking, this is the most important about this algorithm.)
3) Subtruct the first CTS offset from the all CTSs.
Adding EditBox is another method of removing initial delay, but some splitter don't support it. ex: MPC(Gabest's) MP4 Splitter
Thererfore, I and seraphy designed such a algorithm to create compatible AVsynced MP4 and FLV.
This algorithm is mounted seraphy's x264afs, x264gui.auo and DtsEdit, and my tc2mp4Mod. (I don't know if roozhou's direct264 uses the same algorithm.)
      --b-delay <integer>     Initial delay for B-frames in MP4/FLV [1]
                                  - -1: Insert EditBox
                                  -  0: Eliminate initial delay
                                  -  1: Leave initial delay

Concrete example about b-frames=1 and b-byramid=none:
b-delay=1 (default)
timeScale=30000
I1: DTS=0,CTSOffset=1001,CTS=1001, timecode=33.367
P1: DTS=1001,CTSOffset=2002,CTS=3003, timecodes=100.100
b1: DTS=2002,CTSOffset=0,CTS=2002, timecode=66.733
P2: DTS=3003,CTSOffset=1001,CTS=4004, timecode=133.467

b-delay=0
timeScale = 60000
I1: DTS=0,CTSOffset=0,CTS=0, timecode=0.000
P1: DTS=1001,CTSOffset=3003,CTS=4004, timecode=66.733
b1: DTS=2002,CTSOffset=0,CTS=2002, timecode=33.367
P2: DTS=4004,CTSOffset=2002,CTS=6006, timecodes=100.100

I'll add supporting of complete VFR VBV to this patch, but I don't have sufficient knowledge of x264 ratecontrol yet.


Edit: Updated a link of FGO patch.

[Dark Shikari]

I'll add supporting of complete VFR VBV to this patch, but I don't have sufficient knowledge of x264 ratecontrol yet.

I'll do that myself after we commit "true VFR" and Nal-HRD.

[Emess]

Nal-HRD is going to get committed? About damn time.

[Biggiesized]

Nal-HRD is going to get committed? About damn time.

I'm not complaining, but I sure am happy to get it without a patch.

[JEEB]

Now that both nal-hrd patches are probably broken, too -- I think that it's a good time to let it go by until it gets committed. If only people would have more time to give into checking the newer patch... of course, I do understand that since very rare people are getting paid for x264 development it's just natural to have to wait for some stuff a bit longer.

Not to mention that making such a feature means reading a lot of specs, too.

edit:

x264_hrd_pd_interlace.16_r1369.diff
x264_thread_pool_v2.3_slices.diff
x264_log_file_k07.r1369.diff

ガっ！

[komisar]

x264_hrd_pd_interlace.16_r1369.diff
x264_thread_pool_v2.3_slices.diff
x264_log_file_k07.r1369.diff

x264_hrd_pd_interlace.16_r1369_fix.diff (with initialisation of cpb_removal_delay = 0)

[techouse]

x264_hrd_pd_interlace.16_r1369.diff

<3

[burfadel]

Not currently a patch, but could be trialled (it is a very basic idea I know):
The default b-frames are 3-frames, isn't there only a slight performance hit of using --b-adapt 2 over the default --b-adapt 1 for that number of b-frames?

I was thinking the 'medium', aka default mode should be --b-adapt 2, but when more than 5 b-frames are selected manually a command line print stating that using more than 5 b-frames is very slow and may result in little or no benefit.  I think this would be good mainly because most people use the default b-frames anyway, and 3 is really not a massive performance hit.

Also how does the b-frame detection of --b-adapt 2 work anyway? how does this analysis compare with mb-tree?

[kierank]

x264 ffms / lavf patch + output muxer cleanup

This patch allows input using ffms2 and/or lavf. The latter supports piping. Patch by ACoolie

It also changes muxing to work frame-by-frame instead of nalu by nalu amongst other small fixes.

http://pastebin.com/m102f194f

Please test and report broken samples.

[Kurtnoise]

sorry, what are the pros/cons of ffms over lavf, except piping ?

[mikeg]

ffms2 has real seeking (lavf seeking is slow because it has to be careful not to miss the frame), can easily detect SAR (lavf won't get SAR until one frame has been decoded, and then it is too late), and sets frame total so you can see percent finished. ffms2 will be used by default if it is installed and the input is a regular file. ffms2 will index the input file for every encode unless you specify somewhere to save the index. `x264 in.mkv --index in.mkv.ffindex -o out.mkv`

[kierank]

lavf/ffms patch updated.

[Emulgator]

While trying to find a x264 setting that would import into Sony DVD-A 5.0b Build 180 (and probably Encore CS3 / DVDDitProHD 6.4):
x264r1376M (Jeeb) run from MeGUI 0.3.1.1060 zathor patched. Commandline by hand:

Code: [Select]

program --profile high --level 4 --crf 18 --thread-input --keyint 25 --min-keyint 2 --b-adapt 0 --interlaced --ref 4 --weightp 0 --qpmax 45 --ipratio 1.2 --pbratio 1.2 --vbv-maxrate 24000 --no-mbtree --trellis 2 --psy-rd 1.0:0.20 --no-mixed-refs --no-dct-decimate --aud --nal-hrd --sar 1:1 --output "output" "input" DVD-A imports as .avc, does not announce transcoding (yippie), but fails on muxing.
Sony DVD-A 5.0b Build180 Error Report:

Dateiname: STREAM/00000.m2ts  Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. - m_ptsOfNextGOP is empty.

Encodes made with x264r1376MJeeb (nal_hrd patched16(?) (looks ok, but fails on muxing)
vs.Sony Vegas 9.0c Build 896 as SONY AVC(muxes in DVD-A without transcoding, but looks ugly)

While examining and comparing these .avc elementaries I found the following missing entries suggesting that nal-hrd might not be embedded properly:
Screenshot x264 .avc mediainfo

Screenshot x264 .avc Stream Summary (my fault: no vbv)            Screenshot Vegas 9 .avc Stream Summary                 Screenshot x264 .avc Stream Summary (now with vbv)

Screenshot x264 .avc Header NAL (my fault: no vbv)                   Screenshot Vegas 9 .avc Header NAL                         Screenshot x264 .avc Header NAL (now with vbv)

Screenshot x264 .avc Header SPS (my fault: no vbv)                   Screenshot Vegas 9 .avc Header SPS top                   Screenshot x264 .avc Header SPS (now with vbv)

Screenshot Vegas 9 .avc Header SEI top                                    Screenshot x264 .avc Header SEI top(now with vbv)    Screenshot x264 .avc Header SEI bottom(now with vbv)

                                                                                          Screenshot Vegas 9 .avc Header SPS bottom
                                                                                         

Could it be that other nal-hrd patched builds work somewhere else
or can I assume that the patch itself is broken
or is it driver error on my side?

[Emulgator]

Never mind. Driver error on my side.
vbv-bufsize was 0, this was the reason for nal_hrd not to be written.

Now that nal_hrd is there I will do further testing for muxer acceptance...

Back from testing: The report is still there (Sony DVD-A 5.0b Build 180):
("Dateiname: STREAM/00000.m2ts  Status: TSWrapper.dll::CTSWrapper::ProcThreadMain:
This program has a bug. - m_ptsOfNextGOP is empty")

[Chortos-2]

I see quite a few patches at Komisar’s (the link is for r1713) and X5-452’s sites and many of them seem (to me) to have nothing that should prevent them from going into the official git repository/whatever-it-is-called-when-git-is-the-version-control-system. Some even look like they were submitted to a mailing list, although I cannot find them in the archives of x264-devel. I would like to know why these patches are not getting committed to x264.git and to try to help fix the outstanding issues.

[atavarius]

I don't think most of those patches really "fix" anything, they seem mostly cosmetic/convenience. The only 2 I would call major are LSMASH which is a work in progress and JDarnley's filter patch which he is working on getting comitted. 

[Blue_MiSfit]

Demuxer threads sounds interesting..


Derek

[Chortos-2]

I don't think most of those patches really "fix" anything, they seem mostly cosmetic/convenience.

Yes, and I think users of the official git should have the same convenience.

[J_Darnley]

Some even look like they were submitted to a mailing list, although I cannot find them in the archives of x264-devel. I would like to know why these patches are not getting committed to x264.git and to try to help fix the outstanding issues.

I'll start with the patches on komisar's site:
k.x264_cosmetic.diff - Nobody needs crf stored to 4dp in the header.  Why does the string need to be printed to the log?
k.x264_force_level.diff - Looks somewhat useful.  Why doesn't someone send it to the mailing list?
k.x264_restore_console_title.diff - Meh
x264_avi_output.v4.r1675.diff - Just no.
x264_demuxer_threads.diff - Might be useful if the default setting was automatic.
x264_enc_time.diff - Dark Shikari has said that the system has tools for doing this and they should be used.
x264_logger.v6.1675.diff - A little easier than tee but lacks an append option
L-SMASH - I think it's destined for use when finished

And now for X5-452’s:
x264-LS_1_writing_options_in_sei__r1722+269.diff - Dark Shikari is against this.  There is no reason to exclude it other than to hide your own stupidity.
x264-LS_2_k.cosmetic.diff - see above
x264-LS_3_k.restore_console_title.diff - and again
x264-LS_4_fade_compensation_r1713+227.diff - If fade compensation wasn't a hack and could be used without another option then it would be work while.  Dark Shikari is aware of this and what it does, it is his own code after all.
x264-LS_5_mp4_dts_compression_sw_r1713+249.diff - No comments on this
x264-LS_6_auto_vbv_settings_r1703+219.diff - Similar to komisar's, could be useful when combined with it.
x264-LS_7_film_grain_optimization_r1713+227.diff - Dark Shikari's code again.  Similar hackery.
x264-LS_8_filters_hqdn3d_yadif_pad_v8_r1722+269.diff - My patch which has not been updated correctly.  yadif and hqdn3d are GPL!
x264-LS_9_enc_time.diff - Doesn't that look familiar?
x264-LS_10_video_format_info_lavf_ffms_r1713+256.diff - Not sure how this helps people?
x264-LS_11_demuxer_threads_r1713+256.diff - Looks familiar again
x264-LS_12_fprofiled_acodec_none.diff - Perhaps when the audio system gets committed.

General comment about psyopts: They need fewer options, they need to work without the user tweaking them for every video.

[komisar]

k.x264_cosmetic.diff -- pick crf-value to get the desired size (i use them some time)
k.x264_force_level.diff -- need reworked...
k.x264_restore_console_title.diff -- console window not change title after end encoding...
x264_demuxer_threads.diff -- more helpfull with ffmpeg-mt
x264_enc_time.diff -- some ppl lazy to write `date /d >enc_log.txt` in his encoding script
x264_logger.v6.1675.diff -- append to log-file as default

[J_Darnley]

pick crf-value to get the desired size (i use them some time) -- Isn't that what 2pass is for?
append to log-file as default -- My apologies, I didn't see that.

[komisar]

for some reason i encode in crf-only mode (not 2-pass) and need exact bitrate for video. may need 19.253-like values

and for some reason some ppl need to print encoding params in log...  this is real values after parse command-line...

[VFR maniac]

x264-LS_5_mp4_dts_compression_sw_r1713+249.diff
This patch is for devices that don't support edit-list to eliminate initial delay.
Many japanese PS3 users want to apply this, and this is one reason why some japanese still use rev1376.
One problem is this patch breaks function of specifying timebase.

This demand comes from laziness of the manufacturers, but some x264 users in the 2ch board blame x264 devs not the manufacturers.

[Chortos-2]

First of all, sorry for all the quoting…

x264_enc_time.diff - Dark Shikari has said that the system has tools for doing this and they should be used.

x264_enc_time.diff -- some ppl lazy to write `date /d >enc_log.txt` in his encoding script

On Linux, there is the time utility and the time keyword, but on Windows, there is nothing. I am not sure if this ‘date /d’ is supposed to emulate time in newer versions, but on my Windows XP it does not work at all. The best thing I can do using the Windows command prompt is print the current date or print the current time (if I want them both, I cannot get them on a single line without involving third-party utilities). I do have MSYS (so I can use the time keyword) and a precise time-like utility of my own, but others do not, and sometimes you realize you want to know the time after you have already encoded or started encoding. As the patch is so simple, it should not make maintaining the code harder, but it would be useful to at least some users.

k.x264_cosmetic.diff - Nobody needs crf stored to 4dp in the header.  Why does the string need to be printed to the log?

I would rather ask ‘Why does it not?’ I find it useful to see the actual settings when using presets and profiles before the encoding is finished.

k.x264_restore_console_title.diff - Meh

k.x264_restore_console_title.diff -- console window not change title after end encoding...

I am not sure what your ‘meh’ meant , but to elaborate on Komisar’s explanation (at least for those who do not know what this is about), in Windows, console windows, just like all other windows, have titles, and x264 already utilizes this feature by displaying the encoding progress in the title of the console window it is running in (so you can see the progress in the task bar or whatever other list of windows you use and in the title bar of the actual console window), but does not restore the original title when the encoding is finished, so if you are unfortunate enough, it stays something like ‘x264 [100.0%] 33000/33000 frames, 25 fps, 2000 kb/s, eta 0:00:00’ until the window is closed (other programs that later change and correctly restore it will restore it to this title set by x264).

k.x264_force_level.diff - Looks somewhat useful.  Why doesn't someone send it to the mailing list?
x264-LS_6_auto_vbv_settings_r1703+219.diff - Similar to komisar's, could be useful when combined with it.

k.x264_force_level.diff -- need reworked...

Interesting (all of the quoted). I will make a separate topic to discuss this further.

x264-LS_10_video_format_info_lavf_ffms_r1713+256.diff - Not sure how this helps people?

Even if we are not sure how it can help, I believe there will be people whom it will help, and they will know how.

x264-LS_2_k.cosmetic.diff - see above
x264-LS_3_k.restore_console_title.diff - and again
x264-LS_9_enc_time.diff - Doesn't that look familiar?
x264-LS_11_demuxer_threads_r1713+256.diff - Looks familiar again

So we know there are at least two build makers who found these patches useful.