[FFmpeg-devel] SOC Qualifiction tasks

[Uoti Urpala]

On Fri, 2008-03-14 at 20:20 +0100, Andreas ?man wrote:
> Uoti Urpala wrote:
> > On Fri, 2008-03-14 at 18:56 +0100, Andreas ?man wrote:
> >> * Asynchronous decoding (I.e. decoding frames even when the caller
> >>    is not currently in 'avcodec_decode_video()').
> >>    Of course this must be fully hidden from the caller POV.
> > 
> > You can't hide it from the caller. Normally the caller gives the frame
> > data and expects full results before the call returns. With that API
> > there is nothing to decode when the caller is not currently in
> > avcodec_decode_video(). For asynchronous decoding you need a different
> > API that allows the caller to queue frames in advance.
> 
> I was under the impression that '*got_picture_ptr' would be zero in the
> case when the decoder can not (yet) deliver a complete picture.
> So it will just be zero the first few calls to avcodec_decode_video().
> But perhaps I'm missing something.

- Return value will not be correct in case of errors.
- Doesn't for with LOW_DELAY.
- Without LOW_DELAY will make DTS (even more) meaningless.
- A naive implementation would call get/release buffer callbacks from
another thread and/or outside avcodec_decode_video() call. It's probably
possible to avoid this in most cases but at least it requires extra
work.

This would break timing based on DTS (in the cases where it worked
before). It would break the hack ffmpeg.c uses to reorder pts in decoder
unless the code was changed so that all buffer management is done in the
calling thread before returning. MPlayer's basic method of reordering
pts in a decode delay sized buffer would keep working, but it would
break the comparison with avctx->has_b_frames used to detect cases where
a pts will really never have a corresponding visible frame. The timing
problems are not purely the fault of the thread-related API changes
though; if FFmpeg had better functionality to track frame timestamps and
reordering across decoding then such changes would not break things so
easily.

On a more general level I don't like the idea of managing concurrently
running threads behind the caller's back as the ONLY supported mode of
operation.