How to force Direct Play from remote ?

[snakuzzo 1]

Hi all,
When I play my movies...
if I'm on the same network of server I watch my movies in Direct Play, but when I'm away my movies are played in Direct Stream

Is there a way to fore Direct Play from remote ?

Thanks

[Abobader 3464]

Hello snakuzzo,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Happy2Play 9780]

Need a specific example to include server and ffmpeg log.  But there are to many variable to guess.  

It is about the client and the Remote connection, I guess on could disable user options for Media Playback but that may prevent the media from being playable all together as conditions require conversion.

[Carlo 4560]

@snakuzzo

[snakuzzo 1]

Hi all...thank you for the answer. I have to try reproducing a file... Now I'm away ... I think I can try in a couple of days 

[pwhodges 2012]

You cannot force Emby to direct play.  You have to ensure that it has no reasons not to do so.

Reasons Emby might not be able to direct play:

-- The client cannot handle an encoding in the file; this may be video, audio or subtitle format.
Note that the handling of one incompatibility may introduce another - for instance, transcoding audio might then require re-muxing, and that may then require video transcoding (because Emby's default streaming format when remuxing doesn't handle HEVC, for instance); or subtitles which need burning in require video transcoding as part of the burning-in process.

-- The bit rate of the file may be too great.
The possible bit rate is determined by: hardware and network limitations; rate limitations set within Emby Server for internal connections, external connections, or individual users - they may also be set in individual clients.  Transcoding is used to reduce the bit rate as specified.

When playing, use the cog menu to bring up "Stats for nerds" which will tell you the reason for transcoding - you can then correct the setting, or ask for advice on how to prevent it. Some information is also on the server dashboard (try clicking the (i) symbol related to the client connection for greater detail)  Note that the term "direct streaming" implies that the container has been changed - this is often because the audio is being transcoded (which is trivial), but not the video.

Note that the client speed setting of "Auto" has a reputation for misjudging things, so it's worth trying explicit settings which you are confident your system can handle.  

Paul

[Luke 42077]

@snakuzzo please let us know if this helps. thanks.

[snakuzzo 1]

Hi all.

...removing this flag now it works in Direct Play

 

Thank you all!

[Luke 42077]

1 minute ago, snakuzzo said:

Hi all.

...removing this flag now it works in Direct Play

 

Thank you all!

Please read the help text before coming back and reporting that something isn't playing correctly.

[broskratos 0]

 

On 3/15/2021 at 1:41 PM, snakuzzo said:

Hi all.

...removing this flag now it works in Direct Play

 

Thank you all!

Where you get this option? I do not have this.

[Luke 42077]

8 minutes ago, broskratos said:

 

Where you get this option? I do not have this.

Hi there, what are you trying to accomplish?

[Carlo 4560]

On 3/15/2021 at 3:41 AM, snakuzzo said:

Hi all.

...removing this flag now it works in Direct Play

 

Thank you all!

Newer versions of the server have a bit better wording for this option you find on the first tab when editing a user.

[Happy2Play 9780]

But this only works if clients are capable of playing the media.  Primarily transcode do to Auto playback quality.  If client is not capable your media will just error out.

[strezi 1]

Thanks snakuzzo and Carlo!
This setting - disabling all three options for the User - have fixed the choppy, transcoding playback on my setup.
Server: Intel 4770R far from capable of seamless HDR10 and DTSHD 7.1 or  DD HD MA transcoding, nor do I want / need it
Player: LG 65 C6 OLED

The player client clearly reports some of the above not present on the TV, but in practice it plays and sounds (again) smooth as butter(as it used to couple of versions ago) using Direct play for both video and audio streams! I will keep the updates disabled from now on . ..

[strezi 1]

Also tested this with an iPhone13 client, and the stuttering is gone there as well! Direct Play everywhere!

[Hellegaard 0]

Where is these settings located I can’t find them in Emby ?

[Luke 42077]

36 minutes ago, Hellegaard said:

Where is these settings located I can’t find them in Emby ?

Hi, what setting are you asking about? Emby will already direct play whenever possible. There’s nothing you need to do to force that.

[strezi 1]

1 hour ago, Luke said:

Hi, what setting are you asking about? Emby will already direct play whenever possible. There’s nothing you need to do to force that.

Not true! We had problems, and the above flag fixed the bad, server side slow, transcoding playback. Both on the LG OLED and the iPhone13 Mini. 
So, clearly your detection what can and can't be played on the client is bogous! I had my content playing flawless, nothing changed but your server and client(s)....

[visproduction 315]

Is the TV receiving via Wifi?  I would think that failed ACK acknowlegement TCP packets will cause direct play to stop and switch to encode.  ACK packets not returning in proper order would be caused by any problem with server to end playback bandwidth.  This normally happens with speed changes in Wifi packet transfer or possibly any other software or hardware issues with direct cable router,  hub, switch mismatch, loss of signal strength through walls or at too large a distance. 

For example: using an old switch that cannot do 1 GB would slow all Ethernet down to 100 kbps.  Wifi interference by all sorts of problems or using the 2.4 instead of 5 Ghz band to receive the Wifi on a TV or phone can also drop the speed by up to 75%.

Another issue might be excessive subtitles on some content requiring additional bandwidth per second of media to be sent because of the master media file that has multiple times per text and built in multiple texts that have to be sent.  The option to play or not play embedded subtitles are controlled by the playback hardware and not the server.  So not playing subtitles does not reduce the media size that has to be sent.  You have to use separate subtitles files on the server to allow the server to send or not send subtitle information.  If subtitle overload causes ack packets to not return in acceptable order, the server would probably see that as insufficent bandwidth and drop direct play.

I did not code any of this in the Emby product.  I am an outside user.  I am just assuming this is how it works.  Strezi, if you want to test an installation, you really need to use proper "Test media" files that have no subtitles and has no internal errors.  A majority of online video has internal errors and incorrect data in the file.  You just don't usually notice this.   

Also perhaps consider direct connections and check if iPhone 13 can handle 5Ghz Wifi, which I think it cannot do that.  Normally 2.4 GHz bandwidth should be enough for most any 1080P media, but it depends on your Wifi setup.  You didn't mention if you are playing back on the iPhone using data or Wifi.  If you are testing with cell data packets,  then I believe there are other packet transfer issues that come into play that can cause slight delays that make ack packet returns fail and probably trigger the server to drop direct play.

Did you check all this already?  It's not mentioned in the above comments.  All these issues can reduce data transfer speeds and result in dropping direct play.

You guys that wrote the code... Is something not right in my breakdown?

Hope this helps.

[rbjtech 5284]

For anyone that has used emby for a length of time, it is known that the mechanism to determine 'bandwidth' has some (lets be kind) 'improvement areas'.

Passing data over a WAN introduces all sorts of unknows - latency, jitter, packet loss - and unless the client can handle these - then it's going to likely think bandwidth is poor and transcode.

The OP above has clearly stated, that by simply turning off the ability to transcode, it now direct plays and works perfectly.   So from that fact alone, I take it 'bandwidth' is not actually a problem - but some other unknown 'factor' is.   

Without knowing the details behind the emby 'bandwidth detection' code and a packet analysis from the client to the server - frankly, we are all but guessing on what it might be .. 

Edited October 4, 2023 by rbjtech

[pwhodges 2012]

2 hours ago, visproduction said:

check if iPhone 13 can handle 5Ghz Wifi, which I think it cannot do that. 

5Ghz wifi came to the iPhone with the iPhone 5.

Paul

[Carlo 4560]

 

On 10/19/2022 at 11:08 PM, Carlo said:

Newer versions of the server have a bit better wording for this option you find on the first tab when editing a user.

This can stop transcoding and direct streaming, leaving an item unable to be played.
It can also stop a direct stream from taking place when it would be beneficial over a direct play.

Direct Play is usually the best for LAN use where spikes in bandwidth have little effect on the home network.  Those same spikes in bandwidth used on a WAN connection will often cause trouble and not be the best type of playback over WAN.

The bottom line, is that the server log and ffmpeg log files need to be looked at to find out why the playback type was chosen.