Lynne (12021-09-09): > It's a necessary piece of information pertinent to the correct > presenting of each frame. Moreover, it simplifies the API,
That piece of information is already present along with all the other pieces of information necessary to make sense of a frame. > 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 > timebase field are you supposed to use from lavf? The global > context's? The stream's? The codecparameter's? This This is already documented. Maybe the documentation can be made clearer. > 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. This is an interesting remark, but please consider that relying on the change of a field that used to be constant is a terrible API break. > 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). And yes, that is all the arguments I have, or you can even say it in singular: argument, because it is one and the same: redundancy is a bad idea because it is hard to keep in sync. As for "halfway across Jupiter", stop this ridiculous hyperbole. The fact is that all frames are relative to a certain context that give meaning to the timestamps: an AVStream when it comes from a demuxer or goes to a muxer, an AVFilterLink in libavfilter, an OutputStream in fftools, another application-defined data structure for any application. There is never a frame in isolation, so designing an API as if there were is a waste of time. > The only honest argument you stated has been an implicit "I don't > like this". Please have the courtesy of not accusing me of dishonesty. This is an absolute prerequisite for constructive discussion. -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
