Direct Playing when should be Direct Streaming

[Malleyc94 0]

Hello

 

So according to https://emby.media/community/index.php?/topic/11297-transcoding-streamcopy-direct-play-direct-stream-help/

 

Direct play and direct stream are two different things. Direct play means that the client can access the file directly. IE it can see the windows shares. Direct stream means the client couldnt' see the file directly so the server is streaming it without transcoding.

 

However i have an out of network device connected to the sever (Chrome Web Player) playing a file and it shows up in the emby management interface as "Direct Playing" as this is out of my local network i expected this to be direct streaming. Here are the relevant log files i could find

 

Does this mean my SMB shares are accessible outside my network?? or am i missing something simple here

2016-10-03 04:07:53.3649 Info App: Profile: Unknown Profile, Path: \\server\Media\TVShows\Roadies\Season 1\Roadies - S01E01 - Life Is a Carnival SDTV.mkv, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2016-10-03 04:07:53.3663 Info App: RemoteClientBitrateLimit: 5000000, RemoteIp: my.friends.public.ip, IsInLocalNetwork: False
2016-10-03 04:07:53.3663 Info App: Profile: Unknown Profile, Path: \\server\Media\TVShows\Roadies\Season 1\Roadies - S01E01 - Life Is a Carnival SDTV.mkv, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2016-10-03 04:07:53.3663 Info App: RemoteClientBitrateLimit: 5000000, RemoteIp: my.friends.public.ip, IsInLocalNetwork: False
2016-10-03 04:07:53.3663 Info App: Profile: Unknown Profile, Path: \\server\Media\TVShows\Roadies\Season 1\Roadies - S01E01 - Life Is a Carnival SDTV.mkv, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2016-10-03 04:07:53.3663 Info HttpServer: HTTP Response 200 to my.friends.public.ip Time: 8ms. http://my.domain.name:8096/emby/Items/4354f6790de9f1dec556bb6068c7683b/PlaybackInfo?UserId=82cfb27f3f814de7b04f550ad8d418fb&StartTimeTicks=0
2016-10-03 04:07:54.0143 Info HttpServer: HTTP GET http://my.domain.name:8096/emby/Items/d2703cceab3d753d2da6b501160a2f04/Images/Backdrop/0?maxWidth=2560&tag=9f87f283b49fc3f7df51115a5479459e&quality=40. UserAgent: Mozilla/5.0 (Linux; Android 6.0.1; SM-G920I Build/MMB29K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.124 Mobile Safari/537.36
2016-10-03 04:07:54.0245 Info HttpServer: HTTP GET http://my.domain.name:8096/emby/Items/d2703cceab3d753d2da6b501160a2f04/Images/Primary?width=1600&tag=0b2efd472b42007727c8eee8d2c2d907&quality=50. UserAgent: Mozilla/5.0 (Linux; Android 6.0.1; SM-G920I Build/MMB29K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.124 Mobile Safari/537.36

 

* Edited logs to show only relevant info

Edited October 4, 2016 by Malleyc94

[Luke 42077]

Hi, they are the same thing. Can you please describe what your actual problem is? Is it failing to play? thanks.

[MSattler 390]

Hi, they are the same thing. Can you please describe what your actual problem is? Is it failing to play? thanks.

 

Um.... wrong.....

 

Come on Luke.... I mean everyone on here knows that you know the difference.

 

Direct Streaming = The content is going through the Emby server

Direct Play = The player can play the content directly from a storage server, and it does NOT have to go through the Emby server.

 

The only way DP is going to work is if the player has direct SMB access to the storage server, assuming the Emby server is NOT also the storage server.

 

But at some point it was deemed that both should be labeled as Direct Play when in reality they are not.

[Luke 42077]

It really depends on who the audience is. There is always an advanced segment but that is not the majority.

[Angelblue05 4132]

@@MSattler it's the same file is being played. Just the mean of distribution is different. But what matter is the end file being played. That's what really determines directly being played from transcoding. I, for one, do not want to see the term direct stream make a re-appearance. It was confusing to the user. And for plex users, the term doesn't even exist.

[MSattler 390]

It really depends on who the audience is. There is always an advanced segment but that is not the majority.

 

Perhaps.... so since most people don't know the difference between Direct Streaming and Direct Play, Emby will just label either as Direct Play.

 

I think it's reaching a bit, since Direct Streaming will never equal direct play in some very specific circumstances.

 

Last time I checked Plex still acknowledges a difference.

 

If you are worried about user perception then let's document the difference between the two.  But labeling direct stream as direct play is simply a lie.  Nothing short of it.

[Luke 42077]

Perhaps.... so since most people don't know the difference between Direct Streaming and Direct Play, Emby will just label either as Direct Play.

 

I think it's reaching a bit, since Direct Streaming will never equal direct play in some very specific circumstances.

 

Last time I checked Plex still acknowledges a difference.

 

If you are worried about user perception then let's document the difference between the two.  But labeling direct stream as direct play is simply a lie.  Nothing short of it.

 

Actually in their case, Direct Play covers both, Direct Stream = container swap without any encoding.

[Luke 42077]

But rather than get off topic, we should circle back to the original posting. Is there a failure or an error of some sort?

[MSattler 390]

@@MSattler it's the same file is being played. Just the mean of distribution is different. But what matter is the end file being played. That's what really determines directly being played from transcoding. I, for one, do not want to see the term direct stream make a re-appearance. It was confusing to the user. And for plex users, the term doesn't even exist.

 

Actually plex explains the difference pretty damn well:

 

https://support.plex.tv/hc/en-us/articles/200250387-Streaming-Media-Direct-Play-and-Direct-Stream

 

If we want to hide a term, then hide the term Direct Play, since 95% of the user base will never see Direct Play.  But labeling Direct Stream as Direct Play is simply wrong.  95% of your users cannot Direct Play because they don't have a seperate storage server.  So why would you label it something it won't be 95% of the time.

 

Unless someone is purposely trying to mislead potential Plex users coming over to Emby with the hope that they will get Direct Play.  Which in most cases they won't because they will direct stream.

 

The only way to truly direct play is via:

 

Emby Android Client + External Player playing from SMB

Kodi playing from SMB.

[MSattler 390]

But rather than get off topic, we should circle back to the original posting. Is there a failure or an error of some sort?

 

Re-read what he wrote.

 

It's saying Direct-Playin when i reality it is Direct-Streaming.

 

Because no where does it say that in Emby world Direct-Playing = Direct-Playing or Direct-Streaming.

[MSattler 390]

Actually in their case, Direct Play covers both, Direct Stream = container swap without any encoding.

 

Hmmm that goes against what it says here what it explains the differences pretty well.

 

Maybe we should just copy and paste that entire post and post it in the forums....

 

https://support.plex.tv/hc/en-us/articles/200250387-Streaming-Media-Direct-Play-and-Direct-Stream

Edited October 3, 2016 by MSattler

[Angelblue05 4132]

I've been using my brother's plex server. And it does not mention direct stream under usage. In fact it says it's direct playing from my remote location. They use this redirect HTTP path and it shows up as direct playing. Can you explain?

 

I've really been under the impression that Plex, even if explained in the wiki, does not mention direct stream when being reported. I've also seen a few plex user coming to me* under the impression they've been direct playing with plex. I ask for logs and it shows that HTTP path.

 

Anyhow, I do see your point, for the naming. But, the only distinction is how the file is provided. I think direct play and transcode are the only true quality in representing the file being played back.

Edited October 3, 2016 by Angelblue05

[Luke 42077]

 

Luke, on 03 Oct 2016 - 2:43 PM, said:

Actually in their case, Direct Play covers both, Direct Stream = container swap without any encoding.

 

Hmmm that goes against what it says here what it explains the differences pretty well.

 

Hmmm maybe we should just copy and paste that entire post and post it in the forums....

 

https://support.plex.tv/hc/en-us/articles/200250387-Streaming-Media-Direct-Play-and-Direct-Stream

 

 

I think your link proves my point because look at Direct Stream, it is a container swap

 

• The video and audio tracks are extracted from the original file;
• The streams are saved back into a compatible file container; 

[Luke 42077]

[speechles 2055]

There are two methods of direct file access:

Direct stream the unmodified file over an http path with emby

Direct Play the unmodified file over a network path without emby

 

Obviously direct play cant track resume, watched status and some other things since it goes around emby. Emby calls both methods above direct play, so does plex.

 

Here is where things get tricky, when remuxing:

The video track is copied and audio track is copied, only the container is changed. Technically this is a remux, it is a direct stream of both audio/video inside a new container. Plex calls this direct play, but really if it changes something and isnt using the original unmodified file its a remux. Silly plex calls this direct, when its actually a remux transcode.

 

Then there is full transcode of either the video stream, audio stream, or both. This involves converting those streams into a new codec, then package them into a new container. Plex calls this a transcode, so does emby. The one place they both agree.

Edited October 3, 2016 by speechles

[MSattler 390]

 

I think your link proves my point because look at Direct Stream, it is a container swap

 

• The video and audio tracks are extracted from the original file;
• The streams are saved back into a compatible file container; 

 

 

Fine, then label it as Direct Stream from the Admin panel.  Labeling everything as Direct Play is wrong, because as you said yourself, most users will never have Direct Play, because most of the user base will be Direct Streaming.  So why label the playback something it will never be, for most of your user base?

[MSattler 390]

Direct Play the unmodified file over a network path without emby

 

 

And that is my point of contention.  Don't label playback in Emby as Direct Play if it is really Direct Stream.   

 

It's stupid....  and honestly when I noticed the change I wondered how long it would be before people noticed it.

 

The only true way to figure out if it is direct playing or direct streaming is to check your Emby server network utilization.......   

[Angelblue05 4132]

Direct stream is not a true reflection of the state of a file being played.

 

Instead, I would rather see a transport label: HTTP/Network(or local), for example: Direct play/HTTP. In my opinion, it reflects the situation better than having the term Direct stream which makes it sound like a different file is being played.

 

I've spent countless time explaining this to users. In their view, they see direct stream as the original file not being played, and then they realize, after a lot of back and forth, that the only difference is how the file is accessed. The file itself is unchanged.

Edited October 3, 2016 by Angelblue05

[speechles 2055]

If you are using an emby app, with emby features you are most certainly 100% direct streaming. Same with plex. The problem is plex started calling this direct play. Now all emby did was follow the leader. If you want to correctly place blame on why it is that way, blame plex. It puts emby at a disadvantage to be honest and claim it is always really direct streaming.

 

People go, but plex is direct playing the file why cant emby? Then you shake your head, and smile, and try to tell them how it is the same thing. They argue, if it is the same why are different words used? This leads us nowhere you say, and you politely remind them it is the same thing and try to escape the conversation.

 

It really is the same thing technically. The minor difference, is emby serves the file over an http path rather than the OS over a network path. To argue semantics on how this isnt the same, is to argue that 1ply and 2ply toilet paper isnt the same. Technically, they are, they both clean your butt. The 1ply would be streaming over an http path. If emby crashes so does the path. 2ply is network path to the file. Even if emby crashes the file still continues to play. To the average user all this is miles over their head. All they need to know is if the file is direct or ran through ffmpeg. Emby accomplishes this.

 

I agree with @@Angelblue05 that it should be "direct/http" and "direct/network" to avoid the issue. Then you know its direct and if you care you can see its using an http via network path. This keeps it honest and adds the extra detail for advanced users.

Edited October 3, 2016 by speechles

[MSattler 390]

If you are using an emby app, with emby features you are most certainly 100% direct streaming. Same with plex. The problem is plex started calling this direct play. Now all emby did was follow the leader. If you want to correctly place blame on why it is that way, blame plex. It puts emby at a disadvantage to be honest and claim it is always really direct streaming.

 

People go, but plex is direct playing the file why cant emby? Then you shake your head, and smile, and try to tell them how it is the same thing. They argue, if it is the same why are different words used? This leads us nowhere you say, and you politely remind them it is the same thing and try to escape the conversation.

 

It really is the same thing technically. The minor difference, is emby serves the file over an http path rather than the OS over a network path. To argue semantics on how this isnt the same, is to argue that 1ply and 2ply toilet paper isnt the same. Technically, they are, they both clean your butt. The 1ply would be streaming over an http path. If emby crashes so does the path. 2ply is network path to the file. Even if emby crashes the file still continues to play. To the average user all this is miles over their head. All they need to know is if the file is direct or ran through ffmpeg. Emby accomplishes this.

 

Sent from my Nexus 7 using Tapatalk

 

While the file content is the same, the path being taken isn't the same.   I think AngelBlue's approach makes more sense, label it with the network transport method, and whether it is transcoded or not.

 

HTTP/Transcode

HTTP/Direct

SMB/Direct

SMB/Transcode

[speechles 2055]

While the file content is the same, the path being taken isn't the same. I think AngelBlue's approach makes more sense, label it with the network transport method, and whether it is transcoded or not.

 

HTTP/Transcode

HTTP/Direct

SMB/Direct

SMB/Transcode

The issue will be coordinate all the emby app/clients to follow suit. Having consistency and not confusing users requires @@Luke tell us the best course of action here? The rest of us will follow his command. Sort of like the cylons in battlestar galactica. By your command. Edited October 3, 2016 by speechles

[Angelblue05 4132]

Well, as far as emby for kodi is concerned, we still report directplay/stream and transcode. So really, it's just a matter of relabelling what's being shown in the dashboard. If it reports as direct play, then display Direct (Play)/Network, direct stream as Direct (Play)/HTTP.

Edited October 3, 2016 by Angelblue05

[speechles 2055]

Well, as far as emby for kodi is concerned, we still report directplay/stream and transcode. So really, it's just a matter of relabelling what's being shown in the dashboard. If it reports as direct play, then display Direct (Play)/Network, direct stream as Direct (Play)/HTTP.

Exactly. Internally we still use the same way we are now. But externally, for human display to users we can make it be whatever we want. This is what I meant.

 

Having luke come up with something will speed up adoption into all the other clients, rather than a few apps do, and some dont, and it all starts to look quite amateur hour. Having a unified presentation for users is important.

 

Sent from my Nexus 7 using Tapatalk

[Malleyc94 0]

Wow didn't quite expect this response!

Sounds like speechles hit the nail on the head.

 

I had seen direct streaming when playing content from a emby for Kodi device outside my local network. and therefore assumed the web player would also report direct streaming when outside my network.

 

Sent from my Nexus 5X using Tapatalk