[FFmpeg-devel] [PATCH 3/3] Mobotix MxPEG decoder, parser, demuxer

Anatoly Nenashev nenashev_as
Mon Aug 16 23:39:06 CEST 2010


On 16.08.2010 23:22, Reimar D?ffinger wrote:
> On Mon, Aug 16, 2010 at 10:53:08PM +0400, Anatoly Nenashev wrote:
>    
>> On 16.08.2010 21:13, Michael Niedermayer wrote:
>>      
>>> On Sat, Aug 14, 2010 at 03:32:33AM +0400, Anatoly Nenashev wrote:
>>>        
>>>> Here is MxPEG clip file demuxer implementation.
>>>>          
>>> this demuxer already scans for ffxx so why is a seperate parser needed?
>>>
>>>        
>> Because of Reimar Doeffinger comment in thread  "[PATCH] Mobotix
>> .mxg demixer and MxPEG decoder basic    implementation" :
>>
>> "Splitting into individual frames really does not belong into the demuxer,
>> it should be done in a parser.
>> A demuxer should only do things like splitting audio and video,
>> and if available process pts, dts, metadata, keyframe flags etc.
>> This is doubly true for JPEG where I think there are still issues
>> with interlaced JPEG and this could not benefit from
>> any fixes to that."
>>      
> It's mostly the last part, however that of course means that
> the JPEG parser would have to be reused for this, a completely
> new parser would not be of any advantage (I did not look
> at the new patch so far, so I don't know what is done).
>
>    

JPEG parser just sequentially finds SOI marker position while MxPEG 
demuxer & parser needs to do a lot of work:
- find SOI marker
- find APP13 marker for audio data, extract audio data
- find COM marker which contains MXF tag, extract timestamp out there

Also some blocks of data needs to be skipped as a whole (COM, APP13), 
but not sequentially. Otherwise it may cause errors in decoder.
So I don't see any reason to reuse JPEG parser functionality because it 
is comparatively empty.




More information about the ffmpeg-devel mailing list