GNOME Bugzilla – Bug 773785
splitmuxsink: Use first buffer TS as mux start time
Last modified: 2016-11-08 10:44:08 UTC
Do not use last buffer TS + buffer duration because buffer duration might be inaccurate, especially for frame rates like 30fps where a rounding error is observed.
Created attachment 338905 [details] [review] 0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Created attachment 338950 [details] [review] 0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Created attachment 338981 [details] [review] 0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Created attachment 338990 [details] [review] 0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch Sorry for the noise.
I see one potential problem. Previously, the mux_start_time was deterministic (based on the muxed_out_time taken from the reference stream), but now I think can be based on whichever stream first outputs a packet after the new fragment starts. There's no timestamp based ordering on the output from the multiqueue. I think we'd need to make sure that other streams don't resume until the reference stream first outputs something.
Created attachment 339052 [details] [review] 0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch Thanks for the comment. As discussed on IRC, the attached patch should address the issue.
Thanks, pushed: commit bbd4dd2fb141603913b5fa9587536a74cabcce07 Author: Vivia Nikolaidou <vivia@toolsonair.com> Date: Tue Nov 1 19:56:36 2016 +0200 splitmuxsink: Use first buffer TS as mux start time Do not use last buffer TS + buffer duration because buffer duration might be inaccurate, especially for frame rates like 30fps where a rounding error is observed. https://bugzilla.gnome.org/show_bug.cgi?id=773785