|
Rockbox mail archiveSubject: Re: Video plugin and tools problems/limitationsRe: Video plugin and tools problems/limitations
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Thu, 19 Feb 2004 00:29:43 +0100 Hello [IDC]Dragon On 18.02.2004, you wrote: >> - Question: Is it possible to set the "repeat" flag in the >> RVFh... > Yes, the player is using this flag, you can do so. ... Ok. Will do a run time test this way, but not today/tomorrow. >> - Perhaps on the 2 MB recorder it is better to not spin down >> the > Hmm, then I would have to explicitely prevent the disk from > falling asleep. Needs a new plugin function, or I change it to > do nothing and you set a long spindown timer. Currently I > spindown immediately when the data portion is read. It would be sufficient to do it the simple way (currently the disk spins up about every 25 s on a 2 MB recorder, so setting the spindown timeout to 30 s would prevent it from spinning down while watching video (hey - this is only for testing!) >> It should be possible to read even >4 GB on windows if you >> use NTFS. Don't know about linux here. > It seems the POSIX file functions I use for portability dont > > 2 GB. If I give that up, I can use Windows' 64 bit > file addressing. I googled around a bit and found that there _is_ a POSIX way of doing large file support. From what I got, you have to use the type "off_t" instead of "long" for file offsets and maybe #define _FILE_OFFSET_BITS=64 #DEFINE _LARGEFILE_SOURCE (this goes for GCC and Cygwin version 1.5.0+ shall also support it) >> >> - "RVF_MUX" has problems multiplexing the video with audio >> >> that uses MPEG2 or MPEG2.5 sample rates ... >> >>> MPEG2 should work. I have not implemented the 2.5 audio >>> formats, but this can be easily changed. >> >> MPEG2 definitely doesn't work most of the time. I did the >> following thorough tests: > May be a bug. I have meanwhile implemented 2.5, without > testing it, I send it to you in a separate email. Maybe it > changes the 2 behaviour as well, but I don't think so. It doesn't change the MPEG2 behaviour at all. Here are the new results for MPEG2.5: freq | MP3 mode | results -------------------------------------- 12000 | VBR | 163x ASE, FG, AGLB 12000 | CBR 48k | works! 11025 | VBR | 52x ASE, F0, hangs 11025 | CBR 48k | 72x ASE, FG, AL (ASE = "Audi sync error in file..." FG = result file was generated F0 = result file has zero bytes hangs = you have to press ctrl-c AGLB = audio glitches & loops back on playback AL = audio runs significantly longer than video) It looks like that the same bug strikes both at 2 and 2.5. It looks like this pattern: - "even" freqs (24000/16000/12000/[8000?]) with CBR will work - "even freqs with VBR give sync errors and too long audio - "odd" freqs (22050/11025) with CBR give sync errors and too long audio too - "odd" freqs with VBR will hang RVF_MUX > I have also speeded up halftone.exe by a factor of 3. In there > some really suboptimal code from my first tries was never > reworked. Feel free to redistribute, I can't update my > webspace right now. Couldn't test this one since it is apparently compiled with #define PROFILING and I have no Windows C compiler at hand :( >> > Strange, I only set the volume, because it can be muted >> > when the plugin starts. The others I don't touch. ... >> But it definitely does reset these. I tested ... > Other people have reported that as well. I set the volume and > init the playback. Maybe there are some side effects. I > currently can't compile Rockbox, while being in Taiwan. I guess this has to wait until you are back in good old europe then... >> > I try. I'm (slowly) working on a one-click tool to ... >> Don't know if a one-click tool makes much sense since there >> are many special things in the conversion process which >> require manual correction ... >> Most appreciated would be a >> tool (could be a portable command line tool too) that >> - can read AVI >2 GB and even >4 GB on NTFS > The portability already stops at AVI, I think. Since there are AVI players for other OSes than Windows, there must be something like an open source AVI lib that you can compile in. Of course this doesn't make much sense for your tool on platforms where AVI is not a canonical video format. >> This way you don't even need to create the intermediate AVI >> physically - have a look at "AVIsynth" >> (http://www.avisynth.org). > This is also Windows only, if I read correct. Correct. The option to virtualize the intermediate AVI would only be possible on Windows this way. > But yes, with what I have in mind you won't need any > intermediate files. Afair you one-click-tool will be Windows only either. Regards, Jens _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockbox Received on 2004-02-19 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |