www.makemkv.com

preserve wrote:if you output HEVC/H265 (the codec used by UHDs), Handbrake does retain the Rec. 2020 HDR color space.

preserve wrote:Although both have the WCG 2020 color space, the original MakeMKV file has a pixel matrix of yuv420p10 while the Handbrake-converted MKV has a pixel matrix of yuv420p.

Woodstock wrote:the internal work path is only 8-bit, even on the nightly builds with 10- and 12-bit output support.

preserve wrote:I was seeing bitrate spikes of 65+ on Passengers (someone else mentioned in another thread that they were seeing as high as 78). Those are the parts my laptop was stumbling on. At other times, the bitrates can be quite low.

For a 2-pass VBR encode, Handbrake's average bitrate setting does not enforce a maximum - even with a low average, those high spikes were still occuring.

I was getting smooth playback results by using 25000 as the average bitrate and then adding the following settings manually into the provided input box: "vbv-maxrate=30000:vbv-bufsize=40000"

Low Winter Sun wrote:Nvidia Shield with Kodi or SPMC makes a great Media Center. No lag on playing H265 except at some of the most absurd rates that you can find with these Jellyfish test suites.

http://jell.yfish.us/

Unicron99 wrote:Very interesting topic, I was able to process the Martian Extended Edition UHD by using the keydb.cfg method in this forum with Makemkv 1.18. I have a i-7 7820k overclocked to 4.6Ghz and on a h.265 encode (Auto Passthru AC3 audio, default h.265 settings, rf 23, h.265 encoder set to very fast, 3 subtitle tracks) it took over 6 hours to encode in Handbrake. I am interested in anything that might decrease encode time without drastically affecting quality.

preserve wrote:Although both have the WCG 2020 color space, the original MakeMKV file has a pixel matrix of yuv420p10 while the Handbrake-converted MKV has a pixel matrix of yuv420p.

ffmpeg -i $inputpath -pix_fmt yuv420p10le -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:hdr-opt=1:repeat-headers=1:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)W P(15635,16450)L(10000000,500)" -c:a aac -b:a 256K -y "$outputpath"

skiddy wrote:Ouch. I only have a 4790K at 4.6gig so dread do think how long it will take. Out of interest, what was the original, Vs. final file size?

One thing that I omitted in my previous post was suitability of Handbrake for processing UHD rips due to the 8-bit pipeline.

starmax wrote:Thats about the right size if you are pulling in all the audio. Every movie is different, but most will be 50-80GB.

For me, I use MakeMKV to pull the video track and the main audio track and then don't re-encode it unless the source is VC-1, MPEG2 or I want to burn in subtitles. I am less concerned about the size since I have a 20TB RAID for my Plex Media Server. Also, I read that Handbrake will always convert HDR to SDR unless you are using one of their experimental nightly builds.

Transcoding audio, even DTS, shouldn't tax your i7. My PMS uses an i5-2500k, and it only struggles with transcoding 4k down to 1080p. I have read some stuff in the Plex forums that playback of HDR is a bit messed up at the moment, which some clients triggering a full transcode of the video and audio if source requires any kind of conversion. Not sure if that is your problem or not, but you can check the Plex Web status when playing back the DTS stream to see what all its transcoding.

JGrant06 wrote: Thanks for the info. Here is an update:

I just ripped Blade Runner: The Final Cut and was 45 GB. I have a 10TB RAID but am already using 6 TB so I know I can't do too many 70+GB movies. I did re-rip La La Land without the Spanish and French audio tracks and only lost a few GB which is fine. What do you use as a backup? I am currently using a 7TB external drive and have an additional at my parents. I found more articles also indicating that any re-encoding in Handbrake will remove the HDR, so not doing that.

The transcoding doesn't tax my cpu but it seems to cause the video/audio to lag behind. I have Cat6 running throughout my house except for a Cat5 cable (pre-run from Fios) running from outside to inside my basement. I think this may be the bottleneck and cause of the lag, but do not have another 4k monitor/tv to test. I had the same thing happed with La La Land if I chose an audio track my server had to transcode. My cpu on my server is being utilized very little to transcode audio so I know it is not the bottleneck. I can fix the problem by getting another audio track of Dunkirk but worth a note for any others noticing lag with a 4k direct stream through Plex.

I did successfully watch Blade Runner: The Final Cut and La La Land (both UHD) all the way through and did not notice any buffering. My server did not have to transcode audio either time.