Why indeed? Well, as my fellow amateur Internet broadcaster Justin Zeigler (coincidentally of the same first name) observed, “some people mistake the unix way as doing things the oldest way possible.” There are niceties streaming video solutions provide that are much better suited to solving my particular problem.
Streaming puts the burden of handling different codecs and providing material at a bitrate the client systems can handle on the server. Remember, I said my client system is underpowered and the network I’m delivering across is wireless B. These constraints make streaming video the ideal solution.
Now, if I only wanted to stream the music videos and other material designed to deliver over the Internet, I’d be fine with a remote filesystem. But DVDs and mythtv recordings are too demanding on my little laptop’s resources to work at all.
But, just to make sure, I tried both sshfs and nfs today. Sure enough, I could stream a Quicktime music video from sshfs just fine. However, neither sshfs nor nfs could deliver the material from a mythtv recording fast enough for the client to keep up. I tried both vlc and mplayer, and both were so stuttery they were unplayable. I gave mplayer a larger buffer (32K) which cleaned up the first few seconds of play while the player read from the buffer, but after that, it started stuttering again. And this was with only one floor of separation between the WAP and the laptop, to make sure I had a solid connection.
Clearly, Videolan’s ability to transcode on the fly and stream over the network is a great convenience to me. I suppose I could do a file-to-file transcode and then read the resulting file from sshfs, but I don’t find that nearly as handy as the streaming solution. So I’m sticking with Videolan, as I find it the easiest to use, most elegant solution to delivering a broad range of video material from our powerful hub system to our less powerful client system.