Direct Play Buffering Functionality?

[slicedmass 2]

Hi,

 

Just curious, when something is being "direct played", what kind of buffering is happening on the server side? I ask because sometimes my server is busy writing to the disk that contains the media and it can cause videos to stutter. How I would imagine it works is for the video that is being direct played to buffer ~50-100MB or some chosen value of the video file to memory and be pushing that data to whatever client is requesting the video. It more so feels like it isn't doing that or the buffer is extremely small. Is there any place to modify the buffer size? Just an FYI, the video that is Direct Playing at the times have been 3mbps bitrate and it is definitely because my disks are busy writing or reading at full speeds (tested and its repeatable). It just feels like the emby server is waiting until its too late (emby expects a low latency full disk bandwidth read) to queue up the next piece of data and causing a "blip" on the client side (this is LAN to LAN, ethernet to ethernet).

[Happy2Play 8356]

When somethings is Direct Playing, the server is taken out of the equation.  I know when I start playing something on my Roku that direct plays, I can kill Emby server and the media still continues to play. 

 

So any issue the client players has would be the client itself correct?

[slicedmass 2]

I can only imagine it queues up some other process when you start playing something (like ffmpeg) I would also imagine if you were direct playing from a remote device it would have trouble if you closed the server.

[ebr 14959]

Hi, we'd have to look at a specific example but the server doesn't "queue up" things to the client.  The client requests data and the server delivers it.

[slicedmass 2]

i guess my question is. is it outside of the realm of possibility for the server to pre-emptively buffer the next 50MB or some modifiable value to memory in anticipation of the clients most likely next request? since the only time it would be wrong in anticipated data is when the client seeks the file to some new timestamp and the server could flush the buffer and start from the new position.

 

 

Edit:I say this because under situations where there is high levels of disk activity. There can be stuttering every 10 seconds or so with even 3mbps videos. Leads me to believe that the client makes the request for a piece of the video and the server goes to grab it. Because there is so much activity at the time, windows is not giving Emby Server its fair share of disk time quick enough for Emby Server to push it to the client leading it to freeze for half a second until it gets the data it wanted. I think this would be easily relieved if the contents were inside memory and being pulled from memory when the client requests it. I could imagine you could put the data into chunks in memory (20+ 1MB data chunks) and when Emby server has fully read out a chunk to the client it can purge the chunk and copy a new 1MB chunk to memory and keep up with demand even in high disk activity scenarios. Maybe im just dreaming or maybe it already works in a similar fashion.

 

The only reason I'm lead to believe the disk activity issue is because it happens on LAN devices that are hard wired and I can reproduce it by causing large disk activity.

Edited February 1, 2019 by slicedmass

[Happy2Play 8356]

This still comes back to how the media is being delivered.  If it is Direct playing, the server has nothing to do once the client has it.  Streaming and Transcoding are another story.

 

So if the media is Direct Playing you would have to lower the quality enough to for it to transcode, but you are using even more resources on the machine.

[slicedmass 2]

This still comes back to how the media is being delivered.  If it is Direct playing, the server has nothing to do once the client has it.  Streaming and Transcoding are another story.

 

So if the media is Direct Playing you would have to lower the quality enough to for it to transcode, but you are using even more resources on the machine.

Im not quite sure I understand what you mean. When direct playing, emby is still serving up the RAW media file to the client? Im saying that when I have high disk activity from lets say a fast download/unrar/etc. I experience stutters when Direct Playing. My theory is that is due to the disk not delivering the next piece of data in a timely manner. But we are talking about 3mbps encodes so its not that there isn't enough disk bandwidth to accomplish the task. Its more that the busy disks need windows to allocate disk time to emby when it decides to pass more data to the client (when the client decides to ask for it). I figure this bottleneck could be completely avoided if emby maintained a cache of the assumed (because videos run in sequential file order) next pieces of data so that when the client makes the request, its sitting in ram and can be sent off leaving the disk out of the equation. Or am I missing something here?

 

Edit:This would also reduce small reads which increase IOP requirements unnecessarily (unless it works how im wishing it would, then I dunno know to think).

Edited February 2, 2019 by slicedmass

[Happy2Play 8356]

Im not quite sure I understand what you mean. When direct playing, emby is still serving up the RAW media file to the client? Im saying that when I have high disk activity from lets say a fast download/unrar/etc. I experience stutters when Direct Playing. My theory is that is due to the disk not delivering the next piece of data in a timely manner. But we are talking about 3mbps encodes so its not that there isn't enough disk bandwidth to accomplish the task. Its more that the busy disks need windows to allocate disk time to emby when it decides to pass more data to the client (when the client decides to ask for it). I figure this bottleneck could be completely avoided if emby maintained a cache of the assumed (because videos run in sequential file order) next pieces of data so that when the client makes the request, its sitting in ram and can be sent off leaving the disk out of the equation. Or am I missing something here?

 

Edit:This would also reduce small reads which increase IOP requirements unnecessarily (unless it works how im wishing it would, then I dunno know to think).

 

Emby should have no role when Direct playing a file.  Does the media play normal if you opened it directly on another machine?

[slicedmass 2]

Emby should have no role when Direct playing a file.  Does the media play normal if you opened it directly on another machine?

I don't think that is true at all.

[Happy2Play 8356]

Emby does not process the media at all when the client is Direct Playing, only when Streaming/Remuxing or Transcoding.  I can turn Emby off while any item is Direct Playing.

Edited February 2, 2019 by Happy2Play

[slicedmass 2]

Well I just connected to my server via my phone while on LTE and started playing a file, dashboard says Direct Play but I highly doubt Emby is not involved.

[Happy2Play 8356]

 

Direct Play vs Direct Streaming vs Transcoding

 

don't know how I got the link wrong but updated it.

Edited February 2, 2019 by Happy2Play
updated link

[slicedmass 2]

You linked this thread.

[Happy2Play 8356]

You linked this thread.

 

Don't know how I did that but I updated it. 

[slicedmass 2]

That can't be entirely correct considering I just tested via LTE to my https external Emby server and it says on the dashboard it is direct playing when according to that page it should say im direct streaming. I can also see in resource manager the emby server pushing the exact speed that the file is in mbps.

 

 

[Happy2Play 8356]

Is there a ffmpeg log created in the log folder?

 

I have files direct playing in my browser and shutdown Emby and they are still playing.  And with Emby running and files truly direct playing I get this.

 

[slicedmass 2]

I just tried it, Connected to LTE, starting playing video (showed Direct Playing) killed the emby service and about 20-30 seconds later the video froze. Maybe try on ur end again but see if it eventually kills out if you let it keep playing.

[ebr 14959]

Whether what Happy is describing works depends on the app in use.  If it is one of the HTPC apps (like Theater desktop) then he is correct.  For pretty much all other apps, the server is feeding the file directly to the app.  But, again, in this case, the server simply responds to requests from the app for data.  It has no ability to "push" more to the app than it has requested.

 

It really sounds to me like you simply have an overloaded mechanical disc in these situations.

[slicedmass 2]

Whether what Happy is describing works depends on the app in use.  If it is one of the HTPC apps (like Theater desktop) then he is correct.  For pretty much all other apps, the server is feeding the file directly to the app.  But, again, in this case, the server simply responds to requests from the app for data.  It has no ability to "push" more to the app than it has requested.

 

It really sounds to me like you simply have an overloaded mechanical disc in these situations.

i understand your explanation. im just wondering is it not a better design to be precaching the predictable future data on the server (not client) in memory so that when the client asks the server for the next bit of data it pulls directly from ram? the reason i suggest this is because the total throughput on the disks is the same but because each read to the disks will be bigger (because when it has to hit the disks it will be caching a large chunk like 50+MB) so iops requirements dramatically decrease. ie. its better to have 10 users pull 50MB from the disk every 30 seconds then it is to have 10 users pull 50MB from the disk over a 30 second period of time.

[maegibbons 1267]

Emby does not process the media at all when the client is Direct Playing, only when Streaming/Remuxing or Transcoding.  I can turn Emby off while any item is Direct Playing.

 

This is TOTALLY untrue.  It may happen for the Roku but NOT Android TV and I have debated this before that IT SHOULD BE ALLOWED.

 

In Android TV EVERYTHING goes through the server.  

 

In my environment all my media is hosted on my NAS which is directly accessible via IP or URL.  However the devs have chosen to push the stream through the server.

 

I have asked for this to be changed because it doubles network load unnecessarily

 

Krs

 

Mark

[CBers 6794]

This is TOTALLY untrue. It may happen for the Roku but NOT Android TV and I have debated this before that IT SHOULD BE ALLOWED.

 

In Android TV EVERYTHING goes through the server.

 

 

Correct, purely because the Shield cannot access network shares like PCs can.

 

There should be a way by now to do this, but until there is and Emby makes uses if it, then the best we get is Direct Streaming.

 

The thread that @@Happy2Play posted above, can be confusing for the uninitiated

[CBers 6794]

@@ebr - as an aside, is there any way yet for the Emby ATV app on the Shield to Direct Play content please?

 

I believe it was discussed here, but that back last year, so I wondered if the recent updates to the Shield made Direct Play possible now.

 

Obviously we can already Direct Play content when manually initiated from the Shield via file manager apps such as ES FILE EXPLORER, but it would be nice to have that functionality built-in to the app,

 

Thanks.

[maegibbons 1267]

Yes.

 

That would be awesome and reduce network bandwidth by 50%

 

Yes please!

 

I could then update my server, whilst continuing to watch the show.

 

Yes definately yes!

 

I'm quite excited by the prospect.

 

Krs

 

Mark

 

Sent from my SM-N950F using Tapatalk

[Carlo 4331]

i understand your explanation. im just wondering is it not a better design to be precaching the predictable future data on the server (not client) in memory so that when the client asks the server for the next bit of data it pulls directly from ram? the reason i suggest this is because the total throughput on the disks is the same but because each read to the disks will be bigger (because when it has to hit the disks it will be caching a large chunk like 50+MB) so iops requirements dramatically decrease. ie. its better to have 10 users pull 50MB from the disk every 30 seconds then it is to have 10 users pull 50MB from the disk over a 30 second period of time.

Keep in mind what you are asking for.  If you have say 10 GB files and have 2 people transcoding, do you want to have 20 GB of memory used?  What if you have 45 GB 4K files and 4 people transcoding?

 

Emby could have X amount of "Ram cache" to use but then this complicates things dramatically.  Pickup a cheap "throwaway" SSD drive and use that for transcoding.  The speed difference of the SSD drive over HDD is a lot. Putting it on it's own PCI bus channel is even better. I say throwaway because you'll be writing to the SSD a lot if you have an active system.  You could burn through SSDs every year or two with bad luck (I'm on year 3 or 4).  But you don't need a big SSD for this so a 250 GB or 500 GB (way more than most would need) should be fine and they are cheap these days.

 

Correct, purely because the Shield cannot access network shares like PCs can.

 

There should be a way by now to do this, but until there is and Emby makes uses if it, then the best we get is Direct Streaming.

 

The thread that @@Happy2Play posted above, can be confusing for the uninitiated

 

Well it can if you setup the box to be able to use network shares.

But even without direct access to the file stream, Emby can still direct play the file.

Remember direct play means the file isn't changed (no ffmpeg involved) and not the method used to play it. The file is played AS IS vs being modified (direct stream).

Serving files in this manner is similar to progressive downloads of the past and require very, very little cpu use on the server.

 

That would be awesome and reduce network bandwidth by 50%

That's a network issue more then anything else.  You choose to have your discs on a different box then your server and have intentionally put a network between the two boxes.  Don't take that as a "slam" or anything as it's a fine way to run the system.

 

However, it's not using twice the bandwidth or doesn't need to.  From the standpoint of the NAS there is no additional overhead as it's just server each byte once.

From the standpoint of the server, maybe depending on how you look at it.  If you have two LAN cards (one for NAS) and use switches vs hubs then there is no additional network bandwidth used that matters.  You could argue the semantics of this but unless you only have a single LAN card in the server, it to doesn't really matter.  That little extra bandwidth is nothing.  If using 10 Gb vs 1 Gb LAN cards it's almost a non issue.

[CBers 6794]

Well it can if you setup the box to be able to use network shares.

 

But even without direct access to the file stream, Emby can still direct play the file.

 

Remember direct play means the file isn't changed (no ffmpeg involved) and not the method used to play it. The file is played AS IS vs being modified (direct stream).

 

Serving files in this manner is similar to progressive downloads of the past and require very, very little cpu use on the server.

@@cayars Not saying you're wrong, but you're wrong.

 

Direct Play is direct from the file system, bypassing the server totally.

 

Direct Streaming is when the client cannot access the filesystem natively, so the server has to create a stream.

 

This discussion has come up many times before but we never get a resolution.

 

If you want, we can start a new thread to discuss further, or continue over on @'s thread, so as not to take over this thread, any more than we already have