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 760408 - #750013 (streamsynchronizer patches) broke some use cases in GES
#750013 (streamsynchronizer patches) broke some use cases in GES
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-10 19:23 UTC by Mathieu Duponchelle
Modified: 2016-09-19 22:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fixes the reported issue (1.47 KB, patch)
2016-01-10 19:23 UTC, Mathieu Duponchelle
committed Details | Review

Description Mathieu Duponchelle 2016-01-10 19:23:46 UTC
Created attachment 318679 [details] [review]
fixes the reported issue

This patch broke some seeking cases in GES.

How to reproduce:

mkdir ges_issue && cd ges_issue

wget https://people.collabora.com/~meh/ges_test_assets/test.ogv
wget https://people.collabora.com/~meh/ges_test_assets/reproduced.xges
wget https://people.collabora.com/~meh/ges_test_assets/play-pause-and-seek.scenario

GES needs to have been compiled with validate support.

ges-launch-1.0 --load reproduced.xges --set-scenario ./play-pause-and-seek.scenario --ges-sample-paths file://$PWD

Issue: playback stops for 5 seconds before restarting after the seek, it should restart immediataly.

The attached patch fixes the issue.

Problem description in commit message.

Sebastian asked whether I saw other places in streamsynchronizer where flushing streams should be ignored, a quick glance showed me nothing obvious.
Comment 1 Sebastian Dröge (slomo) 2016-01-10 20:19:28 UTC
Comment on attachment 318679 [details] [review]
fixes the reported issue

Makes sense and doesn't seem to break anything. Please push with a more descriptive commit message :) Why exactly things break and what, and how this is fixing it
Comment 2 Sebastian Dröge (slomo) 2016-01-16 10:08:03 UTC
commit 2717f4a86f3afa8a1cc5d4399b11e4cbab631944
Author: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Date:   Sat Jan 9 04:35:23 2016 +0100

    streamsynchronizer: Ignore flushing streams [..]
    
    [..] when resetting group start time. In GES, we are usually connected
    to the streamsynchronizer on one audio and one video pad.
    
    When seeking the timeline, both nlecompositions often output their flush_start
    before any of them has output its flush_stop.
    
    The current code, when receiving the first flush stop was using the
    running time of the start of the second composition, which could
    be pretty much anything, and means nothing at that point.
    
    This patch is thread-safe, as STREAM_SYNCHRONIZER_LOCK is taken
    both when setting flushing and when checking it.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=750013
Comment 3 Tim-Philipp Müller 2016-01-16 22:22:04 UTC
picked into 1.6 as well (for 1.6.3)
Comment 4 Sebastian Dröge (slomo) 2016-09-19 22:01:28 UTC
This is still racy btw
Comment 5 Thibault Saunier 2016-09-19 22:12:07 UTC
(In reply to Sebastian Dröge (slomo) from comment #4)
> This is still racy btw

Could you explain how and what issue you are seeing related to that?
Comment 6 Sebastian Dröge (slomo) 2016-09-19 22:26:15 UTC
Yes, just let me finish writing the fix and put it into Bugzilla ;) (It's happening with GES btw)