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

[Michael Niedermayer]

On Mon, Nov 01, 2010 at 02:55:26PM +0300, Anatoly Nenashev wrote:
> On 01.11.2010 14:35, Michael Niedermayer wrote:
>> On Mon, Nov 01, 2010 at 02:06:25AM +0300, 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.
>>>      
>> i see what you are trying to do but thats misusing that flag
>> i think you will have to add a new flag for this, and h264 could use that too
>>    
>>
> Ok. I will add a new flag. It might be called CODEC_FLAG_COLLECT_FRAME  

CODEC_FLAG_RETURN_INCOMPLETE_FRAMES
unless someone has a better idea


> for example. But I don't understand how it can be used for h264.
> H264 has I-frames (with IDR flag enabled) and there is no need to  
> collect a full frame from the parts. Am I misunderstand something?

sei_recovery_frame_cnt


[...]
--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101101/85332e88/attachment.pgp>