Why transcode video when only audio can't be DirecStreamed?

[Alefielm 7]

Hi, I'm trying to play this from Emby 4.4.0.40 Linux to Chromecast ultra using the Android app.

 

When paying it says is transcoding because of the unsupported audio (i'ts ok, Chromecast doesn't support AAC 5.1), my question is, why is Emby transcoding the video too to x264?

My server is on a RaspberryPi, so I try to get versions that doesn't need video encoding/conversion, so far I am streaming 4k 5.1 without problems.

 

Is there any configuration to force emby to transcode only the audio whem the problem is audio? I hope that can be achieved with a lot less cpu power than converting video too.

Thank you!

 

Video

Title1080p HEVC

CodecHEVC

Codec Taghev1

ProfileMain 10

Level120

Resolution1920x800

Aspect Ratio2.40:1

AnamorphicNo

InterlacedNo

Framerate23.976

Bitrate2,000 kbps

Bit Depth10 bit

Pixel Formatyuv420p10le

Reference Frames1

Audio

TitleEnglish AAC 5.1 (Default)

LanguageEnglish

CodecAAC

Codec Tagmp4a

ProfileLC

Layout5.1

Channels6 ch

Bitrate224 kbps

Sample Rate48,000 Hz

DefaultYes

Subtitle

TitleEnglish (SRT)

LanguageEnglish

CodecSRT

DefaultNo

ForcedNo

ExternalYes

Containermp4

Path/Movies/aaaa.mp4

Size1983MB

Edited March 24, 2020 by Alefielm

[rechigo 294]

The reason your video is transcoding as well is because DirectStreams use a streaming protocol called "HLS", which doesn't support HEVC, so the server must convert the video into a suitable format (h264)

 

Your options are:

1) Reencode the whole video to a suitable codec, OR 2) Either replace the audio track completely, or add a separate audio track that you can switch to that your device can direct play

Edited March 24, 2020 by rechigo

[Happy2Play 9142]

I think we need a sticky or wiki that explains this as were have way to many topics asking Why.

 

@@Luke

@@ebr

@@cayars

@@softworkz

[Luke 38842]

In the near future we're going to be exploring alternative protocols to allow for more flexibility. Thanks.

[Alefielm 7]

The reason your video is transcoding as well is because DirectStreams use a streaming protocol called "HLS", which doesn't support HEVC, so the server must convert the video into a suitable format (h264)

 

Your options are:

1) Reencode the whole video to a suitable codec, OR 2) Either replace the audio track completely, or add a separate audio track that you can switch to that your device can direct play

 

Then why when I stream HVEC 4k (with a suitable audio) it DirectStream without transcoding? I take your options, just want to understand the issue better.

[crusher11 901]

If both audio and video are compatible it doesn't direct stream, it direct plays.

 

If the audio needs to be converted, that new audio needs to be recombined with the video. That's the step HVEC isn't compatible with. When direct playing it just reads the file as is, and nothing needs to be combined, so it doesn't require anything to be altered.

[softworkz 4292]

I think we need a sticky or wiki that explains this as were have way to many topics asking Why.

 

@@Luke

@@ebr

@@cayars

@@softworkz

 

 

In the near future we're going to be exploring alternative protocols to allow for more flexibility. Thanks.

 

Some reference explanation would still be a good idea for the current situation, I think.

[Carlo 4483]

I agree softworkz.  I'll see what I can come up with.

[Guest asrequested]

If both audio and video are compatible it doesn't direct stream, it direct plays.

 

Not completely correct. If the player doesn't have direct access, it will direct stream. If the player doesn't support the container, it will direct stream.

[softworkz 4292]

Not completely correct. If the player doesn't have direct access, it will direct stream. If the player doesn't support the container, it will direct stream.

 

Correct.

 

PS: Glad you're back!

[rechigo 294]

Not completely correct. If the player doesn't have direct access, it will direct stream. If the player doesn't support the container, it will direct stream.

What do you mean by "player doesn't have direct access"

 

Sent from my SM-G973U using Tapatalk

[Carlo 4483]

What kind of definition are you guys using for "Direct Play"?

 

Direct Play long time back used to mean the video was played off the HDD subsystem using OS file system hooks directly, but this is not what Direct Play means anymore in Emby Speak.

 

So I just want to clear that up and make sure you guys are talking about this correctly.

Edited March 25, 2020 by cayars

[pwhodges 1744]

As I understand it, Direct Play means that the file is sent on for playing without change.  Direct Stream means that the audio and video streams are unchanged (no transcoding), but are repackaged in a new container because the client doesn't handle the original container (e.g. mkv).

 

Paul

[ebr 15436]

As I understand it, Direct Play means that the file is sent on for playing without change.  Direct Stream means that the audio and video streams are unchanged (no transcoding), but are repackaged in a new container because the client doesn't handle the original container (e.g. mkv).

 

Paul

 

That is correct and the below is not:

 

 

Not completely correct. If the player doesn't have direct access, it will direct stream.

 

The player doesn't need "direct access" to the media for it to be direct played (which means played with no modifications whatsoever).

[softworkz 4292]

That is correct and the below is not:

 

 

 

The player doesn't need "direct access" to the media for it to be direct played (which means played with no modifications whatsoever).

 

I would understand "direct access" as the ability to randomly read arbitrary sections of a file ("random access") as opposed to using a streaming protocol.

 

Random file access is possible on local file systems of course, on LANs (e.g. via SMB) but also on WANs (e.g. http with support for range requests).

[softworkz 4292]

You could also say that the client directly accesses the _original_ video file - which isn't happening in the two other cases.

I'm not quite sure what would be wrong about that?

[maegibbons 1268]

I would like "Direct Access" to a networked nas share to be possible from Android TV so that the Server is avoided where possible.

 

I understand this is available in Emby Theatre.

 

So can we have feature compatability in the Android TV app please.

 

Krs

 

Mark

 

Sent from my SM-N976B using Tapatalk

[ebr 15436]

I would understand "direct access" as the ability to randomly read arbitrary sections of a file ("random access") as opposed to using a streaming protocol.

 

Random file access is possible on local file systems of course, on LANs (e.g. via SMB) but also on WANs (e.g. http with support for range requests).

 

When he says "direct access" he means the file is being read directly from its location via a file protocol as opposed to being fed by the server over http.  We do not require that situation to call something "direct play".  Direct Play just means the file is being played with no modifications.  Exactly how the file is delivered to the app is not a factor.

[ebr 15436]

I would like "Direct Access" to a networked nas share to be possible from Android TV so that the Server is avoided where possible.

 

I understand this is available in Emby Theatre.

 

So can we have feature compatability in the Android TV app please.

 

Krs

 

Mark

 

Sent from my SM-N976B using Tapatalk

 

We've been over this a lot and you've been a part of those discussions.  The benefit that would provide (extremely minimal) does not currently outweigh the support requirement it would create due to the complications in providing direct access to remote file systems in Android.

[Carlo 4483]

Here is what has been in the wiki/knowledge base: https://support.emby.media/a/solutions/articles/44001920144

If anyone sees anything needing change let me know.  I'll likely add some info to this page or at least a link on this page with info from this thread.

 

Direct Play

Media file is used AS IS without any modification. It can be sent from the Emby server or (some clients) allowed to be played directly from the file system. The media fits all the criteria needed by the client including:

• Stored in a compatible file container playable by the client
• Encoded with compatible codecs for the client
• Encoded with a compatible bit rate for the client
• Has a resolution compatible with the client

Direct Stream

Also known as transmuxing. The Media file is altered in real-time while being delivered to the client. This happens when the container of the media file is not compatible with the client, (.avi, .wmv, .ts, etc), but the resolution, bitrate, and codecs are supported.

In this case the server extracts the internal tracks of the media file such as the video, audio & subtitle tracks and rewrites the file in real-time to a compatible container format the client does support.

Direct Streaming does not touch the video or audio tracks in anyway so there is no loss of quality.

Transcoding

Transcoding takes place when one or more tracks in the media file are not compatible with the client app. This could be the video codec, audio codec, or subtitle being used. The media file could have a higher resolution then requested by the client app or the bit rate of the file could be higher then the client can presently use.

Transcoding at a high level, is taking already encoded content; decoding it; and then altering it. After altering, it is then reassembled/encoded back into a format compatible with the client app and the current settings it is using.

As an example, you might change the audio and/or video format (codec) from one to another, such as converting from an MPEG2 source (commonly used in broadcast television) to H.264 video and AAC audio (the most popular codecs for streaming).

Transcoding only the audio track is a light weight process. Transcoding video can be very taxing on the CPU in the server depending on the resolution, bitrate and codecs being used.

[Happy2Play 9142]

Here is what has been in the wiki/knowledge base: https://support.emby.media/a/solutions/articles/44001920144

If anyone sees anything needing change let me know.  I'll likely add some info to this page or at least a link on this page with info from this thread.

 

Direct Play

Media file is used AS IS without any modification. It can be sent from the Emby server or (some clients) allowed to be played directly from the file system. The media fits all the criteria needed by the client including:

• Stored in a compatible file container playable by the client
• Encoded with compatible codecs for the client
• Encoded with a compatible bit rate for the client
• Has a resolution compatible with the client

Direct Stream

Also known as transmuxing. The Media file is altered in real-time while being delivered to the client. This happens when the container of the media file is not compatible with the client, (.avi, .wmv, .ts, etc), but the resolution, bitrate, and codecs are supported.

In this case the server extracts the internal tracks of the media file such as the video, audio & subtitle tracks and rewrites the file in real-time to a compatible container format the client does support.

Direct Streaming does not touch the video or audio tracks in anyway so there is no loss of quality.

Transcoding

Transcoding takes place when one or more tracks in the media file are not compatible with the client app. This could be the video codec, audio codec, or subtitle being used. The media file could have a higher resolution then requested by the client app or the bit rate of the file could be higher then the client can presently use.

Transcoding at a high level, is taking already encoded content; decoding it; and then altering it. After altering, it is then reassembled/encoded back into a format compatible with the client app and the current settings it is using.

As an example, you might change the audio and/or video format (codec) from one to another, such as converting from an MPEG2 source (commonly used in broadcast television) to H.264 video and AAC audio (the most popular codecs for streaming).

Transcoding only the audio track is a light weight process. Transcoding video can be very taxing on the CPU in the server depending on the resolution, bitrate and codecs being used.

 

This is still a conflict of Emby's usage/display of these terms.

 

Direct Play is displayed when Emby streams the media.

 

Emby considers changing the Audio track as a Direct Stream.

 

Transcoding only appears if the Video track needs converting.

[maegibbons 1268]

We've been over this a lot and you've been a part of those discussions. The benefit that would provide (extremely minimal) does not currently outweigh the support requirement it would create due to the complications in providing direct access to remote file systems in Android.

Ok Mr Touchy

 

File explorers seem to connect to my NAS from Android just fine.

 

Excluding features in emby clients just because they could cause some support work is not the right development philosophy.

 

Reminding you of features we would like is surely a good thing from your user base.

 

This probably has not come up for 12 months so I am just restating their is a case for it whether you like it or not.

 

And I did think that client app compatability was an emby goal these days.

 

Krs

 

Mark

 

 

 

 

Sent from my SM-N976B using Tapatalk

[pwhodges 1744]

Emby considers changing the Audio track as a Direct Stream.

 

Transcoding only appears if the Video track needs converting.

 

I am sad that there is no indication of audio transcoding.  Is there any reason not to specify which streams are being transcoded?  E.g., after the word Transcoding show (video, audio) or even just (V, A) in brackets as appropriate.  Not that i'd make a fuss about it, you understand, as I know audio is a much lesser deal than video in this regard...

 

Paul

[softworkz 4292]

I am sad that there is no indication of audio transcoding.  Is there any reason not to specify which streams are being transcoded?  E.g., after the word Transcoding show (video, audio) or even just (V, A) in brackets as appropriate.  Not that i'd make a fuss about it, you understand, as I know audio is a much lesser deal than video in this regard...

 

Paul

 

It's not that we wouldn't have that information in all detail:

 

 

 

The question is - what's reasonable to display within the available screen estate?

 

On the dashboard main page, there's not much space for the client cards and adding even more information would quickly make it appear overcrowded..

[Guest asrequested]

That is correct and the below is not:

 

 

 

The player doesn't need "direct access" to the media for it to be direct played (which means played with no modifications whatsoever).

 

Well yes indeed, I stand corrected. Without direct access, the server does stream the video, but is now reported as DirectPlay.