9 Sept 2021, 22:18 by andreas.rheinha...@outlook.com:
> 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
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 s
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
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 a
Paul B Mahol (12021-09-09):
> Such people should than leave project.
I will chose to ignore that useless remark.
> I read this as personal attack.
This was not my intent, I am sorry you took it that way. If you would
please explain to me how you read a personal attack in a sentence that
affirms
On Thu, Sep 9, 2021 at 9:18 PM Lynne wrote:
> 9 Sept 2021, 19:40 by one...@gmail.com:
>
> > On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
> >
> >> Lynne (12021-09-09):
> >> > That's fine, no argument about this. We talked about this on IRC
> >> > and I agreed that duration fields on fram
9 Sept 2021, 19:40 by one...@gmail.com:
> On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
>
>> Lynne (12021-09-09):
>> > That's fine, no argument about this. We talked about this on IRC
>> > and I agreed that duration fields on frames make no sense and
>> > are difficult to guarantee.
>>
>>
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 event
9 Sept 2021, 15:53 by geo...@nsup.org:
> Lynne (12021-09-09):
>
>> Because all of our codecs pass their frames through a wrapper function before
>> they get to the user. So, we just set the field there, add a FATE test, and
>> now
>> they're guaranteed to be correctly kept updated.
>>
>
> This is
On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
> Lynne (12021-09-09):
> > That's fine, no argument about this. We talked about this on IRC
> > and I agreed that duration fields on frames make no sense and
> > are difficult to guarantee.
>
> Thank you for mentioning this.
>
> Not everybody
Lynne (12021-09-09):
> Because all of our codecs pass their frames through a wrapper function before
> they get to the user. So, we just set the field there, add a FATE test, and
> now
> they're guaranteed to be correctly kept updated.
This is wrong and not enough. Codecs are not the only origin
9 Sept 2021, 14:53 by geo...@nsup.org:
> 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?
>
Because all of our co
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
>
9 Sept 2021, 12:48 by geo...@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.
>> A
Lynne (12021-09-09):
> That's fine, no argument about this. We talked about this on IRC
> and I agreed that duration fields on frames make no sense and
> are difficult to guarantee.
Thank you for mentioning this.
Not everybody can spend time synchronously on IRC.
> One thing though, "Speaking as
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.
9 Sept 2021, 12:02 by geo...@nsup.org:
> Speaking as the maintainer of libavfilter, and without closing any
> further discussion, I say: the duration of a frame is currently defined
> as the difference with the timestamp of the next frame, and it should
> continue to be. If a duration field is add
9 Sept 2021, 12:02 by geo...@nsup.org:
> Marton Balint (12021-09-08):
>
>> So how this is going to work? Will e.g. avcodec_send_frame check the time
>> base of the frame and recalculate pts/duration to the encoder time base?
>> Same goes for every function which is receiving frames?
>>
>
>
> Thank
Marton Balint (12021-09-08):
> So how this is going to work? Will e.g. avcodec_send_frame check the time
> base of the frame and recalculate pts/duration to the encoder time base?
> Same goes for every function which is receiving frames?
Thanks for raising this question.
If we add this field wit
8 Sept 2021, 01:25 by c...@passwd.hu:
>
>
> On Tue, 7 Sep 2021, Lynne wrote:
>
>> 7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:
>>
>>> Lynne:
>>>
This adds a time_base field (currently unused), analogue to the
AVPacket.time_base field.
Patch attached. doc/APIchanges an
On Tue, 7 Sep 2021, Lynne wrote:
7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:
Lynne:
This adds a time_base field (currently unused), analogue to the
AVPacket.time_base field.
Patch attached. doc/APIchanges and version bump to be done at push time.
+/**
+ * Time base fo
7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> This adds a time_base field (currently unused), analogue to the
>> AVPacket.time_base field.
>>
>> Patch attached. doc/APIchanges and version bump to be done at push time.
>>
>> +/**
>>
>> + * Time base for the timestamps
On Tue, Sep 7, 2021 at 7:37 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Lynne:
> > This adds a time_base field (currently unused), analogue to the
> > AVPacket.time_base field.
> >
> > Patch attached. doc/APIchanges and version bump to be done at push time.
> >
>
> > +/**
Lynne:
> This adds a time_base field (currently unused), analogue to the
> AVPacket.time_base field.
>
> Patch attached. doc/APIchanges and version bump to be done at push time.
>
> +/**
> + * Time base for the timestamps in this frame. May be 0, in which case
> the
> + * time_ba
24 matches
Mail list logo
