'forcing output' //523971 times
Audio is way out of sync. Video freezes. Kindly look at the log (attached due to webmail size limit) and tell me what I did wrong. Note: Previous snipping did not snip the chapters. Ignore that for now. Thank you, Mark.
On Fri, Sep 29, 2023 at 2:51 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Audio is way out of sync. Video freezes. Kindly look at the log (attached due to webmail size limit) and tell me what I did wrong. Note: Previous snipping did not snip the chapters. Ignore that for now.
You generally can't set the audio PTS in that manner, as it blindly assumes that an audio packet will contain exactly 2000 samples (which it very likely will not, depending on the codec). 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) Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
Hey Devin, On Fri, Sep 29, 2023 at 3:20 PM Devin Heitmueller <devin.heitmueller@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?
On Fri, Sep 29, 2023 at 5:14 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On Fri, Sep 29, 2023 at 3:20 PM Devin Heitmueller <devin.heitmueller@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@ltnglobal.com
participants (2)
-
Devin Heitmueller -
Mark Filipak