Storing videos as H.265 or H.264

Processing in Plex… Okay, it’s ready to flip between versions.

Not a huge discernible difference. There is just a bit of difference, but nothing that you can put your finger on.

I checked for differences on my mobile and then desktop.

So yeah, you can save a good deal of space that way. I’m no where near out of space, but if space is an issue, and your eyes won’t scream at you for a minor change, it’s the route to go for space savings. :slight_smile:

You can fiddle with a ‘medium’ LapSharp filter too.
It works great, but my default profile has it as ‘light’ - you know, just in case.

Don’t use any filtering for HD stuff.
It doesn’t help that much and it adds months to the encode time… years for 265.

:smiley:

1 Like

Thanks for your assistance. HB is a beast if you’re just poking at it without knowing what to fiddle with. Chances of getting anything remotely close to being suitable are nil to none.

Appreciated. :slight_smile:

1 Like

… and ya know…

950 is my TV Show bit rate.
A Movie I’d give 1250-1450 - just 'cause it’s a movie.

If you’re sporting young eyeballs and a decent display - you may need more bit rate.
240 Second ‘Previews’ in an Other Videos Library really are the way to go to find what works best for YOU.

Ahh. That’s good to know. Maybe I’ll toss around one of those bitrates or a bit higher just to see what it’s like.

Good tip on the other library. :wink:

Yea man, you can drop those 4 minute previews in an Other Videos Library and they’re almost immediately available to watch on everything you got.

4 minutes give you a few scenes to look at and you can make spot checks in different places - like static or action scenes.

Rename 'em what they are - like:
480p 1250 Lapsharp Medium
you’ll know exactly what you’re looking at.

1 Like

Unfortunately, I have to completely disagree with you here… I have spent hours running multiple tests on various content, and it definitely makes a viewable difference.

Firstly, 10Bit tends to do better at reducing banding. This is not only a given, I have proved it to myself and my own eyes.

And secondly, as mentioned before, you get the same quality at roughly half the bitrate, and that matters both on storage space, and a remote user streams from me.

Some things are subjective, but some are simply fact…

I’ve heard people say things like that before, and normally they are self employed and everything boils down to how much they normally get paid.

In this regard, that is all irrelevant!

Once you have figured out the processes involved, you just Queue 'em up and let 'em go… Your time isn’t really the issue here.

Again, depending on all factors involved such as server capabilities, client capabilities, internet connection at both ends, the difference is indeed worth it.

And as far as I’m aware (but I might be wrong here) all UHD BluRays are now H.265 by default ?

You’ve said this a few times in this post, but I cannot figure out how you’ve come to that conclusion!

Again, you achieve the same quality at half the bitrate… REGARDLESS of material… It doesn’t matter if its SD, HD, UHD… The same applies… Same quality, at half the bitrate.

This means that once you have settled on your “preferred” H.264 bitrate values, depending on the material, opinion and your eyesight, you can now more or less half that with H.265, gain some space back and lose absolutely no quality.

The point above was that you don’t gain another 50% when encoding DVD source material in h265 over h264 (neither as file size reduction nor quality improvement). In fact, most of the time the differences are marginal as the h264 encoders are highly optimized.

Then again… I won’t stop anybody from following their encoding path of choice.
If all your client devices can deal with h265 you should be good anyway.

Well, I don’t know what to tell ya other than this hasn’t been my experience so far. In pretty much every example I have tried, I have ended up with the same quality at half the bitrate.

I’ve even had some content that I came across, that is 640x480 at 450 Kbps x264, and once converted to 225 Kbps x265, the video track was roughly half the original size and there was absolutely no difference in quality.

And I’m saying this because I have done it, again and again and again…I have been running 2 twin Xeon HP ProLiant servers for over 2 years, both running conversions, and each and every time I achieve exactly the same result… Regardless of the content.

However I will certainly concede to the notion that people eventually settle on their preferences, and once they are happy with that, then all’s good with the world :smiley:

Blockquote

You couldn’t be more wrong in your assumption of how I work and get paid. Someday, you’ll figure out that time does equal money, and everything has a cost to benefit ratio.

Simple math here:

Conversion time ~40 minutes per movie average based off of the experiment done today just bit starving to h.264. h.265 adds even more time.
Collection = greater than 800 movies but we’ll just use 800 for simple math
40*800=32,000 minutes
32,000 minutes is 533.33 hours
533.33 hours is 22.22 straight days of 100% cpu use

Which means 22.22 straight days where I can’t:

  • DVR record / remove commercials because the CPU is maxed out
  • I can’t stream anything that would cause transcoding without issues - sorry remote users, you’re out of luck
  • Electric bill goes up double normal cost for this server. ~90w idle, ~180w while cpu pegged.
  • Cooling bill goes up, cuz that amount of CPU work is going to heat that room

That’s a heck of a lot of inconvenience, and cost, to try to to claim that a $125 drive is more expensive, and that still applies if I mirror the drive for another $125. I can work a few hours of my regular job, and pay for that drive and be done with it. Time is money, and is surely not irrelevant.

Well I guess we’re both coming at this from 2 completely different points of view, and more importantly, objectives.

From my point of view, time is irrelevant and I couldn’t care a less about the extra few hundred £’s a year in my energy bill.

However just one last point to make… By default, the Handbrake process runs at “Below Normal Priority”, so it shouldn’t interfere with anything else your PC may be doing, and based on experience so far, I have certainly found this to be the case.

1 Like

You are correct, I did forget the process priority setting. So transcodes, dvr, etc would work at the cost of a longer batch conversion time if it were interrupted.

For me, it’s all about Direct Play and a file small enough not to make a nuisance of itself 'cause it’s 5 times larger than it needs to be for the Juicetown Maulers.

I can create 265-10 bit DVD encodes in 4 hours, or the more ‘reasonable’ 40 minutes above. They’ll both look exactly the same, but one might be a few MB smaller and contain placebo bit rates myself and my gang of retired Gopher Smashers stopped seeing 40 years ago - the other flies through the air with the greatest of ease (like those daring young men on the flying trapeze) and I can make 4 for the price of one - in the limited time I have left.

Personally - I’d like to be doing something other than watching Handbrake crawl through a DVD episode when my bucket is kicked - FOR NO GOOD REASON!

Here is a good reason tho:

General
Unique ID                                : 221082455013390369121427916987312424855 (0xA652EE99720F6E05C78723D26700C797)
Complete name                            : D:\Handbrake Dumps\Twin Peaks - S03E01 - Part 1 My Log Has a Message for You.mkv
Format                                   : Matroska
Format version                           : Version 4
File size                                : 710 MiB
Duration                                 : 1 h 0 min
Overall bit rate                         : 1 639 kb/s
Encoded date                             : UTC 2020-07-15 22:31:38
Writing application                      : Lavf58.42.100
Writing library                          : Lavf58.42.100
ErrorDetectionType                       : Per level 1

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L4@Main
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 1 h 0 min
Bit rate                                 : 1 222 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Original frame rate                      : 23.976 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Stream size                              : 530 MiB (75%)
Writing library                          : x265 3.2.1+1-b5c86a64bbbe:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
Encoding settings                        : cpuid=1064959 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=5 / lookahead-slices=6 / scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=16 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / no-signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=0 / subme=0 / merange=57 / temporal-mvp / no-hme / no-weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=2 / selective-sao=0 / early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=1250 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
Language                                 : English
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : Identity
matrix_coefficients_Original             : BT.709

Audio
ID                                       : 2
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Commercial name                          : Dolby Digital
Codec ID                                 : A_AC3
Duration                                 : 1 h 0 min
Bit rate mode                            : Constant
Bit rate                                 : 384 kb/s
Channel(s)                               : 6 channels
Channel layout                           : L R C LFE Ls Rs
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 SPF)
Bit depth                                : 16 bits
Compression mode                         : Lossy
Stream size                              : 166 MiB (23%)
Writing library                          : Lavc58.77.101 ac3_fixed
Language                                 : English
Service kind                             : Complete Main
Default                                  : Yes
Forced                                   : No

Menu
00:00:00.000                             : :00:00:00.000
00:03:41.638                             : :00:03:41.638
00:18:22.393                             : :00:18:22.393
00:24:28.592                             : :00:24:28.592
00:34:35.574                             : :00:34:35.490
00:45:16.505                             : :00:45:16.505
00:58:41.643                             : :00:58:41.601

That one is still warm and took about an hour and 15 minutes - not too bad - and worth it while you’re watching it (but doesn’t do a thing to bring Lynch’s Plot into focus - maybe the 4th viewing will reveal something the first 3 didn’t).

But if ‘your way’ floats your boat - bon voyage.
Youth is wasted on the young.

1 Like

I am fortunate enough to have sufficient upload bandwidth to not have forced transcodes from the server side. I can’t rule out transcoding by remote clients I can’t control, but the frequency of that is trivial. So for now at least, my current setup works. I can only guess that as time progresses and people upgrade their clients that this would improve.

That does not discredit the work that can be done to reduce bitrate and put into a a more compatible format. If I had more struggles with streaming, I would probably do more to convert my library. But as is, 40mbit upload is more than sufficient for the media I host and the people I share with. If I ever get into Bluray media, this topic would surely need to be revisited and implemented. Now I have a viable guide to do so. :slight_smile:

2 Likes

I headed that assumption off at the pass - by buying a Roku Ultra Refurb for ALL ‘The Juicetown Maulers’, had Amazon ship them where they needed to go, then I showed up for The Spring Picnics at various places in North Eastern America (and West Virginia) to hook them all up. The 'Mauler’s paid me the $65 I gave for their ‘Refurbs’ and there was no upgrade drama.

I loathe unnecessary Drama - in the ranks - or during encodes.

1 Like

You’re making me look bad. :stuck_out_tongue:

How so?

‘The Maulers’ are great at Mauling (or at least we were), but really suck at Plex stuff.

I did the heavy lifting - 'cause I knew I was the only one that could.
Trust me - it worked out best for me.
The Maulers didn’t know what happened - they just coughed up the cash…lol

1 Like

Cuz Uh Oh isn’t gonna fork out for friends or family to have a unified streaming device. And Uh Oh isn’t driving everywhere to configure it for people and then be on the hook for support whenever something goes amiss. If they’re savvy enough to want to stream, they have to be savvy enough to figure out how to run their own clients. Only exception to that is my in-laws, and well… that has proven to be mostly a disaster. They won’t get their device back online until the pandemic is over, and that’s just the way it’s going to be.

Props to you for getting them all online with a device that matches what you want on your server. I’m quite sure that the experience is pretty nice. I’m just not that nice. :wink: