Emby never Direct Playing any media on any client

[cochize1 42]

Hold on, you mean I can restart the server without user knowing it when all active streams are Direct Play?

[Luke 37253]

37 minutes ago, cochize1 said:

Hold on, you mean I can restart the server without user knowing it when all active streams are Direct Play?

We don't recommend it, but you might get lucky.

[Carlo 4331]

1 hour ago, cochize1 said:

Hold on, you mean I can restart the server without user knowing it when all active streams are Direct Play?

I was referring to "direct file playing" where the client is playing the file directly from the file system as GrimReaper had mentioned.

This is not the same as the normal "Direct Play" you see in the console that works with all devices.

With that said, if you have a pretty fast server that can restart quickly, you sometimes can do this with regular direct play streams as well and get away with it if the client buffer is full and the server has restarted before the client buffer goes dry. Don't do it if transcoding or direct streaming. A much safer bet that will work far more often (direct play only) is to pause the client, restart the server, then continue playback.

Keep in mind we're talking about existing files already on the server and not live TV or anything like that. I certainly wouldn't try this the first time during a family movie night.  Try it if you must when its only you playing something back. As Luke pointed out it's not something we advocate doing, but sometimes can be done under the right circumstances.

[cochize1 42]

Just to clarify, does this is definition of Direct Stream (converting to compatible container), because it shows in Grafana as Transcoding?

[GrimReaper 3330]

13 minutes ago, cochize1 said:

does this is definition of Direct Stream (converting to compatible container)

Yes.

https://emby.media/support/articles/DirectPlay-Stream-Transcoding.html

Edited September 15, 2023 by GrimReaper

[Bagul 149]

21 hours ago, GrimReaper said:

Are you actually checking within Emby Dashboard that items are DirectStreaming or relying only on your Grafana stats? If theye were, there would be ffmpeg-remux logs created for each session. And I've often seen same happening when using external tool - Playback Reporting plugin - reporting DirectStream when the item is DirectPlayed and surmised it must've been doing interpreting even DirectPlay over http as DirectStream in some circumstances.

Speaking of, have just one like that currently:

 

 

When making an API call to Emby, the PlayMethod attribute given by the api is direct stream for direct play and transcode for direct stream.
That's why the exporter and plugin don't display the right value, I think.

[GrimReaper 3330]

36 minutes ago, Bagul said:

When making an API call to Emby, the PlayMethod attribute given by the api is direct stream for direct play and transcode for direct stream.
That's why the exporter and plugin don't display the right value, I think.

You appear to be right, DirectPlay/DirectStream/Transcode examples below. That would make this a core issue, @Luke, if both Exporter and PR plugin are (likely) using API calls?

"PlayState": {
      "PositionTicks": 122472720,
      "CanSeek": true,
      "IsPaused": false,
      "IsMuted": false,
      "VolumeLevel": 54,
      "AudioStreamIndex": 1,
      "SubtitleStreamIndex": 2,
      "MediaSourceId": "ba89b646c7d464a6d84bf876dafb980c",
      "PlayMethod": "DirectStream",
      "RepeatMode": "RepeatNone",
      "SubtitleOffset": 0,
      "PlaybackRate": 1
    }

"PlayState": {
      "PositionTicks": 243760420,
      "CanSeek": true,
      "IsPaused": false,
      "IsMuted": false,
      "VolumeLevel": 54,
      "AudioStreamIndex": 1,
      "SubtitleStreamIndex": -1,
      "MediaSourceId": "e7b7d3363b5a745a398c45d6040abc95",
      "PlayMethod": "Transcode",
      "RepeatMode": "RepeatNone",
      "SubtitleOffset": 0,
      "PlaybackRate": 1
    }

{
    "PlayState": {
      "PositionTicks": 1293798750,
      "CanSeek": true,
      "IsPaused": false,
      "IsMuted": false,
      "VolumeLevel": 54,
      "AudioStreamIndex": 1,
      "SubtitleStreamIndex": -1,
      "MediaSourceId": "e7b7d3363b5a745a398c45d6040abc95",
      "PlayMethod": "Transcode",
      "RepeatMode": "RepeatNone",
      "SubtitleOffset": 0,
      "PlaybackRate": 1
    }

 

[cochize1 42]

Did I just accidently found a bug?:)

[Bagul 149]

I don't think this is a bug. If there's a direct stream and there's a conversion from one container to another, it's probably considered a transcoding because ffmpeg comes into play. There are other attributes such as "TranscodingInfo.IsVideoDirect" or "TranscodingInfo.IsAudioDirect" or "TranscodeReasons".
I think I need to modify the exporter by finding the right attributes to correctly detect the status.

Edited September 15, 2023 by Bagul

[GrimReaper 3330]

7 minutes ago, Bagul said:

I don't think this is a bug. If there's a direct stream and there's a conversion from one container to another, it's probably considered a transcoding because ffmpeg comes into play.

You don't want to go there, it is a long-standing (neverending) debate which pops-up in regular intervals about what should or should not be considered DirectPlayed, Streamed or Transcoded - current (and has been for a long time) schema in Emby is:

https://emby.media/support/articles/DirectPlay-Stream-Transcoding.html

So, 

7 minutes ago, Bagul said:

If there's a direct stream and there's a conversion from one container to another, it's probably considered a transcoding

It's not, it's considered DirectStream in Emby's nomenclature. 

As long as video track is untouched, nothing is considered Transcoding. 

Edited September 15, 2023 by GrimReaper

[Bagul 149]

6 minutes ago, GrimReaper said:

You don't want to go there, it is a long-standing (neverending) debate which pops-up in regular intervals about what should or should not be considered DirectPlayed, Streamed or Transcoded - current (and has been for a long time) schema in Emby is:

https://emby.media/support/articles/DirectPlay-Stream-Transcoding.html

So, 

It's not, it's considered DirectStream in Emby's nomenclarute. 

I misspoke (English...) Ahah
I was talking about the api that returns transcoding during a "DirectStream", maybe because ffmpeg comes into play and Emby's dashboard determines the DirectStream with other attributes returned by the API.

But maybe @Lukecan enlighten me.

[GrimReaper 3330]

6 minutes ago, Bagul said:

I was talking about the api that returns transcoding during a "DirectStream", maybe because ffmpeg comes into play and Emby's dashboard determines the DirectStream with other attributes returned by the API.

You (or whoever else might be utilising API calls) might implement additional logic to determine that as all the info to base the decision on is already there, though that doesn't solve discrepancy between returned results and established nomenclature, as, for example, DirectPlayed item should not return PlayMethod: DirectStream (though some of us would advocate that IS DirectStream since it's delivered over http), but as said, I'd avoid going there again.

Edited September 15, 2023 by GrimReaper

[Luke 37253]

26 minutes ago, GrimReaper said:

You don't want to go there, it is a long-standing (neverending) debate which pops-up in regular intervals about what should or should not be considered DirectPlayed, Streamed or Transcoded - current (and has been for a long time) schema in Emby is:

https://emby.media/support/articles/DirectPlay-Stream-Transcoding.html

So, 

It's not, it's considered DirectStream in Emby's nomenclature. 

As long as video track is untouched, nothing is considered Transcoding. 

Actually the newest solution that you see in the server dashboard is to not have any nomenclature and just indicate how the video and audio are served. this erases all confusion.

[GrimReaper 3330]

1 minute ago, Luke said:

Actually the newest solution that you see in the server dashboard is to not have any nomenclature and just indicate how the video and audio are served. this erases all confusion. 

Not sure how an item that is DirectPlayed having PlayMethod:DirectStream does that.

 

[Luke 37253]

5 minutes ago, GrimReaper said:

Not sure how an item that is DirectPlayed having PlayMethod:DirectStream does that.

 

No idea what you're trying to say, but this is one case where I would not try to correlate the api output with what you see on screen. The api output is done in a way that makes sense for developers. What you see on screen is done in a way that makes sense for users.

 

[GrimReaper 3330]

31 minutes ago, Luke said:

No idea what you're trying to say

57 minutes ago, GrimReaper said:

DirectPlayed item should not return PlayMethod: DirectStream

1 hour ago, GrimReaper said:

i

"PlayState": {
      "PositionTicks": 122472720,
      "CanSeek": true,
      "IsPaused": false,
      "IsMuted": false,
      "VolumeLevel": 54,
      "AudioStreamIndex": 1,
      "SubtitleStreamIndex": 2,
      "MediaSourceId": "ba89b646c7d464a6d84bf876dafb980c",
      "PlayMethod": "DirectStream",
      "RepeatMode": "RepeatNone",
      "SubtitleOffset": 0,
      "PlaybackRate": 1
    }

 

 

32 minutes ago, Luke said:

but this is one case where I would not try to correlate the api output with what you see on screen. The api output is done in a way that makes sense for developers. What you see on screen is done in a way that makes sense for users.

That correlation is what stemmed this whole thread - as at least two devs (Emby Exporter and Playback Reporting plugin) are relying on it and expecting it to report PlayMethod as Emby itself stipulated for a long time, hence reported results do not correlate to expected results/what is evidenced in the Dashboard.

[Luke 37253]

We created those values a long time ago, however they are too raw to display directly to end users. Doing that will result in nothing but question and answering. So the way they are displayed has changed bit in Emby apps over time.

[jaycedk 399]

I guess the API should reflect Emby's decision, and display the API as what the Dashboard is showing.

Other wise devs, user will be running in circles around this forever. 

Edited September 15, 2023 by jaycedk
Spelling

[GrimReaper 3330]

52 minutes ago, Luke said:

Doing that will result in nothing but question and answering.

As opposed to now?

52 minutes ago, Luke said:

So the way they are displayed has changed bit in Emby apps over time.

I feel like we're running in circles or you're deliberately sidelining it - it is not about what's displayed in the Dashboard or presented to end users - it is about the API not returning results in respect to well established Emby's own nomenclature.

3 hours ago, Bagul said:

When making an API call to Emby, the PlayMethod attribute given by the api is direct stream for direct play and transcode for direct stream.

Funny thing is, I completely agree with the above, and still remember last occurrence when we had same discussion, where @CBers, @rbjtechand myself advocated for DirectStream to denote delivery protocol as we still had File access widespread in AndroidTV app and have it reference file delivered as-is over http to discern same happening with direct file access which would be DirectPlay only, and have Remux category implemented in addition, to cover cases where audio remux/container swap was required (what is currently covered under DirectStream), in addition to Transcoding. And I still remember both you and @ebrvehemently defending your stance that delivery method is irrelevant since item is untouched and that DirectPlay should apply to both delivery methods and DirectStream to cover other scenarios where video track is untouched. And now you're stating that item that it is DirectPlayed should report in API call as DirectStreamed? Can't have it both ways, if that is the new norm now, it should be clearly communicated to the devs and KB article appended or removed altogether, as only audio remux (currently considered DirectStream) also gets reported as PlayMethod: Transcode in the API now.

Edited September 15, 2023 by GrimReaper

[rbjtech 4333]

The only people that care are the people that know the difference.   The reason DirectPlay is incorrectly being used is because that's what Plex are showing (they are fooling their customers) - and Emby want to be seen to be on-par with them and rightly or wrongly, don't want the questions on why emby is not 'DirectPlay' when Plex is.

I'll remain with my stance, that nothing can be 'Direct' if it goes VIA another transformation or service - the only 'DirectPlay' should be via Theatre using the optional paths for direct file system access NOT using emby server to 'transform' file(smb/nfs etc) to an http stream.   Thus ALL connections via http, should be DirectStream - what the stream contains, is the next level of detail.  

Anyway .. I think there are a lot more priorities in Emby I'd like to get resolved first - so I'll move along ... 

Edited September 15, 2023 by rbjtech

[speechles 1929]

Let me explain the issue. Once you see the issue you can see how to solve it is exactly as Emby has done.

First off, the Roku cannot Direct Play anything in the truest sense of the word. It isn't possible. No way, shape, or form. It is ALWAYS either direct streaming or transcoding. The Roku cannot interface with network names, or any other protocols except HTTP. It is a streaming device.

Now lets look at Plex and see on the Roku they claim to Direct Play. But.. we know this isn't possible. So are they lying? No.. They want to give the user the best impression. They call this Direct Play because that is the BEST you can get.

At first Emby was being completely honest. This was causing people to think Emby was inferior at streaming. Why does Plex claim to Direct Play so much when Emby is always Direct Streaming?

A debate began about the best way to approach this. We settled on matching terminology. So that the consumer (read as you) would have the same information regardless of whether this is Plex or Emby. We use the same thing. To get the Direct Play to show, you must copy the video stream., not convert it. A repackage of the container is acceptable and is noted in the streaming details. The video and audio streams are marked as Direct Play. The container is not.

It has been this way for a very long time. You need to read the session and then look for the transcoding info if there is any. If there is not the container is Direct Playing. If there is transcoding info there is an isDirectPlay field attached to both the video and audio streams in the session json returned. You need to match the terminology as Emby is doing. Otherwise you will confuse people.

Does this help explain why this is done? Do you see any better way?

Edited September 15, 2023 by speechles

[jaycedk 399]

I try one more time

1 hour ago, jaycedk said:

I guess the API should reflect Emby's decision, and display the API as what the Dashboard is showing.

Other wise devs, user will be running in circles around this forever. 

If that was the case, then this discussion would not have taken place.

Edited September 15, 2023 by jaycedk
Adding

[GrimReaper 3330]

46 minutes ago, speechles said:

You need to read the session and then look for the transcoding info if there is any. If there is not the container is Direct Playing. If there is transcoding info there is an isDirectPlay field attached to both the video and audio streams in the session json returned.

As said:

3 hours ago, GrimReaper said:

You (or whoever else might be utilising API calls) might implement additional logic to determine that as all the info to base the decision on is already there

i.e. isDirectPlay for both Video and Audio streams. That ain't the issue. Issue is that Emby put itself into the corner using same terminology for different scenarios:

1. DirectPlayed item (actually DirectStreamed) gets reported PlayMethod: DirectStream in API. User using some external tool or plugin sees DirectStream and wonders why it ain't DirectPlaying (this actual case); In reality, Emby is reporting correctly as it IS DirectStreaming, and since DirectStreaming impact is generally negligible/non-existent and probably not worth investigating further; some might, tho, like the OP.

2. DirectStreamed item (audio remux for example) gets reported PlayMethod: Transcode in API (again, reported correctly). BUT User using some external tool or plugin sees Transcoding and (rightfully) wonders why, as it should be DirectStreaming - knowing that Transcoding usually means high(er) impact on server machine (while in reality it was likely just negligble audio remux) completely unnecessary investigation is very likely to ensue, as why is it transcoding? 

As API calls are primarily directed towards 3rd party devs/advanced users and generally are of no interest to majority of users, PlayMethod argument should not use same terminology, as that would alleviate any confusion: they're not intended for average users, and devs would not need to know that DirectStream in API call does not mean DirectStream as we are all familiar with and denoted in KB article. I reckon very few devs and advanced users knew that distinction till now, myself included.

Edited September 15, 2023 by GrimReaper

[speechles 1929]

Lets make this easier to understand. Then you will see that one of the terms would never be used.

39 minutes ago, GrimReaper said:

As said:

i.e. isDirectPlay for both Video and Audio streams. That ain't the issue. Issue is that Emby put itself into the corner using same terminology for different scenarios:

1. DirectPlayed item (actually DirectStreamed) gets reported PlayMethod: DirectStream in API. User using some external tool or plugin sees DirectStream and wonders why it ain't DirectPlaying (this actual case); In reality, Emby is reporting correctly as it IS DirectStreaming, and since DirectStreaming impact is generally negligible/non-existent and probably not worth investigating further; some might, tho, like the OP.

Anything using Emby URL's to play media rather than direct network/data access is never using Direct Play. As stated before there are very few apps which Direct Play and in doing so have to report back the playback state and watched status from their renderer back to Emby. As Direct Play is not using Emby to play. It is access the file directly. I know Kodi can Direct Play. Emby Theater can Direct Play. Android TV can Direct Play if told to in settings. Any other apps you know of?

39 minutes ago, GrimReaper said:

2. DirectStreamed item (audio remux for example) gets reported PlayMethod: Transcode in API (again, reported correctly). BUT User using some external tool or plugin sees Transcoding and (rightfully) wonders why, as it should be DirectStreaming - knowing that Transcoding usually means high(er) impact on server machine (while in reality it was likely just negligble audio remux) completely unnecessary investigation is very likely to ensue, as why is it transcoding?

Everything using an Emby URL is sent via direct streaming. Since you must because it is sent over HTTP.

Then there is full on transcoding where Emby has to hand off to ffmpeg to do some of the lifting.

Now we do not need to know which streams are copied or anything to use this method. But since Emby is the software handling URL conversion it is always direct streaming if you read that part of the payload and that PlayMethod. It will always be direct streaming or transcoding.

 

Therefore, Emby does do a little bit more to read the streams inside and see how they are being sent. Rather than just is the protocol using a file:// (directplay) type access or http:// (directstreaming/transcoding) type access? Because 99.9(999999)% of the time for users it will say Direct Stream all the time if we did that.

@rbjtech Is correct. But if we always used that method people would be upset because we are weaker than the competition. Rather than confuse users entirely we just went maybe we can just follow their lead and then blame them or something. At least then it would put us on even footing with them. That is sorta what is happening. You are correct.

Since the PlayMethod via the API is for developers it should use the actual value. The developer should be smart enough to clean this up for a user display afterwards. That is my thinking.

 

Edited September 15, 2023 by speechles

[Luke 37253]

2 hours ago, GrimReaper said:

As opposed to now?

I feel like we're running in circles or you're deliberately sidelining it - it is not about what's displayed in the Dashboard or presented to end users - it is about the API not returning results in respect to well established Emby's own nomenclature.

Funny thing is, I completely agree with the above, and still remember last occurrence when we had same discussion, where @CBers, @rbjtechand myself advocated for DirectStream to denote delivery protocol as we still had File access widespread in AndroidTV app and have it reference file delivered as-is over http to discern same happening with direct file access which would be DirectPlay only, and have Remux category implemented in addition, to cover cases where audio remux/container swap was required (what is currently covered under DirectStream), in addition to Transcoding. And I still remember both you and @ebrvehemently defending your stance that delivery method is irrelevant since item is untouched and that DirectPlay should apply to both delivery methods and DirectStream to cover other scenarios where video track is untouched. And now you're stating that item that it is DirectPlayed should report in API call as DirectStreamed? Can't have it both ways, if that is the new norm now, it should be clearly communicated to the devs and KB article appended or removed altogether, as only audio remux (currently considered DirectStream) also gets reported as PlayMethod: Transcode in the API now.

Well the original question here I thought was about what some other app was displaying.