[FFmpeg-devel] SOC Qualifiction tasks

[Michael Niedermayer]

On Sun, Mar 16, 2008 at 11:04:55PM +0200, Uoti Urpala wrote:
[...]
> 
> > 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.

A patch documenting it is welcome.
Also IMO the alternative of having a foobar field from AVCodecContext moved to
AVFrame isnt more obvious either ...


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

Could be but theres nothing stoping a decoder from setting it.

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/aef61821/attachment.pgp>