[FFmpeg-devel] Politics

[Lynne]

18 Dec 2021, 15:28 by softworkz at hotmail.com:

>
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Lynne
>> Sent: Saturday, December 18, 2021 2:33 PM
>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Politics
>>
>> 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'm suggesting those things that are doable. 
>
>
>> 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.
>>
>
> I can't follow. With 120fps, the frame duration is 8300 microseconds.
> And you say that's not enough to hit the right frame?
>
> None of the subtitle storage formats has a precision higher than
> milliseconds, often it's less. 
>
> Finally, a fixed time base avoids frequent re-scaling and that
> in turn means less rounding errors.
>

A timebase completely eliminates all scaling.
Bitmap subtitles exist, as well as ATSC subtitles, which
are embedded in frames, and therefore have the same timestamp
and timebase as the frames themselves. Forcing them to be
rescaled to whatever timebase you thought is good enough is
a bad, inflexible design choice.
Also, some text subtitle formats have a timestamp precision
much greater than a millisecond, like Ogg Kate. We don't
support it yet, but you never know. An API must be able to
handle everything.