On Fri, Sep 29, 2023 at 5:14 PM Mark Filipak <markfilipak.i...@gmail.com> wrote: > 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?
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.heitmuel...@ltnglobal.com _______________________________________________ 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".
