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 768132 - Reusing a (preview) GESPipeline with new clips is not possible
Reusing a (preview) GESPipeline with new clips is not possible
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-editing-services
1.4.5
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-28 10:17 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 12:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ges-testcase.c (7.86 KB, text/plain)
2016-06-28 10:17 UTC, Sebastian Dröge (slomo)
Details
log with GST_DEBUG=2,nlecomposition:6 (388.04 KB, text/plain)
2016-08-07 05:49 UTC, Sebastian Dröge (slomo)
Details

Description Sebastian Dröge (slomo) 2016-06-28 10:17:27 UTC
Created attachment 330481 [details]
ges-testcase.c

See attached testcase (fill in the 2 URIs at the top). When clicking on the "next" button, it will set the pipeline to NULL state, removes clip, add new clip, commit timeline. Clicking on the "play" button has no effect but also there are no errors anywhere.
Comment 1 Thibault Saunier 2016-06-28 14:41:26 UTC
OK, I indeed reproduced on 1.8.2 and master with your code but very interestingly I could not reproduce the issue with what I think is the exact scenario you are explaining here:

    description, seek=true, handles-states=true
    add-clip, name=(string)uriclip0, layer-priority=(int)0, asset-id=(string)file://FIXME, type=(string)GESUriClip
    commit;
    play;
    set-state, state=null, playback_time=(double)1.0;
    remove-clip, name=(string)uriclip0;
    add-clip, name=(string)uriclip1, layer-priority=(int)0, asset-id=(string)file://FIXME, type=(string)GESUriClip
    commit;
    play;
    stop, playback_time=(double)1.0;
Comment 2 Mathieu Duponchelle 2016-06-28 15:32:04 UTC
I just gave a quick look at the C test case, as thib showed going to NULL and back to PLAYING is known to work.

The two differences I can spot are:

1. validate will wait for ASYNC_DONE on READY_TO_PAUSED
2. the C test case embeds the sink in a graphical UI, validate does not

I don't think 1. should be relevant here, though it would be better practice to wait for ASYNC_DONE here before allowing new state changes.

Regarding 2., thibault said the test case worked in pitivi, which does embed the sink in GTK, so I'm not sure whether that is relevant either.

I would suggest looking at the difference in the logs between both test cases, possibly with nlecomposition:4 or nlecomposition:5 :)
Comment 3 Sebastian Dröge (slomo) 2016-06-28 15:41:01 UTC
1) is also irrelevant here, I doubt you can click the buttons fast enough to do another state change before async-done ;)

2) should not matter either, why would anything care if it's embedded or not ;) I also checked in basesink debug logs and for the second file only a CAPS event arrives but not a single video frame
Comment 4 Mathieu Duponchelle 2016-06-28 15:44:29 UTC
> 1) is also irrelevant here, I doubt you can click the buttons fast enough to do another state change before async-done ;)

Yes, that's what I was saying, just pointing out what I saw :)

> 2) should not matter either, why would anything care if it's embedded or not ;) I also checked in basesink debug logs and for the second file only a CAPS event arrives but not a single video frame

Looking at nlecomposition's debug output would be helpful too
Comment 5 Sebastian Dröge (slomo) 2016-08-07 05:49:35 UTC
Created attachment 332878 [details]
log with GST_DEBUG=2,nlecomposition:6
Comment 6 GStreamer system administrator 2018-11-03 12:53:18 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/26.