Rockbox

Sorry, forgot to remove the libavutil/trash directory before making the previous patch

   librm.patch (451 KiB)

Good work! Next step is to clean up all the dead code in there.

I only skimmed quickly, but some impressions:

cook_float should probably be removed since we’re not going to try and keep fp support.
The libavutil and ffmpeg_config.h defines you’re actually using can probably be combined into a cook.h file or similar.
dsputill.h can probably be combined too.
dsputil.c probably doesn’t have much in it beyond the windowing functions (ff_vector_fmul_add_add_c, etc), and these can be put into cook.c

Modified patch : Major code clean-up. I think it’s almost ready to be ported.

   librm.patch (233.2 KiB)

patch1 :
rm-wav converter using floating point cook decoder.

patch2 :
rm-wav converter using fixed point cook decoder.

patch3 :
clean code. (no ffmpeg-specific code)

   libcook.patch1 (539.8 KiB)
   libcook.patch2 (452.2 KiB)
   libcook.patch3 (177.4 KiB)

-Removed main() from cook.c to a separate main.c.
-Created cook.h which defines COOKContext and the decoder’s functions protoypes.

   libcook.patch2 (15.8 KiB)

I’ve committed the last libcook.patch2 as r20897 and r20898 - thanks.

Convert cook.c to use fixed-point arithmetic. Still didn’t drop almost any floating point code, although some functions maybe (#if 0)’ed for cook.c to compile.
@Dave : Thanks for the commit.

   libcook.fixp_convert (64.6 KiB)

libcook.fixp_convert committed as r20901

Drop floating point code from cook.c/h.
Remove fft.c, mdct.c and dsputil.h.

   libcook.drop_float (67 KiB)

Remove avcodec.h

   libcook.del_avcodec (112.5 KiB)

Drop floating point code from cook.c/h.
>Remove fft.c, mdct.c and dsputil.h.

Committed in r20902.

libcook.del_avcodec committed as r20909

“Preliminary” patch for get_rm_metadata().
This patch enables Rockbox to recognize a rm/ra file and parse it to get the metadata for the WPS.
The only codec supported now is cook. However, cook codec in this patch is just a fake a codec (actually it’s just the one I wrote
for my qualification task ) The purpose of the codec is just to make the file run for its length just to be able to check if the parsing
was done correctly.

For read_uint32be to work properly (to eliminate warnings during compiling ) I had to #undef uint32_t, and then redefine it to unsigned
int, as it seems it was defined for “long unsigned int”. Not an elegant solution, but it’s not my focus currently either.

Also I had to define read_uint8() [just reads a byte] and read_uint16be() as I couldn’t find it in metadata_common.h. Should I add
a read_byte() and a read_uint16be() to metadata_common.h, or just define them whenever I need them ?

   rm_md_parsing (18.3 KiB)

This is a quick-and-dirty patch for getting rm playback to work in the sim.
The patch isn’t intended for committing, it’s mainly for debugging purposes.

   rm_in_sim.patch (47.2 KiB)

Sorry the patch is no good. I’m working on another one.

This one should work. I tried it on a clean source copy.

   rm_in_sim.patch (49.5 KiB)

This patch is to add support for rm playback in rockbox. Still no seeking.

   rm_playback.v1.0.patch (53.2 KiB)

Fixed some issues from the previous patch (Pointed out by Dave Chapman on IRC) which are:
-TABs were mistakenly used as indentation in some files.
-svn:executable property was added for some files. (I really don’t know how it was added !)
-Some local functions weren’t declared static.
-No handling for big endian targets.

Note : I don’t have a big endian target, so I’d appreciate it if someone who has one could test this patch on it.

   rm_playback.v1.1.patch (57.1 KiB)

Still fixing for playback on big endian targets.

   rm_playback.v1.2.patch (57.6 KiB)

Playback works on big endian targets. I have duplicated wma’s bswap.h since it already optimized for rockbox.

   rm_playback.v1.3.patch (62.2 KiB)

Some simple modifications on rm metadata parser.

   rm_playback.v1.4.patch (62.1 KiB)

I’m wondering why your read_uint*() implementations require pointers instead of just returning the data?

For example real_read_audio_stream_info() & rm_parse_header() could benefit of this, because the numerous variables could then be registers/on stack instead of memory variables (or am I wrong here and are these already on stack?)

The above patch was committed as r21695 after some modifications for reducing bin size.