Quoting Lynne (2021-11-26 09:00:59) > 25 Nov 2021, 23:49 by c...@passwd.hu: > > > > > > > On Thu, 25 Nov 2021, Lynne wrote: > > > >> This adds a time_base field (currently unused), analogue to the > >> AVPacket.time_base field. > >> This allows for API clients to exchange AVFrames directly, without > >> needing to plumb extra data from sources via side mechanisms. > >> > > > > The objections raised before still stand I believe, and again, the main > > concern is that the API user won't know when to use the packet or frame > > timebase and when to use the frame/packet source timebase. > > > > You write this in the doxy: > > > >> Time base for the timestamps in this frame. May be 0, in which case the > >> time_base from the frame source should be used. > >> > > > > One could easily think - based on this text alone - that every user of > > avcodec_receive_frame should check if AVFrame->time_base is 0 to calculate > > real PTS... > > > > I'd be a lot more willing to accept this if you could document explicitly > > that AVFrame->time_base (and AVPacket->time_base) is not used by the API > > right now, and is similar to e.g. *opaque field. And later, if by using > > some magic flag or new API or whatever it turns out to make sense to > > actually use AVPacket/AVFrame time base, the doxy text can be extended > > accordingly. > > > > So you'd like for the field to either be fully opaque or fully working (by > always > having the correct time_base value)? > That sounds fair, description changed: > "Time base for the timestamps in this frame. Currently unused by any API, > users can set this and use it as an opaque field. In the future, this field > may > be set by the API for you, but its value will always be ignored."
Always is a bit too strong, presumably we do want to start using that field eventually. How about something like: In the future, this field may be set on frames output by decoders or filters, but its value will be by default ignored on input to encoders or filters. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".