VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab Passkey and remove Blu-ray and DVD protection! :)
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 50 of 50
Thread
  1. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Either that ... or you learn to be more patient and wait for more founded replies than mine. A forum is not a live chat. The best answer may arrive a week later...
    Quote Quote  
  2. Member SanderMan's Avatar
    Join Date
    Feb 2001
    Location
    Netherlands
    Search Comp PM
    Finally got it to work, by switching to handbrake 1.07 instead of the latest nightly. Thanks again for the assist.
    Quote Quote  
  3. As LigH.de mentioned, the NASM assembler is now required to compile the x264 and x265 video encoders as they now support AVX-512 optimizations, they also require a very recent version to work (2.13.02 or later), I've noticed Ubuntu 16.04 LTS does not detect the latest stable release and picks up version 2.11.08 instead, I therefore recommend using Ubuntu 17.10 (or later), Fedora or WSL for this process instead!

    See: https://github.com/HandBrake/HandBrake/pull/1081
    However, you can compile the latest version of NASM with the following command in Ubuntu 16.04 LTS as mentioned here: https://handbrake.fr/docs/en/latest/developer/build-windows.html
    Last edited by AntW93; 14th Apr 2018 at 12:15.
    Quote Quote  
  4. Member
    Join Date
    Jan 2018
    Location
    Malaysia
    Search Comp PM
    vmware workstation player with ubuntu 16.04.3

    got an error while compiling handbrake, forgot to take a screenshot.

    after that I saw AntW93 tips, then I use ubuntu 17.10.1 instead, everything went smoothly and compiled successfully.

    no problem using the compiled hb.dll on my windows 10 with handbrake 1.0.7

    million thanks to author and everyone for the guide
    Quote Quote  
  5. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    A pity MSYS2 under Windows seems to be unsupported; I tried to run the guide in a MinGW64 shell of MABS, instead of a real Linux host:

    Code:
    $ ./configure --cross=x86_64-w64-mingw32 --enable-x265 --enable-qsv --enable-fdk-aac --enable-libav-aac --launch-jobs=1 --force --launch
    probe: host tuple...(fail) code 1
      + ./make/config.guess
    It seems to fail in make/configure.py:

    Code:
    ## GNU host tuple probe: determine canonical platform type
    Looking back up, it was already mentioned:

    Originally Posted by AntW93 View Post
    As far as I know, HandBrake for Windows can only be cross-compiled, not natively compiled, it even says in its online documentation that building HandBrake for Windows requires Linux and a recent MinGW-w64 toolchain, see: https://handbrake.fr/docs/en/1.0.0/developer/build-windows.html

    I would love to be proved wrong though and shown that HandBrake can be compiled under the Windows environment, but I don't think it can, unfortunately!
    Quote Quote  
  6. Originally Posted by LigH.de View Post
    A pity MSYS2 under Windows seems to be unsupported; I tried to run the guide in a MinGW64 shell of MABS, instead of a real Linux host:

    Code:
    $ ./configure --cross=x86_64-w64-mingw32 --enable-x265 --enable-qsv --enable-fdk-aac --enable-libav-aac --launch-jobs=1 --force --launch
    probe: host tuple...(fail) code 1
      + ./make/config.guess
    It seems to fail in make/configure.py:

    Code:
    ## GNU host tuple probe: determine canonical platform type
    It is apparently possible to build HandBrake for Windows using MSYS2 as mentioned here: https://github.com/HandBrake/HandBrake/pull/506 and: https://github.com/HandBrake/HandBrake/issues/1054

    I have yet to test this for myself though, WSL is also faster than MSYS!
    Quote Quote  
  7. Thanks for the Guide , but I had one small glitch in following it ,I use Ubuntu on Windows 10 and windows use 16.4 which come with old NASM repository so i tried to build a newer version of it according to the guide
    Code:
    curl -O http://www.nasm.us/pub/nasm/releasebuilds/2.13.02/nasm-2.13.02.tar.bz2
    tar -xf nasm-2.13.02.tar.bz2
    cd nasm-2.13.02
    ./configure --prefix=/usr/local --enable-sections --enable-lto
    make -j$(nproc)
    sudo make install
    source ~/.bashrc
    cd ..
    well I had small problem of you don't have permission to do so untill I modified the commands like this
    Code:
    curl -O http://www.nasm.us/pub/nasm/releasebuilds/2.13.02/nasm-2.13.02.tar.bz2
    sudo tar -xf nasm-2.13.02.tar.bz2
    cd nasm-2.13.02
    sudo ./configure --prefix=/usr/local --enable-sections --enable-lto
    sudo make -j$(nproc)
    sudo make install
    source ~/.bashrc
    cd ..
    and I wonder why compiling this must take several hours (let just say around 10 hours)
    Quote Quote  
  8. I have a question ,I noticed after building hb.dll with fdkAAC and copying it in Vidcoder I no longer have 10bit x264 and x265 support also there is no 12bit x265 support ,


    I wonder if anybody can help me to enable support for those color depth
    Quote Quote  
  9. @JEskandari

    Thanks for the heads up, the location of the NASM source is indeed wrong, the instructions give the location with http protocol, but it requires https for the tarball path as mentioned here: https://forum.handbrake.fr/viewtopic.php?f=11&t=37605

    I have now updated the guide to reflect these changes!

    As for VidCoder, I'm not sure why you no longer have 10bit/12bit x264 and x265 support, try building it again in Ubuntu 17.10 or later in a VM to save time, as WSL is quite slow due to the way it handles disk access!
    Quote Quote  
  10. Just finished compiling HB 1.1.0 with AAC-FDK. Currently running an encode to see if it fixes the whistling wind problem I was having on some files. It took around 2-3 hours to get through the process but I already had VirtualBox installed so that probably saved me a few minutes. I mostly used the instructions at handbrake.fr for compiling the Windows version, but I referenced your guide when it failed and I found your explanation of what to do with the export PATH line to be more clear. Anyway, pain in the butt and I can't believe there isn't a good open source AAC encoder available that could be distributed with the HB installer. I did notice that AC3 was working better than the avcodec AAC, but I read AAC is better. Is AAC really better or are they about the same when you have good working versions of both?
    Quote Quote  
  11. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    AC3 (Dolby Digital) is about as good as MP3.

    AAC is the next generation of audio encoding, more efficient than both. Ogg Vorbis is similar. And for sane bitrates, ffmpeg's own AAC encoder is not even bad.

    The top format today is Opus; but not all containers support all audio formats.
    Quote Quote  
  12. I have a doubt.
    After compile the latest version (20180703) the version of x256 included in hb.dll is 2.6, but the version included in the nighty is 2.8.
    What am I doing wrong?
    Thanks
    Quote Quote  
  13. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Just guessing ... may depend on the version of libx265 already installed in your build system. You may have to update all the libraries used by Handbrake's conversion engine before compiling it, if it doesn't care about all of them (like MABS does when compiling ffmpeg).
    Quote Quote  
  14. Originally Posted by LigH.de View Post
    Just guessing ... may depend on the version of libx265 already installed in your build system. You may have to update all the libraries used by Handbrake's conversion engine before compiling it, if it doesn't care about all of them (like MABS does when compiling ffmpeg).
    I make "rm -rf Handbrake" before each compilation but the proccess download x265_2.6 not x265_2.8
    Quote Quote  
  15. Originally Posted by jmrf06 View Post
    Originally Posted by LigH.de View Post
    Just guessing ... may depend on the version of libx265 already installed in your build system. You may have to update all the libraries used by Handbrake's conversion engine before compiling it, if it doesn't care about all of them (like MABS does when compiling ffmpeg).
    I make "rm -rf Handbrake" before each compilation but the proccess download x265_2.6 not x265_2.8
    My complete process:
    Code:
    sudo apt-get install autoconf automake bison build-essential bzip2 cmake curl flex gcc git gzip g++ intltool libtool libtool-bin m4 make patch pax pkg-config python tar wget yasm zlib1g-dev 
    
    sudo apt autoremove
    
    rm -rf HandBrake/
    
    git clone https://github.com/HandBrake/HandBrake.git
    
    cd HandBrake/
    
    git tag
    
    git checkout tags/1.1.1
    
    cd
    
    HandBrake/scripts/mingw-w64-build x86_64.distclean
    HandBrake/scripts/mingw-w64-build x86_64 
    export PATH="/home/jmraja/toolchains/mingw-w64-5.0.3-gcc-7.2.0/mingw-w64-x86_64/bin:${PATH}"
    
    x86_64-w64-mingw32-gcc -v 
    
    cd HandBrake
     
    ./configure --cross=x86_64-w64-mingw32 --enable-x265 --enable-qsv --enable-fdk-aac --enable-libav-aac --launch-jobs=1 --force --launch 
    
    cd
    Quote Quote  
  16. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    In this case I believe the HandBrake script explicitly downloads x265 with the 2.6 version tag to ensure that HandBrake knows the API of x265 at this revision. There are often changes to supported options in x265, and HandBrake might fail using x265 after such changes if it doesn't adapt to them.

    A next guess ... when you clone from HandBrake.git, you will probably retrieve the stable or master branch. I wonder if there is also a development branch, then you may have to alter the "git clone" or the following "git checkout tags" command accordingly, to retrieve that "nightly" source instead?
    Quote Quote  
  17. Originally Posted by LigH.de View Post
    In this case I believe the HandBrake script explicitly downloads x265 with the 2.6 version tag to ensure that HandBrake knows the API of x265 at this revision. There are often changes to supported options in x265, and HandBrake might fail using x265 after such changes if it doesn't adapt to them.

    A next guess ... when you clone from HandBrake.git, you will probably retrieve the stable or master branch. I wonder if there is also a development branch, then you may have to alter the "git clone" or the following "git checkout tags" command accordingly, to retrieve that "nightly" source instead?
    Thanks, thanks, solved. Now I've x265 2.8 !!!
    It was solved by commenting two lines. I also had to remove the --enable-libav-aac flag from the configure because it was causing an error.
    Now my procedure is like this:
    Code:
    sudo apt-get install autoconf automake bison build-essential bzip2 cmake curl flex gcc git gzip g++ intltool libtool libtool-bin m4 make patch pax pkg-config python tar wget yasm zlib1g-dev 
    
    sudo apt autoremove
    
    rm -rf HandBrake/
    
    git clone https://github.com/HandBrake/HandBrake.git
    
    cd HandBrake/
    
    # git tag
    
    # git checkout tags/1.1.1
    
    
    cd
    
    HandBrake/scripts/mingw-w64-build x86_64.distclean
    HandBrake/scripts/mingw-w64-build x86_64 
    export PATH="/home/jmraja/toolchains/mingw-w64-5.0.3-gcc-7.3.0/mingw-w64-x86_64/bin:${PATH}"
    
    x86_64-w64-mingw32-gcc -v 
    
    cd HandBrake
     
    # ./configure --cross=x86_64-w64-mingw32 --enable-x265 --enable-qsv --enable-fdk-aac --enable-libav-aac --launch-jobs=1 --force --launch 
    ./configure --cross=x86_64-w64-mingw32 --enable-x265 --enable-qsv --enable-fdk-aac --launch-jobs=1 --force --launch
     
    
    cd
    Last edited by jmrf06; 4th Jul 2018 at 17:47.
    Quote Quote  
  18. I'm currently working on a major overhaul of this guide in preparation for the next stable release of HandBrake (version 1.2.0), which has now switched from Libav 12.3 to FFmpeg 4.0 and will therefore come with an improved default AAC encoder which is no longer considered beta/experimental, Nvidia NVENC encoding will also finally be available in HandBrake as well as AMD's VCE encoder (for Windows only)!
    Quote Quote  
  19. Originally Posted by AntW93 View Post
    I'm currently working on a major overhaul of this guide in preparation for the next stable release of HandBrake (version 1.2.0), which has now switched from Libav 12.3 to FFmpeg 4.0 and will therefore come with an improved default AAC encoder which is no longer considered beta/experimental, Nvidia NVENC encoding will also finally be available in HandBrake as well as AMD's VCE encoder (for Windows only)!
    Great news.
    Is FFmpeg 4.0 AAC encoder comparable to FDK-AAC encoder?
    Thanks
    Quote Quote  
  20. Originally Posted by jmrf06 View Post
    Great news.
    Is FFmpeg 4.0 AAC encoder comparable to FDK-AAC encoder?
    Thanks
    I believe its much better than the Libav AAC encoder that HandBrake has been using as its default AAC encoder for Windows and Linux for quite some time now, however the FDK-AAC encoder is still better than the FFmpeg 4.0 AAC encoder because it offers HE-AAC support and encodes more efficiently producing higher quality audio.

    Also, it states on this website (https://wiki.hydrogenaud.io/index.php?title=AAC_encoders) that "The native AAC encoder created in FFmpeg, and forked with Libav, was considered experimental and poor. A significant amount of work was done for the 3.0 release of FFmpeg (February 2016) to make its version usable and competitive with the rest of the AAC encoders. Libav has not merged this work and continues to use the older version of the AAC encoder. These encoders are LGPL-licensed open-source and can be built for any platform that the FFmpeg or Libav frameworks can be built."

    And that "both FFmpeg and Libav can use the Fraunhofer FDK AAC library via libfdk-aac, and while the FFmpeg native encoder has become stable and good enough for common use, FDK is still considered the highest quality encoder available for use with FFmpeg. Libav also recommends using FDK AAC if it is available."

    I hope this answers your question!
    Quote Quote  



Similar Threads