Jump to content

Emby never Direct Playing any media on any client


cochize1

Recommended Posts

We don’t really see as many questions about this as we used to. Now we just show you the input and output and stop trying to give it a fancy name and I think that has helped eliminate confusion.

Link to comment
Share on other sites

GrimReaper
20 minutes ago, speechles said:

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. 

20 minutes ago, speechles said:

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

I honestly don't know why do you feel the need to explain that:

2 hours ago, GrimReaper said:

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 this discussion constantly steers towards what is presented to users: it is about what is returned in the API - I just gave you examples where it is currently giving wrong impression. API is fully technically correct, noone is debating that, but it's using terminology that has been used in a different context way more often/being presented to users for years and they've learned to tie it to specific circumstances. But since this debate is just repeating itself, let's call it quits, devs will eventually figure it out, as will few odd users.

@Bagulis likely following this topic and will adjust his tool accordingly.

@TeamB, would it be possible for you to do the same in Playback reporting plugin?

 

Link to comment
Share on other sites

GrimReaper
9 minutes ago, Luke said:

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

It was, but both the tool in question and PR plugin are relying only on API call PlayMethod argument, which has lead to this discussion altogether.

Link to comment
Share on other sites

3 minutes ago, GrimReaper said:

It was, but both the tool in question and PR plugin are relying only on API call PlayMethod argument, which has lead to this discussion altogether.

Right, other apps are free to display however they wish. We stopped trying to put a name on the overall play method. Instead it's either MKV -> Direct or MKV -> HLS (if hls is used).

And then same for the video and audio streams, e.g. HEVC -> Direct or HEVC -> H264

In other words, just showing Direct if it's untouched, or if it's converted, then showing what the output is. That removes the whole debate about what is direct play or direct stream, and for us, problem solved. The viewer can also see the protocol that it's being streamed from, and all of this is more explicit than before and no more questions about well if it's this protocol it's direct play or that protocol is direct stream blah blah, etc.

  • Like 1
  • Agree 2
Link to comment
Share on other sites

jaycedk

Not satisfied with that !!

My question is still not answered.

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

Its a quiet simple answered question.

1) can not

2) will not

3) And the good old ( Planed for the future )

Edited by jaycedk
Link to comment
Share on other sites

1 hour ago, jaycedk said:

Not satisfied with that !!

My question is still not answered.

Its a quiet simple answered question.

1) can not

2) will not

3) And the good old ( Planed for the future )

Actually I think that it does. All of the information that is there needs to be there. We can't take any out. However that doesn't mean it all gets displayed.

We don't display the value of PlayMethod anymore, but it is still used in the code and can't be removed. In most cases the code is only checking if PlayMethod equals Transcoding and doesn't care about the other possible values...so in theory PlayMethod could be removed and replaced with a new value that is just a yes or no.

But that's not easy to do when you've got apps on lots of platforms, including some apps on some devices that can't be updated anymore. I'm not going to risk breaking them over this.

It's just like anything else. You start with a foundation, make little changes over time as things evolve (but within reason), and then when it gets to a point where you need to completely replace it in order to do new things, then you do that, and that's when you get a chance to rethink all of these little things.

  • Like 1
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...