[FFmpeg-devel] SOC Qualifiction tasks

[Uoti Urpala]

On Sun, 2008-03-16 at 20:22 +0100, Michael Niedermayer wrote:
> On Sat, Mar 15, 2008 at 06:05:04AM +0200, Uoti Urpala wrote:
> > At least it would clearly change the API from the application's POW.
> > There was no possible delay before.
> 
> a CODEC_CAP_FRAME_THREADS/CODEC_FLAG_FRAME_THREADS does not change the
> existing API, it extends it. Only an application which does something like
> 
> if(codec->flags & CODEC_CAP_FRAME_THREADS)
>     context->flags |= CODEC_FLAG_FRAME_THREADS;
> would see the new behavior.

Yes, but what I responded to originally was Andreas's opinion that
threading "must be fully hidden from the caller POV". If you need such
new behavior enabled by explicit threading flags then obviously it is
visible to the caller.
 
> > The exact input format of avcodec_decode_video() doesn't matter much,
> > main thing would be to have some way to give a pointer and have it
> > returned with the frame. The pts field in AVPacket is int64_t which
> > might not match what an application uses.
> 
> I think you are abstracting things too far here.

I don't think so. Wanting to know which input the output corresponds to
looks very reasonable to me, and using a pointer token to idenfity it is
a standard method. An union with alternative field types is a reasonable
alternative too (like epoll which allows the application to give an
union of {void *ptr; int fd; uint32_t u32; uint64_t u64;} to identify
the file descriptions that results are returned for).

> Also we do have the get_buffer() method which allows you to move a opaque
> pointer to AVFrame, this doesnt break with frame threads unless you
> implement things in a way which breaks it.

Yes, though it's IMO an ugly hack. It's also very nonobvious when it's
not explicitly documented (you need to mess with buffer callbacks to
implement timing based on pts?) and it's not clear whether it's
guaranteed to work.

> [...]
> > > > Another thing is that if you use LOW_DELAY then (AFAIK) there's no way
> > > > to access the reordering information. So if you decode a bunch of frames

> > For use in a practical player it would still be useful to know WHICH
> > frame is output from the codec's point of view even if you always buffer
> > at least has_b_frames+1. It's necessary if you only have DTS, and even
> > with PTS it would be nice to be able to check that the timestamps really
> > are sane.
> 
> We have coded_picture_number and display_picture_number in AVFrame, maybe
> they could be usefull here?

coded_picture_number doesn't tell anything about reordering with
LOW_DELAY, and the only references to display_picture_number seem to be
in encoding code.