slicedmass 2 Posted February 2, 2019 Author Share Posted February 2, 2019 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. The thing is, all my videos are efficiently encoded before they are stored on my drives. Everything is HEVC and do not rise above 15-20mbps (4k HDR stuff). I do not allow my server to transcode any video (turn off the options that allow it). I leave audio allowed just in case but even with my testing I was making sure it was direct playing and it was only 1 user, Me. I dont think a universal value or a per user and server total value would be that tasking. If you have a 16GB workstation/server, you can easily handle 1-2GB (if you allow transcoding for some reason) or more if you do not allow transcoding. There would be a balance between disk capability and cache size per server and per user anyways. I think it would dramatically improve performance because pretty much everyone is trapped on HDD storage for where their media resides. The other option, follows your logic. Let me have a 256GB or even 64GB drive. When someone requests video, keep a rolling cache of 1GB on the drive and feed requests from that. There are many approaches but I think its important for it to be implemented. 1 Link to comment Share on other sites More sharing options...
maegibbons 1267 Posted February 2, 2019 Share Posted February 2, 2019 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. Sorry but that definition is what you have chosen to adopt. I have seen the definition elsewhere on the internet and other references that it is only TRULY direct play if it COMES direct from the source untouched. I know, i know its unmodified but it is not DIRECT FROM SOURCE However lets not argue about this. It is semantics. Do not be so dismissive of the issue of network bandwidth being cut by 50%. In all terms of CPU, Drive Space, AND NETWORK TRANSIT costs a saving of 50% as a "simple" fix to achieve would be chased down ruthlessly in the commercial world. So lets not be complacent that the massive overhead that 1gbps/10gbps home networks generally give us that we should not care about unnecessary duplication, I'm not saying it is an imperative issue BUT it certainly is something that I would like to see happen. Just because you do not particularly want to see something, others might. Krs Mark 2 Link to comment Share on other sites More sharing options...
Guest asrequested Posted February 2, 2019 Share Posted February 2, 2019 Something to keep in mind. 1Gb/s = 1000Mb/s, a large 4k HDR movie is around 60Mb/s. If your network bandwidth is at 50%, something massive is using it. Even if the movie were 200Mb/s, it still wouldn't use 50% of your network bandwidth. 1 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted February 2, 2019 Share Posted February 2, 2019 (edited) LOL No - wrong - he means 50% reduction of the USED bandwidth In your example from 120Mb/s to 60Mb/s Edited February 2, 2019 by PenkethBoy 1 Link to comment Share on other sites More sharing options...
Guest asrequested Posted February 2, 2019 Share Posted February 2, 2019 Oh, my bad Link to comment Share on other sites More sharing options...
Jdiesel 1114 Posted February 2, 2019 Share Posted February 2, 2019 I've been asking for network paths in the ATV app for a long time but it doesn't seem that there is much appetite from the devs to add it. Even with the Shield TV having native SMB support. 2 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted February 2, 2019 Share Posted February 2, 2019 SMB is still only v1 (bad idea) - v3 is still a ways off so people will have issues with any modern version of Windows when trying to connect - without some additional addon over that provided via plex provided smb support as it is now. 1 Link to comment Share on other sites More sharing options...
Carlo 4331 Posted February 2, 2019 Share Posted February 2, 2019 @@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 I'm sorry but you're wrong and I can prove it. How about we ask the software itself? Play a file on a device without file access (ie Roku, xbox, Shield TV) and make sure it doesn't need to remux or transcode. Now go to the web panel and look at what it tells you. What does it say? Direct Play So there is a definition and it's built right into Emby itself. This also happens to be the same definition as used by Plex, Wowza and other media giants. Emby is the only well known media server that even allows you to play files from the file system (not talking about things like Kodi) and it's the only support forum where this "direct play" thing even comes up. Media servers are built on web standards and those don't include direct file access so it's a strange concept outside of Emby. Sorry but that definition is what you have chosen to adopt. I have seen the definition elsewhere on the internet and other references that it is only TRULY direct play if it COMES direct from the source untouched. I know, i know its unmodified but it is not DIRECT FROM SOURCE It's not me who's adopted it but the industry at large. I can dig that definition and it still fits. When you get a file "direct played" via the Emby server (not file system) it's the same file as it was on disc. It's byte for byte the same file! It's what used to be called a progressive download. Not really any different then downloading files via a web browser. It will have the same checksum on the server as on the device. It therefore is untouched. Now there is a slight difference in that we no longer have to do pure progressive downloads. We can now skip through files via web standard calls so the client can say "jump to 20:30 mark" or "skip 2 minutes", but that's the same as disc access as well. However lets not argue about this. It is semantics. Do not be so dismissive of the issue of network bandwidth being cut by 50%. In all terms of CPU, Drive Space, AND NETWORK TRANSIT costs a saving of 50% as a "simple" fix to achieve would be chased down ruthlessly in the commercial world. So lets not be complacent that the massive overhead that 1gbps/10gbps home networks generally give us that we should not care about unnecessary duplication, I'm not saying it is an imperative issue BUT it certainly is something that I would like to see happen. Just because you do not particularly want to see something, others might. I'm not dismissive of the "extra" bandwidth needed by a server talking to a NAS. I totally get that but I'm saying it's not a big deal in a properly configured network. It really only matters if there is 1 LAN card that's 1 Gb or less. If you have 2 1 Gb NICs (one dedicated to talk to the NAS) then you aren't using any additional bandwidth. Remember we don't use HUBS any more (hope not) and use SWITCHES so both NICs can perform at the same speed (maxed out) with no penalty. The NAS does not see any additional activity regardless of how the files are served this way. The client does not see any additional activity this way. Only the Server sees additional activity which may or may not be worse. The same amount of data is traveling though the computer. It's just getting the media via a 2nd lan port vs a PCI/Bus disk controller. That could improve performance on some systems (usually not). But it's not really 50% or double the throughput because the Server is still processing the same amount of data (just getting it differently) and neither the client or NAS is doing any additional work. There also isn't any additional household data traffic because we use switches and not hubs. I certainly do understand however that if a client could play the video back directly from the NAS that there would be no transfer in the one leg (NAS to Server) but it hardly matters in the real world (if using 2 NICs). Make better sense stated that way? Link to comment Share on other sites More sharing options...
CBers 6794 Posted February 2, 2019 Share Posted February 2, 2019 Oh @@cayars, give up and go back to bed mate 2 Link to comment Share on other sites More sharing options...
CBers 6794 Posted February 2, 2019 Share Posted February 2, 2019 It says Direct Play in the Dashboard, because that's what @@ebr and @@Luke have unilaterally decided to code it that way. As @@Happy2Play stated earlier, if you play something that is Direct Play and restart your Emby server, it will continue playing. Now do that with Emby and playback will stop, apart from when the Emby WMC, ET and Emby for Kodi is the client. 1 Link to comment Share on other sites More sharing options...
slicedmass 2 Posted February 2, 2019 Author Share Posted February 2, 2019 Lets get off the semantics talk. When Emby is serving media to client requests, there should be a cache option. whether its caching to memory in some fashion or caching to an SSD. It would improve the bottleneck we all most likely have which are the spinning disks. 1 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted February 2, 2019 Share Posted February 2, 2019 spinning disks that so 2018! 2 Link to comment Share on other sites More sharing options...
Carlo 4331 Posted February 2, 2019 Share Posted February 2, 2019 (edited) It says Direct Play in the Dashboard, because that's what @@ebr and @@Luke have unilaterally decided to code it that way. As @@Happy2Play stated earlier, if you play something that is Direct Play and restart your Emby server, it will continue playing. Now do that with Emby and playback will stop, apart from when the Emby WMC, ET and Emby for Kodi is the client. Yep and they have followed what other media providers have done as well. Direct play is playing the media without changing it (basically). How it's transported is irrelevant. We could play it back via http, https, ftp or direct file access). Don't know why you would do this but technically the server could transcode a file and allow a PC to play that back via direct file access and I don't think any of us would call that "direct play". I would hope we'd all agree, that the best terminology of the platform is to use the language of the platform and the software and they call this direct play (through media server or from file access). EDIT: Maybe to get rid of confusion the dashboard could say "Direct Access" or "File Access" instead of direct play for clients playing media back directly via UNC/drive. Lets get off the semantics talk. When Emby is serving media to client requests, there should be a cache option. whether its caching to memory in some fashion or caching to an SSD. It would improve the bottleneck we all most likely have which are the spinning disks. You can do this already but it won't affect direct play files. It can help direct stream and transcode files. For these latter types the file is processed and rewritten. This process can make use of an SSD. If you have an SSD then check out option "Transcoding temporary path:" on the Transcoding page in the admin console. Edited February 2, 2019 by cayars Link to comment Share on other sites More sharing options...
slicedmass 2 Posted February 2, 2019 Author Share Posted February 2, 2019 EDIT: Maybe to get rid of confusion the dashboard could say "Direct Access" or "File Access" instead of direct play for clients playing media back directly via UNC/drive. You can do this already but it won't affect direct play files. It can help direct stream and transcode files. For these latter types the file is processed and rewritten. This process can make use of an SSD. If you have an SSD then check out option "Transcoding temporary path:" on the Transcoding page in the admin console. I'm aware that can be done, as I stated before though, I would like that functionality so when emby is serving up a direct or even on the fly muxed file to the client. Link to comment Share on other sites More sharing options...
maegibbons 1267 Posted February 2, 2019 Share Posted February 2, 2019 (edited) I like the term "Direct Access" for direct from device access. So when ET or Roku play direct from my NAS thats what it would say. And "Direct Play" when it goes through the server and "Direct Stream" when its audio remuxed and Transcode for everything else. Now weve agreed on the term can we please get "Direct Access" working on ATV Krs Mark Edited February 2, 2019 by maegibbons 1 Link to comment Share on other sites More sharing options...
Happy2Play 8356 Posted February 2, 2019 Share Posted February 2, 2019 Back to semantics. As long as Emby documents their definition of these terms it doesn't matter what anyone else's definition is. Link to comment Share on other sites More sharing options...
Carlo 4331 Posted February 2, 2019 Share Posted February 2, 2019 I'm aware that can be done, as I stated before though, I would like that functionality so when emby is serving up a direct or even on the fly muxed file to the client. It is for muxed content just not for direct stream. It's not going to benefit you in that situation. All you would be doing is add another set of steps into the mix which would slow things down vs speed it up. I like the term "Direct Access" for direct from device access. So when ET or Roku play direct from my NAS thats what it would say. And "Direct Play" when it goes through the server and "Direct Stream" when its audio remuxed and Transcode for everything else. Now weve agreed on the term can we please get "Direct Access" working on ATV Krs Mark I wouldn't mind seeing "Direct Access" either and it would save these tangents we go off on every month or so. LOL Do mean activating the option on ATV settings->Playback Settings->Pass Direct Path (Pass the file system path instead of streaming URL) option? Link to comment Share on other sites More sharing options...
FrostByte 5061 Posted February 2, 2019 Share Posted February 2, 2019 1 Link to comment Share on other sites More sharing options...
CBers 6794 Posted February 2, 2019 Share Posted February 2, 2019 Do mean activating the option on ATV settings->Playback Settings->Pass Direct Path (Pass the file system path instead of streaming URL) option? That's only used for external players. 1 Link to comment Share on other sites More sharing options...
CBers 6794 Posted February 2, 2019 Share Posted February 2, 2019 I wouldn't mind seeing "Direct Access" either and it would save these tangents we go off on every month or so. LOL @@ebr and @@Luke will never change the descriptions. Link to comment Share on other sites More sharing options...
maegibbons 1267 Posted February 2, 2019 Share Posted February 2, 2019 @@ebr and @@Luke will never change the descriptions. Don;t be negative. This is an additional clarification! I am sure they will see the wisdom here - especially if it stops us all debating it constantly!!! Krs Mark 1 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted February 2, 2019 Share Posted February 2, 2019 Wow - did i see a pig fly by just then? 1 Link to comment Share on other sites More sharing options...
Happy2Play 8356 Posted February 2, 2019 Share Posted February 2, 2019 This is a endless debate as no two people will ever agree what terminology should be used. As long as Emby states what their definition is, that is all that matters. Link to comment Share on other sites More sharing options...
CBers 6794 Posted February 2, 2019 Share Posted February 2, 2019 This is a endless debate as no two people will ever agree what terminology should be used. As long as Emby states what their definition is, that is all that matters. Sounds like a quote from Eric's book of wisdom 2 Link to comment Share on other sites More sharing options...
Carlo 4331 Posted February 2, 2019 Share Posted February 2, 2019 (edited) Back to semantics. As long as Emby documents their definition of these terms it doesn't matter what anyone else's definition is. https://github.com/MediaBrowser/Wiki/wiki/Direct-Play,-Direct-Stream-&-Transcoding Does that put this to rest? Edited February 3, 2019 by cayars 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now