Dan Ritter wrote: > In this case you aren't really streaming... Sure. Early versions of MythTV worked this way, with live video "streamed" via an NFS mount point. (Newer versions stream over a TCP protocol.)
> The application thinks it has a reliable file and will not be > expecting to have to do extra buffering and error-correction. Well, NFS should still be doing the error correction (application layer above UDP), but I'll agree that TCP will provide some buffering as a side effect of how it works. Bad for a real-time protocol, but no big deal when streaming a broadcast where some added propagation delay is irrelevant. So if you have a modern video player that will do buffering even when reading from the file system, like say VLC (or the player used by XBMC/Kodi), then no real advantage to using TCP for your NFS mounts. On the other hand, the overhead of TCP is not likely to be significant for typical compressed video use. I often stream HD (720p) content over sshfs mounts (which are on top of TCP) over WiFi and get stutter-free playback. (On very rare occasions XBMC/Kodi will pause for a second to buffer, then resume.) -Tom -- Tom Metro The Perl Shop, Newton, MA, USA "Predictable On-demand Perl Consulting." http://www.theperlshop.com/ _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss