|
Rockbox mail archiveSubject: Re: Doom demo backgrounderRe: Doom demo backgrounder
From: roland <for_spam_at_gmx.de>
Date: Sun, 14 Dec 2003 21:55:34 +0100 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 > > Received on 2003-12-14 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |