Open BeOS is the opensource derivate of BeOS - This list is used by the OpenBeOS MediaKit Team to discuss C & C++ coding as well as designing questions

Marcus Overhagen | 14 Jan 2004 10:03

AVI Support

Hi,

I just wanted to give you a small status update about the media kit.

AVI (divx video, etc) file support should be ready very soon. Right now,
avi file reading is not fully workig, but I expect to finish that later this
evening. Then the ffmpeg codecs, which are already in CVS, need to
be connected to the codec API, which shouldn't be very hard.

At the moment, we already have support for MP3, WAV, AIFF, AU and
OGG Vorbis.

After AVI playback is working, I'll make a new public alpha version package
available, most likely next Sunday evening.

The media kit codec API is a playback only right now, this means you can't
record anything. Of cause this will be changed sometime, but it will take a
couple more weeks.

regards
Marcus

headers

Jérôme Duval | 14 Jan 2004 11:22

Re: AVI Support

Selon Marcus Overhagen <ml@...>:

> After AVI playback is working, I'll make a new public alpha version package
> available, most likely next Sunday evening.
> 
> 

I'll try tomorrow to take an hour to see if a problem i have with the media kit 
is easy or not. It would be better (i'd say it's not required though) if not 
present in the alpha.

Bye,

Jérôme

headers

Marcus Overhagen | 14 Jan 2004 13:10

Re: AVI Support

Jérôme Duval wrote:

> I'll try tomorrow to take an hour to see if a problem i have with the media kit 
> is easy or not. It would be better (i'd say it's not required though) if not
> present in the alpha.
That would be nice. If required, we can delay the alpha, I'm also not sure how
many new bugs introducing video playback will reveal.

After fixing a terrible system deadlock caused by the mixer about 2 weeks
ago I didn't have noticed any major problem so far.

Of cause, having less bugs is better. Since a few people have already been
testing the media kit directly compiled from CVS, I would like to encourage 
them to report bugs or abnormitys found (to this mailinglist).
Not everything can be fixed rigt now, but we could at least include them in 
a known bugs list.

Marcus

headers

Andrew Bachmann | 21 Jan 2004 10:10

decoder discoveries

Hello all,

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

(Continue reading)

headers

Axel Dörfler | 23 Jan 2004 08:39

New BMediaFormats and friends

Hi there,

I brought the BMediaFormats class into a usable state and reworked the 
decoder seek process.
Here is what I did:
- BMediaFormats is now completely implemented
- Reader::GetStreamInfo() must now call one of the BMediaFormats::Get*
FormatFor() calls to create the empty outFormat and do his changes 
based upon that - the outFormat will automatically have a valid 
encoding because of that.
- I moved MediaPlugin::RegisterPlugin() to 
DecoderPlugin::RegisterDecoder() (since only this class used it)
- The myDecoder::RegisterDecoder() implementation must call 
BMediaFormats::MakeFormatFor() to register the media_format_description 
for the decoder.
- There is quite some magic involved with MakeFormatFor() and I am not 
sure if we should keep it this way or not; basically, the AddOnManager 
who is responsible for calling Decoder::RegisterDecoder() installs a 
hook in the server local BMediaFormats class that will call it when 
MakeFormatFor() is called - the AddOnManager is locked during that 
time, so that there is no way to call the wrong hook (it's the same 
method Marcus used before for the DecoderPlugin)
- that hook not only calls FormatManager::RegisterDe/Encoder() to get a 
valid outFormat, it also stores the new format in the decoder_info
- these formats are used to implement GET_DECODER_FOR_FORMAT - and 
that's why the reader has to pass a registered format to this call
- the FormatManager manages the audio_encoding/video_encoding fields - 
when a codec calls MakeFormatFor(), it will assign a new ID to it
- I also fixed the == and < operators for media_format_description 
(didn't touch the B_OGG_FILE_FORMAT, though)

(Continue reading)

headers

Axel Dörfler | 23 Jan 2004 08:57

BMediaDecoder

Hi there,

is it accidently or by reason that both, MediaDecoder.cpp and 
PluginManager.cpp declare a global _plugin_manager object (two 
different ones)??

Bye,
   Axel.

headers

Axel Dörfler | 23 Jan 2004 09:01

Broken locking in old AddOnManager

Hi there,

just to note it here, since I forgot to put it into the CVS change 
message:

Both AddOnManager::RegisterReader()/Decoder() had a broken locking 
strategy:

void
AddOnManager::RegisterReader()
{
	1) lock
		check if the reader already exists
	unlock

	... initialize reader ...

	2) lock
		add reader
	unlock
}

When you lock again in 2), the same reader could have been added in the 
meantime; you would have to check for its existence again.
It's better in this case to hold the lock during the whole time, given 
that the whole process is relatively light-weight.

Bye,
   Axel.

(Continue reading)

headers

Marcus Overhagen | 23 Jan 2004 09:36

Aw: BMediaDecoder

> Hi there,
> 
> is it accidently or by reason that both, MediaDecoder.cpp and 
> PluginManager.cpp declare a global _plugin_manager object (two 
> different ones)??
> 

This is a bug. MediaDecoder.cpp should not have it's own 
plugin manager object, and a function like the
static DecoderPlugin * GetDecoderPlugin(const media_format * format)
should be moved into the plugin Manager. In fact, PluginManager already has
status_t _CreateDecoder(Decoder **decoder, media_codec_info *mci, const media_format *format)
which returns a Decoder * (not DecoderPlugin *) and also filles out the media_codec_info.

Marcus

headers

Marcus Overhagen | 23 Jan 2004 09:42

Aw: Broken locking in old AddOnManager

> Hi there,
> 
> just to note it here, since I forgot to put it into the CVS change 
> message:
> 
> Both AddOnManager::RegisterReader()/Decoder() had a broken locking 
> strategy:
> 
> void
> AddOnManager::RegisterReader()
> {
> 	1) lock
> 		check if the reader already exists
> 	unlock
> 
> 	... initialize reader ...
> 
> 	2) lock
> 		add reader
> 	unlock
> }
> 
> When you lock again in 2), the same reader could have been added in the 
> meantime; you would have to check for its existence again.
> It's better in this case to hold the lock during the whole time, given 
> that the whole process is relatively light-weight.
> 
Well the idea was that RegisterReader() is only called from RegisterAddOns()
which is only executed once during startup (and only from a single thread).
The lock is only used to preserve list integrity (Rewind() changes internal list pointer).

(Continue reading)

headers

Marcus Overhagen | 23 Jan 2004 09:43

Aw: New BMediaFormats and friends


> I brought the BMediaFormats class into a usable state and reworked the 
> decoder seek process.

This looks all very good. I'm going to try it out as soon as I'm home.
BTW, is CVS working again? Yesterday it was dead slow.

Marcus

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

1	September 2009
20	July 2007
1	June 2005
4	March 2005
6	September 2004
17	August 2004
4	March 2004
21	February 2004
14	January 2004
11	December 2003
2	October 2003
10	September 2003
7	August 2003
15	July 2003
20	June 2003
1	May 2003
3	February 2003
1	January 2003
2	October 2002
7	September 2002
33	August 2002