Jump to content


Photo

Hardware Transcoding


  • Please log in to reply
96 replies to this topic

#61 Michael K. OFFLINE  

Michael K.

    Advanced Member

  • Members
  • 160 posts
  • Local time: 01:59 AM

Posted 13 May 2019 - 11:09 PM

If you want to use CPU transcoding, you'll want to use something like a Threadripper. I have a 1st gen, and it handles everything, pretty well. Not as fast as a GPU, but fast enough. The later versions will probably be much better.

 

Damn, that's a nice looking CPU with great specs. At first glance it looks way better than the Intel's.



#62 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 13 May 2019 - 11:18 PM

Very interesting. So in my case, every title is always played with subtitles burn-in. Does this mean that the GPU encoding would likely never be engaged, or is the load split between CPU/GPU somehow when using subtitles?

 

The load is split. Decoding can be done in the GPU, then it's copied back to system memory where CPU is performing  the subtitle overlay, then data is transferred back to GPU for encoding.

 

As for the Intel GPU (QuickSync), I haven't been able to get it to work well with emby. I've been trying with the i7-7700. I haven't tried the new emby v4 yet, which I understand has significant GPU improvements.

 

Windows or Linux? On Windows it should work at least after installing the latest Intel drivers. On Linux, the setup is a bit complicated.



#63 Doofus OFFLINE  

Doofus

    Advanced Member

  • Members
  • 13710 posts
  • Local time: 11:59 PM

Posted 13 May 2019 - 11:20 PM

Damn, that's a nice looking CPU with great specs. At first glance it looks way better than the Intel's.

 

They were designed  with gamers in mind. So they do well with image rendering.



#64 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 14 May 2019 - 12:26 AM

This all depends on your individual requirements. 

But when you want real high performance transcoding to support a large number of simultaneous streams, there's no way around GPU transcoding. 

 

Just some rough figures for an example:

 

A while a go I was testing some transcoding performance using a quite average i3 6100 CPU (4 core).

(File was some typical H..264 video without any specialties, no subtitles but scaling)

 

SW-Transcoding was 12x speed.

HW-Transcodng ran at 70x speed

(full hw pipeline, even scaling done by the GPU)

 

Then I found out that the 70x speed wasn't even the GPU limit.

Limiting factor was in fact the CPU because it couldn't do audio-transcoding any faster (it's a single-threaded operation)

Removing audio transcoding allowed 110x transcoding speed.

 

 

Disclaimer for all readers: Don't use these absolute numbers for any calculations or assumptions about performance.

There are so many factors playing a role here. An H.264 HD video alone can be encoded in bitrates differing by factor > 10x

 

 

I just want to illustrate how big the difference between hw and sw performance can be (under ideal conditions, though!).


  • Doofus and Q-Droid like this

#65 Doofus OFFLINE  

Doofus

    Advanced Member

  • Members
  • 13710 posts
  • Local time: 11:59 PM

Posted 14 May 2019 - 12:55 AM

For sure there's a huge difference, but is there any real advantage to a super fast transcode over a very fast transcode? It's still considerably faster than real-time. I suppose it might make a difference if you intend seeking and want to skip large chunks of the video. Other than that, software allows much more control over the quality and options.

 

I mean, just a quick test.

Metadata:
    title           : Cliffhanger.1993.2160p.BluRay.x265.10bit.SDR.DTS-HD.MA.TrueHD.7.1.Atmos
    encoder         : libebml v1.3.6 + libmatroska v1.4.9
    creation_time   : 2019-02-18T11:19:31.000000Z
  Duration: 01:52:41.79, start: 0.000000, bitrate: 50188 kb/s
    Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv), 3840x1600 [SAR 1:1 DAR 12:5], Level 153, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
    Metadata:
      title           : Cliffhanger.1993.2160p.BluRay.x265.10bit.SDR.DTS-HD.MA.TrueHD.7.1.Atmos
      BPS-eng         : 41686682
      DURATION-eng    : 01:52:41.755000000
      NUMBER_OF_FRAMES-eng: 162120
      NUMBER_OF_BYTES-eng: 35234391602
    Stream #0:1(eng): Audio: truehd, 48000 Hz, 7.1, s32 (24 bit), Start-Time 0.026s (default)
Stream mapping:
  Stream #0:0 (hevc) -> scale (graph 0)
  scale (graph 0) -> Stream #0:0 (libx264)
  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

5cda497884193_Snapshot_208.jpg



#66 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 14 May 2019 - 01:35 AM

Of course nobody would want to watch a video faster than realtime... ;-)

 

i'm seeing such figures rather as an indication of server performance when it's about the number of simultaneous transcoding sessions that a server is able to handle.

 

The OP asked about building a high-performance server with load-balancing of hw acceleration and no tight budget constraints.

By using CPU transcoding he would stay way behind from what would be achievable  with GPU acceleration, so that wouldn't be the best advice IMO as he obviously wants to go for performance.

 

But there is nothing wrong with CPU transcoding as long as it meets your requirements.

BTW, opposed to those systems that I use for testing and development, my private Emby Server doesn't have any hw acceleration either (dual Xeon...)

So I never meant to imply that there's something bad about CPU transcoding ;-)


  • Doofus likes this

#67 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 3093 posts
  • Local time: 02:59 AM

Posted 14 May 2019 - 05:20 PM

We need to differentiate between decoding and encoding. For live streaming, Emby is using H.264 encoding only (the HLS spec doesn't include H.265 anyway).

Encoding is the much harder part of the story in most cases.

 

https://developer.ap...r_apple_devices

 

Apple has been supporting HEVC in HLS since late 2017.

 

Of course DASH is much easier anyway to use HEVC IMHO.



#68 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 14 May 2019 - 06:45 PM

https://developer.ap...r_apple_devices

 

Apple has been supporting HEVC in HLS since late 2017.

 

Of course DASH is much easier anyway to use HEVC IMHO.

 

Sorry for being inaccurate. Yes, Apple had added it to the spec later, but it hasn't been widely adopted so far, that's why it is not a relevant option.

 

About HEVC (H.265) in general:

 

It provides

  • equal quality
  • using half the amount of data compared to H.264
  • at the cost of requiring 10x times more processing power!!!

HEVC is very attractive for static streaming provider for saving storage and bandwidth. But these are always serving pre-encoded files.

 

When comparing Emby with above providers and current industry development...

...we must not forget that Emby is doing something very special and unusual: Live-Transcoding.

 

And for live-transcoding - IMO - current average(!) hardware performance is not yet sufficient for switching from H.264 to H.265.


  • Doofus likes this

#69 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 3093 posts
  • Local time: 02:59 AM

Posted 15 May 2019 - 07:18 AM

I'd agree with that softworkz EXCEPT for using 10x the processing power.

If using GPU that supports H.265 then it's "free" sort of. :)

 

By that I mean if you have an nVidia consumer you are limited to 2 streams so why not use H.265 vs H.264 all else equal?

I haven't tested quantity of H.265 vs H.264 streams using Intel GPU but if in hardware doubt there will be a large difference.

 

The benefit is gained mainly by those with limited upload bandwidth on their servers.  If you have Comcast for example it's quite likely you only have 5 Mb or (if upgraded) 10 Mb of upload that has to be shared for all remote streams.  Being able to send the videos in H.265 vs H.264 is almost like getting a double or trippling of upload bandwidth as the server will be able to support more remote streams.  What could only handle 1 or 2 streams prior can now handle an additional stream or two if needed but will have better quality due to the compression that preserves the original video better.

 

So in affect it's not really EQUAL quality either but can be better as you have more "bandwidth" to use.  By this I mean a video using 5 Mb of bandwidth compressed with H.265 will almost always look a lot better then a video of 5 Mb done with H.264.

 

I'm presently stuck with no choice but to use Comcast and have 10 Mb upload for my remote family.  It's very limiting using H.264.  For months I've been converting files offline to H.265 (using CPU for best compression) and the difference in streaming is amazing.

 

I certainly realize H.265 isn't supported in HW as well as H.264 is, nor all the options.  But it would be nice to be able to transcode to H.265 in real time in HW for those that have it.  This could be especially useful for OTA broadcast in Mpeg2 that really compress well to H.265.  So just keep this on the list of additions for Emby transcoding as it can be a real game changer for some of us!


  • Charlie117 and VirgilFox like this

#70 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 15 May 2019 - 04:03 PM

It provides

  • equal quality
  • using half the amount of data compared to H.264
  • at the cost of requiring 10x times more processing power!!!

 

 

So in affect it's not really EQUAL quality either but can be better as you have more "bandwidth" to use.  By this I mean a video using 5 Mb of bandwidth compressed with H.265 will almost always look a lot better then a video of 5 Mb done with H.264.

 

My points above were referring to a single context:

  • equal quality using half the amount of data 

Also true would be 

  • "double" quality using the same amount of data 

 

 

Adopting H.265 for HLS would mean a lot of caveats.

On one side, there's the lack of client support. Not even hlsjs has support for that.

Many client OS versions don't even include an H.265 software decoder. We would need to detect whether there's a hardware decoder available (omg).

On the server side we're often automatically falling back to software encoding when hw encoding fails. In case of H.265 that wouldn't be possible in many cases because the CPU won't be able to handle it. The server can't switch to H.264 though, because the client is expecting H.265, and even if that would be signaled back to the client in some way, it wouldn't be a consistent experience (sometimes H.265, sometimes H.264). Not only confusing users but also once again an additional complication for support and diagnostic cases..



#71 cayars OFFLINE  

cayars

    Advanced Member

  • Alpha Testers
  • 3093 posts
  • Local time: 02:59 AM

Posted 16 May 2019 - 02:26 PM

Personally to adopt H.265 I'd do DASH vs HLS first as it's easier IMHO and has good support.  Arguably DASH is better than HLS in many environments anyway.

 

H.265 in my mind would be a preference if the client can support it AND it can be done easily on the server.  So if HW on the server can be used then easy.  If it requires some "weird" filtering or something that would require CPU vs HW (or no HW support) then use H.264 as usual.

 

So try to convert to H.265 via HW ELSE convert fall back to EXACTLY what we have now which would be H.264 via HW, CPU, etc

H.265 via CPU could be added down the road if ever.

 

It would essentially just be a replacement for H.264 via HW (first) to save bandwidth approach.  That would be a good way to introduce and use H.265.  It would also really help those with very limited upload bitrate and have a need to stream a couple of remote sessions.

 

Carlo



#72 IkeTaylor11 OFFLINE  

IkeTaylor11

    Advanced Member

  • Members
  • 487 posts
  • Local time: 01:59 AM

Posted 17 May 2019 - 11:54 AM

For those up against the 2 stream limit for Nvidia GPU's, there is a patch now that you can use to do more than 2 streams. 

 

https://github.com/k...tree/master/win


  • FrostByte likes this

#73 Jdiesel ONLINE  

Jdiesel

    Advanced Member

  • Members
  • 2834 posts
  • Local time: 12:59 AM
  • LocationRegina, SK

Posted 17 May 2019 - 12:39 PM

For me the x264 versus x265 for transcoding is kind of a moot point but I suppose the bandwidth benefits for out of network devices would be nice.

 

For me the the exciting part about having excess transcoding overhead would be the opportunity to have an option to force transcoding on all remote streams in order to implement adaptive quality/bitrate control. Having consistent buffer free playback on out network devices is much more important to me personally.



#74 neik OFFLINE  

neik

    Advanced Member

  • Members
  • 1025 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 09:54 AM

For me the x264 versus x265 for transcoding is kind of a moot point but I suppose the bandwidth benefits for out of network devices would be nice.

For me the the exciting part about having excess transcoding overhead would be the opportunity to have an option to force transcoding on all remote streams in order to implement adaptive quality/bitrate control. Having consistent buffer free playback on out network devices is much more important to me personally.


Also wrote this some post else but once again +1.

This would be a huge improvement for those with fluctuating bandwidth (e.g. mobile, bad WiFi, etc.)

#75 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 02:50 PM

This would be a huge improvement for those with fluctuating bandwidth (e.g. mobile, bad WiFi, etc.)

 

...Not quite. You will be able to achieve higher quality, but it wouldn't be adaptive, so like now, the client would measure the available bandwidth, subtract some percentage to accommodate for varying bandwidth and the server would transcode the video with that bandwidth. It would be just the same like now (with higher quality, though). 

 

...But somewhat: the percentage for safety could be increased, that would help a bit for such cases. But you can already achieve the same by manually selecting a lower bandwidth. As a result: It's again "only" about better quality at the same bandwidth.



#76 neik OFFLINE  

neik

    Advanced Member

  • Members
  • 1025 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 05:42 PM

Thanks for your comment, really appreciate the time you take to explain your thoughts.

 

I have by no means the knowledge you have but I have to disagree in your first point:

Let's assume that you start playing a 10mbit file with only 5mbit bandwith available, the result will be transcoding - so far so good.

During the playback your available bandwith drops to 1 or 2mbit, the result will be buffering as Emby only adapts the transcode to the available bandwith once.

 

To your second point: Increasing the percentage might alleviate in some cases but it woudln't be as good an adaptive solution.

While having the ability to select your bandwith manually is nice, most of the users just want to play their stuff and not worry about any bandwith settings, all they want is no buffering... Plug & Play

 

There are a couple of topics discussing this:

https://emby.media/c...tive-streaming/

https://emby.media/c...tive-streaming/

https://emby.media/c...ity-needs-work/



#77 Jdiesel ONLINE  

Jdiesel

    Advanced Member

  • Members
  • 2834 posts
  • Local time: 12:59 AM
  • LocationRegina, SK

Posted 22 May 2019 - 05:46 PM

I think this is what people are interested in

 

https://support.plex...hen-streaming/ 


  • neik likes this

#78 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 05:49 PM

I have by no means the knowledge you have but I have to disagree in your first point:

Let's assume that you start playing a 10mbit file with only 5mbit bandwith available, the result will be transcoding - so far so good.

During the playback your available bandwith drops to 1 or 2mbit, the result will be buffering as Emby only adapts the transcode to the available bandwith once.

 

And that would be no different with HEVC. 

 

Maybe you think that HEVC would automatically mean that it's adaptive?

That's not the case.



#79 neik OFFLINE  

neik

    Advanced Member

  • Members
  • 1025 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 05:51 PM

And that would be no different with HEVC. 

 

Maybe you think that HEVC would automatically mean that it's adaptive?

That's not the case.

 

This has nothing to do with the codec, the same bandwith variation can happen with HEVC as well.

No matter if it is h264, h265, VP8, VP9, AV1...

 

What Jdiesel just posted is the "adaptive" I am talking about.



#80 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 2560 posts
  • Local time: 07:59 AM

Posted 22 May 2019 - 05:55 PM

This has nothing to do with the codec, the same bandwith variation can happen with HEVC as well.

No matter if it is h264, h265, VP8, VP9, AV1...

 

What Jdiesel just posted is the "adaptive" I am talking about.

 

Correct. Adaptive streaming could also be done with H.264.

That's what I was trying to point out: We don't need HEVC for this.


Edited by softworkz, 22 May 2019 - 05:55 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users