[FFmpeg-devel] SOC Qualifiction tasks

[Michael Niedermayer]

On Sat, Mar 15, 2008 at 06:05:04AM +0200, Uoti Urpala wrote:
> 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.

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.


> 
> 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.

Indicating somehow why no frame has been output is certainly a good idea.


> 
> > > 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.

I think you are abstracting things too far here.
Maybe we want to fill in missing timestamps by using information from
various headers.

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.


[...]
> > > 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.

We have coded_picture_number and display_picture_number in AVFrame, maybe
they could be usefull here?

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080316/ddb8f9ed/attachment.pgp>