[openbeosmediakit] Re: Question on new codec API
- From: Marcus Overhagen <marcusoverhagen@xxxxxxxx>
- To: openbeosmediakit@xxxxxxxxxxxxx
- Date: Fri, 5 Dec 2003 13:34:27 +0100 (CET)
> > > The GetNextChunk(void *cookie,
> > > void **chunkBuffer, int32 *chunkSize,
> > > media_header *mediaHeader)
> > >
> > > Method does not supply a streamnumber which makes it difficult to
> > > determine which cookie I need to cast to.
> >
> > The idea is that AllocateCookie gets called once for each stream, so
> > you can put everything needed for the stream (even it's number)
> > into the cookie, and common data into the Reader class itself.
>
> Hmm, I am thinking of a stream as being a stream of audio or video
> data.
> Are you thinking of a stream being the file?
No, a stream is a track inside a file, either audio or video
> > > I think all the methods need to supply this parameter
> > >
> > > FreeCookie, GetStreamInfo, Seek.
> >
> > We could do that, but do we really need it?
> > What exactly are you trying to do?
>
> Well, my AVI reader handles 2 types of streams. Audio and Video.
Ok, was to be expected :)
>
> So I made a seperate cookie for each type. Perhaps that was wrong of me.
Perhaps the api is wrong, no problem.
> I was expecting that a streamnumber would be supplied so I can
> determine what data to supply (audio or video and from what track).
> Also some containers have multiple audio or video tracks so how do I
> determine which one I should be reading in GetNextChunk?
well, my idea was that each cookie hold all this information,
like current position of the stream, type, whatever.
until we find a better solution (which could mean adding the stream number as
parameter)
you could add a int32 stream_id to the top of both cookie structures, so what
they are
at the same place.
You can initialize it inside AllocateCookie, and access it in GetNextChunk
like:
struct a_cookie {
int32 stream_index;
someing else for audio...
}
struct v_cookie {
int32 stream_index;
someing else for video...
}
doesn't matter which type you use for initial comparing of stream index,
since it's at the same position in both cookies. you just need to initialize
it in AllocateCookie()
if (static_cast<a_cookie *>(cookie)->stream_index ==
whatever_number_you_expect) {
a_cookie *a = static_cast<a_cookie *>(cookie);
// handle audio stream
} else {
v_cookie *v = static_cast<v_cookie *>(cookie);
// handle video stream
}
you could also (and that was my original intention) use a common cookie
structure like
struct the_cookie {
int64 position;
int32 stream_2cc; // two character code used in avi for htis stream
bool is_audio;
...
}
so that you don't have to care about the stream index number, because
the cookie contains everything to find the next chunk of data.
You just need to properly initialize it with the right values in AllocateCookie
so that you can use it opaque.
However, I haven't written anything yet that would use it this way, so
I don't know for sure if there is a benefit.
I would like to try it, but if it proves to be useless, we can change it.
Marcus
Other related posts:
