[FFmpeg-user] 'forcing output' //523971 times

[Devin Heitmueller]

On Fri, Sep 29, 2023 at 5:14 PM Mark Filipak <markfilipak.imdb at gmail.com> wrote:
> On Fri, Sep 29, 2023 at 3:20 PM Devin Heitmueller
> <devin.heitmueller at ltnglobal.com> wrote:
> > You generally can't set the audio PTS in that manner,
>
> Did I make a mistake? How would you do it?

So in general changing timestamps without a very good reason is likely
to cause these sorts of problems.  I would probably not ask "how would
I change the timestamps?", but rather "why do I think I need to change
the timestamps in the first place?"

> > as it blindly
> > assumes that an audio packet will contain exactly 2000 samples (which
> > it very likely will not, depending on the codec).
>
> Well, ffmpeg has the stream. Doesn't it know how big the audio packets
> are? If not, how can I discover it and how can I tell ffmpeg?

Yes, ffmpeg knows how many samples are in each audio packet.  You can
see that info by running "ffprobe -show_packets <filename>" or
"ffprobe -show_frames <filename>" depending on whether you want to
view the timestamps and durations in the compressed or uncompressed
domain.

> > Basically you're assigning arbitrary timestamps to the audio packets
> > that are irrespective of what the actual audio timing is on the input
> > stream.  Over time the delta between audio/video grows and you'll
> > start to see errors spewed to the console within a few seconds once
> > the delta exceeds a threshold (as well as you'll quickly fall out of
> > A/V sync)
>
> Initial audio is late by 25 seconds. It's out of sync and then goes
> silent 32 seconds later. Then it picks back up where it was but 2
> minutes 3 seconds has elapsed. The video first freezes at 3:31 and the
> audio drops out about 20 seconds later. The first spoken word is at
> 2:10 running time (it's an Ingmar Bergman film ... :-). Video runs
> again about a minute later, freezes again at 5:48 and audio drops out
> again. That first spoken word is actually heard at 8:13 on the run
> time clock (which is about 12 minutes in real time). I noticed that
> whenever the audio picks up, the video freezes at the exact same
> moment.

I assume you're talking about the behavior when trying to play the
file you've created.   If the timestamps are improperly set, the
behavior could vary wildly depending on what player you are using.  It
all comes down to what sort of mitigations the player(s) employ if the
timestamps are screwed up, which will vary across player
implementations.

>
> I'm not going to ask why ffmpeg is so ignorant. Instead, I ask: What
> would you do to assure TB=1/90000, 1st PTS=0, 1st DTS=0, and audio
> stays in sync?

While I've got plenty of complaints about ffmpeg, in this case it
isn't really being ignorant.  It would likely be setting proper
timestamps by default except you are explicitly throwing away the
built in logic and replacing the timestamps based on your own
heuristic.  Your use of setts actually overrides whatever built in
logic would have set the timestamps.

It's worth noting that rather than trying to use setts and writing
your own heuristic, you may wish to look at specifying the
"-start_at_zero" and "-copyts" arguments.  You could potentially also
force the timebase to 1/90000 with the setts filter by passing through
the existing timestamps but specifying just the time_base.  I would
definitely get away from
"setts=time_base=1/90000:pts=N*48000*1001/24000:dts=N*48000*1001/24000"
as there's so many things wrong with that heuristic I'm not sure where
to start.

There's no "audio keep in sync" option.  When the audio is out of sync
it's a side-effect of the timestamps being screwed up.  It's not clear
to me why you think you explicitly need the timebase to be 1/90000, or
why you need the first PTS/DTS to be zero.  It wouldn't surprise me if
even those basic assumptions aren't necessarily valid unless you have
a very good technical reason.

If you haven't already, I would suggest you familiarize yourself with
"ffprobe -show_packets -print_format csv <infile>" as that would allow
you to directly inspect the timestamps of whatever file you create to
see if they are actually what you intended them to be.  You can also
run it against your source file and compare the two, so you can
understand what effect the transformation had on your timestamps.

Good luck,

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller at ltnglobal.com