HandBrake

HandBrake does not support encoding to mpeg-1

The file has a DecoderConfigDescriptor with a length field of 0. The ISO/IEC 14496-1 spec doesn't indicate that this is an error. It only says that length is the size of the remaining descriptor after the length field. So this is an ffmpeg bug IMO. The function ff_mp4_read_dec_config_descr returns a...

Hopefully the windows GUI developer will chime in. But it could have just been a random selection. There may be no *good* reason. Linux GUI's selection of the "middle" preset is also a fairly random selection.

The encoder presets are not equivalent between different encoders even though they may have the same names. Whenever you change the encoder, the GUI is going to select a default encoder preset since the old preset name may not even exist in the new encoder. It seems the windows GUI chose to use fast...

BradleyS wrote: ↑

Wed Mar 20, 2019 7:26 pm

I believe we need libnuma for multi-socket systems, which is in consideration. What Woodstock said is still relevant.

Not just mult-socket these days. AMD Epyc and some Ryzen are multi-module in a single socket. These also benefit from numa.

HandBrake logging is very chatty at it's lowest verbosity level. There is no level to output only warnings. There are only levels to increase log output.

For your use case, fixing the video really needs to be a done with a separate program and not built in to HandBrake. Look at your process. You found the cut points you wanted with VLC, then cut it with HandBrake. If HandBrake and VLC do not see the same video (which was the case when the stream had ...

You should be using an RF of at least 16 or higher.

HandBrake can do soft VOBSUB in mp4. The latest should not force you to burn in one. IIRC that was a bug that got fixed. But as BradleyS said, VOBSUB in mp4 isn't supported by many players. So if you expect your video to be portable to multiple players, you need to consider other options.

The codec used to encode BDs is *lossy*. When you transcode, it decodes that lossy encoding to raw images that are the full size (in bytes) of the original lossless video. *That* is what is passed to the encoder in HandBrake. If you then tell the encoder to encode lossless, it will be attempting to ...

I'm not sure what that's all about. Are you able to run other flatpak apps on your system? I'm wondering if this is specific to HandBrake or if there is some other problem with flatpak in general on CentOS.

Very few of us speak French. Official language of the forums is English.

QSV is enabled and working according to your log. But you also have some filters enabled that are not hardware accelerated. This is most likely the reason it is not as fast as you expect. You're source isn't interlaced, so you can safely disable comb detect and decomb filters.

Yup, that'll be the place to find them. Keep an eye on the date in the filename. When a new one comes out, it hopefully willl have QSV support. Scott is a busy guy and the nightly builds are on his shoulders. So can't say what the ETA might be.

Woodstock wrote: ↑

Mon Mar 11, 2019 7:51 pm

If someone tells you how to do something using the advanced tab, they're probably referring to a version of handbrake from 5 or more years ago, when the presets were not as good as they are now.

Or even older when the encoder presets didn't even exist yet.

And... are you sure it's /opt/intel/mediasdk/lib and not /opt/intel/mediasdk/lib64? lib64 was the default install location when I built it.

One thing, did you run ldconfig after adding /etc/ld.so.conf.d/msdk.conf? /etc/ld.so.cache is what's actually looks at to load libs and ldconfig updates this file.

This is why I made the previous comment here https://forum.handbrake.fr/viewtopic.php?f=13&t=38624&p=183248#p182870 There are many things can go wrong in setting this up. Start out by showing us an activity log of HandBrake starting up. There might be some clue in that. This is also why I created a ...

The film tune is designed to work best with "film" sources. I quote "film" because it kind of begs the question, how does the encoder define what a film source is? The encoder makes some assumption about what the video "looks like". E.g. animation, and camcorder video have different characteristics ...

Any change in settings or source video can lead to Larger or smaller file size Lower or higher quality Slower or faster encoding time When doing comparisons, you need to change only one thing at a time. If you are changing a setting, use the same video source for your comparisons. The film tune coul...

You still have to install Intel MediaSDK separately and make sure the shared libraries it creates are somewhere the system can find them.

It hit the PPA about 20 minutes after I posted. So it's there now.

If you are using the GUI, activity logs for past encodes are saved. https://handbrake.fr/docs/en/latest/hel ... y-log.html

Correct me if I'm wrong, but UHD is not necessarily HDR. In fact, I believe HDR is still relatively uncommon in UHD releases? So HandBrake has UHD support thanks to some helpful contributions. We don't yet have HDR support, probably because it's a more difficult feature to implement. I haven't looke...

According to your log you didn't use VCE. Have you tried it? There should be an ETA at the bottom of the GUI window telling you how long it will take. I cant' say what to expect since I don't have VCE capable hardware, but it will be faster than the software encoder x265 that you used.