Closed steveowashere closed 6 years ago
@steveowashere My transcode-video
tool has been able to handle 4K input and output for some time. But even though, as you noticed, x264_10bit
can be used as an encoder, it's not available in current builds of HandBrakeCLI
, AFAIK. You would have to build a version yourself with that codec.
HDR output is not all that useful if you don't have an HDR-capable display. And can, as you noticed, sometimes look odd on non-HDR screens.
But 4K and HDR appear to be the future of video. They're just not all that accessible in the present. :)
Let me know if you have other questions.
It's good to know 10bit is supported by your program at least. I just checked and the nightly builds of handbrakeCLI have the ability to use x264_10bit encoding. But they are nightly builds, so I don't think that's the best solution.
HDR on the other hand, I'm not sure how that is handled by handbrake at the moment and I can't seem to find it in their documentation. From what I've gathered there is no standard for converting HDR to SDR and there are certain programs that get it pretty close, like MPV but it uses color grading and isn't 100% accurate. So when transcoding, I don't know if any of this will be taken into consideration or if going from HVEC HDR to x264
My main issue is that at some point in the next few years i'll upgrade my hardware to be able to take advantage of 4K HDR content. So do i start future proofing everything now and buying 4K blu-rays and transcoding them into something that can hopefully be played back normally on my SDR 1080p hardware or do I have to buy every movie twice, once in 1080p and once in 4k. This is my main dilemma at the moment.
Now i'm starting to understand the motto, 'Gramps don't beta.' :)
@steveowashere Yeah, the whole HDR thing is a bit confusing now. Hopefully all that is needed is 10-bit transcoding and a little metadata.
But you should just come to terms now with the fact that you'll have to re-transcode your library at some time in the future. :) If not for HDR, then for HEVC so you can make it smaller.
This is why I just transcode everything using --veryquick
. Why waste time now? Plus, I'm not transcoding for "archival" purposes. There's no such thing as an archival transcoding anyway. Your archive is your original rip.
This is why I just transcode everything using --veryquick
Yea, that's a good way to handle it. As you said, sooner or later everything will need to be transcode again anyway... I store all my Blu-Ray as ISO images on my home server anyway, so re-ripping isn't a huge deal. I'll do a few tests to see what works best with my Plex setup and take it from there. (I don't think Plex even fully supports HDR at this point to begin with.)
Anyway, thanks for indulging me once again, nice to get some other perspectives on how to handle these types of things.
@steveowashere No worries and good luck! I'll close this now but feel free to open other issues or even comment here.
Hello again!
I've gotten my hands on a few 4k blu-rays and I guess HDR and 10bit are the latest thing, I'm just wondering how video transcoding handles that? I don't have a 10bit or HDR display and I transcode my content to regular h.264. So am I missing out on anything by just transcoding to h.264? (i.e. the process from going to 10bit to 8bit )
I've noticed while watching processed 4K HDR 10bit rips of movies like Arrival and Blade Runner they are considerably more washed out in comparison to my older 1080p non-HDR and non-10bit rips.
Thanks for taking the time to answer 👍
Afterthought: Just noticed in the changelog that
x264_10bit
can be used, but i'm still not sure if that's relevant for my situation because I don't own any displays that are 10bit. I assume some 'downsampling' (probably not the right term) occurs if 10bit content is displayed on an 8bit display.