[FFmpeg-devel] SOC Qualifiction tasks

[Uoti Urpala]

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);

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.

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?