HandBrake 0.10.5 Discussion Thread
Re: HandBrake 0.10.5 Discussion Thread
Hey s55 and the Handbrake development team,
Now that x265 is becoming more stable, is it time to include some sensible defaults in the presets list for it? A "normal" and a "high profile" preset for x265 would be great since I'm not familiar with all the options. I fully acknowledge that there is basically no device support now, but I'd like to gain the advantage of smaller file sizes today.
Now that x265 is becoming more stable, is it time to include some sensible defaults in the presets list for it? A "normal" and a "high profile" preset for x265 would be great since I'm not familiar with all the options. I fully acknowledge that there is basically no device support now, but I'd like to gain the advantage of smaller file sizes today.
Re: HandBrake 0.10.5 Discussion Thread
There is some level of confusion around compiling from source. But, essentially (if you follow the CompileOnWindows wiki), in order to compile HB for Windows, you have two separate compiles. The first compile is what creates libhb (hb.dll) and the Windows CLI (HandBrakeCLI.exe). This compile is done on a Linux machine. If you follow the instructions on the Wiki, doing this compile using Ubuntu is pretty straight forward (I use an Ubuntu VM). The one thing that you have to do different from the instructions is add the --enable-fdk flag to the compile string. Once the compile completes, you get two important files, hb.dll and HandBrakeCLI.exe. The second compile is what compiles the Windows GUI. This is done on Windows using Visual Studio. The instructions are pretty straight forward on the Wiki with one exception in that it is missing a minor, but important step (the Wiki assumes that you know to do this, but if you have never compiled anything before, you likely won't). The missing step is that BEFORE you go to the build menu and build the project, below the build menu (in the ribbon bar) is two drop down boxes. By default, they will say "Debug" and "Mix Platforms." You will need to change the section that says "Debug" to "Release." You will also need to change "Mix Platforms" to the architecture of your machine (x32 or x64). Then, you can go to the build menu and build the solution. When this is complete, you will get everything needed to run the Handbrake GUI with exception to hb.dll and HandBrakeCLI.exe (those were compiled on the Linux machine). To get a full working Handbrake, you simply copy the two files on the Linux machine to the folder that was built on the Windows machine. After doing that, you can then run Handbrake and have FDK.Lazyncoder wrote:Is there any chance to have FDK-AAC HE in HB WinGUI?
Just to be clear, does "compiling" option work for WinGUI too? or is it just Linux?
I mean if we compile it, can we have fdk-aac?
is there any way at all?
I will also point out that you can also do this a bit easier by simply installing Handbrake (the release version), downloading the release source code to your Linux VM, compile the libhb and CLI against the release source with the --enable-fdk flag, and merely overwrite your existing hb.dll and HandBrakeCLI.exe with the ones you compiled on Linux. By doing it this way, you only have to do one compile.
Re: HandBrake 0.10.5 Discussion Thread
I've created my own Normal and High profiles by starting with the existing Normal and High profiles and tweaking settings (using x265) until I found a good mix of quality as it relates to performance. I've been happy with that so far, but it would be good to see some official x265 presets. Interestingly, device support is a bit better in some places than in orders and, in many cases, is unknown that you have the support. For example, my Roku's, Xbox One, PC's/Laptops, cell phones and tablets (all Android), all fully support x265 playback. The Xbox One is technically my oldest device with a release in 2013. What I'm finding on the Apple side of things is that the iPhone 6 and newer do have the hardware to playback x265 (and does so with Facetime), it isn't supported via the software (iTunes). But, that isn't to say that won't change here soon. So, I think that this year, we'll likely see more devices with the capability.dguido wrote:Hey s55 and the Handbrake development team,
Now that x265 is becoming more stable, is it time to include some sensible defaults in the presets list for it? A "normal" and a "high profile" preset for x265 would be great since I'm not familiar with all the options. I fully acknowledge that there is basically no device support now, but I'd like to gain the advantage of smaller file sizes today.
Re: HandBrake 0.10.5 Discussion Thread
HB can passthrough AAC audio.Ozman wrote:If I use makemkv to rip a dvd I own, using fdk-aac for the audio, can I then use the latests Handbrake to transcode (and reduce the file size) as Handbrake would simply be copying the audio?
Re: HandBrake 0.10.5 Discussion Thread
Just like to say a big 'Thanks' to the developers of this application (and I registered just so I could do that) that I have been using for many years...
Also, I'm glad to see the (non-reported?) issue of a massive slow-down in transcoding speed that crept in with 0.10.3 (on my Mac) has gone... On my mid-2009 MacBook Pro which I've used from new, it used to take the DVD playing time plus 10-50% of the playing time again to transcode... The time - I guess - to be dependent on how complicated the DVD video structure was (older DVDs with little or no special effects transcoded fast, some newer DVDs with lots of special effects seemed to take longer).
0.10.3 resulted in a transcoding time of at least 200% of the DVDs playing time, with average times ranging from 4-8 hours to transcode and issues with swapping between applications also inherent. I went back to 0.10.2 to verify the speed difference and yes, 0.10.2 was consistently faster, as was my system whilst using it.
0.10.5 has again dropped the time taken to just over the DVDs playing time. I'd have to use all three versions on the same DVD to empirically 'prove' my subjective times via the logs, but having transcoded 2 DVD's this morning, while working on the Mac, I'm again happy. Swapping between Applications is also faster and I know that this is a subjective report, but that part of the upgrade is well deserving of a 'Thanks for that'.
Also, I'm glad to see the (non-reported?) issue of a massive slow-down in transcoding speed that crept in with 0.10.3 (on my Mac) has gone... On my mid-2009 MacBook Pro which I've used from new, it used to take the DVD playing time plus 10-50% of the playing time again to transcode... The time - I guess - to be dependent on how complicated the DVD video structure was (older DVDs with little or no special effects transcoded fast, some newer DVDs with lots of special effects seemed to take longer).
0.10.3 resulted in a transcoding time of at least 200% of the DVDs playing time, with average times ranging from 4-8 hours to transcode and issues with swapping between applications also inherent. I went back to 0.10.2 to verify the speed difference and yes, 0.10.2 was consistently faster, as was my system whilst using it.
0.10.5 has again dropped the time taken to just over the DVDs playing time. I'd have to use all three versions on the same DVD to empirically 'prove' my subjective times via the logs, but having transcoded 2 DVD's this morning, while working on the Mac, I'm again happy. Swapping between Applications is also faster and I know that this is a subjective report, but that part of the upgrade is well deserving of a 'Thanks for that'.
On FDK AAC removal
Contrary to what the FFMPEG team chooses to believe (https://www.ffmpeg.org/index.html#aac_encoder_stable) their revised AAC does not seem to be transparent at 128kbit/s. "Kamedo2" whom they mention in their post did another listening test vs. FDK AAC: https://hydrogenaud.io/index.php/topic,111085.0.html
You, the Handbrake team, seems to think that Apple's AAC Encoder is the best one available (default on OS X). Why not add that encoder also to the Windows build now that FDK AAC seems to be out of the picture without any hope that it will soon return - if ever.
Downloading iTunes is not that hard and those who absolutely do no want to install iTunes itself can just extract the codecs from the installation package and install them separately (open iTunes installer executable in 7-Zip using "File/Open inside" and extract the ApplicationSupport MSI installation file for 32bit or 64bit environments).
I would assume that this would be a safe way to keep a good AAC encoder in Handbrake. FFMPEG stills seems to have quite a long way to go until they are able to match Apple or Fraunhofer (FDK).
You, the Handbrake team, seems to think that Apple's AAC Encoder is the best one available (default on OS X). Why not add that encoder also to the Windows build now that FDK AAC seems to be out of the picture without any hope that it will soon return - if ever.
Downloading iTunes is not that hard and those who absolutely do no want to install iTunes itself can just extract the codecs from the installation package and install them separately (open iTunes installer executable in 7-Zip using "File/Open inside" and extract the ApplicationSupport MSI installation file for 32bit or 64bit environments).
I would assume that this would be a safe way to keep a good AAC encoder in Handbrake. FFMPEG stills seems to have quite a long way to go until they are able to match Apple or Fraunhofer (FDK).
Re: HandBrake 0.10.5 Discussion Thread
CoreAudio is not part of Windows. It would require us to link to a non GPL compatible library so is not an option.
So the exemption we get on mac doesn't work for Windows
So the exemption we get on mac doesn't work for Windows
-
- Veteran User
- Posts: 4859
- Joined: Wed May 04, 2011 11:06 pm
Re: HandBrake 0.10.5 Discussion Thread
@KDCNZ
If you are having issues with HB you should start a separate thread and please post your logs.
If you are having issues with HB you should start a separate thread and please post your logs.
Re: HandBrake 0.10.5 Discussion Thread
Did this resolve the issue with nvidia's latest gpu drivers and some laptops?
Re: HandBrake 0.10.5 Discussion Thread
No. It's an Nvidia problem.
Re: HandBrake 0.10.5 Discussion Thread
Any deatails on this issue?
Re: HandBrake 0.10.5 Discussion Thread
Other than it doesn't work? No. It's not being investigated. I don't have any hardware to test with.
All I can tell you is it'll work fine if you rollback your driver. I don't recall what version but atleast one person posted which driver version they rolled back to that fixed it.
Basically we are waiting to see if anything is fixed over the next few releases and if not, we'll look into removing or adding an option to disable the opencl code on their hardware.
All I can tell you is it'll work fine if you rollback your driver. I don't recall what version but atleast one person posted which driver version they rolled back to that fixed it.
Basically we are waiting to see if anything is fixed over the next few releases and if not, we'll look into removing or adding an option to disable the opencl code on their hardware.
Re: HandBrake 0.10.5 Discussion Thread
Has it been reported to nvidia?
Re: HandBrake 0.10.5 Discussion Thread
Nope. No point in reporting it when all we can tell them is "It doesn't work". No investigation is done so a proper bug report can't be made.
Re: HandBrake 0.10.5 Discussion Thread
Any simple for-the-complete-and-utter-novice instructions for doing this libhb & CLI for-windows compile on a Mac would be appreciated.I will also point out that you can also do this a bit easier by simply installing Handbrake (the release version), downloading the release source code to your Linux VM, compile the libhb and CLI against the release source with the --enable-fdk flag, and merely overwrite your existing hb.dll and HandBrakeCLI.exe with the ones you compiled on Linux. By doing it this way, you only have to do one compile.
All the instructions seem to talk about linux, but I can't imagine many changes would be needed to do it on a Mac. I just don't know enough to guess. I have no experience compiling HB for the Mac on a Mac, either, though apart from installing yasm it doesn't look that bad.
Something has to give with these licenses. In the meantime, the best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for our Windows friends, since for some reason _that_ is a loophole, but calling an apple library installed on a windows machine isn't. Seems so arbitrary, probably because it is.
Re: HandBrake 0.10.5 Discussion Thread
The two issues are completely unrelated, and you don't seem to understand either.radellaf wrote:Something has to give with these licenses. In the meantime, the best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for our Windows friends, since for some reason _that_ is a loophole, but calling an apple library installed on a windows machine isn't. Seems so arbitrary, probably because it is.
Re: HandBrake 0.10.5 Discussion Thread
No it's not, you can build it and use it for yourself, but the same licensing reasons that prevent us from distributing it to you prevent you from distributing it to your friends. If we could distribute builds with FDK, we just would.radellaf wrote:In the meantime, the best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for our Windows friends, since for some reason _that_ is a loophole
Re: HandBrake 0.10.5 Discussion Thread
How about being nice? I'm sorry that you had to make this change, and wish there were something I could do to help. (Donate to the EFF?)
It is definitely a loophole that there's any legal difference between source and binary distribution.
Understanding why that is, or why it's a loophole but using other libraries isn't, is interesting history but kind of beside the point.
So:
"The best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for Windows since a lot more of us, who have never done it before, will need to do it."
It is definitely a loophole that there's any legal difference between source and binary distribution.
Understanding why that is, or why it's a loophole but using other libraries isn't, is interesting history but kind of beside the point.
So:
"The best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for Windows since a lot more of us, who have never done it before, will need to do it."
Last edited by radellaf on Mon Feb 22, 2016 1:25 am, edited 1 time in total.
Re: HandBrake 0.10.5 Discussion Thread
The directions for doing so are already published. Have you even tried them?radellaf wrote:"The best I can ask is eventually something to make it easy, preferably very easy, for people with a Mac or Linux machine to compile those files for Windows since a lot more of us, who have never done it before, will need to do it."
Re: HandBrake 0.10.5 Discussion Thread
They're a little cryptic. The instructions for Mac compiling don't directly address cross compiling for windows, and it's beyond my expertise to confidently extend the instructions for doing it under linux, to doing it under OSX.
Re: HandBrake 0.10.5 Discussion Thread
If you want to compile windows you have to do it under Linux. I recommend a Virtual Machine and using the same version of Ubuntu as in the instructions. I figured it out after a few mistakes. If you need help start a new thread and people here will help you out.radellaf wrote:They're a little cryptic. The instructions for Mac compiling don't directly address cross compiling for windows, and it's beyond my expertise to confidently extend the instructions for doing it under linux, to doing it under OSX.
Re: HandBrake 0.10.5 Discussion Thread
You can technically compile HandBrake on Windows and Mac as well. I've done it on both but these days I always use Linux so those are the instructions provided as it's known to work properly.
Regardless, if you chose to do so, your pretty much on your own.
Regardless, if you chose to do so, your pretty much on your own.
Re: HandBrake 0.10.5 Discussion Thread
From Doom9's x265 thread, it seems like there is an issue with 2-pass x265? Has anyone encountered that?
Re: HandBrake 0.10.5 Discussion Thread
couldn't you get around this by including a script that downloaded all the required sources and compiled them on the users computer? the same way nvidia/ati get their binary blobs into the linux kernel?
or host it in countries where it's not illegal or nobody cares?
or host it in countries where it's not illegal or nobody cares?
Re: HandBrake 0.10.5 Discussion Thread
Can you link it please?nhyone wrote:From Doom9's x265 thread, it seems like there is an issue with 2-pass x265? Has anyone encountered that?