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

Kind regards,
softworkz