[FFmpeg-devel] [PATCH] Mobotix .mxg demixer and MxPEG decoder basic implementation

Anatoly Nenashev nenashev_as
Wed Aug 11 19:22:48 CEST 2010


On 11.08.2010 20:13, Michael Niedermayer wrote:
>
>> diff -r 02ffe42e2ae2 libavcodec/mjpeg_parser.c
>> --- a/libavcodec/mjpeg_parser.c	Sun Aug 01 14:52:28 2010 +0400
>> +++ b/libavcodec/mjpeg_parser.c	Tue Aug 10 23:42:47 2010 +0400
>> @@ -26,6 +26,7 @@
>>    * MJPEG parser.
>>    */
>>
>> +#include "libavutil/intreadwrite.h"
>>   #include "parser.h"
>>
>>
>>      
>    
>> @@ -70,6 +71,22 @@
>>       return END_NOT_FOUND;
>>   }
>>
>> +static int64_t mxpeg_get_timestamp(const uint8_t *buf, int buf_size)
>> +{
>> +    int i;
>> +    uint16_t state = 0;
>> +    int64_t dts = AV_NOPTS_VALUE;
>> +    for (i = 0; i<  buf_size - 18; ++i) {
>> +        state = (state<<8) | buf[i];
>> +        if ((state == 0xFFFE)&&  (AV_RL32(buf+i+3) == MKTAG('M','X','F',0))) {
>> +            dts = av_rescale(AV_RL64(buf+i+11), 1, 10000);
>> +            break;
>> +        }
>> +    }
>> +
>> +    return dts;
>> +}
>>      
> this looks wrong and inefficient
> i dont belive scaning the buffer like this is the correct way
>
>
>    

Ok. I will reimplement this code. But it works on test data :-)

>> diff -r 02ffe42e2ae2 libavcodec/mjpegdec.c
>> --- a/libavcodec/mjpegdec.c	Sun Aug 01 14:52:28 2010 +0400
>> +++ b/libavcodec/mjpegdec.c	Tue Aug 10 23:42:47 2010 +0400
>> @@ -331,18 +331,28 @@
>>               s->avctx->pix_fmt = PIX_FMT_GRAY16;
>>       }
>>
>> -    if(s->picture.data[0])
>> -        s->avctx->release_buffer(s->avctx,&s->picture);
>> +    if (CODEC_ID_MXPEG == s->avctx->codec_id) {
>> +        if (s->avctx->reget_buffer(s->avctx,&s->picture)<  0) {
>>      
> this makes double buffering with direct rendering impossible
>
>
>    

Well, I'm not agree or there is something I don't understand. By my 
opinion reget_buffer do 3 things:
1) create new buffer
2) copy data from old buffer to new buffer
3) release old buffer

Decoder is the owner of a picture thus no one must destroy or trash 
picture outside the call of ff_mjpeg_decode_frame.
On the other hand decoder will lost the owning of old picture after 
reget_buffer call (or release_buffer).
I can't see any problem with delayed direct rendering.

>    
>> @@ -1026,6 +1044,12 @@
>>       if(8*len + get_bits_count(&s->gb)>  s->gb.size_in_bits)
>>           return -1;
>>
>> +    /* skip MXPEG audio data*/
>> +    if ((s->avctx->codec_id == CODEC_ID_MXPEG)&&  (s->start_code == APP13)) {
>> +        skip_bits(&s->gb, (len-2)<<  3);
>> +        return 0;
>> +    }
>>      
> how does the audio data reach the video decoder?
> this just looks like the demuxer is wrongly implemented
>
> [...]
>
>    

On the other hand APP13 is valid marker for JPEG format. So, there no 
need to extract this data from video stream.
Also rejecting audio data from video stream will reduce the performance.


Anatoly.



More information about the ffmpeg-devel mailing list