Lynne: > 9 Sept 2021, 21:15 by geo...@nsup.org: > >> Lynne (12021-09-09): >> >>> No, you don't, there's nothing special about this! >>> >> >> There is no need for something special, it is an universal fact of >> programming that if several redundant pieces of information are supposed >> to be in sync, unless there are strong systems to keep them in sync, >> they will eventually get out of sync because of a code inconsistency. >> >> Avoiding redundancy is one of the most important principles of code >> hygiene. >> >> This is why I oppose this change, and this is why I propose to remove >> the time_base field in AVPacket. >> > > It's a necessary piece of information pertinent to the correct > presenting of each frame. Moreover, it simplifies the API, > which new users are still finding difficult to use. Like for example > timebase negotiation in lavf, which requires a complicated dance > to perform, and is not documented anywhere. And which
What is undocumented? > timebase field are you supposed to use from lavf? The global > context's? The stream's? The codecparameter's? This Global context? You mean AVFormatContext? It does not contain a timebase at all; the timestamps and durations contained in it are in microseconds. And AVCodecParameters also hasn't a timebase either. Only the stream has one. > field eliminates any source of doubt which timebase to use. > And this isn't about the difference between frames and packets > either, frames can be wrapped as packets too. > Additionally, this will allows us to deal with stream switching and > stream splicing correctly without needing to reinitialize components. > > Right now, all the arguments you've given are "it's redundant" > (it isn't, you __need__ a timebase to make sense of any timestamps, > and if a timebase isn't found in the frame but halfway across Jupiter, > it's simply missing), it's complicated (it isn't, it's a 10-line patch, > maximum), it's hard to keep in sync (it isn't, it's a frame field like > any other which will be printed by ffprobe and tested by FATE). > The only honest argument you stated has been an implicit "I don't > like this". _______________________________________________ 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".
