From: "Peter Zebühr" <peter@zebuhr.se> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: [FFmpeg-devel] Matroska and output_ts_offset Date: Mon, 29 Aug 2022 16:16:57 +0200 Message-ID: <30245E67-C26D-4DD0-879E-CEF516AD52BF@zebuhr.se> (raw) Hello, I noticed the other day that if I try to mux opus in webm with a timestamp offset set I don't get the expected timestamps out on my packets. Example: ffmpeg -f lavfi -i "sine=frequency=1000:duration=60" -output_ts_offset 200ms -c:a libopus sine_200ms_offset.webm Now if I inspect the packets with ffprobe on the produced output the first packet has a PTS of 186. My expectation would be that it would be: 200 - 6.5 (opus encoder delay) ~= 193. Looking at the output with mkvinfo also indicates that it starts at 193ms (186 + encoder delay I assume here). At first I thought it looked like the encoder delay gets added twice, but after some more pondering I think what is happening here is: 1. Opus outputs packets starting with the priming samples, that ends up with a negative PTS (rounded to -7) 2. In mux.c the output_ts_offset takes effect before the call to "handle_avoid_negative_ts" 3. PTS -7 gets shifter by the requested ts_offset to 193 4. Matroska muxer writes the side data about encoder delay. 5. The produced stream now effectively starts one encoder delay distance too early. I played around locally with moving the call to "handle_avoid_negative_ts" in mux.c/write_packet to right before the ts_offset handling instead of right after and that seems to fix this particular problem. But, I am unsure what other potential consequences that would have. Would appreciate if someone more familiar with this can help fix this issue. Regards, Peter _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next reply other threads:[~2022-08-29 14:17 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-29 14:16 Peter Zebühr [this message] 2022-08-29 14:37 ` Andreas Rheinhardt 2022-08-29 15:00 ` Peter Zebühr 2022-08-29 15:20 ` Andreas Rheinhardt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=30245E67-C26D-4DD0-879E-CEF516AD52BF@zebuhr.se \ --to=peter@zebuhr.se \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git