dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Video plugin and tools problems/limitations

Re: Video plugin and tools problems/limitations

From: Jens Arnold <>
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
(this goes for GCC and Cygwin version 1.5.0+ shall also support

>> >> - "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

>> > 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"
>> (

> 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

Received on 2004-02-19

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy