General H.264-to-H.265 for best fidelity & "no better"

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Locked
markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 4:16 am

I'm new to HandBrake. It's simultaneously wonderful and frustrating.

Probably everyone who reads this understands I-frames & P-frames & B-frames and decoding and all that. Decoding is fairly straightforward. The result of decoding is video frames, audio, and subtitles (content). The fundamental function of HandBrake is to encode that content according to the user's choice of encoder.

The objective is to produce an encoded stream that matches the content & no better. I write "no better" because one cannot improve on the source -- I of course disregard file size because I seek the best fidelity and "no better"; I don't want loss at all but I don't want file-size waste, either. H.265 is more efficient, and thus, H.264-to-H.265 transcode should produce smaller files, and that alone will satisfy me.

It occurs to me that if I take a 1080p24 H.264 M2TS source and transcode it to a 1080p24 H.265 MKV target, there is only one set of HandBrake settings that can do it with 100% fidelity and "no better". In fact, the source (1080p24 H.264 M2TS) really shouldn't matter. Whatever the source, given the decoded content, there should be one set of HandBrake settings that will produce the best (100%?) encode & "no better".

What are those HandBrake settings?

Of course there are many details involving filtering & block size-v-motion compensation &tc., nonetheless, assuming that I only transcode 'up' (H.264-to-H.265, for example), I contend that once the source has been decoded and a target codec has been chosen, there is one & only one set of HandBrake settings that will duplicate the source content & "no better".

Now, I can suppose that it's theoretically impossible to duplicate the source, even when transcoding 'up'. Is that so? I can suppose that I can only approach the source asymptotically; 98% ... 99% ... 99.9% ... 99.99% ... Is that so? It's easy to say that's so, but is it really so?

Now, suppose I knew how the source's H.264 encode had been set up, would I then be able to duplicate those settings for an equivalent H.265 encode? Is there an H.264-to-H.265 correspondance? Does HandBrake know what the H.264 settings were? I suspect not. But can HandBrake infer what the H.264 settings were based on metadata? I suspect so.

Currently, I have QP and the "Optimize Video" knobs to twiddle. They are mysterious to me and I'm tiring in the attempt, based on perceived video quality of test runs, to reverse engineer what they do and their effects.

Do 'you' have any thoughts? comments?

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 7:30 am

The source settings are mostly irrelevant because as you mention, the decoded picture is used.

If you're trying to minimize loss, throw more bits at the problem or more complex analysis at the problem or both. So, use a higher quality setting (lower QP or RF until visually lossless or to your liking) and use a slower encoder preset to turn on the bells and whistles for analysis (veryslow is very slow but maximally analytical).

Optimize is a handy tool for moving the MOOV atom at the end of an encode to the beginning of the file, which requires rewriting the file. It's mostly useful for progressive downloading over the internet and does not influence quality.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 7:42 am

I should also mention, with lossy codecs much is subjective. Your 99% and my 99% are not likely to correlate highly.

Most people strive for visually pleasing with reasonable file sizes and use a quality setting around or slightly better than what they determine to be visually negligible loss in motion on their devices. If you want perfect with zero loss, the only technical solution is to keep the source and/or remux it into a more suitable container.

The official presets with slight quality adjustments based on your preferences are designed to cover common use cases. See https://handbrake.fr/docs/en/1.2.0/work ... ality.html for quality setting recommendations. Exceeding the recommendations usually provides diminishing returns, much like your percentages above. Why spend hours more time encoding and/or waste more space for a fraction of a percent difference that's unlikely noticeable?

Storage is relatively inexpensive these days, so when in doubt, use high quality settings within the recommended ranges and stock up.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 8:26 am

Hi Bradley,

A 2 hour movie has 172,800 frames. That's a total of 537 GB of raw 4:2:0 YCbCr frames. Those frames were H.264 encoded, but that's irrelevant. Now that I have all I-frames, I want to H.265 encode them to reap the benefits of H.265's better motion compensation and more efficient B-frame compression but otherwise not waste final file size on resolution that wasn't in the source. How do I set up HandBreak to do it?

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 8:33 am

Also, I want to put the final video into a MKV wrapper so that I can integrate the audio channels (by name) and the subtitles. But that, of course, is irrelevant to the final objective of my previous message.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 8:58 am

Start with the official MKV presets, for instance H.265 MKV 1080p30. The encoder preset is "slow"; use a slower one if you can tolerate the encoding time. "placebo" is exactly that; academic only. "veryslow" is the slowest encoder preset useful for actual encoding. Then adjust quality within the range recommended by the article I linked.

Do note that the x265 encoder only really shines at ultra-low bit rate encoding (not what you're going for) and > 1080p resolution, such as 2160p 4K. So you might not achieve anything perceptually better than x264 by using the current state-of-the-art H.265 encoder, x265 (hint: it's based on x264). Despite access to a fast machine, I use x264 for 1080p encodes and below. Better motion compensation and b-frame compression likely do not apply across the board, meaning sure, with low bit rates things are improved but for archival purposes, perhaps not.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 9:45 am

Thanks so much, Bradley. You don't ignore my questions, and I appreciate that.
BradleyS wrote:
Wed Aug 14, 2019 8:58 am
Start with the official MKV presets, for instance H.265 MKV 1080p30.
That brings up the issue of pull-down, but I'll save that for the end. Right now, the source is just 1080p24.
The encoder preset is "slow"; use a slower one if you can tolerate the encoding time. "placebo" is exactly that; academic only.
"Placebo" is exactly what I did the first time I used HandBrake. The resulting video file was almost twice the size of the original. That did't make any sense to me. Afterall, even if HandBrake simply passed the original frames through, the target should have been approximately the same size as the source.
"veryslow" is the slowest encoder preset useful for actual encoding. Then adjust quality within the range recommended by the article I linked.
I really don't care about coding speed. I can be doing other things (like sleeping) while HandBrake runs.
Do note that the x265 encoder only really shines at ultra-low bit rate encoding (not what you're going for) and > 1080p resolution, such as 2160p 4K.
No, I'm not doing 4K and I'm not doing anything above p24. What do you mean by "ultra-low bit rate"? To me, "ultra-low bit rate" means ultra-high compression. That would be fine if, 1, the resulting video stream can be decoded in real-time (i.e., at p24), and 2, the video frames were the same resolution as the source. Or, by any chance, do you mean low frame rate (or tiny frames)?
So you might not achieve anything perceptually better than x264 by using the current state-of-the-art H.265 encoder, x265 (hint: it's based on x264). Despite access to a fast machine, I use x264 for 1080p encodes and below. Better motion compensation and b-frame compression likely do not apply across the board, meaning sure, with low bit rates things are improved but for archival purposes, perhaps not.
Okay, screw H.265. So, my next question is this: How can I persuade HandBrake to pass the H.264 source straight through without transcoding, yet put the result in an MKV package?

Regarding pull-down, does HandBrake do 2-3 pull-down or 3-2 pull-down? And can I control that?

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 10:00 am

The presets use peak frame rate by default. 24p is not conformed to 30p, but 60p would be.

Placebo is useless acadamia. Use veryslow. I forget exactly but the difference is so minuscule it's not worth the electricity. Even the people who wrote x264 don't use placebo.

x265 can make better looking video when you're shooting for super small files, which is what I refer to as low bit rate (data rate / bits per second). Think YouTube or worse, not archival.

HandBrake always re-encodes video. It sounds like MKVToolNix might be more to your liking. It's a muxer/remuxer, meaning it will copy tracks from one container to another without alteration.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 10:02 am

I can't answer your pulldown questions with accuracy, but it doesn't seem to apply in your case here.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 10:45 am

BradleyS wrote:
Wed Aug 14, 2019 10:00 am
The presets use peak frame rate by default. 24p is not conformed to 30p, but 60p would be.
I don't use the presets. Besides that, I haven't a clue what "not conformed to 30p" means. Also, I only work in constant frame rate.
Placebo is useless acadamia. Use veryslow. I forget exactly but the difference is so minuscule it's not worth the electricity. Even the people who wrote x264 don't use placebo.
Well, in pharmacology, "placebo" is a therapy that employs a fake (pharmacologically ineffective) treatment that the patient-subject doesn't know isn't a real threatment (as a 'control' subject in a 'blind' experiment) or that the patient-subject knows is fake but believes will improve their condition anyway (as a matter of faith or psychology as a test of whether 'belief' can be a valid treatment method). What does "placebo" mean in the realm of video? I imagine it means that no processing takes place or only fake processing takes place. How that applies is anyone's guess. I don't know.

Of course, none of that explains a 2x increase in file size. In fact, I think nothing explains a 2x file size except maybe that the x265 library doesn't work right.
x265 can make better looking video when you're shooting for super small files, which is what I refer to as low bit rate (data rate / bits per second). Think YouTube or worse, not archival.
So, low bit rate means highly compressed, doesn't it? I don't mean that argumentively. Higher compression produces 'thinner' streams, right? And 'thinner' streams come from smaller files, right? Or am I misunderstanding you?
HandBrake always re-encodes video. It sounds like MKVToolNix might be more to your liking. It's a muxer/remuxer, meaning it will copy tracks from one container to another without alteration.
Thanks for that. I will look into MKVToolNix.

Regarding pull-down. I have an i30 video from a professional studio that was made from a mix of i30 sources (NTSC TV) & p24 sources (film). If the detelecined result is saved as p24, all is joy. But if the detelecined result is then converted to i30 by HandBrake, the transcoded, i30 video displays significant motion-object combing. From that experience, I have conjectured that HandBrake is doing 2-3 pull-down. but I'm not sure and have no means of confirming it. I'd hoped you would know.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 10:55 am

To flesh out the points (and confusion) about file sizes and low bit rates: MPEG-2 is ~10x compression, right? And MPEG-4 is about twice that, right? Now, suppose someone came up with a compression scheme that was 100x. That would definitely mean lower bit rate and smaller source video, but would it mean lousy picture? No.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 11:16 am

Low bit rate means highly compressed. Less data / fewer bits per second. x265 is more efficient than x264 for high compression. Where less compression is desired to maintain higher quality, not as much.

Peak frame rate, in the case of 30 fps peak, means that any portion of the video at or below 30 fps will be preserved, and any portion above 30 fps will be limited to 30 fps. Conformed = converted = dropping frames or however you want to look at it.

When using detelecine, you will probably have better luck with setting the frame rate to Same As Source and ensuring Variable Frame Rate (not constant) is selected. This allows the 24p portions to remain 24p and the 30p portions to remain 30p.

Provide an activity log and we can probably better explain the double file size. Chances are you used a quality setting exceeding the recommended range.

Generational quality loss / size inflation with lossy codecs is a thing; it actually takes more data to reproduce a compressed source perfectly due to quantization error and other techy things. Further, if the source video has an average QP of 20 and you decode it and ask to encode it at QP 10, then yeah it's going to get bigger. The quality metric is relative to the uncompressed picture.

Placebo is named as such because you can't tell the difference between it and veryslow. ;) It disables some shortcuts in analysis that have proven to be inconsequential.

nhyone
Bright Spark User
Posts: 225
Joined: Fri Jul 24, 2015 4:13 am

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by nhyone » Wed Aug 14, 2019 3:47 pm

markfilipak wrote:
Wed Aug 14, 2019 10:45 am
I don't use the presets.
Why not?

Super HQ 1080p30 Surround preset is a good place to start if you want to be transparent to the source.

It is as simple as that.

Common misconceptions:
  • Presets is for beginners
  • I want to control bitrate, so use average-bitrate
  • There is a lossless CRF, I'm going to use it!
  • Use placebo encoder preset for maximum quality
  • Maxing out reference and b-frames
  • Setting high me-range
  • H.265 (x265) is better than H.264 (x264)
BradleyS wrote:
Wed Aug 14, 2019 11:16 am
Placebo is named as such because you can't tell the difference between it and veryslow. ;) It disables some shortcuts in analysis that have proven to be inconsequential.
This is true for x264, but not for x265. Didn't they move placebo to veryslow in v3.0 and make placebo even slower?

Anyway, it is academic for me because the slowest I can tolerate on x265 is slower preset. Now that slower is the old veryslow, my threshold is somewhere between slow and slower.

The x264 presets don't really affect quality much. Ultrafast to veryslow, they are very close. It is not true for x265. The faster presets tradeoff (significant) quality for speed. I won't use anything faster than slow preset on x265. YMMV.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 3:53 pm

Placebo for both encoders means no early terminations in analysis.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 6:01 pm

nhyone wrote:
Wed Aug 14, 2019 3:47 pm
Super HQ 1080p30 Surround preset is a good place to start if you want to be transparent to the source.
Well, starting at the leftmost tab
Dimensions: Cropping is set to 'Automatic', but I want 1920x1080 soft matted.
Filters: Decomb, but my source is not interlaced.
Video: H.264, but I want H.265(QSV).
Video: 30 fps, but my source is p24.
Video: Variable frame rate, but I want constant frame rate.
Video: ...the "Optimize Video" settings? I have no clue what they do, and when I change to H.265, they change -- they are modal and depend on codec.
Audio: Only the 1st audio stream is there.
Audio: The 2nd audio stream, DTS-HDMA 7.1 is missing.
Audio: AAC is used. I don't want AAC.
Audio: Bit rate is set to 160bps, huh?
Audio: Output is 2.0, huh?

Why would I (or anyone) want to use that preset?

User avatar
JohnAStebbins
HandBrake Team
Posts: 5456
Joined: Sat Feb 09, 2008 7:21 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by JohnAStebbins » Wed Aug 14, 2019 6:25 pm

Video: H.264, but I want H.265(QSV)
If you want "best fidelity" then you don't want to use QSV or any currently existing hardware encoders. None of them equal the quality that the software encoders are capable of.
Video: 30 fps, but my source is p24.
FYI, that's 30 fps peak which means it will match the source framerate up to 30 fps. Framerates higher than 30fps would result in dropped frames.

Given your preferences, you appear to be shooting for something that falls between HandBrake's production presets and the general presets categories. So yeah, none of them are all that close to what you want. The presets are suggestions for certain use cases, but they don't cover every possible use case.

musicvid
Veteran User
Posts: 3319
Joined: Sat Jun 27, 2009 1:19 am

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by musicvid » Wed Aug 14, 2019 7:02 pm

It occurs to me that if I take a 1080p24 H.264 M2TS source and transcode it to a 1080p24 H.265 MKV target, there is only one set of HandBrake settings that can do it with 100% fidelity and "no better". In fact, the source (1080p24 H.264 M2TS) really shouldn't matter. Whatever the source, given the decoded content, there should be one set of HandBrake settings that will produce the best (100%?) encode & "no better".

What are those HandBrake settings?
Those settings don't exist. There being no clear lines between suboptimal, optimal, and superoptimal bandwidth for a given source, it does not bear out a top-down solution, as you propose. All transcodes are "no better" than the original. So your perspective may benefit from looking at the inverse goal, in this case "no worse."

Now we have put this question into the domain where it truly belongs, which is subjective, temporal, and highly personalized. If 100% of viewers consistently identify a lower-bitrate version as looking "worse." there is a good chance it is suboptimal. If the output size exceeds the source, it is obviously already superoptimal, with no identifiable gains from artificially inflated bandwidth. That leaves us a pretty big workspace. Somewhere in there lies one's personal, nonassignable notion of "optimal."

So how do we quantify the optimal numbers for our personal viewing zeitgeist?
For me, on my system, and when my eyes were younger, I defined my ideal "sweet spot" as "the highest CRF that maintains a 0.995 SSIM with a corresponding PSNR of >=35dB. Once this point is established, I can compromise in some situations without fear of wrecking my encode. This test has never failed my eyes, and I am certain it is not gross overkill, since it corresponds to CRF 18-22 (full HD x264), an agreed sane encoding range among seasoned users.

It should be obvious by now, that your idealized "no worse" index point is a moving target, not in a single setting that works for all source, viewing environments, eyes, and perceptions, which are almost entirely dependent on expectations, lacking any evidence of human ability to objectify visual discrimination at the resolutions being used today, even HD.

My point? The "one set of HandBrake settings that can do it with 100% fidelity and "no better" will not exist until you create it for you, without requiring concurrence from the rest of the world. That way, you will not be disappointed.

markfilipak
Regular User
Posts: 131
Joined: Thu Aug 01, 2019 8:58 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by markfilipak » Wed Aug 14, 2019 11:08 pm

Hi musicvid. Thank you for your thoughtful comments. Thank you for taking the time.
musicvid wrote:
Wed Aug 14, 2019 7:02 pm
It occurs to me that if I take a 1080p24 H.264 M2TS source and transcode it to a 1080p24 H.265 MKV target, there is only one set of HandBrake settings that can do it with 100% fidelity and "no better". In fact, the source (1080p24 H.264 M2TS) really shouldn't matter. Whatever the source, given the decoded content, there should be one set of HandBrake settings that will produce the best (100%?) encode & "no better".

What are those HandBrake settings?
Those settings don't exist.
Well, HandBrake surely doesn't have them.
There being no clear lines between suboptimal, optimal, and superoptimal bandwidth for a given source, it does not bear out a top-down solution, as you propose.
I don't know why you say that.
All transcodes are "no better" than the original.
Okay, point to you. By "no better" I mean not bigger, not bandwidth wasting. That's why I put "no better" in quotes. No transcode can be better than the source. It can be different, It can be softer. It can have 'sharper' (higher slope) edges (with resulting Fourier artifacts). It can have deeper blacks (with less color gamat). All twiddling incurs loss, but the loss may be acceptable. I'm not seeking twiddling. I seek to avoid twiddling.
So your perspective may benefit from looking at the inverse goal, in this case "no worse."
Every transcoding is worse. Do you understand entropy? Every source decode yields I-frames that are only approximations of the original production (film or video). That's the nature of lossy compression. But if an existing decode is already what I want, I think it should be possible for HandBrake to transcode it intact, with a click of a button, or with a canned preset (either worked out and automatically generated based on metadata).
Now we have put this question into the domain where it truly belongs, which is subjective, temporal, and highly personalized. ...
I fail to understand why anyone who is informed could/would write that.

Users who are happy with the source's video rendering should be able to transcode it at the existing quality with a click of a button. Kindly don't misconstrue what I write. I adore HandBrake. I think it's an excellent ffmpeg front-end. But I'm sure that the developers acknowledge that it could be improved.
If 100% of viewers consistently identify a lower-bitrate version as looking "worse." there is a good chance it is suboptimal.
For a given encoder, lower bitrate will always be sub-optimal. But why would someone "transcode" from a given coder @ a some inherent resolution to the same coder @ the same resolution but with different metrics -- what those metrics are is not revealed by HandBrake -- ...how would any saavy user expect anything that is not suboptimal?
If the output size exceeds the source, it is obviously already superoptimal, with no identifiable gains from artificially inflated bandwidth.
"Superoptimal"? There's no such thing. It's a matter of physics & thermodynamics (i.e., entropy as incorporated into information theory).
That leaves us a pretty big workspace. Somewhere in there lies one's personal, nonassignable notion of "optimal."
"Optimal" means identical to the source in every way.
So how do we quantify the optimal numbers for our personal viewing zeitgeist?
Your premise is specious. Identical is identical. Your argument assumes that the user (me) wants to change some video attribute(s). I don't. I'm not being simply argumentative. I'm happy with the source. I want to duplicate it but using a newer, more efficient coder. I have no way to do that. HandBrake has some excellent controls -- they are somewhat mysterious, but with some twiddling, they can produce some awsome results. But for me, having to run HandBrake over and over while twiddling one control after another in order to suss out what happens in the output... It's just too much considering that I'm already happy with the source. To put it succinctly, I assume that an H.264 encode contains metadata that was used to control (parameterize) the H.264 decode. The question is: Can that metadata be utilized to automatically set up a subsequent H.265 encode of the same video?
For me, on my system, and when my eyes were younger, I defined my ideal "sweet spot" as "the highest CRF that maintains a 0.995 SSIM with a corresponding PSNR of >=35dB.
Assuming for the moment that structural similarity & signal-to-noise are valid metrics and are comprehensive, do you have such tools? Can you point me to them? Thanks! (Such tools would go some of the way to attaining my goal.)
Once this point is established, I can compromise in some situations without fear of wrecking my encode. This test has never failed my eyes, and I am certain it is not gross overkill, since it corresponds to CRF 18-22 (full HD x264), an agreed sane encoding range among seasoned users.
Well, I have no doubt that some useful rules-of-thumb have been developed. And I'm sure those rules-of-thumb presets were painstaking found and that they do work. But there's no way to tweek those preset rules-of-thumb in an objective manner because HandBrake either doesn't 'know' the heuristics or doesn't incorporate some image analysis. That's understandable. HandBrake is a work-in-progress.
It should be obvious by now, that your idealized "no worse" index point is a moving target, not in a single setting that works for all source, viewing environments, eyes, and perceptions, which are almost entirely dependent on expectations, lacking any evidence of human ability to objectify visual discrimination at the resolutions being used today, even HD.
I'm not asking for a one-size-fits-all solution. Such a solution could exist, but probably doesn't, at least not easily. I simply want to produce an H.264-to-H.265 transcode that produces an identical video with identical properties. I don't see how that is not possible, and I don't see how that will forever be subjective.
My point? The "one set of HandBrake settings that can do it with 100% fidelity and "no better" will not exist until you create it for you, without requiring concurrence from the rest of the world. That way, you will not be disappointed.
Sorry. You kinda lost me there. I don't expect/require concurrence from anyone.

Bradley has suggested that I look into MKVToolNix, a tool that will simply put an existing H.264 encode into a new container (in my case, MKV). That means not going to H.265. but it would allow me to avoid all the cruft in a DVD/BD ISO rip and make those movies & bonus features that I actually want available to a file manager and one-click away from playing via MPV. That alone would conserve some space on my media server, but transcoding to H.265 would be better.

If I try HandBrake transcodes over and over while viewing the results in an attempt to asymptotically 'find' the true, 1-to-1 transcode (which surely exists), will I catch everything that needs to be seen? Or will I later discover some motion artifact that spoils the show in the future? If HandBrake had a 1-to-1 duplicate capability, that wouldn't happen.

I began this topic requesting a HandBrake setting that will produce a 1-to-1, H.264-to-H.265 transcode; it seemed a reasonable request. I think such a goal is attainable and that, as a bonus, such an automatic function -- perhaps via metadata, perhaps via automatic analysis -- would provide a welcome preset starting point for those people who want to further tweek the preset to attain some subjective objective. I do not seek such a subjective goal, but others may (or surely will).

Does an H.264 source contain metadata that is used to set up decoding? I can't conceive that it doesn't, but I don't know. Could that metadata be utilized to set up an H.265 encode to duplicate the source? I don't know, but I think it's worth investigating.

Thanks for reading all this.

User avatar
BradleyS
Moderator
Posts: 1672
Joined: Thu Aug 09, 2007 12:16 pm

Re: General H.264-to-H.265 for best fidelity & "no better"

Post by BradleyS » Wed Aug 14, 2019 11:29 pm

"transcode it intact" <- This is remuxing. HandBrake is a transcoder, MKVToolNix is a muxer.

"But why would someone "transcode" from a given coder @ a some inherent resolution to the same coder @ the same resolution but with different metrics"

Because mature encoders like x264 can typically reduce the size of high bit rate (low compression) video further with minimal loss in quality. It's not uncommon for a 40 GB source to reduce to under 10 GB with negligible loss in visual quality.

"I began this topic requesting a HandBrake setting that will produce a 1-to-1, H.264-to-H.265 transcode; it seemed a reasonable request. ... I do not seek such a subjective goal"

The entire point of lossy encoding is psychovisual maths to trick the subjective mind. What you ask is not possible. The standard guidance I have already detailed.

I'm locking this thread as it's super broad and likely to digress, distract, and possibly turn argumentative. I hope the information has been useful, and if you have more specific questions, please provide an activity log for a test encode so we can make further recommendations.

Locked