[FFmpeg-devel] Politics

[Lynne]

Dec 18, 2021, 12:34 by softworkz at hotmail.com:

>
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Paul B
>> Mahol
>> Sent: Saturday, December 18, 2021 11:27 AM
>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Politics
>>
>> On Wed, Dec 15, 2021 at 2:34 PM Soft Works <softworkz at hotmail.com> wrote:
>>
>
> [..]
>
>> > > > Once for the facts: the subtitle_pts field in AVFrame exists since
>> > > > V5 of my patchset, which I have submitted on 2021-09-12.
>> > > > This has been 3 months ago. Nobody had objected its existence
>> > > > until only 2 or 3 weeks ago.
>> > >
>> > >
>> > > This is really irrelevant, please stop insisting on hacks like
>> > subtitle_pts.
>> >
>> > New idea:
>> >
>> > I could remove the three fields (subtitle_pts, subtitle_start_time,
>> > subtitle_end_time) from AVFrame and add it to AVSubtitleArea.
>> >
>> > How about that? It would allow the frame to be "clean" at least.
>> >
>>
>>
>> Yea, much better, But still original issue is not solved.
>>
>
> Yes, correct, this changes the location but not the logic.
> But this is something I could surely do. It's a bit of work, 
> but it would be safe to do without breaking everything into
> dysfunctional pieces ;-)
>
> It wouldn't be my first choice since there can be multiple
> AVSubtitleAreas while only those values from the first one
> would be relevant. But when this would help to increase the
> acceptance, then it will be fine for me.
>
> Another possibility I had thought about, might be to leave
> them at the side of AVFrame, but put them in a struct field
> of AVFrame named 'subtitle_timing', which itself would have
> the fields pts, start_time, end_time.
>
>
> I did some research regarding the use of the start_time
> field. While it is used and cannot be dropped, I found
> that the following changes would be possible with moderate
> effort:
>
> - change the time base of start_time and end_time
>  to the same like subtitle_pts (AV_TIMEBASE_Q)
> - rename subtitle_start_time to subtitle_start_offset
> - rename subtitle_end_time to subtitle_duration
>  and adapt the logic everywhere where it's used
>
> In combination with the subtitle_timing struct idea it 
> could then look like:
>
> frame->subtitle_timing.pts
> frame->subtitle_timing.start_offset
> frame->subtitle_timing.duration
>
> or even eliminate the pts naming and do like:
>
> frame->subtitle_timing.start
> frame->subtitle_timing.start_offset
> frame->subtitle_timing.duration
>
> or still move them to AVSubtitleArea, which wouldn't 
> be that nice to access and require to check the
> subtitle_area_nb value wherever it needs to be
> accessed:
>
> frame->subtitle_areas[0].start
> frame->subtitle_areas[0].start_offset
> frame->subtitle_areas[0].duration
>
>
> Please let me (all) know whether one of those suggestions would
> be an acceptable compromise.
>

Renaming the fields doesn't get around the issue that they're
still overriding fields with a different meaning from the
AVFrame structure. That's not really a compromise since they're
still there.

I also am not accepting a hardcoded timebase of microseconds.
Rounding really matters for subtitles, since presenting them
a frame early or late is unacceptable, so I'd like a time_base
field for the timestamps.

Like elenril said, this is an API that'll stay for decades at the least,
and replacing and changing will be impossible once it's merged.
Just stuffing the entire AVSubtitle field in a frame simply won't do.