[FFmpeg-devel] SOC Qualifiction tasks

[Michael Niedermayer]

On Mon, Mar 17, 2008 at 01:05:26AM +0200, Uoti Urpala wrote:
> On Sun, 2008-03-16 at 23:03 +0100, Michael Niedermayer wrote:
> > On Sun, Mar 16, 2008 at 11:04:55PM +0200, Uoti Urpala wrote:
> > > 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 ...
> 
> When I mentioned the AvCodecContext field I intended that as an internal
> libavcodec implementation detail to move the hack inside libavcodec and
> present a sane API outside. Meaning you'd have an API like
> 
> avcodec_decode_video(AvCodecContext *avctx, ..., union {void *p; double
> d; int64_t i64;} user_data);

This is totally insane. Do you really suggest we break the API&ABI because
you dont like it? And then add this union nonsense?
Why in hell should this opaque user data be treated differently from every
other field in AVCodecContext?!
No, we have a system that works, use of AVPackets as input might be cleaner
the other suggestions are a mess at least as big as what we have.
And the whole is pure bikeshed anyway.


> 
> Then the easiest way to have an implementation of the hack inside
> libavcodec would be to do avctx->temp_user_data=user_data; in
> avcodec_decode_video, and move it to AVFrame when get_buffer is called.
> 
> 
> > > > 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.
> 
> There's nothing stopping it, but the mere existence of the field in
> AVFrame isn't really any closer to a solution than having nothing at
> all.

What exactly are you arguing about? We do NOT have support for frame level
threading with LOW_DELAY. Any solution should use the existing API.


> 
> Also, if the field is meant semantically to indicate the position in
> reordered output, can you always know that at decoding time? Do you
> always know in h264 for example exactly how many B frames there will be
> before this picture appears in output order?

Set display_picture_number to the picture order count from h.264 this is
as much information as there is in h.264.

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20080317/0443cae0/attachment.pgp>