[FFmpeg-devel] Politics

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Lynne
> Sent: Saturday, December 18, 2021 4:17 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Politics
> 
> 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

There are like 2 or 3 characters in each frame. Sometimes
they are shown as they are coming in, sometimes only 
when a line is completed, sometimes needs to wait
for subsequent frames before emitting new characters.
This is really not a high-precision thing.


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

What precision do you want?

This is nothing like audio. You just need to hit one
frame or the next frame, nothing in-between because there
is nothing in between.

So what's this about? Videos with 1 Million fps?

> Also, some text subtitle formats have a timestamp precision
> much greater than a millisecond, like Ogg Kate. 

But only because it uses the same bitstream layout as for
audio and video.

> We don't
> support it yet, but you never know. An API must be able to
> handle everything.

It will handle this perfectly fine.


I'm afraid, but IMO you are trying to construct cases which  
do not even have a theoretical value.


Kind regards,
softworkz