[FFmpeg-devel] [PATCH 1/2] MxPEG decoder

[Anatoly Nenashev]

On 01.11.2010 02:06, Anatoly Nenashev wrote:
> On 01.11.2010 00:44, Michael Niedermayer wrote:
>> On Sun, Oct 31, 2010 at 09:20:34PM +0300, Anatoly Nenashev wrote:
>> [...]
>>> @@ -195,6 +198,37 @@ int ff_mjpeg_decode_dht(MJpegDecodeContext *s)
>>>       return 0;
>>>   }
>>>
>>> +static int mjpeg_allocate_picture(MJpegDecodeContext *s)
>>> +{
>>> +    if(s->picture.data[0])
>>> +        s->avctx->release_buffer(s->avctx,&s->picture);
>>> +
>>> +    s->picture.reference= 0;
>>> +    if(s->avctx->get_buffer(s->avctx,&s->picture)<  0){
>>> +        av_log(s->avctx, AV_LOG_ERROR, "mjpeg get_buffer() failed\n");
>>> +        return -1;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int mxpeg_allocate_picture(MJpegDecodeContext *s)
>>> +{
>>> +    if (s->mxctx.reference_picture.data[0])
>>> +        
>>> s->avctx->release_buffer(s->avctx,&s->mxctx.reference_picture);
>>> +    s->mxctx.reference_picture = s->picture;
>>> +    s->picture.data[0] = s->picture.data[1] =
>>> +        s->picture.data[2] = s->picture.data[3] = 0;
>> the indention is odd
>>
> Just a feature of Emacs. Indention removed.
>
>>> +
>>> +    s->picture.reference= 1;
>>> +    if(s->avctx->get_buffer(s->avctx,&s->picture)<  0){
>>> +        av_log(s->avctx, AV_LOG_ERROR, "mxpeg get_buffer() failed\n");
>>> +        return -1;
>>> +    }
>> duplicate code
>>
>>
> May be not because "mxpeg_allocate_picture" used in two places: 
> ff_mjpeg_decode_sof and mxpeg_decode_mxm.
>
>> [...]
>>> @@ -788,14 +823,29 @@ static int 
>>> mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, i
>>>           }
>>>       }
>>>
>>> +    if (use_mxm_bitmask) {
>>> +        if (s->mb_width*s->mb_height>  
>>> (s->mxctx.mxm_bitmask_size<<  3)) {
>>> +            av_log(s->avctx, AV_LOG_ERROR, "MXM bitmask is not 
>>> complete\n");
>>> +            return -1;
>>> +        }
>>> +
>>> +        init_get_bits(&mxm_bitmask_gb, s->mxctx.mxm_bitmask,
>>> +                      s->mxctx.mxm_bitmask_size<<  3);
>>> +
>>> +        s->picture.pict_type= FF_P_TYPE;
>>> +        s->picture.key_frame= 0;
>>> +    }
>>>       for(mb_y = 0; mb_y<  s->mb_height; mb_y++) {
>>>           for(mb_x = 0; mb_x<  s->mb_width; mb_x++) {
>>> +            const int copy_mb = use_mxm_bitmask&&  
>>> !get_bits1(&mxm_bitmask_gb);
>>> +            if (!reference_picture_avail&&  copy_mb) continue;
>> cant use_mxm_bitmask be 0 when !reference_picture_avail
>> (would avoid 1 check per mb)
>>
> Fixed. Conditions are switched in "if()".
>
>> [...]
>>> @@ -1505,6 +1631,15 @@ not_the_end:
>>>   the_end:
>>>       av_log(avctx, AV_LOG_DEBUG, "mjpeg decode frame unused %td 
>>> bytes\n", buf_end - buf_ptr);
>>>   //    return buf_end - buf_ptr;
>>> +
>>> +    if (s->avctx->codec_id == CODEC_ID_MXPEG&&
>>> +        !s->mxctx.has_complete_frame) {
>>> +        if (s->picture.key_frame)
>>> +            s->mxctx.has_complete_frame = 1;
>>> +        else if (!(s->avctx->flags&  CODEC_FLAG_LOW_DELAY))
>>> +            *data_size = 0;
>> mxpeg is always low delay, unless i misunderstand something
>>
>>
>
> Not absolutely so. Generally there's no I-Frame concept for MxPEG 
> known from other codecs. Every encoded frame contains some parts of 
> all image.
> All that we know is after fixed time delay we can collect a full 
> puzzle. Actually some cameras send full JPEG  frame in connection and 
> this feature is supported in attached patch but this is not that case 
> on which it is necessary to rely. That's why if CODEC_FLAG_LOW_DELAY 
> is disabled the decoder must collect a full image before return a 
> first decoded frame. Otherwise, if CODEC_FLAG_LOW_DELAY is enabled we 
> may see a frame full of holes at the start of played video.
Patch sended before is empty. Reattached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mxpeg_v2.patch
Type: text/x-patch
Size: 12774 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101101/35fc4acf/attachment.bin>