Notices

I like to watch a tv series episode in bed on my N800 before I go to sleep. But I got tired of every time having to wait, first while the movie encodes, then while copying to a SD card. So I figured out a simple way to bypass those steps. What is done here is that mencoder encodes a movie on your desktop with some clever tricks, the output goes directly to a FIFO. Netcat then reads from that FIFO and streams to a netcat on the N8x0, which outputs directly to the STIO of mplayer, which plays the movie as the movie is encoded and streamed over the network.

What you need:
* A desktop computer fast enough to encode a movie for IT viewage faster than the movie is played back. A computer newer than 4-5 years or so should be fine for this for most video files. If the source is a HD movie then you may need a relatively fast computer. My two year old computer is too slow to encode from a HD source on the fly, but just barely.
* The desktop needs to run some kind of unix (linux), and have both mencoder (usually comes with mplayer) and netcat installed. The mencoder build needs to be newer than a year or so, since it uses some relatively new features of mencoder.
* Netcat and mplayer installed on the N8x0 device. The netcat from the extras repo doesn't seem to work very well, use this one instead. It was provided by lbt from #maemo.

Put this in a file somewhere in your PATH on your desktop box. For example I keep mine as /usr/local/maemo_stream.sh. Don't forget to chmod 755 it.

Warning: the script will kill all mencoder processes currently running when the movie is finished playing. This is to work around a freeze (requireing kill -9) that otherwise occurs if you end the viewing of the movie prematurely. There has a to be a better solution here, but I don't know what it is.

Now on the desktop to stream filename.avi run in a terminal:
The script will encode on the fly, so you don't have to wait for it to be encoded or anything, you can start playback on the IT immedately. This will be left paused until you actually initiate the connection from the IT. To do so run the below in xterm on the IT. The ip needs to be changed to whatever ip your desktop computer has.
The command may be just nc rather than nc.traditional depending on how you installed netcat. I suggest putting the command as an alias in your .profile file to avoid having to type so much each time.

You may have to lower video and/or audio bitrate if sending the data over a slow connection. The settings I put should work fine on the average home wifi. Also up the cache in the mplayer command on the IT if you're on a slow connection. You can pause the video, but you can skip forwards or backwards. Mencoder will encode at the speed data is read from the FIFO, not as fast as it can go. This is good because it means that neither the desktop box nor the IT will have to cache a large amount of data in memory. The codec used is one that encodes very fast but still provides good quality.

If you find any other problems with it report below. You may have to kill some other processes manually too if something goes wrong.

This should be everything needed to get it working. However I want to take some time to discuss the mencoder options. As you may see my encoding script is quite a bit shorter than the average encoding script for maemo is. However I think mine provides all the same functionality as the longer ones, thanks to some relatively new filters in mencoder. "-vf-add dsize=${MAX_XRES}:${MAX_YRES}:2,scale -vf-add expand=${MAX_XRES}:${MAX_YRES}::::${MAX_XRES}/${MAX_YRES} -vf-add crop=${MAX_XRES}:${MAX_YRES}" is the part I'm talking about. What that does is scaling, and if necessary adding black borders and cropping (croping should never remove more than one line of pixels, its for when there is an odd number of lines), to always get the 400x240 resolution, so hardware pixel doubling on the ITs can always be taken advantage of. No separate analyzing of the source needed, perfect result every time, any source mencoder can read from should work. Very nice quality, and the code is so much shorter than analyzing and calculating this separately as other scripts does. Encoding script authors should take a look at what this does and see if they can use it to cut down the size of their own scripts considerably.

If you find any bugs or have any questions, or just want to add something else, please post below. Once I'm certain all the bugs are worked out I will be posting this on the wiki.

Or you could just use mediaserv or setup mediatomb with transcoding and watch with canola and the upnp-plugin.

Sure, that works too. But I prefer this way as it doesn't require me to install anything I don't already have, doesn't require me to run a daemon on my desktop comp at all times that keeps track of what media files I have, and is easier to modify if I want to experiment with it since its just a simple shell script. And I don't really care for canola, too flashy for me, and nothing beats the speed of a cli interface.

Use whatever way you like, having multiple different choices is what linux and the free software community is all about.

Or you could just use VLC to transcode it and stream it to your N800--that's what I do. I've also captured and streamed audio from live tv so I could have the TV on and listen to it while doing dishes without distracting my wife while she was doing homework in the same room. Basically turns the N800 (and its headphones) into an (expensive) wireless headset.

s/shell/Perl/ and you've got mediaserv. As part of the tablet-encode lightning session at the summit on Saturday, I'll also be showing mediaserv.

I've also started on a Java version which should be more reliable (Perl's threading's not exactly great), and maybe even cross-platform.

Indeed.

s/shell/Perl/ and you've got mediaserv. As part of the tablet-encode lightning session at the summit on Saturday, I'll also be showing mediaserv.

I've also started on a Java version which should be more reliable (Perl's threading's not exactly great), and maybe even cross-platform.

Indeed.

N8x0 does not have pixel doubling support (this was only used in Nokia 770). Instead of it, N8x0 has support in hardware for a single arbitrary upscaled window using high quality bicubic algorithm, which is used for video overlay.

So there is no performance advantage using exactly 400x240 resolution, surely the total number of pixels in each frame does matter, but that's all about it. Adding black borders is generally considered a bad idea and it also does not provide any kind advantage on maemo, there even will be a small performance penalty.

Ah. Thanks for enlightening me.

But still, the dsize filter is very nice for scaling video with mencoder, even if you don't add the black borders. And other mencoder filters are nice too. I still think scripts like tablet-encode and other encoding scripts could save many lines of code by using them.

I believe the correct substitution would be s/simple shell/complex Perl/

Perl is usually my scripting language of choice, but I agree that threads are not its strong part. Perl 6 is supposed to have better threads, when it comes. But the bad threads of perl 5 is not really a disadvantage in my opinion, using fork() and having multiple processes rather than threads is both easier to code/debug, more stable, and better performance wise (on linux at least). Personally I'm hoping that software in general turns away from multithreaded apps and goes for more multiprocess apps instead.

Indeed, mediaserv has, since it was pretty much released, used fork(). Unfortunately, that's not too great for sharing state between the processes and you end up with IPC or some hacky solution.

Edited the first post. Fixed the bug where mencoder freezes when the movie is ended prematurely, however this comes at the disadvantage of having to run killall -9 mencoder after the playback is finished, which may kill other mencoder processes the user has running. There has to be a better solution here, but I don't know what it is.

Also made sure the script always cleans up after itself and adjusted the cache settings since the cache was a bit too small for high intensity scenes when the wifi network couldn't provide the data fast enough (but was still able to provide more than enough in the low intensity scene to fill up the cache in the mean time).