Hi,

On Fri, Mar 16, 2012 at 12:20 PM, Janne Grunau <[email protected]> wrote:
> On 2012-03-16 11:05:02 -0700, Ronald S. Bultje wrote:
>> On Fri, Mar 16, 2012 at 10:36 AM, Janne Grunau <[email protected]> 
>> wrote:
>> > The decoder knows in decode_frame() already if the next slice is the
>> > first slice of a frame. So move all frame initialization code from
>> > decode_slice here for clarity. This allows us to check if decoder has
>> > still a partly decoded frame. If it has we can return it and mark it as
>> > finished. This prevents hangs during frame-multithreaded decoding.
>> [..]
>> > +    /* first slice */
>> > +    if (si.start == 0) {
>> > +        if (s->mb_num_left > 0 && s->current_picture_ptr) {
>> > +            av_log(avctx, AV_LOG_WARNING, "last frame is incomplete.\n");
>> > +            *got_picture_ptr = finish_frame(avctx, pict);
>> > +            //s->current_picture_ptr = NULL;
>> > +            s->mb_x = s->mb_y = s->mb_num_left = 0;
>> > +            return 0;
>> > +        }
>>
>> I don't think this works in -mt in practice. We _require_ that buffers
>> are consumed in full in MT codecs, and that by extension means that a
>> buffer contains no more than 1 frame. This basically comes down to 2
>> frames in a buffer. I don't think this happens in practice anyway, so
>> I'd just error out.
>
> It should never happen with proper streams. It happens with broken
> streams. depending on how broken they are returning them makes sense.
>
> Erroring out is wrong since we lose two frames that way. Just marking
> the frame complete and continue decoding sounds like the best option.
> I'll test with artificially broken streams.

I'm just afraid that not consuming the full packet will open a
complete new shitload of design issues that we just shouldn't want to
have to deal with... If it doesn't happen with real streams, then
erroring out may simply be easier, even if it's not ideal. Don't
forget, it's something that should never happen anyway...

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to