"Quality" Branches Dedicated to HEVC / x265


#1

Hey Guys -

First of all, thanks to all who work on Sonarr. I use it daily and it’s fantastic!

I have a substantial local library where the media alone takes up many terabytes of space. Recently, I started manually replacing shows with larger sizes with ones encoded in HEVC / x265. This has maintained or improved quality while saving a tremendous amount of space.

It would be fantastic if I Sonarr had HEVC / x265 quality categories for both 720p / 1080p. This way, I could configure shows to first search for HEVC / x265 format and if not found, then grab one with different encoding and/or set shows to this option to have them convert automatically (if available of course.)

I’ve tried setting custom restrictions, but it doesn’t provide the desired result.

If anyone has suggestions for how I could do this now, that would be great - otherwise, it would be a great and I imagine fairly simple implementation.

Thanks!


More options in the profiles
#2

Sry mate, that’s not going to happen. The quality system is based on source+resolution only, and HEVC/x265 is a codec. If we go down that road you’d have xvid and what not as ‘qualities’. It becomes far too complex for the average user (which is the target audience for Sonarr)

Preferred words would likely allow some of this, but we’re not yet sure whether we’ll support auto-upgrades for it, see https://github.com/Sonarr/Sonarr/issues/385


#3

I asked the exact same thing but alas, not willing. I understand the reasoning though but would be a fantastic feature as x265 is amazing with file sizes. 2 suggestions:

  • Add a preferred word to search for (I use x265, X265)
  • Set file size limits for each quality

Neither option is ideal as the preferred word is a mandatory word, not actually preferred and the file sizes option helps but doesn’t always get desired results so some of the time I end up using the manual search to find the desired files.


#4

@Taloth I totally understand your perspective, and see the wisdom in what you are saying.

However, Sonarr does have an Advanced Settings option and this could be under advanced. Thereby maintaining your ease of use for the general Joe/Joanna and giving the power user a little more control.


#5

This is now true. The quality is based on whats in the file name, so if you have nothing in the file name it will set the quality by default to HDTV-720p but you add web-dl 1080p to each file name sonarr will pick it up as WEB-DL 1080p and the same goes for downloads. It checks the filename.

That’s all we are suggesting. It would be nice see to Sonarr catch up with the times and include two sets of quality varibles, one for HEVC (h265,and x265) and H264 (x264). I am sure this wouldn’t be hard to do.

Thanks,


#6

I don’t follow what you’re suggesting, what you said above is what Sonarr does.

x264 and x265 aren’t different qualities, they’re the same quality with different encodings. We are not going to conflate the quality system with 2x the qualities.

Preferring x264 over x265 or vice versa would be covered by this issue.

I’m not really sure what wouldn’t be hard, but if you say so…


#7

The world revolves the two types of qualities so they should be treated as such. Because you don’t want to treat it as such suggests you are too lazy. I guess others will have to make the change to your code so they can benefit from deciding “I only want x265 for these tv shows, and x264 for these other tv shows”. What we want is choice and not headaches because someone is too lazy provide “choice”. :slight_smile:


#8

You can already do this…

Either reject x265 or accept x264 (or both) and link it to the series you want via the x264 tag that also needs to be on the series.

Too lazy too look around the UI vs the guy that that actually implemented the feature…


#9

Restrictions can enforce a 265 selection only, but can they help an upgrade from a 264 to a 265 encoded file? I’ll take a look at it and see what comes.

In an Agile project, the Product Owner would simply add this to the backlog driven by user priority, has this happened? I know https://github.com/Sonarr/Sonarr/issues/385 details the requirement as an enhancement but there does not appear any way for users to give weight to a given requirement, especially given it is closed.

Keep up the good work, love the product.


#10

hey, this is great! i didn’t know about restrictions!

a few questions: because this content is sometimes flagged hevc or h265, is there a way to account for that?

also, maybe this is way too over my head, but is there a way to have already existing content “upgrade” to this, OR, say it’s the night a show airs—i’d love for whatever’s available fast to come in as soon as it can, but then upgrade to this after. is this doable?


#11

Restrictions are currently very umm… strict. So if you add hevc, the release must have this word, always.
You’re looking for a “should contain” restriction, where the hevc release would be rated higher but others are acceptable as well. That doesn’t exist in sonarr currently.


#12

is there any, um, roadmap for this?


#13

Another user here who has asked for this and would love to see it. If you are also someone who would like this “freferred, but not forced/only functionality” add your comments!


#14

the issue has been open since 2014, so do not get your hopes up…

It should be possible to take the “preferred tag” code from Radarr (where it already has been inplemented), and paste it into you own sonarr fork…

maybe there are already forks out there? Does anyone know? Should not be too difficult…


#15

Hi…i also use the same and as per my experience quality system is based on source+resolution only, and HEVC/x265 is a codec. If we go down that road you’d have xvid and what not as ‘qualities’.

percentages calculator


#16

Long time user, infrequent forum poster. Sorry for the long post.

Just wanted to throw my 2 cents in supporting changing the release quality system. The current system as is parses releases for source, resolution, and size. This was designed when the codec choices were more limited and it made sense. It was unlikely to find very high resolution videos distributed in less efficient codecs.

I believe the existing Sonarr size/resolution-window logic is fundamentally broken by new, more efficient codecs and I don’t know that the reason I see for that has been considered by the dev team. I believe we’ve come to a point where many videos are being released at comparable resolutions and encoding quality but with drastically different sizes due to codec choice. This situation is a problem, at least for me, as I am frequently getting missed episodes or finding that when I manually search there are much better choices Sonarr could have made. Sonarr doesn’t make these choices because that would require setting the size windows for a given “quality” much too large and allowing for junk to be downloaded to regularly.
Since most releases that are posted are being tagged with the codec used I think it would be well worth considering the effort and minor increase to the app complexity for parsing for codec as another point of information in the logic choosing a release to download.

What I would like to suggest may actually be simpler to understand than the current system where we have multiple different “qualites” of each resolution. My idea would be to have a tiered system such that each resolution would have sources (HDTV, WEB-DL, BluRay, etc) and under each source a codec. Then you could define a size window for each combo of resolution/source/codec. I believe such a system would be simple to understand and improve the accuracy/success of downloads.

And for future proofing or maybe as an advanced setting, allow the user to add new resolutions, sources, and codecs to the system.

Just my 2 cents. Thanks for reading my long post.


#17

the issue with the quality definitions is that they link a resolution to a file size range - which was fine up until x265 came around as it can now be well under half the size of the other codecs so setting, for eg, the 1080p range to be 800-1200mb isnt really viable when you can get 300-600mb x265 sized files which are probably fakes or just garbage in x264 format

what seinar posted above makes sense. we need to be able to define file size ranges per resolution per codec.

you could put them in the quality section so theyre global across all profiles (simpler and presumes you want the same codec for all shows, which isnt always true), or remove the quality section completely and move it into the profiles (more complex but allows for individual shows to have a specific codec ordering set). either way sonarr could use the codec ordering for each resolution as part of the download ranking system which is also something people are starting to want (and presumably why the preferred text option was added in v3 - as this is way more complex and harder to work out)

while that might add some bloat to the UI and complexity to the code i think the new grouping system that was added in v3 would help to reduce that as you could use it to group (and order) the codecs under each resolution.

people that dont care about x265 would have all the codecs in a single group with a single file size range, so not really a lot of diffeence at the UI level. for those that do want x265 they would break it out of the default group and set it up on its own with a file size range and order it above the default group in each resolution they wanted it - its a bit more work for the user but thats to be expected when you want to customise it.

v3 has just come and i dont think people expect this to be added any time soon, just considered for v4


#18

After quite a bit of searching on x265 / hevc in Sonarr, I found this thread. Just echoing @markus101 in saying that adding a restriction, then attaching the restriction to the series worked for me. You can’t auto “upgrade” from x264 to x265 and this restricts to just x265 (no way to “prefer”), but this does now only pick up x265 versions.

Of note, you can use regex in the “Must contain” and “Must not contain” fields. Here’s what I have:

Must contain = /(hevc|[hx]265)/i
Must not contain = /[hx]264/i
Tags = x265

Hope this helps others!

draft


#19

this is already known. the issue as youve noticed is that its mandatory so if you want the end goal to be x265 but will take an x264 in the interim (as sometimes the x265 variant never becomes available and you have to convert it yourself) then it cant be done in v2

v3 (which is now in alpha release) gets around the issue with its preferred words list, which is a good workaround, but its just that, a workaround for using a filename filter. it has no linkage to anything else (like file size)

i havent had a chance to use v3 yet so it really depends on how its been implemented (does it apply to both initial grabs as well as upgrades?) as to how useful the feature will be for the purpose of codec selection/prioritisation.


#20

v3 does not have preferred words. Not sure where you saw that it does.