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 755012 - GES timeline playback stops after playing a clip with an effect containing the pitch plugin
GES timeline playback stops after playing a clip with an effect containing th...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
git master
Other Mac OS
: Normal normal
: 1.5.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-14 22:23 UTC by Sjors Gielen
Modified: 2015-09-15 11:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case. See bug description. (4.27 KB, text/x-csrc)
2015-09-14 22:23 UTC, Sjors Gielen
Details

Description Sjors Gielen 2015-09-14 22:23:11 UTC
Created attachment 311312 [details]
Test case. See bug description.

It seems like when the pitch plugin is used as a GESEffect on a GESClip, GES stops playback after that clip is done playing. This also happens when the same effect is applied to the clip after it, even when that second clip was created by splitting the first one. Playback stops on all GES layers. I have not found a work-around for this problem yet.

A possibly related warning seen in the debug log when this happens is:

0:00:01.988957000 50144 0x7fc15b0598f0 WARN            audiodecoder gstaudiodecoder.c:1657:GstFlowReturn gst_audio_decoder_drain(GstAudioDecoder *):<mad2> audio decoder push buffers failed

A test case is attached that shows the problem. This test case initializes GES, creates a test clip on a separate layer (so we can hear that playback stops on all layers), then loads a clip from a file "foo.mp3" (which must exist). It splits the clip four times, but this is quite arbitrary; it then applies the effect to any of the split clips, and plays the pipeline. We can hear the playback speed up in the correct clip, but after that clip part finishes, playback stops. You can play around with the created clips, remove the effect, add it to other clips (even before the split). I think I've narrowed down the issue to the situation where a clip ends with the pitch effect applied to it.

I first encountered this on GES revision fdd1456 and found that it also applies to current master.

The test case can be compiled using:

gcc `pkg-config gst-editing-services-1.0 --cflags` `pkg-config gst-editing-services-1.0 --libs` -Wall main.c -o main
Comment 1 Sjors Gielen 2015-09-14 23:17:30 UTC
Note: currently, in GStreamer master, clip splitting seems to be broken. This has nothing to do with this bug, I noticed; even if no effect is applied at all, playing the second clip fails.

I can still reproduce this bug on GES master patched to build against GStreamer 1.5.1; the test case behaves as described on my machine (playing normally works, unless the pitch effect is applied to a clip, then playback stops shortly after playing that clip).
Comment 2 Sjors Gielen 2015-09-15 08:39:52 UTC
For future reference: the bug for playback being broken with GStreamer master (specifically, gst-plugins-bad) is #754893 and was caused by the fix to #753196.

Playback is fixed when the fix to #753196 is reverted from gst-plugins-bad master, and this bug still occurs in that case.
Comment 3 Thibault Saunier 2015-09-15 11:47:20 UTC
commit b6ad1b0c22de9d815a10ccf7471ca592bf25fc8c
Author: Thibault Saunier <tsaunier@gnome.org>
Date:   Tue Sep 15 13:40:58 2015 +0200

    pitch: Set seqnum on newly created segment event
    
    https://bugzilla.gnome.org/show_bug.cgi?id=755012