Lynne (12021-09-09): > It's not a maintenance nightmare, it's a single optional field. Please don't
Then please answer this simple question: How do you guarantee that this
new field will always be correctly kept updated?
> reject my ideas and needs outright, I'm not the only API user who would
> benefit from this. Browsers have had issues with sandboxing for ages,
> and they'd love to have all state be maintained in the frames. But since
> that's unreasonable, I think just having the timebase used for the timestamps
> makes a large difference to usability.
Software design 101: if you need some information along with an object,
you define a structure to store that object and that information
together.
In other words:
typedef struct My_frame {
AVFrame *frame;
AVRationl time_base;
whatever else I need;
} My_frame;
> What direction? It's completely reasonable to have timebases for the
> currently-isolated timestamps in AVFrames in the same way it was
> reasonable for packets.
Isolated timestamps make no sense.
> But they do exist in a void, I've been using them within a void with
> only AVFrames serving as links between components. It's really
> neat. Only avcodecparameters breaks that.
No, they do not exist in a void: not existing in the void is the
difference between a frame and just an image.
> You say you don't understand this patch, but on the other hand,
I have not said I do not understand the patch. I have asked that you (1)
clarify the semantic and (2) specify what problem it is trying to solve
so we can see if there is a simpler solution.
If the problem is that people want to use AVFrame in isolation, then
there is a simpler solution: we answer that it is not how it is meant to
work.
I will add: if fftools/*.c could work without time_base in AVFrame, then
any application can.
> I don't understand your reasoning at all. It's not an over-arching
> API design change, it's a single optional field that API users
> were already including in their opaque context anyway.
And something extra we have to maintain and keep updated.
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".
