Visual Land VL-878 tips and tricks

I bought a Visual Land VL-878 portable audio/video player recently, and had some adventures trying to get it to work. I'm collecting the results of my trial and error on this page so that others with this or similar devices can save themselves some trouble.

Copying files to the device

One reason I chose this device instead of others was that it functions as a USB storage device instead of using one of these wacky digital-camera protocols. I wanted to be able to mount it like a USB flash drive and copy files there instead of needing a special synchronization client.

It works, but only with a 2.4 Linux kernel. When I try to use it with a 2.6 kernel, the device says "I'm attached to a dumb charger and will only recharge my batteries, not allow file access." This decision is made visible by the device's display switching to a charging-battery animation, the same as when it's connected to a dumb charger, instead of the iPod-connected-to-iMac graphic it normally displays when connected to a computer.

I wasn't able to fix this; rebooting temporarily into the 2.4 kernel is a semi-acceptable workaround for my purposes. I don't think it's unique to my configuration, because I had the same problem connecting the device to a friend's computer with a different 2.6 kernel. What seems to be going on is that the sd_mod module (for SCSI disk drives) attempts to reset the SCSI bus when it connects. That reset, translated to USB commands by the usb-storage module, causes the VL-878 to disconnect. Either the 2.4 sd_mod module doesn't to the reset, or the 2.4 usb-storage module doesn't translate it in a way that freaks out the VL-878.

UPDATE: The latest 2.6 kernels fix the problem.

BONUS COMPLAINT: Directory listings are shown in the actual order that files appear in the VFAT file table, not sorted. If you're used to Unix directory sorting, you may have to be careful about the order in which you copy things to the device. This is especially significant because playing songs out of the directory listing proceeds in directory order, so if you want the songs on your album to play in proper sequence, you have to either be careful to keep the directory sorted, or use the ID3-tag-based "album play" feature instead of playing them from the directory.

NEW: Unicode filenames

I've become interested in Japanese-language music and I wanted to put files on the device with non-ASCII characters like 「漢字とひらがなとカタカナ」 in the filenames. Just copying them onto the device the way I'd been copying files with ASCII names resulted in garbage, but it turned out to be easy to fix: use the "utf8" option when mounting the device's vfat filesystem, and then it works. I don't know just how complete the device's Unicode font coverage may be for displaying the filenames, but it seems to cover Japanese at least, and given the likely target market, it probably covers all of CJK.

Ogg files

The Visual Land Web site says that this device plays Ogg files. At this point the kind of people who think that the computer operating system known to non-weenies as "Linux" should be called something else, will no doubt jump in to point out that Ogg is a container format and the file format is not fully specified unless you also name the codec, but fuck them; everyone else on the planet with a reason to care knows exactly what an Ogg file is.

My VL-878 cannot play Ogg files. It just doesn't support them at all. You can copy them onto it, and it will refuse to play them. I have tested it successfully with WAV and MP3. Various other sources say that it should be able to play WMA and FLAC, but I'm not holding my breath about the FLAC. (It also doesn't do WMA DRM, but that's a good thing.) The manufacturer's Web site is simply lying about Ogg support. If, like me, you chose this device over others partly to get Ogg support, then too bad, you were ripped off. If you read the Web site carefully you will note that one page listing supported formats lists Ogg, but another page doesn't. Retailers and other reviewers who say it plays Ogg files are just copying the manufacturer's spec sheet without actually verifying it, and shame on them.

My email to the manufacturers on this subject has not been answered.

It is possible to imagine that some future firmware upgrade could add Ogg support; the fact that it has enough CPU to decode video (but see below) suggests that there should be nothing needed to support Ogg beyond writing the software.

It could be worse - on Amazon there's a reviewer claiming that she was lied to about the device also containing a camera. I don't know about that; I was never told it contained a camera; but it certainly does not contain a camera.

AVI files

The device is also supposed to play "AVI files," and that, too, is a container format which can meaningfully contain many different kinds of video. What it actually means is that it plays AVI files if they contain MPEG4 video, only, and not even all of those. I've not been able to get it to work on any other kind of AVI file. It's also supposed to play RealVideo and FLV formats, and I think both of those are pretty close to MPEG4 internally, so what's probably going on is that they have an MPEG4 code base with some tweaks to do the others, and that's all.

The main thing I want to watch on my device is Japanese anime that I buy on DVDs; the original format for that is MPEG2, so it has to be transcoded in any case. Incidentally, I also tried anime fansubs, most of which were in AVI-MPEG4 already, and they tended not to work, but that's no big surprise given the wacky encoding some of these fansub groups do. Probably best to re-encode them myself the same as I would with DVD video. The first thing I tried was to just use mencoder's "lavc" MPEG4 encoder on the default settings, but I found a number of issues with that:

• Audio and video fall out of sync. This is less of an issue for me than it would be for others, because I'm reading subtitles anyway, but the audio runs about 0.2% faster than the video and by the end of one act of a TV episode, it's off by over a second, which is enough to be a problem. On a full-length movie it would be intolerable.
• There are glitches in the video; sometimes it seems to skip by as much as half a second. That's enough to lose a subtitle.
• The device stretches video to fit its wide screen regardless of the original aspect ratio. So 16:9 video looks correct, but 4:3 is stretched where it ought to be picketfenced.
• The device's screen is actually 15:9 (I measured): 60 millimetres by 36 millimetres. That's close enough that you won't notice, but to really be correct, 16:9 widescreen video ought to be slightly letterboxed to display properly.
• Sometimes it goes into a state for a few seconds where only moving parts of the frame are correct, superimposed on some earlier frame.
• The smallest increment that the fast-forward and rewind buttons can handle is ten seconds - and it's not ten seconds from the point you were at, it's that there is a boundary of some sort every ten seconds and you can only seek to those boundaries, not to any point in between. (People who know digital video will be able to guess the connection between this annoyance and the previous one...)

I read the mencoder man page, and found among other things that it uses a ridiculous keyframe interval by default. This is, unfortunately, not a surprise given some of the previous experiences I've had with mencoder. Anyway, in the encoded video stream, it's usual for each frame to be very similar to the frame before it, especially with animated material where the animators often double up the frames anyway. So the encoder usually doesn't actually encode the entire frame, it just encodes the differences between the current frame and the last one. But that makes it difficult to jump into the middle of the stream, and for that and other reasons, the encoder does occasionally send an entire frame without reference to previous frames. Those are called key frames. Key frames are also useful if the decoding process gets screwed up in some way, because they reset the frame to a known appearance instead of just letting the errors remain on-screen indefinitely.

One keyframe per second would be a reasonable number of them. Mencoder by default emits one every 300 frames, which is slightly over ten seconds at NTSC frame rate. That's why the VL-878 will sometimes go nuts for a few seconds - if anything gets screwed up on the screen for any reason, it can remain screwed up until the next key frame, which won't be for a long time. It's also why the fast forward and rewind buttons are so inaccurate - because they only seek to key frames and key frames are rare. It is not even allowed by the MPEG4 specification to have so few keyframes. This fact is documented on the mencoder man page; they note that it violates the spec to set the interval to more than 132, but they don't give any reason for why they think they know better than the spec writers. My guess is it may be a misguided attempt at saving bitrate, because key frames take a lot more bits to store, but I think it's a foolish economy. I raised the keyframe rate to one per second, a factor of ten increase, and got a barely noticeable increase in filesize, though of course that may partly be due to it stealing bits from all the other frames (lowering overall quality) to pay for the additional keyframes.

Here's a typical mencoder command line for the VL-878 with more keyframes. The important bit is the "keyint=30"; but don't use this yet, there are other things that still need to be done with it. The stuff about DVD title and chapters and selecting audio and subtitle languages should be fairly uncontroversial, as should the options for encoding the audio as constant-quality VBR.

mencoder dvd://1 -chapter 1-10 -alang ja -slang en \
   -oac mp3lame -lameopts q=7 \
   -ovc lavc -lavcopts vcodec=mpeg4:vhq:keyint=30 \
   -o episode01.avi

As for aspect ratio, I tried a bunch of different things. What I really wanted was to tell the encoder "Scale it enough to fit into a rectangle with THIS many pixels and THAT aspect ratio, while keeping the material in its original shape and adding black bars as necessary." Mplayer will do this if you use the -fs and -monitoraspect option - it will scale the video as big as possible while keeping it the right shape, even when both the video and the monitor have non-square pixels. Unfortunately, neither mencoder nor transcode (which I tried and then abandoned for other reasons) seem able to do this automatically.

The VL-878 manual says the biggest video it can handle is 800x480. (Do we believe the manual?) And that's supposed to fit on a 16:9 screen. But 800x480 isn't actually 16:9, it's 15:9. Fortunately, the VL-878's screen isn't actually 16:9 but 15:9 also, so its biggest video size is really a square-pixel mode after all. That makes things a little easier: we just need to scale the video and add bars to make it 800x480 with square pixels, instead of worrying about non-square pixels at both ends.

Mencoder has a scaling mode where you give it one dimension and it will calculate the other dimension to make the pixels square. That works. Unfortunately, which dimension we give it has to be different for 16:9 and 4:3. Both kinds of video typically come in at 720x480 (NTSC DVD, either 4:3 or 16:9), with nonsquare pixels. For 4:3 that has to scale to 640x480 to fit in 800x480 with square pixels. We can do that by telling mencoder "-vf scale=-2:480". But for 16:9 that'll give us about 853x480, which is no good; we need "-vf scale=800:-2", which will scale to 800x450.

I wasn't able to come up with a better solution; I ended up just having to write a perl script that called "tcprobe" to measure the aspect ratio of the input and chose a different scale filter setting appropriately.

But wait! Even if we scale it to square pixels, the work will all be lost when the VL-878 gets it hands on the file, because it will scale the file to 15:9 anyway. We need to add black bars so that the file will really be 800x480, which is 15:9 and the VL-878 will leave it alone. It's probably best that 800x480 be the actual size of the file instead of some other pixel size that is also 15:9, because 800x480 seems to be the real physical size of the screen and so (we can hope) the VL-878's CPU will do a little less work scaling it to fit. Reducing work for the VL-878's CPU is important for reasons we'll discuss next.

Mencoder can add the black bars easily with the "-vf expand=800:480" option, which works correctly for both 640x480 4:3 and 800x450 16:9. So the command line now looks like this, for 4:3 content:

mencoder dvd://1 -chapter 1-10 -alang ja -slang en \
   -oac mp3lame -lameopts q=7 \
   -ovc lavc -lavcopts vcodec=mpeg4:vhq:keyint=30 \
   -vf scale=-2:480,expand=800:480 \
   -o episode01.avi

or for 16:9 content:

mencoder dvd://1 -chapter 1-10 -alang ja -slang en \
   -oac mp3lame -lameopts q=7 \
   -ovc lavc -lavcopts vcodec=mpeg4:vhq:keyint=30 \
   -vf scale=800:-2,expand=800:480 \
   -o episode01.avi

So far we've fixed the aspect ratio in both directions, and vastly improved the messed-up-screen issue and the seek buttons, but on testing, it appears that the audio sync problem is not much better, and the glitches are actually much worse. Testing with different keyframe intervals revealed that it glitches noticeably at every keyframe. So more keyframes just makes the glitching worse.

I tried a lot of things for this. My best idea was to switch to MJPEG as the codec - because everything supports MJPEG, and it sends all of every frame without reference to other frames. In effect, every frame of MJPEG is a keyframe, so there can't be any issue of it treating keyframes differently. I spent several hours in dependency Hell trying to get an MJPEG encoder that would actually work, including having to upgrade my installation of GNU make, and even when I had an encoder that sort of worked I didn't bother testing the results on the VL-878 until I got the encoder really working - because hey, everything supports MJPEG, right?, and testing it on the VL-878 would have required an annoying reboot because of the kernel version issue.

So, of course, all that work was wasted when I discovered that the VL-878 does not support MJPEG. It says it supports "AVI," and that's a container format not a codec yadda yadda yadda, and everybody else who supports AVI supports AVI-MJPEG, but the VL-878 supports AVI-MPEG4 and AVI-MPEG4 only.

It took a fair bit more experimentation which I won't go through in detail here, but I ended up coming to a shocking conclusion: the VL-878 just does not have enough CPU power to decode 29.97 frames per second in any format! Bear in mind that it seems to be sold for the purpose of watching things you download from YouTube or elsewhere on the Net, which tend to be compressed to very low bit rates and horribly low frame rates. You give it an AVI ripped from high-bit-rate DVD at 29.97 (the standard NTSC frame rate) and each frame takes a little longer than 1/29.97 of a second to decode, so it falls further and further behind, and then when there's a keyframe it sort of tries to sync up by dropping some frames, but that doesn't work all that well partly because keyframes take even longer to decode, and that explains all the symptoms I saw.

The workaround is to lower the frame rate. I'm using a frame rate of 15, which seems to work pretty well and corresponds nicely to half the NTSC frame rate (except for the colour-subcarrier fuckage which makes NTSC not exactly 30fps, but we don't need to go into that). Dropping the frame rate isn't great, but I'd rather lose the temporal resolution in a smooth way like this than put up with the glitches that come from giving the VL-878 more frames than it can handle. Losing subtitles is really, really bad.

Note that if you had a well-behaved telecined movie it might make sense to try inverse telecining it to 23.976, but the horribly-mastered DVDs I'm working from are bizarre mixtures of 23.976 and 29.97, often switching every few seconds, and I don't want to throw the complexities of inverse telecine in there as well. I'm also not sure just what the maximum frame rate the VL-878 can handle actually is; 23.976 may well still be too much. Instead of worrying about inverse telecine, telling mencoder to drop the frame rate and letting it do that in its default way seems to work best.

So the final command line I'm using for 4:3 looks like this. Note the keyframe interval decreased to 15 to account for the lower frame rate. The frame rate conversion itself is just the "-ofps 15" option. Substitute "scale=800:-2" with 16:9 input.

mencoder dvd://1 -chapter 1-10 -alang ja -slang en \
   -oac mp3lame -lameopts q=7 \
   -ovc lavc -lavcopts vcodec=mpeg4:vhq:keyint=15 -ofps 15 \
   -vf scale=-2:480,expand=800:480 \
   -o episode01.avi

Video transcoded using those settings provides the best performance I've seen from the VL-878 so far, though I'm still experimenting a bit to see if I can improve it further. On Boogiepop Phantom, which I was using for testing, the bitrate comes to about 800kbps video and 100kbps audio; I expect that with other series the video bit rate may be a bit higher because Boogiepop Phantom's stark visual design may tend to be more compressible than average. The default bitrate seems to be reasonable given the amount of storage space on the device and how much video I want to watch on it between reloads; I haven't experimented much with trying to raise or lower the bitrate.