HandBrake

Or mkvmerge CLI, if your output is MKV.

Irrelevant. Unless you're encoding raw uncompressed video, even a mechanical hard drive will have no impact on encoding performance whatsoever.

Detelecine and Deinterlace/Interlace Detection aren't directly related.

GUI hasn't been angry for a while. Got upgraded to fresh, calm and reasonably happy pasta.

Interlace detection is off in your log. Probably the Windows GUI sanitized it for you.

Well, as you put it in the topic title, they are encoding options -- if you can't see the difference, don't use them.

We just explained that encoding an 8-bit source using a 10/12-bit encoder improves compression efficiency. So there is a use case…

Woodstock wrote: ↑

Tue Sep 03, 2019 1:25 pm

"GPU encoders" is a misnomer - the video encoding hardware is separate from the GPU, so GPU processors and memory aren't used.

Erm the VRAM is used, the hardware-accelerated video encoder doesn't have any direct access to RAM that I know of.

No importance whatsoever. HandBrake doesn't need BD-J as it doesn't display any Java Blu-ray disc menus or any related functionality.

Not in terms of compatibility, no. I would stick with 10-bit, AFAIK there's very few devices with hardware-accelerated 12-bit decoding support. So IMHO 10 is better than 12

Improves compression efficiency a touch due to reduced internal rounding errors. It may also slightly reduce color banding issues.

It might make sense to encode to e.g. AAC+E-AC-3 at 1536 Kbps, to preserve just a bit more of the original track's audio quality. You could even select higher bitrate, but with diminishing returns and larger output file sizes, and anything above 1536 Kbps would exceed the maximum S/PDIF bandwidth, i...

Can you be more specific about what you mean by "damage"? A screenshot perhaps?

Use MKV output.

They don't really say what settings they're using, but the results have to be more useful than Anand's -- last I checked the latter x264 and x265 benchmarks, they made no sense whatsoever.

Locked for rule violation.

That's an x264/x265 specific feature. Other H.264/HEVC encoders don't insert those kind of SEI messages in the bitstream.

Yeah, for distribution, you can't just disable stuff because your machine doesn't support them, there is one build of HandBrake for everyone. Personal builds are different of course.

libhb/common.c somewhere, off the top of my head.

Yeah but those typically aren't scanned (IIRC), there are no forced flags to find. The video parsing requirements comes from something else, j45 probably remembers.

No, we go through the video stream for the subtitle pass scan, it is needed (for a reason I cannot remember). But we never actually decode it (hence the 0 decoded frames), only parse it.

The stats for the main (encoding) pass are: [07:02:39] dca-decoder done: 323977 frames, 0 decoder errors [07:02:39] dca-decoder done: 323977 frames, 0 decoder errors [07:02:39] ac3-decoder done: 107993 frames, 0 decoder errors [07:02:39] ac3-decoder done: 107993 frames, 0 decoder errors [07:02:39] h...

Yeah, the only thing written to disk is the output file and the 2-pass stats file (only if you're doing two-pass). Neither of them are disk intensive enough to warrant an SSD.

The output of HandBrakeCI --help will list all available available encoders. IIRC it's vt_h265 but I can't remember for sure.

s55 wrote: ↑

Tue Aug 06, 2019 2:47 pm

- ffmpeg master -> Seems to recognise the file now, and will run the encoder but it's not producing useful video output.

Using FFmpeg master's libavcodec in a build of HB or ffmpeg command-line? Latter works for me, both ffplay playback and ffmpeg remux to Matroska then playback in VLC…