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 754528 - decklinkvideosink: Properly handle pipelines where the running time does not start around 0
decklinkvideosink: Properly handle pipelines where the running time does not ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other All
: Normal normal
: 1.5.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-03 13:40 UTC by Sebastian Dröge (slomo)
Modified: 2015-09-09 14:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decklinkvideosink: Handle pipelines where the running time does not start around 0 properly (2.92 KB, patch)
2015-09-03 13:40 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2015-09-03 13:40:40 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2015-09-03 13:40:44 UTC
Created attachment 310592 [details] [review]
decklinkvideosink: Handle pipelines where the running time does not start around 0 properly

We were converting all times to our internal running times, that is the time
the sink itself spent in PLAYING already. But forgot to do that for the
running time calculated from the buffer timestamps. As such, all buffers were
scheduled much later if the pipeline's running time did not start at 0.

This happens for example if a base time is explicitly set on the pipeline.
Comment 2 Nicolas Dufresne (ndufresne) 2015-09-03 13:46:14 UTC
About the commit message, does it say that a pipeline the does not start at running time 0 is not proper, or more something like "Properly handle the case where initial running is not 0" ?
Comment 3 Sebastian Dröge (slomo) 2015-09-03 13:48:55 UTC
The second case :) Starting at a running time that is not 0 is not a problem, just that the decklink synchronization code did not handle that.
Comment 4 Nicolas Dufresne (ndufresne) 2015-09-03 14:14:49 UTC
Review of attachment 310592 [details] [review]:

Looks correct to me (can't test).
Comment 5 Tim-Philipp Müller 2015-09-09 13:04:19 UTC
Comment on attachment 310592 [details] [review]
decklinkvideosink: Handle pipelines where the running time does not start around 0 properly

Let's get this in then, I assume you've tested it.
Comment 6 Sebastian Dröge (slomo) 2015-09-09 14:01:36 UTC
commit b6498c32f3971bffbc4424353264932e7c47a7fc
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Thu Sep 3 16:36:57 2015 +0300

    decklinkvideosink: Handle pipelines where the running time does not start around 0 properly
    
    We were converting all times to our internal running times, that is the time
    the sink itself spent in PLAYING already. But forgot to do that for the
    running time calculated from the buffer timestamps. As such, all buffers were
    scheduled much later if the pipeline's running time did not start at 0.
    
    This happens for example if a base time is explicitly set on the pipeline.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=754528