[FFmpeg-devel] [PATCH] frame: add a time_base field

[Lynne]

9 Sept 2021, 12:48 by george at nsup.org:

> 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.
>

It's not a maintenance nightmare, it's a single optional field. Please don't
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.


>> 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.
>

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.


> 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.
>

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.

You say you don't understand this patch, but on the other hand,
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.