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-requ...@ffmpeg.org with subject "unsubscribe".
