Re: [xine-devel] SPU decoders.

[Michael R. <mr...@us...>]

Hi James, Hi Miguel,

> > The problem is how to decide when to close the current spu_decoder
> > and open a new one.
> > (...)
> > I have thought of a few possible solutions: -
> > 1) Support for multiple decoder plugins open at once.
> > 2) Support for grouped buf types. I.E. For the libspudec handled
> > ones, don't switch decoder, but if a different buff type comes
> > along, switch.
> >
> > I was thinking of supporting (2) by changing the following: -
> >
> > Then, the video_decoder will think CLUT, PACKAGE and NAV etc are
> > the same type, as it only looks at the top 16 bits. Then SPU_TEXT
> > and SPU_CC would be handled differently.
>
> This sounds the best compromise for now. Alternatively the CLUT,
> PACKAGE and NAV subtypes could be moved to flags/special info inside
> the buffer (much like we do with FRAME_END, PALETTE, DECODER_CONFIG,
> etc). imho, this would make it more consistent with other decoders
> without using extra bits we might find another use in the future.

This sounds like the cleanest solution. After all BUF_SPU_NAV & co are 
no stream types of their own, so changing them to decoder flags seems a 
good idea.

> Also, cleaning up the SPU buffer types as you propose in (2) doesn't
> invalidate the idea you expressed in (1). So i think we can fix the
> problem you found now and then later revisit the issue of multiple
> spu decoders...

I think these additional spus are done best in a separate stream. We 
would have to change the sputext decoder into a "real" stream aware 
decoder and write a very thin demuxer for sputext files.

Michael

-- 
"C combines all the power of assembly language with all the 
ease of use of assembly language"  - trad