building x264 for mp4 output ("gpac or L-SMASH support")

[hydra3333]

Hello. Just wondering.

"x264.exe --help" shows this

x264 core:148 r2748 97eaef2
Syntax: x264 [options] -o outfile infile
Infile can be raw (in which case resolution is required),
  or YUV4MPEG (*.y4m),
  or Avisynth if compiled with support (yes).
  or libav* formats if compiled with lavf support (yes) or ffms support (no).
Outfile type is selected by filename:
 .264 -> Raw bytestream
 .mkv -> Matroska
 .flv -> Flash Video
 .mp4 -> MP4 if compiled with GPAC or L-SMASH support (no)
Output bit depth: 8 (configured at compile time)

which suggests that x264 coud be built with mp4 outputfile capability ("gpac or L-SMASH support").

Here's a run of the existing x264 build and its output

"VSPipe.exe" "test.vpy" - --y4m   | "x264.exe" - --stdin y4m --thread-input --profile high --level 4.1 --preset slow --interlaced --tff --no-cabac --crf 18 --sar 64:45 --colormatrix bt470bg -o "test.h264.mp4"
x264 [error]: not compiled with MP4 output support
Error: fwrite() call failed when writing frame: 0, plane: 0, line: 5, errno: 22
Output 8 frames in 0.55 seconds (14.66 fps)

That x264 was built with " --build-x264-with-libav=y " which, by the good graces of you, gives it .mpg/.mp4 "input file" capability :-

sudo ./cross_compile_ffmpeg_opencl.sh --cflags='-O3' --gcc-cpu-count=2 --sandbox-ok=y --build-ffmpeg-shared=n --build-ffmpeg-static=y --disable-nonfree=n --build-x264-with-libav=y --build-intel-qsv=y --build-libmxf=n --build-mp4box=y --build-mplayer=n --build-vlc=y --git-get-latest=y --prefer-stable=n --high-bitdepth=n --compiler-flavors=multi --enable-gpl=y --build-lsw=n

Would it be possible to build it so that it also has MP4 output file capability too ?

[ghost]

You set --build-lsw=n so no build_lsw() and no build_lsmash(). Then just run the script for a 2nd time and you should get an MP4 capable x264.exe ...

[hydra3333]

OK !
set --build-lsw=n first, then build, then set --build-lsw=y and build again ?
Righty ho.

[hydra3333]

Hmm, did that, it didn't work. The x264 exe's are identical before and after.

[ghost]

Sorry, but that's not what I said. You set --built-lsw=y and leave it like that ALWAYS and then run the script again right after its first completion and without touching/cleaning anything out of the sandbox ... The output of x264 --fullhelp should begin like this if successful:

x264 core:148 r2762 90a61ec
Syntax: x264 [options] -o outfile infile

Infile can be raw (in which case resolution is required),
or YUV4MPEG (.y4m),
or Avisynth if compiled with support (yes).
or libav formats if compiled with lavf support (no) or ffms support (no).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC or L-SMASH support (lsmash)
Output bit depth: 8 (configured at compile time)
[...]

[ghost]

BTW:
x264 core:148 r2748 97eaef2

that's an old version ....

[ghost]

Replace

do_git_checkout "http://repo.or.cz/r/x264.git" $checkout_dir "origin/stable" # guess we always prefer stable here...

with

do_git_checkout "http://git.videolan.org/git/x264.git" $checkout_dir "origin/master"

in build_libx264()

Don't know why rdp is doing/hardcoding that when there's

git_get_latest=y
prefer_stable=y

which is what I use ....

[hydra3333]

Thank you !! That worked just fine.

Since I'm changing rdp's beaut build script anyway to build with nvidia openCL, every time rdp releases a new script - as a terrible but effective hack, I added a variation of that "double build" by also changing it to

• force build-lsw=y enable_opencl=y build_x264_with_libav=y
• and then doing an additional call to both build_lsw and build_libx264 after build_apps
• changing the libx264 build to use do_git_checkout "http://git.videolan.org/git/x264.git" $checkout_dir "origin/master"
• add nvidia openCL build stuff
  then changed the call of the hacked script to
• --git_get_latest=y
• --prefer_stable=y
• --build-lsw=y

Now x264.exe can accept .mpg and whatnot as input and can deliver .mp4 as output. That's handy.

cross_compile_ffmpeg_opencl_lsw.sh.txt
3.runit_opencl_lsw.sh.txt

[hydra3333]

@rdp would you maybe consider

• changing the libx264 build function to use the latest stable ?
• do_git_checkout "http://git.videolan.org/git/x264.git" $checkout_dir "origin/master"
• changing the script so that as a final step it builds lsw and then rebuilds libx264 so that x264.exe can output .mp4 files too ?

[hydra3333]

Unless I'm doing obviously wrong, just building it ordinarily once with --build-lsw=y seemed to work, after I deleted the sandbox build x32/x64 folders and ran it.

[ghost]

Deleting the sandbox isn't proper cleaning actually. There's $mingw_w64_x86_64_prefix/lib/* and headers/files etc left and, IIRC, it also depends on --build-x264-with-libav=y/n as one of them is doing the "extra first round" already so lsmash will be there already as well so no extra run/build_lsw() is needed then ...

[rdp]

those are all in the sandbox?

…

On Sun, Apr 2, 2017 at 8:02 AM, Schmidt, Hubert ***@***.***> wrote: Deleting the sandbox isn't proper cleaning actually. There's $mingw_w64_x86_64_prefix/lib/* and headers/files etc left and, IIRC, it also depends on --build-x264-with-libav=y/n as one of them is doing the "extra first round" already so lsmash will be there already as well so no extra run/build_lsw() is needed then ... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#218 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAw0H5dFFaKNapnb37eFfGRYlIIgYBFks5rr7hygaJpZM4Mp-7E> .

[ghost]

Yes, sorry. What I meant was actually that some people only delete the win32 and x86_64 folders inside the sandbox and keep the cross_compilers folder, and that's not good enough ...

[hydra3333]

That's what I did, which wasn't good enough.
Thanks for pointing it out !

[hydra3333]

This one seems to result in a build, with nvidia-OpenCL and MP4box-with-gpac and x264-with-libav-and-LSMASH

edit: this is now superseded, refer #219 (comment)
cross_compile_ffmpeg_opencl_lsw_updated.versions.sh.txt

It has software versions more aligned with the build on Zeranoe's site (except for openjpeg 2.1.2 which fails to build for me) and an additional dependence on a small Opus 1.1.4 patch from this person's website #219

[ghost]

You can use opus.git now, check #219.

[hydra3333]

Yes, OK changed to that now, however the updated patch by Reino17 still seems to need to be applied to the GIT version..

[ghost]

openjpeg 2.1.2 builds just fine, after a PROPER cleanup of the sandbox and a quick READ UP on some of the ~30 openjpeg CMakeLists.txt files and #37 ...

build_libopenjpeg2() {
download_and_unpack_file https://github.com/uclouvain/openjpeg/archive/v2.1.2.tar.gz openjpeg-2.1.2
cd openjpeg-2.1.2
export CFLAGS="$CFLAGS -DOPJ_STATIC"
do_cmake_and_install "-DBUILD_SHARED_LIBS:BOOL=off -DBUILD_THIRDPARTY:BOOL=on -DBUILD_PKGCONFIG_FILES:BOOL=on"
reset_cflags
cd ..
}

[hydra3333]

Thank you schmidthubert.

Serves me right, I should have paid attention :)

updated script will arrive over at #219 after it's tested