Hey Devin, On Fri, Sep 29, 2023 at 3:20 PM Devin Heitmueller <devin.heitmuel...@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? _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
