Modern Internet, Direct Play, Transcoding (Is it needed)

[ZACHxAxROO 4]

So recently, I purchased a Quadro P620 to handle a couple 4K transcodes here an there when I am not at home or my relative wants to stream a 4K movie. After a bit of finagling with drivers, I got the card to work with Emby. At first I thought it was working great, and to be fair, it was doing a great job transcoding. Transcoding 4K HEVC to 4K H264 100Mb. I then questioned why it was transcoding at all at that bitrate. Turns out because I was using a browser. I then tested the app and my phone. Both of which direct played flawlessly away from home. Now I am only 10 miles away. So It does not need to go through a lot of paths between my work and my house. I am unsure of the limit when further from home.

 

Is modern internet speed reducing the need for transcoding? Or am I just close enough to my home server to allow for such speeds? I haven't been on any vacations or trips that have taken me more than a state away recently and haven't been able to test it out until now. If needed, how many of you transcode from 4k to a lower bitrate 4k? Or do most transcode 4K to 1080p? Is it better to transcode 4K to 1080P or directly play 1080P (over the internet)? 

 

I'm curious to see if my relatives house is close enough to direct play. I kind of feel I bought the P620 for nothing if it does then. I created this topic as a general discussion but also general questions for other users with experience in the transcoding world. I have direct played to a Nvidia Shield up until this point, so while I have had Emby for quite a long time, transcoding is new to me.

[Lessaj 301]

Close geoproximity reduces latency, so yes that could be part of it but there are a lot of other factors to consider as well. When converting from HEVC to H264 a fairly blanket 1.5x on the bitrate is applied IF only transcoding because the device doesn't support HEVC, otherwise it will respect the set limit - IE 20 Mbps. Browsers do support HEVC, you may need to toggle on "graphics acceleration" to get it to work, it may not be on out of the box. You could have multiple versions that are lower resolution but transcoded from the 4k file. The browser will most likely require a transcode of the audio, which does change how the content is delivered, but audio only transcoding is very minimal CPU overhead.

What is your advertised upload speed? This does play a role to deliver the content but again it's not the only factor. Latency's role, or rather round trip time, is a big factor when the client needs to make a lot of requests, IE if every request takes 250ms just to reach the server, it's going to take that much longer to deliver the content too since the RTT is 500ms, on top of the time taken to deliver the content at whatever speed. Some requests are in parallel, some are sequential. When it comes to requesting for transcoded TS segments it is done sequentially. I can see in my httpd logs for some of my friends that their device will request a lot of segments back to back, which it always does for playback start, but I also see it in the middle of playback and I can see one request duration will be really long, like 10+ seconds, and then it requests for a bunch of segments that take <100ms so they have something going on on their end that is causing delays and it has to wait for that segment to complete before it can ask for the next one. I know it's not me because I can have multiple transcoded streams going and only theirs shows TS segments like that.

Ideally you want to direct play HEVC content because it's smaller at the same quality level (and going forward, AV1 is even smaller at the same quality) which is friendlier over the internet.

[Killface69 70]

The need for transcoding in Emby in general is:

1. Bitrate exceeds network limit
2. Client cannot handle video/audio

With a capable internet connection (upstream) from the server side, you're good to go.

Transcoding can still occur if the user is on e.g. on a limited speed, like mobile or bad wifi receiption (speedwise).

The client is also a source for transcoding, like codecs and capabiity. Some audio codecs like DTS required transcoding as almost no browser is capable of playing it, also some browsers have issues with H265. Or require remuxing/do transcoding if container is not MP4 or audio is not or and audio track is not the first one etc.

It's always the best choice to use the OS client.

Transcoding 4k also gets rid of Dolby Vision and requires tonemapping. I'd avoid transcoding 4k at all costs. I have two separate movie libraries, usual stuff up to 1080p, and the good ones also in 4k.

If you're transcoding regularily large files on a SSD, it could wear out your drive. Better to transcode to RAM if possible.

Data on the internet also doesn't measure your distance. If you're 10 miles away from home, the data might have traveled the globe till it reaches the destination. You seem to live in an area with very good line speeds.

[Lessaj 301]

16 minutes ago, Killface69 said:

If you're transcoding regularily large files on a SSD, it could wear out your drive. Better to transcode to RAM if possible.

I disagree with this, see post.

 

[ZACHxAxROO 4]

1 hour ago, Killface69 said:

The need for transcoding in Emby in general is:

1. Bitrate exceeds network limit
2. Client cannot handle video/audio

With a capable internet connection (upstream) from the server side, you're good to go.

Transcoding can still occur if the user is on e.g. on a limited speed, like mobile or bad wifi receiption (speedwise).

The client is also a source for transcoding, like codecs and capabiity. Some audio codecs like DTS required transcoding as almost no browser is capable of playing it, also some browsers have issues with H265. Or require remuxing/do transcoding if container is not MP4 or audio is not or and audio track is not the first one etc.

It's always the best choice to use the OS client.

Transcoding 4k also gets rid of Dolby Vision and requires tonemapping. I'd avoid transcoding 4k at all costs. I have two separate movie libraries, usual stuff up to 1080p, and the good ones also in 4k.

If you're transcoding regularily large files on a SSD, it could wear out your drive. Better to transcode to RAM if possible.

Data on the internet also doesn't measure your distance. If you're 10 miles away from home, the data might have traveled the globe till it reaches the destination. You seem to live in an area with very good line speeds.

 

1 hour ago, Lessaj said:

I disagree with this, see post.

 

I'm less worried about SSD anyway as emby sits on a mirror of enterprise SSD's. I also feel like transcoding 4K is precisely what its there for, at least in the last 5 years. I have never transcoded 1080p media. It has always direct played, no matter where I was. That and with any fairly modern GPU, transcoding is fairly easy. I run two sets of media as well. 1080p and 4K.  I solely purchased the P620 for the fact my relative is accessing my library and I want them to be able to utilize the 4K content even if its transcoded. I figured transcoding down to 1080p from a 4K source would be better than 1080p by itself, but I was unsure if that is true. I also feel like you don't even need a GPU for transcoding 1080p. From my tests, a decent CPU handles that even without quicksync.

 

I guess it will always be needed since compatibility is the bigger reason rather than bandwidth nowadays. That and further distances from the server, but I wonder how long it is until that isn't an issue anymore.

Edited January 7 by ZACHxAxROO

[ZACHxAxROO 4]

1 hour ago, Lessaj said:

Close geoproximity reduces latency, so yes that could be part of it but there are a lot of other factors to consider as well. When converting from HEVC to H264 a fairly blanket 1.5x on the bitrate is applied IF only transcoding because the device doesn't support HEVC, otherwise it will respect the set limit - IE 20 Mbps. Browsers do support HEVC, you may need to toggle on "graphics acceleration" to get it to work, it may not be on out of the box. You could have multiple versions that are lower resolution but transcoded from the 4k file. The browser will most likely require a transcode of the audio, which does change how the content is delivered, but audio only transcoding is very minimal CPU overhead.

What is your advertised upload speed? This does play a role to deliver the content but again it's not the only factor. Latency's role, or rather round trip time, is a big factor when the client needs to make a lot of requests, IE if every request takes 250ms just to reach the server, it's going to take that much longer to deliver the content too since the RTT is 500ms, on top of the time taken to deliver the content at whatever speed. Some requests are in parallel, some are sequential. When it comes to requesting for transcoded TS segments it is done sequentially. I can see in my httpd logs for some of my friends that their device will request a lot of segments back to back, which it always does for playback start, but I also see it in the middle of playback and I can see one request duration will be really long, like 10+ seconds, and then it requests for a bunch of segments that take <100ms so they have something going on on their end that is causing delays and it has to wait for that segment to complete before it can ask for the next one. I know it's not me because I can have multiple transcoded streams going and only theirs shows TS segments like that.

Ideally you want to direct play HEVC content because it's smaller at the same quality level (and going forward, AV1 is even smaller at the same quality) which is friendlier over the internet.

Most carriers around here are symmetrical fiber unless they throttle the upload like our older plan. Which is 700 down and 400 up. My relative is on 1Gig symmetrical. Obviously it still isn't guaranteed as its residential. The 1.5x explains why the bitrate shows higher than source when it was transcoding 4K HEVC to 4K H264. So distance will always be the killer of direct play then, since most times that is one of main reasons for higher latency. Obviously there are other factors but they are less likely with modern hardware.

 

With how easily something like the P620 can do a transcode on a 80GB 4K HEVC file, I wonder if I should even keep the 1080p copies of the movies I have in 4K. Is it better to transcode from 4K to 1080p and reduce the HDR and require tonemapping, or is it better to direct play 1080p non-HDR? Does 4K 80Mb to 1080p 20Mb have the exact same size stream as a direct play 1080p 20Mb source?

[Lessaj 301]

23 minutes ago, ZACHxAxROO said:

Most carriers around here are symmetrical fiber unless they throttle the upload like our older plan. Which is 700 down and 400 up. My relative is on 1Gig symmetrical. Obviously it still isn't guaranteed as its residential. The 1.5x explains why the bitrate shows higher than source when it was transcoding 4K HEVC to 4K H264. So distance will always be the killer of direct play then, since most times that is one of main reasons for higher latency. Obviously there are other factors but they are less likely with modern hardware.

 

With how easily something like the P620 can do a transcode on a 80GB 4K HEVC file, I wonder if I should even keep the 1080p copies of the movies I have in 4K. Is it better to transcode from 4K to 1080p and reduce the HDR and require tonemapping, or is it better to direct play 1080p non-HDR? Does 4K 80Mb to 1080p 20Mb have the exact same size stream as a direct play 1080p 20Mb source?

Based on that both of your connections are fast enough "in theory" to be able to direct play anything. Sometimes it can take some time for the speed of a connection to ramp, but once it starts playing it should be fine. Direct play vs segments is definitely different to measure and understand, segments are pretty easy and straightforward to figure out but direct play requests the original file (typically mkv in my case) so it appears as one request and I only get the size/duration when the client "finishes" the request, whether that's when you're near the end of playback and it has the rest of the file, or when you skip around the file and it has to request from a different start position, or when you actually stop playback. You have to look with network monitoring tools to see things like outgoing bitrate to that IP or look at the buffers with netstat to see if you see a buffer draining slowly or not to figure out if there's a problem, and then probably further with network captures to figure out if it's you or them or something inbetween.

I think it's cheaper in the long run to store the 1080p version as well since it takes energy to transcode but once the data is written to the drive it just sits there, and a drive spinning uses less power than even an idle GPU. Granted you still have to purchase the drive(s) so it depends what you want to spend money on, drives or power bill. However I will throw another caveat here which is if you merge the versions together it's likely going to play the 4k file if it can unless you've put some bandwidth restrictions in place to prevent that, so people might just hit play, it defaults to the 4k, and they complain to you when it stutters.  Tone mapping to SDR still doesn't really achieve what an SDR version looks like to me, you may need to evaluate that with A and B comparisons if you're okay with that. A 4k 80 Mbps transcoded to 1080p 20 Mbps should still be the same size over the network as a direct play 1080p 20 Mbps, but only if that is a constant bitrate and not variable.

[ZACHxAxROO 4]

18 hours ago, Lessaj said:

Based on that both of your connections are fast enough "in theory" to be able to direct play anything. Sometimes it can take some time for the speed of a connection to ramp, but once it starts playing it should be fine. Direct play vs segments is definitely different to measure and understand, segments are pretty easy and straightforward to figure out but direct play requests the original file (typically mkv in my case) so it appears as one request and I only get the size/duration when the client "finishes" the request, whether that's when you're near the end of playback and it has the rest of the file, or when you skip around the file and it has to request from a different start position, or when you actually stop playback. You have to look with network monitoring tools to see things like outgoing bitrate to that IP or look at the buffers with netstat to see if you see a buffer draining slowly or not to figure out if there's a problem, and then probably further with network captures to figure out if it's you or them or something inbetween.

I think it's cheaper in the long run to store the 1080p version as well since it takes energy to transcode but once the data is written to the drive it just sits there, and a drive spinning uses less power than even an idle GPU. Granted you still have to purchase the drive(s) so it depends what you want to spend money on, drives or power bill. However I will throw another caveat here which is if you merge the versions together it's likely going to play the 4k file if it can unless you've put some bandwidth restrictions in place to prevent that, so people might just hit play, it defaults to the 4k, and they complain to you when it stutters.  Tone mapping to SDR still doesn't really achieve what an SDR version looks like to me, you may need to evaluate that with A and B comparisons if you're okay with that. A 4k 80 Mbps transcoded to 1080p 20 Mbps should still be the same size over the network as a direct play 1080p 20 Mbps, but only if that is a constant bitrate and not variable.

Yeah, bitrate has far to many variances to be identical. I guess I will just have to to let them know to try the 4K version and if it doesn't play like they want, then switch to the 1080p version. I'm looking to redo some of my 1080p to better quality but the rest will be stuck as okay quality 1080p. Thank you for the detailed explanations!