Jump to content


Photo

Hardware Transcoding


  • Please log in to reply
96 replies to this topic

#81 Fratopolis OFFLINE  

Fratopolis

    Advanced Member

  • Members
  • 242 posts
  • Local time: 08:34 PM

Posted 02 June 2019 - 05:17 PM

Guys/Gals they are not adding HEVC right now. All that is happening is questions are being asked taking time away from them helping those with issues on current implementations.

This question has been asked forever. How about dropped it and revisit in a year? 🤔

#82 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2935 posts
  • Local time: 09:34 PM

Posted 03 June 2019 - 09:15 AM

This question has been asked forever. How about dropped it and revisit in a year?

Because that would indicate there is no interest in the feature which clearly isn't the case.


  • Charlie117 likes this

#83 Charlie117 OFFLINE  

Charlie117

    Advanced Member

  • Members
  • 61 posts
  • Local time: 03:34 AM

Posted 03 June 2019 - 02:32 PM

Guys/Gals they are not adding HEVC right now. All that is happening is questions are being asked taking time away from them helping those with issues on current implementations.

This question has been asked forever. How about dropped it and revisit in a year?

 

Perhaps people keep asking this question because the arguments made against HEVC transcoding have been rather unconvincing so far.

 

The argument that current hardware is not powerful enough to transcode to HEVC on the fly only applies to software transcoding, whereas real time hardware transcoding to HEVC has been available now for many years on CPUs and GPUs.

 

Just add HEVC hardware transcoding already as an option for people with the right hardware for it, just like H.264 hardware transcoding is currently available to those with qualifying hardware. Then just keep H.264 the default for everyone else.

 

I respect the devs decision to not implement HEVC transcoding yet, but please stop feeding the nonsense idea that our current hardware isn't powerful enough for it yet.

 


  • cayars and VirgilFox like this

#84 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 15313 posts
  • Local time: 06:34 PM
  • LocationWashington State

Posted 03 June 2019 - 02:42 PM

The argument goes both ways as all the additional time and troubleshooting that will go into why hevc transcoding is not working or is to slow on my system.



#85 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135803 posts
  • Local time: 09:34 PM

Posted 03 June 2019 - 02:43 PM

Have you explored the h265 feature request topic? 



#86 Fratopolis OFFLINE  

Fratopolis

    Advanced Member

  • Members
  • 242 posts
  • Local time: 08:34 PM

Posted 04 June 2019 - 06:47 PM

Perhaps people keep asking this question because the arguments made against HEVC transcoding have been rather unconvincing so far.

The argument that current hardware is not powerful enough to transcode to HEVC on the fly only applies to software transcoding, whereas real time hardware transcoding to HEVC has been available now for many years on CPUs and GPUs.

Just add HEVC hardware transcoding already as an option for people with the right hardware for it, just like H.264 hardware transcoding is currently available to those with qualifying hardware. Then just keep H.264 the default for everyone else.

I respect the devs decision to not implement HEVC transcoding yet, but please stop feeding the nonsense idea that our current hardware isn't powerful enough for it yet.

I'd have to side with the devs on this one. Softworkz is already chasing issues with detection and green flickering and improving headless mode on current implementation which for me works fine.

With the issues alone on what is currently implemented for some, your saying you have no trouble with the devs doubling their hardware encoding workload by adding hevc and implemting a way to automatically decide who's hardware supports it and who's doesn't. Then you will have those after this saying "why won't you let me do software hevc encoding I have a 8 core server or a threadripper, you added it for video cards why not software".

H264 hardware encoding still isnt perfect. I know I'm going to get a response to this from everyone so I'll let what I said here stand. Should have kept my mouth shut in the first place🤔!

I hope HEVC dies with their crazy patents. I love the tech just not the insane greed🤯!

Edited by Fratopolis, 04 June 2019 - 06:49 PM.

  • Charlie117 likes this

#87 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2935 posts
  • Local time: 09:34 PM

Posted 05 June 2019 - 11:13 AM

No you shouldn't keep your mouth shut at all. :)  This is one of the ways the devs can gauge what people would like to see added as time and resources permits.

 

I'm personally all in for H.265 and have been converting my own files from H.264 to H.265 using ffmpeg (CPU) with absolutely great results.  With that said I use CPU vs HW as I get much better results in quality and file size using CPU.  The downside of course is my CPU is pegged 100% all the time.  It's worth it to me as I've been able to stop purchasing new HDD as my collection continues to grow.

 

There ARE issues using HW but they are very similar to the same ones with H.264.  I'd like to see H.264 flushed out first for real-time use but the CONVERT function could certainly be modified to allow files to be converted in place to ease H.265 into Emby.  Nothing wrong with easing into this in baby steps, but it takes dialog to talk about things.  :)


  • neik, Charlie117 and VirgilFox like this

#88 Doofus ONLINE  

Doofus

    Advanced Member

  • Members
  • 12045 posts
  • Local time: 06:34 PM

Posted 05 June 2019 - 04:27 PM

I've just started transcoding my stuff to h265 with handbrake using NVENC. It does it at anything from 400fps to 1000fps. The CPU does all the decoding, unfortunately. But it doesn't seem to slow my system down. It's definitely the face of the future.

#89 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2935 posts
  • Local time: 09:34 PM

Posted 05 June 2019 - 08:01 PM

I can definitely tell the difference in quality using NVENC vs CPU in certain scenes and in file size (bitrate).  That's why I went CPU for conversions.

I spent a lot of time trying all kinds of different things using Nvidia, Intel and AMD and CPU was always better except the time it takes.  Hands down looser on the time it takes to convert but I figure I only convert each file once so...

 

I'd have NO ISSUE using HW for one-off on the fly transcodes however as the difference isn't that much and it's a completely different result being sought.


Edited by cayars, 05 June 2019 - 08:02 PM.

  • Charlie117 and VirgilFox like this

#90 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1661 posts
  • Local time: 03:34 AM

Posted 07 June 2019 - 10:22 AM

I can definitely tell the difference in quality using NVENC vs CPU in certain scenes and in file size (bitrate).  That's why I went CPU for conversions.

I spent a lot of time trying all kinds of different things using Nvidia, Intel and AMD and CPU was always better except the time it takes.  Hands down looser on the time it takes to convert but I figure I only convert each file once so...

 

I'd have NO ISSUE using HW for one-off on the fly transcodes however as the difference isn't that much and it's a completely different result being sought.

 

PLEASE NOTE: 

 

This is not a general problem of CPU vs HW Encoding.

It is just due to the fact that Emby currently doesn't provide hw codec specific settings to control encoding quality.

I hope we will get to that point soon to allow this kind of configuration.


  • cybergrimes and Charlie117 like this

#91 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2935 posts
  • Local time: 09:34 PM

Posted 07 June 2019 - 12:25 PM

Nothing to do with Emby as it's done outside of it.  HW just isn't as "tight" with bitrates that software based encoders are.



#92 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1661 posts
  • Local time: 03:34 AM

Posted 07 June 2019 - 05:00 PM

Nothing to do with Emby as it's done outside of it.  HW just isn't as "tight" with bitrates that software based encoders are.

 

HW codecs need different configuration than libx264, even when used via ffmpeg.



#93 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 2935 posts
  • Local time: 09:34 PM

Posted 08 June 2019 - 07:24 AM

Quite aware of that.  Let me say it a different way.  Work any magic you want with the command line for HW encoding and then do the same for CPU and the CPU produced version will always look better then the HW based version and use let bits as well.  However, this comes at the expense of CPU cycles and take a while.  CPU for general use is not suited for real-time but for archival material is much better.


  • VirgilFox likes this

#94 cybergrimes OFFLINE  

cybergrimes

    Advanced Member

  • Members
  • 449 posts
  • Local time: 08:34 PM
  • LocationMinnesota

Posted 10 June 2019 - 09:29 PM

I recently noticed that, on my setup, a CPU transcoded OTA live tv stream will start playback faster than a hardware transcoded stream. For example if I kick off a 1080i channel with CPU decode/encode it will start in 5-7 seconds, the same channel with QSV decode/encode will not start playing until after 10-12 seconds. I thought maybe MPEG2 related or maybe the interlace but my older full MPEG2 blu-ray rips and handful of 1080i H264 rips both consistently start in around 5-7 seconds with either CPU or hardware transcoding.

 

Has anyone else noticed this, or has it been discussed? or perhaps know why?

 

I didn't realize it was a thing until I recently flirted with Channels DVR product (using CPU transcoding) and initially thought wow why is this faster than Emby, well it wasn't, I was just always using hardware transcoding with Emby


Edited by cybergrimes, 10 June 2019 - 09:30 PM.


#95 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135803 posts
  • Local time: 09:34 PM

Posted 10 June 2019 - 10:33 PM

I think that is something that will vary per GPU, but it's bringing additional components into the mix so it's reasonable that it may take slightly longer to start.

#96 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1661 posts
  • Local time: 03:34 AM

Posted 12 June 2019 - 10:31 AM

I recently noticed that, on my setup, a CPU transcoded OTA live tv stream will start playback faster than a hardware transcoded stream. For example if I kick off a 1080i channel with CPU decode/encode it will start in 5-7 seconds, the same channel with QSV decode/encode will not start playing until after 10-12 seconds. I thought maybe MPEG2 related or maybe the interlace but my older full MPEG2 blu-ray rips and handful of 1080i H264 rips both consistently start in around 5-7 seconds with either CPU or hardware transcoding.

 

Has anyone else noticed this, or has it been discussed? or perhaps know why?

 

I didn't realize it was a thing until I recently flirted with Channels DVR product (using CPU transcoding) and initially thought wow why is this faster than Emby, well it wasn't, I was just always using hardware transcoding with Emby

 

There can be differences but that seems to be a huge difference to me.

 

Could you post an ffmpeg log for each case?



#97 cybergrimes OFFLINE  

cybergrimes

    Advanced Member

  • Members
  • 449 posts
  • Local time: 08:34 PM
  • LocationMinnesota

Posted 12 June 2019 - 10:42 AM

There can be differences but that seems to be a huge difference to me.

 

Could you post an ffmpeg log for each case?

 

Absolutely, both logs attached.

For visible playing video on screen the CPU was about 7 seconds here, QSV was about 12 seconds.

Both in web browser with bitrate set to 4 Mbps, this was a 1080i OTA channel from my HDHR.

Attached Files






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users