[FFmpeg-devel] SOC Qualifiction tasks

[Uoti Urpala]

On Sat, 2008-03-15 at 02:50 +0100, Michael Niedermayer wrote:
> On Sat, Mar 15, 2008 at 02:45:33AM +0200, Uoti Urpala wrote:
> > On Sat, 2008-03-15 at 00:00 +0100, Michael Niedermayer wrote:
> > > On Fri, Mar 14, 2008 at 10:44:01PM +0200, Uoti Urpala wrote:
> > > > - Doesn't for with LOW_DELAY.
> > > 
> > > low_delay == no delay which is just the opposit of frame based multithreading.
> > 
> > I don't see it as the opposite or incompatible. Doing reordering in the
> > decoder is IMO orthogonal to whether you want multiple threads to work
> > on different frames.
> 
> Yes, it seems i misunderstood what you meant
> But then i dont see what problem returning frames in another order would have
> in respect to the API.

At least it would clearly change the API from the application's POW.
There was no possible delay before.

Unless the return value is guaranteed to indicate the difference between
delay and other reasons of returning no frame it will also make the it
unclear what outputs correspond to what inputs. Having a mechanism to
identify the frames would solve that too. It could even make sense to
return whichever frame finishes first even if that doesn't match input
order.

> > The most basic issue is keeping track of timestamps (or any other
> > information) related to particular frames across decoding. I think the
> > get_buffer() thing that ffplay.c uses to reorder timestamps is an ugly
> > hack, and the need to use such hacks shows that the library API is
> > lacking.
> 
> Yes, i did suggest a while ago that av_decode_video/audio should take AVPacket
> as input instead of buf/buf_size. That would make passing information
> as timestamps quite easy. Also applications not using lavf really would
> only need
> 
> AVPacket pkt;
> av_init_packet(&pkt); // initalize fields to defaults
> pkt.pts= A
> pkt.data=B
> pkt.size=C
> 
> sadly no volunteers implemented it ...

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.

>From implementation POW I think most of the work would be to pass the
pointer through calls to each decoder (temporarily storing it in avctx
might be less work though somewhat unclean perhaps) at least until it
can be stored in an AVFrame. It'd also be nice to get some kind of
notification if the codec decides that there never will be a
corresponding output frame (in case the player has some allocated memory
for example).

> > 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
> > you don't necessarily even know whether the next visible frame would be
> > one of the frames you decoded or further in the decode order.
> 
> What you call LOW_DELAY really is a hack, i wouldnt be surprised if it has
> various random unexpected sideeffects. This probably is caused by there being
> no? applications using it.
> Anyway, shouldnt the has_b_frames value be enough to awnser the question
> of if one of the decoded frames is output?

I suppose having at least has_b_frames+1 decoded frames should guarantee
that the answer is yes. 0 means no, but in between you can't know either
way.

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.