Zarx 3.0 ERROR

[Kyssifur]

Hey Guys, I get this error message after pressing 'encode' in zarx 3.0:

Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

Please help me, I'd love to encode with this awesome program.

[Kyssifur]

Apparently there is an unknown issue with the fade compensation setting: whenever I set it above zero, I have the error message mentioned above. Otherwise it works fine.

[mirkosp]

The fade compensation is an external patch not part of the main x264 codebase. IIRC Zarxgui 3.0 uses ffmpeg, which means that it's using an encoder based off of the main x264 codebase (it's using libx264), so no external patches for extra customization can be used. This includes stuff like --fgo, --fade-compensate, the whole audio branch of x264 (which should be dead by now), a few bitdepth patches (possibly, I think there was a patch for varying bitdepth with direct avs input) and most importantly --aq-mode 3 (which is very useful).

[Kyssifur]

That's what I thought. Thanks for the answer!

[Qyot27]

The fade compensation is an external patch not part of the main x264 codebase. IIRC Zarxgui 3.0 uses ffmpeg, which means that it's using an encoder based off of the main x264 codebase (it's using libx264), so no external patches for extra customization can be used. This includes stuff like --fgo, --fade-compensate, the whole audio branch of x264 (which should be dead by now), a few bitdepth patches (possibly, I think there was a patch for varying bitdepth with direct avs input) and most importantly --aq-mode 3 (which is very useful).

Not quite. The situation is more complex than this.

Yes, Zarx264gui 3.0 uses FFmpeg. It's the patch stuff where it gets complicated.

x264's source code is divided between the CLI code (the tool x264 itself) and the library (libx264). Some patches for x264 apply only to the CLI (like the audio stuff, input methods and output containers, or the AviSynth 16bit hack) and would have no effect on the encoder itself (the library). The x264 CLI tool accesses libx264 to do its encoding - the CLI is basically just a frontend to the library. FFmpeg's (really, libavcodec's, since this applies to Libav too) support for libx264 simply wraps around the same libx264 the x264 CLI uses. It's not a separate encoder.

This means that if you build a patched libx264, and then build FFmpeg against that patched libx264, any of the library-specific patches are also usable in FFmpeg. FGO and fadecomp don't do anything extreme to the library, so FFmpeg can see and use these just fine if they're present. Other patches that make deeper changes may or may not require deeper changes to FFmpeg's libx264 wrapper (the AQ stuff is in this category, since the TriAQ patch changes the macro names x264 uses internally). You could easily have an FGO+fadecomp-capable FFmpeg without patching FFmpeg, but for the AQ patches you have to patch FFmpeg.

You'd use these things in FFmpeg by passing them through the -x264-params option, since having discrete options for them is less likely (not saying 'impossible' in the long term, just not likely). In Zarx264gui, this probably requires using the Advanced Options and inputting the command yourself:

Code: Select all

-x264-params fgo=5:fadecomp=0.5

The actual issue is, how many people that provide builds of FFmpeg actually build it against patched versions of x264? I'd wager not many. To actually prove my point, though, here is one such build that has FGO, fadecomp, and the AQ patches. This is really only an example build (especially since I'm trying to wrangle with how the AQ stuff should be handled in the discrete options, but it's usable through -x264-params), as the only external libraries it supports are AviSynth and libx264, and the GCC optimizations have been turned off on FFmpeg's side. The patches to deal with all this will go up to my FFmpeg branch on Github, although that's still not a guarantee that anyone'll use them.

[Qyot27]

...and it now seems that --aq-mode 3 is officially committed to upstream x264.

http://git.videolan.org/?p=x264.git;a=c ... 0ab2aeea4f

When the upstream libavcodec wrapper will be updated is up in the air, but I'd assume fairly soon. The TriAQ patch would still need patching to use with it, though.

[Qyot27]

That test build is down since I actually built a fully-featured* one with everything as it should be, against the patches (I opted not to include the TriAQ patch in x264 since it gets entangled with the existing stuff too much, and I dropped those patches from FFmpeg since I don't want to bother - maybe if/when it gets fixed against current x264 master I'll do it again). The regular --aq-mode 3 from x264 master is usable with this build, as are fadecomp and fgo.

http://www.mediafire.com/?sf45gkzum63fcu7

*'fully-featured' means:

Code: Select all

ffmpeg version r68658 git-0e9130b Copyright (c) 2000-2014 the FFmpeg developers
  built on Dec 22 2014 11:28:58 with gcc 4.9.2 (GCC)
  libavutil      54. 15.100 / 54. 15.100
  libavcodec     56. 16.100 / 56. 16.100
  libavformat    56. 16.101 / 56. 16.101
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  4.100 /  5.  4.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100

  configuration:
    --prefix=/home/qyot27/ffmpeg_build
    --cross-prefix=i686-w64-mingw32-
    --enable-gpl
    --enable-version3
    --disable-w32threads
    --enable-avresample
    --disable-doc
    --disable-debug
    --enable-gnutls
    --enable-fontconfig
    --enable-libfreetype
    --enable-libfribidi
    --enable-libass
    --enable-libbluray
    --enable-libbs2b
    --enable-libcaca
    --enable-libcdio
    --enable-openal
    --enable-opengl
    --enable-librtmp
    --enable-libsoxr
    --enable-libvidstab
    --enable-libflite
    --enable-libgme
    --enable-libgsm
    --enable-libilbc
    --enable-libmodplug
    --enable-libmp3lame
    --enable-libnut
    --enable-libopencore-amrnb
    --enable-libopencore-amrwb
    --enable-libopenjpeg
    --enable-libopus
    --enable-libschroedinger
    --enable-libshine
    --enable-libspeex
    --enable-libtheora
    --enable-libtwolame
    --enable-libutvideo
    --enable-libvo-aacenc
    --enable-libvo-amrwbenc
    --enable-libvorbis
    --enable-libvpx
    --enable-libwavpack
    --enable-libwebp
    --enable-libx264
    --enable-libx265
    --enable-libxavs
    --enable-libxvid
    --enable-avisynth
    --cpu=pentium3
    --extra-cflags='-I/usr/i686-w64-mingw32/include/openjpeg-2.1 -mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPT
W32_STATIC_LIB -DCACA_STATIC -DMODPLUG_STATIC'
    --extra-ldflags='-mconsole -Wl,--allow-multiple-definition'
    --target-os=mingw32
    --arch=x86
    --pkg-config-flags=--static
    --enable-concise-version

It does have the patches from my FFmpeg Github repo branches applied.