HandBrake

Dropbox or any other storage service, and then send me the link via a private message, thanks.

FEL is dropped. Adding supports for decoding the FEL and merging it with the BL requires someone working on it, patches are welcomed

The hardware decoders are supposed to fall back to software decoders when they can't decode a video, but we don't handle the cause in which they can't decode a single frame yet. It would be nice if you could upload a short sample (a few seconds) that I can use to reproduce the issue.

x265 is a HEVC encoder (that supports Dolby Vision in HandBrake), VideoToolbox uses a different (hardware) HEVC encoder that can't be used to create a Dolby Vision video yet.

DV is supported only in combination with x265 10-bit.

I think there is a separate "Open directory" menu now.

Converting to UTF-8 is always a good solution. Nowadays there is no reason to not use UTF-8, unless you need compatibility with some obscure 20 years old software or device.

1.7.0 shipped with that feature disabled, get 1.7.1 and it will work.

The palette for vobsubs is not stored in the VOB file. It is stored in the DVD index information. If you want the palette, you must scan the DVD (either an iso, or the VIDEO_TS directory of a DVD rip).

Fixed in 1.7.1.

Please don't post about unrelated issues in the same thread.

1.7.1 has a fix for QSV when there are multiple GPUs from different vendors, maybe it helps, I don't know and I can't test.

The available encoders are shown in the UI.
A list of dependencies can be found on https://github.com/HandBrake/HandBrake/ ... er/contrib

Read above.

It seems to be crashing in x264, quite a strange place to stop. Can you try another encoder? And if you can, could you try if HandBrake 1.4 or HandBrake 1.5 crash too?

Unfortunately it's a bug, disable the Decomb filter (and the Comb detect filter).

By the way, if it stops immediately probably copying only the first 10 seconds to a new file would be enough to reproduce the crash.

Check if there is a crash log in ~/Library/Logs/DiagnosticReports/, there might be something useful in it.

Fixed in https://github.com/HandBrake/HandBrake/ ... 26e49cdf07

Thanks for the file. I reproduced the crash on Windows. It seems to happen only when the Interlace Detect filter is enabled. In the meantime you can disable both Interlace Detect and Deinterlace filters from the Filters tab (your file is not interlaced, so these aren't needed).

Can you upload a short file we can use to reproduce the issue?

It might be caused by the fact that there are closed captions embedded into the video, and now HandBrake is passing them around as side-data, and the nvenc encoder is preserving them.

It seems HandBrake is dropping some audio frames for some reasons. But it's hard to say why without having access to that mp4.

Your finding was right, it's related to chapters that force the encoder to make a keyframe. So the solution is to disable chapters for now until there is a fix in macOS or a workaround.

I guess something is going wrong in an optimised routine of the ProRes decoder on the Intel CPU. But without a way to reproduce the issue, it will be hard to fix it.

That's because you are setting --inline-parameter-sets.