[FFmpeg-devel] Politics

[Lynne]

18 Dec 2021, 16:43 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 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?
>

The exact same time_base used for the video, optimally. That
eliminates all rounding issues. Otherwise, either the format's
native timestamps, or otherwise the container's timestamps
for each packet, if any, whichever is more accurate.
But definitely not just using AV_TIME_BASE for everything and
calling it good enough.


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

This is a very lax attitude towards a serious problem that
everyone in the fansubbing community deals with. A frame
of offset is unacceptable for such use-cases, and they have
to deal with formats which made concessions to timebases
due to historical blunders.