Andrew Bachmann <shatty@...
2004-01-21 09:10:02 GMT
I have been working on the media_decoder app to better understand how the communication
between the extractor and decoder occurs in R5. This all happened because I ran into a problem
because I had an issue with the meta data fields. (the were not being copied) So, I went to R5 to
see how/if they were copied. Well, it turns out all fields are copied verbatim, with one little
gotcha. It seems the _area fields are somehow treated specially if they are not set to
B_BAD_VALUE. But this email isn't about that.
Initially we used the info field to pass header information to the decoder from the extractor.
We abandoned that because our test case app "media_decoder" was able to succeed without
passing any info in. (also there was a related issue with the bebook description of the info field
which is code-wise impossible)
So, I changed over to using the meta data field to store this information, since the "format" is the
only argument passed in to the BMediaDecoder. This works well for the ogg/vorbis pair, ogg/
speex, etc., and seems to have no theoretical problems associated with it, with the minor issue
about copying between address spaces, which seems to be able to be solved by the conveniently
located meta_data_area variable.
Well, I thought I had it all figured out when I went to test the copying behavior on R5. Here's
what I found out:
The format returned from EncodedFormat is fairly spartan. In the case of mp3, it has the
following fields set: type, output.frame_rate, output.channel_count, output.buffer_size,
bitrate. In the case of ogg, it has the following fields set: type, output.frame_rate,
output.channel_count, output.format, output.byte_order, output.buffer_size, encoding.
Notably missing from the above lists are: user_data, meta_data, or any other "miscellaneous"