[Ffmpeg-devel] [PATCH] cook compatible decoder

[Benjamin Larsson]

Rich Felker wrote:

>On Tue, Nov 08, 2005 at 08:08:13AM +0100, Benjamin Larsson wrote:
>  
>
>>Michael Niedermayer wrote:
>>
>>    
>>
>>>Hi
>>>
>>>On Sun, Nov 06, 2005 at 11:23:47PM +0100, Benjamin Larsson wrote:
>>> 
>>>
>>>      
>>>
>>>>[...]
>>>>
>>>>
>>>>The extradata handling has not been changed. The rm containter and codecs
>>>>are not easy separated.
>>>>   
>>>>
>>>>        
>>>>
>>>what exactly is the problem here? except the byte order of extradata, which 
>>>seems a trivial thing to fix, just store the stuff in big endian order
>>>instead of native or always little endian if you prefer
>>>
>>>[...]
>>> 
>>>
>>>      
>>>
>>The real problem is the way cook is stored in rm. They store subpackets
>>out of order. Realplayer reorders the subpackets in the demuxer. I
>>did the reordering in the codec to simplify the demuxer layer. But to be
>>able to know how to reorder I need 2 variables from the ra header. Those
>>variables are added to the extradata and passed to the decoder. Currently
>>5 extra variables are passed, it could be reduced to 2 but it doesn't solve
>>the problem of being able to mux cook into something else without
>>cook specific code in the (de)muxer, if the codec reorders the subpackets.
>>
>>We could do it the way Realplayer does it, then we would only pass real
>>extradata and let the demuxer reorder the subpackets. This way it might
>>be possible to mux into another container without cook specific code.
>>The rm demuxer would need a rewrite for it to work though.
>>    
>>
>
>The demuxer must do the reordering, because the objects sent to the
>decoder should be complete frames, not butchered container format
>specific packets..
>
>Rich
>  
>
I think I agree after some thought, the rm demuxer needs some work
to be able to support cook then. The reordering is quite easy if you just
can read enough data. That should be more easy to do in the demuxer.

MvH
Benjamin Larsson