On Wed, 2013-01-09 at 18:42 +0100, Anton Khirnov wrote:
> When a frame is used on its own outside of lavc, "frame timestamp" still has a
> well-defined meaning. OTOH pkt_pts and pkt_dts do not.

PTS has well defined with a meaning matching approximately what
"pkt_pts" description in avcodec.h now says. It's unclear what the "pts"
field would mean if not the same (some unreliable extra magic by
libavcodec?).


> > Having the decoder reorder pts info is of course necessary to support
> > decoding with pts timestamps at all. Filters also need some mechanism to
> > handle timestamps.
> > 
> > Currently mplayer2 uses type-punning to place timestamps in the
> > reordered_opaque field (as it's badly designed to only support int64_t,
> > while timestamps are doubles). Making it an union supporting more basic
> > types would be preferable.
> 
> I'm considering adding a frame side data type for this.

Needing to separately attach side data sounds kind of clumsy for such
central functionality - this is basically always needed for correct
pts-based decoding.


> As others have pointed out, bringing doubles vs rationals bikeshed into this
> is entirely orthogonal to what i'm trying to achieve. This patchset is
> complicated enough as it is.

The field types are of course orthogonal to refcounting changes; but you
were more generally discussing what kind of fields would be desirable to
have.

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to