Rockbox mail archive
Subject: Doom demo backgrounder
From: [IDC]Dragon (idc-dragon_at_gmx.de)
Thanks for the acknowlegements!
I guess I own you guys some explainations, after rolling that one out.
As you saw, "video.rock" is a little video player. All it does is reading a
file from disk and pumping it to the display, as fast as possible. I did a
new display function which is about twice as fast as the original, which also
wasn't bad. It's not used be the rest of rockbox yet for 2 reasons:
1) it still has a bug, so there is a side effect on the red LED
2) we'd have to "tilt" rockbox' internal screen buffer to have the X-axis as
The file format ".rvf" means Rockbox Video File and is something proprietary
I made up. It is just raw data in exactly the format being sent to the LCD,
so that playback is as straightforward as possible. The poor little box has
no CPU power to do anything mory fancy, don't dare to think about compression.
The plugin has 2 modes depending on file size. If the file completely fits
into the plugin memory (like the Lena picture), it is loaded upfront and then
looped from memory. So this is for stills, highest possible framerate there.
If the file is larger, I stream it from disk as it is displayed.
But you have seen grayscales in the video, correct. This is done offline by
the program which generates the rvf stream. The program switches the pixels
on and off with a ratio depending on the gray value. The slow LCD and eye make
it appear as gray again. The theory behind is similar to a 1-bit DAC in your
CD player. Some signal processing logic charges or discharges the output
very rapidly (oversampling), the slower output gives the desired analog although
the switching was digital. I generate such a "bitstream" for each pixel
individually. The number of gray shades is not really limited, since I don't have
a fixed number of frames which are periodically changed. It is a continuous
For this reason stricly speaking I cannot loop for stills like the Lena
picture, the sequence has no period. If I do, there is a break and you see a bit
of a bump, or regular patterns. The result is not too bad, but Lena looks
better when encoded into a file as long as the viewing time.
Our "oversampling" is not the best. If I interpret the LCD controller specs
correct, it scans its internal frame buffer with about 75 Hz, depending on
voltage and temperature. Unfortunately we have no feedback about this, cannot
sync to the diplay. Ideally I'd like to rewrite the frame buffer for each
scan. The video player almost has that speed (my latest does 71 fps from file,
I've optimized the file reading to do always whole sectors), but can't be in
sync. However I don't see any tearing artifacts from this, probably the slow
LCD levels it out.
You can convert an .avi file into .rvf, once I've brushed up my encoder
program. Currenly I have to write the filename and parameters into the code and
recompile. You'll need an .avi with 112*64 pixel resolution, for best results
bear in mind that the LCD doesn't have square pixels. The X-axis is more
dense, the aspect ratio is 0.8.
The halftoning algorithm is not complicated. On a PC, the encoding is way
faster than realtime. The Archos could also do it (once I've ported it to fixed
point, it's all floats now), but not in real time. For for JPEG/album cover
or whatever viewer it would have to encode a fair number of frames
beforehand, then enter a presentation loop. I think its feasible to give Rockbox a
halftoning module, with these 2 steps.
The MAS can still decode its mp3 audio in the background, so we can have
videos with sound. For best results, the mp3 data should be already byteswapped
in memory, to avoid disk and swap activity during presentation. The current
plugin API doesn't allow me to load, prepare anr run an mp3 file, that's why
there's currently no sound.
PS: I'm not really online the next 2 days, so no quick answers.
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
Page was last modified "Jan 10 2012" The Rockbox Crew