Home > encode, x264, x264-bin > x264 rev2274+704 tMod

x264 rev2274+704 tMod

10th March 2013, Sunday Leave a comment Go to comments

Sources on GitHub: https://github.com/astrataro/x264_tMod.

Actually r2273 was built several weeks ago, but I was too busy to post here. And for some reasons my old file host services ended. Now the new host is http://tmod.nmm-hd.org, so please check it regularly if you would like to get the latest build as soon as possible.

Download:
x264_rev2274+704_tMod-v8.7z : NMM

Updates(some of the features are updated after v2, so only available in Lite builds):
1. <x264_l-smash> updated x264 core to 0.130.2274, with l-smash version stays in 704
2. <patches> added avxsynth audio support, fixed compilation with --disable-audio, and skip useless lavr check when lavf is not available
3. <patches/opts> added back --no-opts as an alias name of --opts 0, and changed --opts 0-2 to 0-3: 0-1 remains the old behaviour, 3 equals to old 2 which print both x264 version and options, the new 2 writes x264 options without version info. Personally I don’t like one using this option, but some people want it….
4. <patches/colormatrix> fixed sometimes BT.709 colormatrix is detected correctly by lavf/ffms, but is wrongly set to be BT.601 in the output file
5. <patches/demuxer=avs> now supports invoking LSMASHSource in avs demuxer ( LSMASHVideoSource/LSMASHAudioSource for mp4/mov/qt/3gp/3g2/m4a, and LWLibavVideoSource/LWLibavAudioSource for general formats
6. <patches/ntsc-fps> added support ntsc fps/timebase correction (e.g., 23.976xxx->24000/1001) for all demuxers, was only available in avs demuxer
7. <patches/MixAQ&OreAQ> fixed crashes in high bit depth build, hope they work as they should….
8. <patches/TriAQ> added aq3 as OreAQ, now can be used with VAQ and HaaliAQ
9. <patches/fgo&yadif> silence some gcc warnings
10. <patches/vf=subtitles> Many improvements:

  • Now you can use --fps or --timebase / --tcfile-in along with subtitles filter ( they would break subtitles rendering in the previous builds ).
  • Input demuxer is not limited to y4m/lavf/ffms any more, it can be any demuxer including avs/raw.
  • When --sub option is found, rendering csp will be automatically switched to i420:8, so if your input is 10-bit clips, you don’t need to manually set --vf resize:csp=i420:8/subtitles any more, just use --vf subtitles and enjoy!

In the last post I wrote a simple instruction to build tMod. If you do not know how to set tMod’s git branches, try the x264_tMod-clone.sh shell script. For those who expect a better instruction for compilation, I might write one when I get some time. You can find some x264_L-SMASH build instructions which are also helpful:

tMod is very similar to them unless your git branch structure should be:

  • plain
  • kaudio
  • lsmash
  • tMod
  • tMod+MixAQ
  • tMod+OreAQ
  • tMod+TriAQ

Another thing for users to take care of is that x264-audio has stopped its progress for a long time, and it is not quite compliant with the latest Libav/FFmpeg’s APIs. I’ve already got many bug reports regarding audio encoding regressions. There’s currently no working maintainer to fix them, so be careful when you’re doing audio encoding with my builds ( and very likely with many other x264-audio/lsmash based builds which support audio encoding but linked with latest Libav/FFmpeg libraries ).

Categories: encode, x264, x264-bin
  1. 11th March 2013, Monday at 12,29am UTC

    Thank you very much😀

    • enymous
      11th March 2013, Monday at 02,49am UTC

      Shinobi pls.

  2. darkboz
    12th March 2013, Tuesday at 11,37am UTC

    Thx alot for the new build !!!

  3. Andtsk
    15th March 2013, Friday at 05,06am UTC

    Hello!
    I have builded the x264+MixAQ with “Intel SDK for OpenCL 2012″ (have changed ‘configure’ script for that) and latest driver ( 9.17.10.2932 ) it runs excelent without option “–opencl”. But with it – driver crashes. I dont know what causes a problem.. here is x264 output before crash:
    http://pastebin.com/LnpGVujk
    Hope you can help!
    Thanks!

    • 18th March 2013, Monday at 08,59am UTC

      I am no expert in OpenCL, but AFAIK there are many issues in Intel’s implementation in Ivy Bridge, which is one of the reasons why official support of OpenCL in x264 was stopped. There were also some problems in AMD GPUs with Catalyst 12.4 to 12.9, and were supposed to be fixed in 12.10 or 12.11.

      • Andtsk
        20th March 2013, Wednesday at 04,22am UTC

        Thanks for the complete answer!

      • kaichou
        22nd March 2013, Friday at 07,35am UTC

        こにちわ、taroさん!
        I started using your build, but I’m a bit confused with something: how do I change the way your build shows the info during the encode? I’m getting something like:

        “[92.5%] 31169/33687 frames, 3.180 fps, 4731.7 kb/s, 733.29 MB, eta 0:13:11, est.
        size 792.53 MB”

        Did you removed the old style or something?
        Thanks in advance!

      • 22nd March 2013, Friday at 10,32am UTC

        What did you expect to be shown?

        If you meant the added “est.size xxx B”, no it cannot be hidden.

        If you meant that your console window keeps flushing with the progress indicator line instead of showing it in one line, it is because your console window buffer is too small to handle such a long line, so one long line is broken into two lines. Most systems’ default buffer width is 80, which is likely to be too small. It can be fixed by the following steps:
        1. Right click on your console title, choose “Defaults”:

        2. In the “Console Window Properties” window, go to “Layout” tab;
        3. Increase “Width” of “Screen Buffer Size” (120 or more is recommended);
        4. Increase “Width” of “Window Size” (optional):

        5. Click “OK” to save changes;
        6. Type “exit” to close console window.
        Then the next time you open a console window, there will be only one line of progress indicator shown as vanilla build.

        If you meant to show rev2204’s new indicator which was deprecated soon after released, you can add --stylish in your command line.

  4. Astez
    28th March 2013, Thursday at 08,17pm UTC

    Hi, I tried your OpenCL build (http://tmod.nmm-hd.org/x264/test/x264_r2274%2Bopencl.7z) from this thread
    http://forum.doom9.org/showthread.php?p=1621638#post1621638
    to encode some game footage but it seems I can’t complete the second pass of encoding for some reason, pops up an error every time.

    First pass works fine with GPU utilization around 30%, it’s only 2-3 fps faster though on a Geforce Titan compared to a 2600K@4.7Ghz (52,17 fps vs ~50,8).

    MeGUI error log:
    http://pastebin.com/5jpK9USn

    Best regards,
    Astez

    • 29th March 2013, Friday at 06,42am UTC

      What I did was a plain minimum build, which does not include mp4 output support. So you cannot output mp4 in MeGUI with this build.

      And btw, opencl only works in lookahead period, which should be done in 1st pass, so there is little meaning to enable opencl in the 2nd pass.

  5. Astez
    29th March 2013, Friday at 09,08am UTC

    Didn’t know that, I thought it would be working in MeGUI like the last one🙂

    I just added under misc->custom command line –opencl, why it applies to both passes, no idea.

    Anyway thanks for clearing that up.

  6. tritech
    8th April 2013, Monday at 06,29pm UTC

    What exactly is this TriAQ? What are the pros and cons of it? Is their any major or minor differences compared to MixAQ or OreAQ? Is it currently for testing purposes only?

    Sorry for all the questions, I’m just really curious about it.

    Thank you.

    • 9th April 2013, Tuesday at 07,28am UTC

      Like in MixAQ, --aq-* stuffs control Variance AQ (as in official x264), and --aq2-* stuffs control Haali’s AQ. The difference is TriAQ adds --aq3-* stuffs to enable OreAQ. So with TriAQ, one can use these three AQ together. Naturally, if you don’t enable aq2 and aq3 (which is by default), it works exactly the same as vanilla builds, and if you only enable aq and aq2, it works exactly the same as MixAQ builds. Enabling aq3 with both aq and aq2 off is a little bit different from OreAQ, because mbtree needs AQ on, while there is no VAQ in OreAQ builds so OreAQ is switched on by mbtree with strength=0, but in TriAQ, mbtree will still switch on VAQ with strength=0 as in vanilla build, even if OreAQ is already enabled. That shouldn’t make much difference in result, so I keep the internal process simple and identical to the vanilla builds, in order to make it a safe replacement of other builds.

      Another minor difference is that TriAQ separates aq*-i/p/bfactor and one can use different value for three AQs, while in MixAQ aq-i/p/bfactor applies globally to both VAQ and HAQ.

      Well, the core functions in these three AQ are supposed to behaviour identically to vanilla/MixAQ/OreAQ builds, only some parameter combination logic ( like on/off with mbtree, etc ) may vary. So everything should already been used for a long time, except for that no one had used them together. If you had used MixAQ/OreAQ before, you won’t have trouble in reading the new fullhelp file. I hope I had done everything correctly so that it can be used in real world encoding. If it does not work similar to MixAQ/OreAQ builds, then I must have done something wrong, but not the AQ stuffs.

      Ideally, if it works as it should in my tests, I might remove pure tMod, tMod+MixAQ and tMod+OreAQ, and only offer the TriAQ version in the future, as TriAQ can safely replace them. I tend to do this by making the current tMod+TriAQ be the new tMod in git, and deprecate other three branches.

  7. tritech
    9th April 2013, Tuesday at 04,42pm UTC

    Ah alright. I understand now. Thank you so much for putting in the time and effort giving such a detailed response. I couldn’t find any information about TriAQ anywhere. So your information helped a lot. I’ll look forward to more of your releases. Thank you.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: