After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773785 - splitmuxsink: Use first buffer TS as mux start time
splitmuxsink: Use first buffer TS as mux start time
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-01 18:17 UTC by Vivia Nikolaidou
Modified: 2016-11-08 10:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch (3.78 KB, patch)
2016-11-01 18:18 UTC, Vivia Nikolaidou
none Details | Review
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch (4.38 KB, patch)
2016-11-02 12:16 UTC, Vivia Nikolaidou
none Details | Review
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch (4.52 KB, patch)
2016-11-02 17:48 UTC, Vivia Nikolaidou
none Details | Review
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch (4.34 KB, patch)
2016-11-02 18:56 UTC, Vivia Nikolaidou
none Details | Review
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch (4.81 KB, patch)
2016-11-03 15:57 UTC, Vivia Nikolaidou
committed Details | Review

Description Vivia Nikolaidou 2016-11-01 18:17:12 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.
Comment 1 Vivia Nikolaidou 2016-11-01 18:18:28 UTC
Created attachment 338905 [details] [review]
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Comment 2 Vivia Nikolaidou 2016-11-02 12:16:32 UTC
Created attachment 338950 [details] [review]
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Comment 3 Vivia Nikolaidou 2016-11-02 17:48:52 UTC
Created attachment 338981 [details] [review]
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch
Comment 4 Vivia Nikolaidou 2016-11-02 18:56:59 UTC
Created attachment 338990 [details] [review]
0001-splitmuxsink-Use-first-buffer-TS-as-mux-start-time.patch

Sorry for the noise.
Comment 5 Jan Schmidt 2016-11-03 13:04:29 UTC
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.
Comment 6 Vivia Nikolaidou 2016-11-03 15:57:56 UTC
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.
Comment 7 Jan Schmidt 2016-11-08 10:43:52 UTC
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