FreeLists / openbeosmediakit / [openbeosmediakit] Re: Question on new codec API

["David McPaul" <dmcpaul@xxxxxxxxxxxxxx>]

Heya,

        Well time for bed.

        Attached is what I have done so far.

        Basically some hard parts are still left.  Using the index to 
position the stream as required (ie Seek and ReadNextChunk).  I will 
look at them tommorrow.

        Also, the reader currently only works for OpenDML AVI files.  
Adding support for original AVI files should just be a matter of using 
the original index type instead of the extended one since original is a 
subset of OpenDML.  I will look at adding that too.

        Something to note, a lot of the code that handles the Audio data is 
taken from some example code that BeOS sent to codec developers.  All 
the video parsing code is my own.

        I cc'ed you since I vaguely remember this list not liking 
attachments.

        Regarding the supplying of the stream number vs not supplying it.  
I am generally against casting void pointers to something they are not 
just to find out what they really are so I can cast properly.

Cheers
David

> 
> > > > 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.