[FFmpeg-devel] Politics

[Michael Niedermayer]

On Mon, Dec 20, 2021 at 11:06:44AM -0300, Daniel Cantarín wrote:
> 
> > 
> > consider a subtitle track
> > consider 2 video tracks for US 30000/1001 fps and EU 25 fps
> > 
> > the 6th frame in the US track is at  0.2002 sec, the 5th in the EU track
> > at 0.2sec
> > 
> > 
> > if these differ and you want a subtitle to either stop displaying after
> > the
> > earlier or begin displaying after the earlier reliably. Then you need a
> > timebase that can represent points within each such close encounter of
> > frame
> > times.
> > 
> 
> So, this isn't a subtitle problem if subtitle timings are correct. You
> let 0.2002 in the subtitle, players will decide the frame. You want to
> match the frame with the content, then you transcode the video properly.
> Am I losing something?
> 
> Then again, we're of course not discussing players. One may say "that's
> not ffmpeg responsability", yet players are 90% of the time the main
> reason we have to do any extra work with ffmpeg. If we discuss real
> life scenarios, we should be discussing players.
> 
> I also fail to see why would somebody want a "frame-perfect" sync
> between two videos with different FPS. That's absurd: there's no such
> thing as "frame-perfect" in such scenarios. What you would want is video
> timings to be honored. That is: FPS conversion to be faithful to video
> timings and content. I can imagine such precision dealing with frames
> being blurred and having to do lots of fine tuning in order to be able
> to perceive a single frame off in subtitles. That would be the real
> problematic situation, not any .0002 rounding.
> 
> So, I see your example as a case of "what would the player do with that
> 0.2002 rounding" (in which case, we all know there would be two
> different subtitle files/streams with different precision for each
> video if it's THAT important) instead of "we need to change the timebase
> to something 4 decimals precise multiplier to both videos".
> 
> And even if this fails and a frame is interpreted incorrectly in the
> player, good luck finding anyone saying anything about it: nobody cares
> about a single frame when it's about subtitles. People watching
> subtitles are simply not looking at that. This isn't speedrunning: it's
> translating and transcribing. People wants to understand what's going on
> in the screen, not debugging video frames.
> 
> So, I see no "serious subtitle problem" nor anything close to
> "unnaceptable" here.
> 
> Let's remark, as softworkz say, this are all fantasy scenarios, and the
> patchset doesn't show any real precision problem so far. If anyone is
> willing to share input files to test such possible precision problems,
> I'm willing to do the tests. No such files so far.

I am not sure the direction from which you approuch this is going to
increase the chances this patch has.

All stream types in libavformat/codec are timebase based, that was
done because its exact (for some definition of exact at least)

I think you should argue why this is the best way forward not why its
not too bad

also in a few places where a fixed timebase is used ffmpeg uses
AV_TIME_BASE_Q which is micro not milli seconds. That suddenly
allows exactly addressing individual frames and audio samples.
And it should be easy to change to from ms, its just a *1000
it would weaken the precission argument

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20211220/b40c3149/attachment.sig>