Lynne (12021-09-09): > Did you read what I wrote? I think I was very clear.
I did. And you, did you read what I wrote? You are only answering one of the questions. > It's an output, unless a specific flag is set to accept it as an input. > API users don't have to maintain it without the flag set. > It helps solve the problem of piping timebases for API users > who isolate all of their contexts and only relay frames throughout, > without them needing to use the opaque fields. So this is the problem it is trying to solve? Applications who do not bother to have a time_base field where they need one, so we have to add one ourselves, and have all the maintenance nightmare of keeping it up to date. No, thank you. > We already have the same field for AVPackets, so not introducing > one for frames would make no sense. I already thought it was a bad idea when it was added to AVPacket. I should have spoken up at the time, but I did not. So let us remove it instead. Or at least not continue in that direction. Neither frames nor packets exist in a void. They are all related to a context. And I do not mean an AVSomethingContext in terms of libav* structures, but a logical context that explains a lot of things about them, and the time_base is only a tiny part of it. Regards, -- 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".
