Jump to content

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


Alefielm
Go to solution Solved by crusher11,

Recommended Posts

Alefielm

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 by Alefielm
Link to comment
Share on other sites

rechigo

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 by rechigo
  • Like 3
Link to comment
Share on other sites

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

Link to comment
Share on other sites

Alefielm

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.

Link to comment
Share on other sites

  • Solution
crusher11

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.

  • Like 5
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

rechigo

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

Link to comment
Share on other sites

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 by cayars
Link to comment
Share on other sites

pwhodges

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

maegibbons

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Happy2Play

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.

  • Like 1
Link to comment
Share on other sites

maegibbons

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

Link to comment
Share on other sites

pwhodges

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

Link to comment
Share on other sites

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:

 

5e7bed863d990_graph_example.jpg

 

 

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..

  • Like 1
Link to comment
Share on other sites

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.

 

5e7c044c43f21_Quicktest.jpg

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...