headers
Peter D'Hoye | 1 May 2009 23:35
Picon
Favicon
Gravatar

RE: DevCon 2009: 19-21 june in Ghent, Belgium

To the devs attending devcon09...

> If you are going to come to devcon 2009 in Ghent, it would be 
> nice if you could update 
> http://www.rockbox.org/twiki/bin/view/Main/DevConEuro2009
> and certainly 
>
http://www.rockbox.org/twiki/bin/view/Main/DevConEuro2009#Hotels_and_Room_Sh
aring
>
> The hotel isn't very big and since devcon is within the holiday season,
> I'm sure the owners would like to know some final numbers soon.

I'd like to do a formal reservation in the hotel by wednesday (2009-05-06),
so could you please update the wiki so that I have some definite numbers?

I'm particulary looking at markun, pondlife and kugel (you're in the
DevCon2009 page).
I'm also looking at amiconn (and pixelma?) (you mentioned you would be
coming by car in irc)

muchas garcias
Peter
Permalink | Reply | 1 comment |
headers
tracker | 2 May 2009 00:00
Favicon

Open patches in Rockbox

Flyspray contains 417 open patches:

0 days old: Allow the FM region to be set from a FMR file
0 comments, 1 files: http://www.rockbox.org/tracker/10181

0 days old: Better runtime for PP502x target through running at 24MHz
2 comments, 1 files: http://www.rockbox.org/tracker/10180

1 days old: JPEG album art
0 comments, 1 files: http://www.rockbox.org/tracker/10178

1 days old: core jpeg decoder
2 comments, 3 files: http://www.rockbox.org/tracker/10177

4 days old: Patch to Spanish language file
0 comments, 1 files: http://www.rockbox.org/tracker/10168

6 days old: USB arrangement - use constants and some cosmetics
2 comments, 2 files: http://www.rockbox.org/tracker/10166

7 days old: Sansa e200 AMS: lcd_blit_yuv() (mpegplayer) 
2 comments, 1 files: http://www.rockbox.org/tracker/10165

9 days old: Clean up MP4 metadata parsing to handle files with tags after 'mdat' atom
3 comments, 1 files: http://www.rockbox.org/tracker/10160

9 days old: Sansa AMS reboot on USB insert
1 comments, 1 files: http://www.rockbox.org/tracker/10159

11 days old: Font: Add IPA P Gothic font (Japanese font)
(Continue reading)

Permalink | Reply | 0 comments |
headers
tracker | 2 May 2009 00:00
Favicon

Open bugs in Rockbox

Flyspray contains 251 open bugs:

3 days old: Album Art does not update after LCD wakes up
4 comments, 0 files: http://www.rockbox.org/tracker/10171

4 days old: formatting and undocumented item in Crossfade/Enable Crossfade section of Playback Settings
0 comments, 0 files: http://www.rockbox.org/tracker/10170

5 days old: Bug in DivX0 codec
1 comments, 0 files: http://www.rockbox.org/tracker/10167

7 days old: Cannot charge iPod from Rockbox on low battery
2 comments, 0 files: http://www.rockbox.org/tracker/10164

8 days old: wierd behaviour when changing folder name while plaing music in it
3 comments, 0 files: http://www.rockbox.org/tracker/10163

9 days old: inaccurate seeking while paused
2 comments, 0 files: http://www.rockbox.org/tracker/10157

9 days old: LCD sleep can theoretically happen after the backlight turns on again
20 comments, 3 files: http://www.rockbox.org/tracker/10156

13 days old: License of firmware/export/usb_ch9.h is unclear
1 comments, 0 files: http://www.rockbox.org/tracker/10143

17 days old: Buggy selection of list items using keyboard
1 comments, 1 files: http://www.rockbox.org/tracker/10134

22 days old: playback of FLAC files on iRiver iHP-120 and H320 pauses periodically
(Continue reading)

Permalink | Reply | 0 comments |
headers
pondlife | 2 May 2009 18:56

Re: DevCon 2009: 19-21 june in Ghent, Belgium

Hi Peter,

Sadly I won't be able to attend this year.  Maybe in 2010 (when maybe I'll 
have had more time to contribute to Rockbox in general).

pondlife
Permalink | Reply | 0 comments |
headers
Alex Bennee | 6 May 2009 09:19

Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

Hi,

I've been working on a patch (FS#10160) to get some m4a files I own to
play on Rockbox. Originally it looked as though the problem was
Rpckbox's limitation on only being able to handle files with a single
"mdat" atom containing data for the codec. Some I dug into the code
and started adding support for this case.

As it happens although the test file in question has two "mdat" atoms
the second one is of zero length (probably a placeholder). However the
reason the file wasn't playing is because additional information
needed to start playback (in the "moov" atom) is after the main "mdat"
atom where rockbox used to stop parsing the file.

I could take this as a quick win, redefine the code to only deal with
single mdat's but parse the whole file before starting. However there
is nothing in the MP4 container spec that says files can't have
multiple "mdat" atoms. However I'm suffering a lack of good test cases
to work with.

So do you have any mp4, m4a or other mp4-alike file that won't play
with the rockbox libm4a codec? If so could you send me a copy?

Even better would be if anyone could tell me the command line foo to
generate such a multi-chucked mp4 file so I can make my own test
cases.

In the meantime the code is in Flyspray for your comments
(http://www.rockbox.org/tracker/task/10160). It currently has one very
un-handled case in it (the FIXME) and quite a lot of enabled DEBUGFs
(Continue reading)

Permalink | Reply | 13 comments |
headers
Paul Louden | 6 May 2009 09:41
Picon

Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

A known limitation, that I believe has to do with metadata parsing, is 
that very long AAC files (several hours, audiobooks for example) don't 
work. It may be that your patch already fixes this (if it parses to the 
end), I haven't checked, but either way it'd be something to note that 
it fixes if it does, and something to look into if it doesn't I guess.
Permalink | Reply | 1 comment |
headers
Vladimir Pantelic | 6 May 2009 09:44
Picon

Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

Alex Bennee wrote:
> Hi,
>
> I've been working on a patch (FS#10160) to get some m4a files I own to
> play on Rockbox. Originally it looked as though the problem was
> Rpckbox's limitation on only being able to handle files with a single
> "mdat" atom containing data for the codec. Some I dug into the code
> and started adding support for this case.
>
> As it happens although the test file in question has two "mdat" atoms
> the second one is of zero length (probably a placeholder). However the
> reason the file wasn't playing is because additional information
> needed to start playback (in the "moov" atom) is after the main "mdat"
> atom where rockbox used to stop parsing the file.

moov after mdat is not uncommon at all. Some MP4 writer SW do that so
they can 1st write all the data, then add the "header" at the end. Of
course that messes up streaming such files....

> I could take this as a quick win, redefine the code to only deal with
> single mdat's but parse the whole file before starting. However there
> is nothing in the MP4 container spec that says files can't have
> multiple "mdat" atoms. However I'm suffering a lack of good test cases
> to work with.

Yes, in theory you could have each "sample" inside it's own mdat if you
wanted.

> So do you have any mp4, m4a or other mp4-alike file that won't play
> with the rockbox libm4a codec? If so could you send me a copy?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Alex Bennee | 6 May 2009 09:55

Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

2009/5/6 Paul Louden <paulthenerd <at> gmail.com>:
> A known limitation, that I believe has to do with metadata parsing,

Yes, a limitation I'd like to fix :-)

> is that
> very long AAC files (several hours, audiobooks for example) don't
> work.

I'll see if my other half has some audiobooks around which could make
good test subjects.

> It
> may be that your patch already fixes this (if it parses to the end), I
> haven't checked, but either way it'd be something to note that it fixes if
> it does, and something to look into if it doesn't I guess.

There are two mp4 metadata parsers (code duplication!), one just for
the metadata and one for the codec. I've tweaked both so far to go
through the whole file. However currently the codec won't play more
than the first "mdat" atom.

--

-- 
Alex, homepage: http://www.bennee.com/~alex/
CV: http://www.bennee.com/~alex/cv.php
Permalink | Reply | 0 comments |
headers
Alex Bennee | 6 May 2009 10:00

Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

2009/5/6 Vladimir Pantelic <pan <at> nt.tu-darmstadt.de>:
> Alex Bennee wrote:
>>
>> Hi,
>>
>> I've been working on a patch (FS#10160) to get some m4a files I own to
> <snip>
>
> moov after mdat is not uncommon at all. Some MP4 writer SW do that so
> they can 1st write all the data, then add the "header" at the end. Of
> course that messes up streaming such files....

This file was from iTunes although curiously the others in the same
album didn't have this moov after mdat layout. As it stands Rockbox
(with my patch) will now play these files.

>> I could take this as a quick win, redefine the code to only deal with
>> single mdat's but parse the whole file before starting. However there
>> is nothing in the MP4 container spec that says files can't have
>> multiple "mdat" atoms.
<snip>
>
> Yes, in theory you could have each "sample" inside it's own mdat if you
> wanted.

That would be pathalogical. At the moment I've a fixed size array in
the codec that will deal with up to 10 mdat atoms in a file. As we
can't really dynamically allocate re-sizeable memory I think the best
that can be done is size it according to what has been seen in the wild.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Vladimir Pantelic | 6 May 2009 10:16
Picon

Re: Bring me your broken MP4s, your twitchy AACs and other non-working m4a's

Alex Bennee wrote:

<snip>
>>
>>  Yes, in theory you could have each "sample" inside it's own mdat if you
>>  wanted.
>
> That would be pathalogical. At the moment I've a fixed size array in
> the codec that will deal with up to 10 mdat atoms in a file. As we
> can't really dynamically allocate re-sizeable memory I think the best
> that can be done is size it according to what has been seen in the wild.

do you really care about the mdat atoms? The offset data for the samples is
not mdat relative, so you don't need to keep the mdat info in memory, do you?
Permalink | Reply | 5 comments |

Gmane