HandBrake

Absent an authoring error, which I don't think is the case here, the grain and/or softness is the intent of the creator. I'd drop the filtering, tune grain, and just eat the larger file size output to preserve what it's supposed to look like. OTOH if you want the grain gone, try hq3dn instead of nlm...

is listed as a "known broken" distribution. :lol: :lol: :lol: It's broken only to incompetent users who don't know how to install and/or use it. Arch is idiot proof but it's not idiot friendly and that's most probably the reason it has been listed as a "known broken distribution"...

How about this video you already posted the log for?

How many frames do you think your input is?

You can choose any preset with a 4K or higher resolution target, a preset with no resolution target, or adjust the resolution target and save your own preset.

Yes you can.

The source file you're providing to HB.

How many frames do you think your input is?

--enable-vce in your ./configure

HB's ability to start an encode at a specific time depends on HB's ability to get to that point in the video.

You'll need to use something intended for DVD ripping to get a clean copy, or a copy with the error portion removed.

HB isn't for ripping disks; use MakeMKV instead.

If you're going to edit later, keep the originals or make an editing-friendly (which will probably not be much smaller) encode with the Production presets. For lossless merging you can use ffmpeg or mkvmerge or probably one of the mp4 muxers for your platform. You can do this with the M2TS files or ...

HandBrake is highly configurable to provide a wide variety of speed, size, and quality tradeoffs; so any difference in speed is trivial to address.

For editing, the Production presets in HB would be a good starting point.

H.264 has a maximum frame size of 139,264 macroblocks (16x16). 5400x2700 is 223,446 macroblocks, so that won't work.
H.265 has a maximum frame size of 35,651,584 pixels (well, luma samples, but same here with HB), which 5400x2700 fits in.

Either of those options are H.265 encoders.

HB thought it had reached the end of the video stream. Video security systems are notorious for malformed output.

Also the source container says it's only 3.7 seconds of video:

Code: Select all

Duration: 00:00:03.71, start: 0.000000, bitrate: 2550 kb/s

Yeah, I've restarted and not going to lie, I've never used event viewer but when I checked nothing seems to show up for handbrake. But I think I found a solution after trying other presets and even using an older version that was actually working albeit on another pc/laptop. It seems like handbrake...

Define "crash" in this context. Machine stops working? Program closed by operating system? System slows to a crawl? Rude noises emanate from the case as smoke rises? The log just stops, which normally would mean that the operating system detected a problem. That would create a system log ...

With an RF that low, you're better off with keeping the 1080p frame size and going to an RF in the low 20s.

Although encode time will be slower unless you pick a faster preset; about one faster on the list should do it.

Sure, with vbv-maxrate and vbv-bufsize.

Sure, it will get you some reasonable result. 95% confidence within 1%? Probably not. But why are you doing this in the first place? If you want to keep the grain, you should use the grain tune, and expect large output files. If you want to obliterate the grain, use nlmeans filter with the grain tun...

The big question is... why?

Your source file doesn't have storage = display, so why would your output?

Fairly certainly you changed the encode settings, or the input file wasn't what you thought it was.

That's why we have to see logs, users can't reliably articulate what they actually did.

Rip with MakeMKV, then use HB if you want it.

Slow-mo isn't the problem, but there's a lot of predicted or bi-predicted frames in the small H.264 version, which the editors struggle with for decode performance.

Since this relates to a specific problem with a specific encode, post your encoding log.