Jump to content


Photo

Transcode in H265

Transcode H265

  • Please log in to reply
174 replies to this topic

#1 Snaaaake OFFLINE  

Snaaaake

    Newbie

  • Members
  • 4 posts
  • Local time: 08:52 AM

Posted 22 June 2017 - 03:57 AM

Hi,

 

I would like to have an option to choose H265 instead of H264 in the Transcode option.

It will be smaller for all bad bandwidth (2~5Mbit ADSL), but will have a great quality.

Mobile phone can benefit of it greatly too with the 4G and the limitation of download.

 


  • daedalus, SikSlayer, DerrickM and 8 others like this

#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 136138 posts
  • Local time: 02:52 AM

Posted 22 June 2017 - 02:56 PM

Do you mean for playback or for offline downloading? Because for playback, not all devices support h265 yet.


  • SilverPeak likes this

#3 Snaaaake OFFLINE  

Snaaaake

    Newbie

  • Members
  • 4 posts
  • Local time: 08:52 AM

Posted 22 June 2017 - 03:07 PM

playback, Emby for android TV with Shield with a poor connexion could use it.

 

If you put an option on

                                    Client side "Use H265"

                                    Server side "Allow users to use H265" 

 

like that you don't care if devices are compatible or not, User have the choice.


  • Mibok and SilverPeak like this

#4 Deathsquirrel OFFLINE  

Deathsquirrel

    Advanced Member

  • Members
  • 1996 posts
  • Local time: 11:52 PM

Posted 22 June 2017 - 05:54 PM

like that you don't care if devices are compatible or not, User have the choice.

 

Not my call but that is WILDLY contrary to the spirit of this project.


  • glenskie16 likes this

#5 Snaaaake OFFLINE  

Snaaaake

    Newbie

  • Members
  • 4 posts
  • Local time: 08:52 AM

Posted 22 June 2017 - 06:28 PM

We have choice for the material acceleration, threads, profil, crf, downmix,  why not for the codec?


  • SikSlayer and SilverPeak like this

#6 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 46431 posts
  • Local time: 02:52 AM

Posted 22 June 2017 - 08:04 PM

Also, encoding to hevc will require quite a bit more resources on the server end.  Most people's setups wouldn't handle it well I imagine.

 

We try to limit the number of options we put in that would only benefit very small audiences and have the potential to cause large audiences to make problems for themselves :).

 

Eventually, I'm sure this will be the norm but I'm not sure it is ready yet.


  • sebasmiles and SilverPeak like this

#7 sebasmiles OFFLINE  

sebasmiles

    Member

  • Members
  • 26 posts
  • Local time: 02:52 AM

Posted 02 August 2017 - 03:39 PM

I would also like to see emby eventually support this either by default or as a poweruser option thanks to the substantially reduced bandwidth requirements (I think it cuts bitrate for same quality by like 40%). There are quite a few hardware solutions out there that support playback like FireTV Gen 2, Samsung S8 phone, etc.

 

EDIT: After further quick review it seems that the CPU processing required is substantially more than H264 (like 10 times more?). Native encoding on Quicksync seems to be implemented into Skylake and newer, so I guess that means that only very new servers or a h265 compatible standalone GPU would be required? If this is right then you guys are on the money, playback may be easier but the chokepoint will be on the encoding side...Thanks for considering this though, perhaps in a couple years it may be valid.


Edited by sebasmiles, 02 August 2017 - 03:56 PM.


#8 JeremyFr79 OFFLINE  

JeremyFr79

    Advanced Member

  • Members
  • 923 posts
  • Local time: 11:52 PM
  • LocationSeattle, WA

Posted 02 August 2017 - 04:02 PM

I would also like to see emby eventually support this either by default or as a poweruser option thanks to the substantially reduced bandwidth requirements (I think it cuts bitrate for same quality by like 40%). There are quite a few hardware solutions out there that support playback like FireTV Gen 2, Samsung S8 phone, etc.

 

EDIT: After further quick review it seems that the CPU processing required is substantially more than H264 (like 10 times more?). Native encoding on Quicksync seems to be implemented into Skylake and newer, so I guess that means that only very new servers or a h265 compatible standalone GPU would be required? If this is right then you guys are on the money, playback may be easier but the chokepoint will be on the encoding side...Thanks for considering this though, perhaps in a couple years it may be valid.

The issue with Skylake and trust me I know as I have one, is that h.265 is ONLY supported on Skylake with Windows10.  Skylake is unsupported on any other OS as far as the GPU drivers are concerned.


  • sebasmiles likes this

#9 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 136138 posts
  • Local time: 02:52 AM

Posted 02 August 2017 - 04:11 PM

We have choice for the material acceleration, threads, profil, crf, downmix,  why not for the codec?

 

Because what will happen is users will enable things that their devices don't support, and then they'll assume there is some kind of Emby problem and expect us to fix it.


  • Volfan6415, fathibn, SilverPeak and 2 others like this

#10 Snaaaake OFFLINE  

Snaaaake

    Newbie

  • Members
  • 4 posts
  • Local time: 08:52 AM

Posted 02 August 2017 - 04:50 PM

If i understand, we have to wait 10 years to be sure everybody will have a supported device ? 

 

I'm joking, but if you put profile wtih recommanded configuration, everyone can understand that.


  • SilverPeak and KeiznKlei like this

#11 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 136138 posts
  • Local time: 02:52 AM

Posted 02 August 2017 - 04:54 PM

No, you don't have to wait 10 years, but we do need to consider how reliable it's going to be, and how many people will actually want to use it given the CPU requirements. Just like any other feature request, we want to see what kind of audience it will have before committing to the work.



#12 otispresley OFFLINE  

otispresley

    Advanced Member

  • Members
  • 134 posts
  • Local time: 02:52 AM
  • LocationApex, NC

Posted 03 August 2017 - 06:39 PM

Just to add a bit here and to offer my $0.02 or less :mellow: , HEVC encoding does use quite a bit more resources and really heavily depends on the CRF/VBR settings used and the encoding preset. I did a lot of research on this and the claim that a CRF of 23 when encoding a Blu-Ray source is visually lossless is just not true. If you have a good display, like a 4k with a larger screen, you can certainly see the difference. 

 

I ended up going with CRF 12 to get to visually lossless with my setup when encoding my collection to HEVC. CRF 23 with the Ultra Fast preset does encode pretty quickly, but you can see the difference between source and destination material. This is fine for smaller devices, but any larger device that can handle the output will suffer in quality with transcoding. For those with hardware accelerated HEVC support, there won't be much of an issue until the transcode tries to output at a 4k resolution because the device is 4k. The output resolution would need to match the source.

 

Also, some source material encodes much faster than others, depending on CODEC, picture quality, motion, etc. VC-1 for instance normally went at about 15 FPS (some lower and some higher) on my server with 2x E5-2660 Xeons. The 32 logical cores struggled greatly without hardware encoding support. Those titles take nearly twice as long as the source video length to transcode with output being 1920x1080. Titles with HEVC typically ran at about 28 FPS but still very CPU intensive and it would never be able to encode fast enough to handle 2 encodes at once if it were on-the-fly.

 

HEVC is great for reducing the size of your video library, even though at CRF 12 some few files end up being larger than the source. Even at that CRF, the overall size of my library was reduced by slightly more than 50%. However for on-the-fly transcoding, this would not be a viable option for me without some significant hardware assistance.


Edited by otispresley, 03 August 2017 - 06:44 PM.


#13 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 02:52 AM

Posted 04 August 2017 - 02:28 PM

Interesting that you went as low as 12 for CRF, but I agree that 23 is definitely not visually lossless for any "normal" source material that I've encountered including 1080p stuff (animation may be fine, but who knows).  I find 18/slow (maybe medium depending on source) to be the absolute highest CRF value I'd ever go with, and even then, it requires a lot of other options to make it work.  16 isn't bad for most stuff, in my opinion.  Below that is splitting hairs and I've found that introducing some other tuning/analysis options can make a huge difference and allow for some flexibility in CRF choice.

 

You're absolutely on-target with encoding HEVC, though.  It's brutal to do on a CPU and even some of the better processors would barely keep up trying to transcode a single 4k source to HEVC at a watchable framerate using software en/decoding.  Transcoding performance of 720p/1080p sources to HEVC is better, but it's still a computationally heavy codec to deal with and supporting more than a stream or two would be rough on many processors (again, assuming software en/decoding).  Bitrate savings can be nice with HEVC, but the amount of processing required to achieve it in a live-transcoding situation is just disproportionate to the gain at this time unless you have hardware encoding available...and even then, hardware encoders often have limitations that make things like detail/grain preservation more difficult.

 

Side note: HEVC stores 10bit material more efficiently than 8bit, so transcoding 8bit sources to HEVC Main10 files often results in even smaller file sizes/bitrates than if you had just used HEVC Main.  If you're doing any library conversions to save space, try it out and see if it helps with your particular files (12-bit storage is more efficient than even 10-bit, but the difference is smaller compared to 8->10 and compatability of the resulting file is reduced even further).



#14 JeremyFr79 OFFLINE  

JeremyFr79

    Advanced Member

  • Members
  • 923 posts
  • Local time: 11:52 PM
  • LocationSeattle, WA

Posted 04 August 2017 - 06:44 PM

I realize I mis stated in an earlier post, KabyLake not SkyLake only allows access to it's GPU and it's HW Acceleration in Windows 10, Skylake only has partial HEVC capabilities.  None the less this does you no good if you're using a real server OS instead of a desktop OS.



#15 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 02:52 AM

Posted 04 August 2017 - 08:05 PM

I don't see why Windows 10 would be required for Kaby Lake hardware transcoding at all.  The only restriction of this type that I know of is for playback of streaming media from services like Netflix in 4k (or any service that requires PlayReady 3.0 support), since they require the DRM to be available...and PlayReady 3.0 is only available with Windows 10 ("or later").



#16 JeremyFr79 OFFLINE  

JeremyFr79

    Advanced Member

  • Members
  • 923 posts
  • Local time: 11:52 PM
  • LocationSeattle, WA

Posted 05 August 2017 - 12:25 AM

I don't see why Windows 10 would be required for Kaby Lake hardware transcoding at all.  The only restriction of this type that I know of is for playback of streaming media from services like Netflix in 4k (or any service that requires PlayReady 3.0 support), since they require the DRM to be available...and PlayReady 3.0 is only available with Windows 10 ("or later").

The driver will NOT install in any other OS, you need the driver to access the h.265 capabilities of the chip.  Trust me I fought this for a week.



#17 Doofus OFFLINE  

Doofus

    Advanced Member

  • Members
  • 12100 posts
  • Local time: 11:52 PM

Posted 05 August 2017 - 01:39 AM

Yeah, only generic drivers are installed.

 

http://www.tomshardw...indows-x64.html

 

http://www.tomshardw...0765.1501911081

 

59855a09d451d_Snapshot_93.jpg



#18 denz OFFLINE  

denz

    Advanced Member

  • Members
  • 2165 posts
  • Local time: 02:52 PM
  • LocationPerth, Australia

Posted 05 August 2017 - 06:02 AM

I have kaby lake pc and win 7 doesnt work on it stops responding after few minutes crashes and had no choice but to install win 10 which works perfectly luckily wmc works perfectly.

Edited by denz, 05 August 2017 - 06:45 AM.


#19 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 02:52 AM

Posted 05 August 2017 - 04:35 PM

The driver will NOT install in any other OS, you need the driver to access the h.265 capabilities of the chip.  Trust me I fought this for a week.

 

Well that's a dumb restriction that I wouldn't have expected.  Thanks for the info.  I can guess why they did it, but it doesn't make it any less ridiculous.



#20 Deathsquirrel OFFLINE  

Deathsquirrel

    Advanced Member

  • Members
  • 1996 posts
  • Local time: 11:52 PM

Posted 05 August 2017 - 08:28 PM

Well that's a dumb restriction that I wouldn't have expected.  Thanks for the info.  I can guess why they did it, but it doesn't make it any less ridiculous.

 

You also can't run windows update on those cpus if you use earlier versions of windows.







Also tagged with one or more of these keywords: Transcode H265

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users