Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Doom demo backgrounder
From: roland (for_spam_at_gmx.de)
Date: 2003-12-14


wow - thanks for the in depth explanation!

just one comment:

>The poor little box has no CPU power to do anything mory fancy, don't
>dare to think about compression.
mhhh - my first thoughts where: not even with lzo/minilzo ? -> http://www.oberhumer.com/opensource/lzo/
maybe - if "we" can reprogram the MAS one day, uncompression routine could be even accelerated whith that dsp?

BUT:
rdf`s seem to be very bad compressible,anyway. i gave it a try with 7zip, the best filecompressor i know. but even that reduced the
doom.rvf by just ~15%. so it`s not even worth thinking about compression,IMHO.

regards
roland

----- Original Message -----
From: "[IDC]Dragon" <idc-dragon_at_gmx.de>
To: <rockbox_at_cool.haxx.se>
Sent: Sunday, December 14, 2003 7:56 PM
Subject: Doom demo backgrounder

> Hello,
>
> 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
> subsequent bytes
>
> 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
> flow.
>
> 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.
>
> So long,
> Jörg
>
> 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
aaa