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

[Mark Filipak]

Hey Devin,

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?

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

> 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'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?