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 586033 - [adder] seeking on live sources is inconsistent
[adder] seeking on live sources is inconsistent
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.17
Assigned To: Stefan Sauer (gstreamer, gtkdoc dev)
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-16 19:31 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2010-04-30 07:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
WIP for how adder works for me (1.86 KB, patch)
2009-06-22 20:58 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
WIP for how adder works for me (1.72 KB, patch)
2009-06-23 21:00 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2009-06-16 19:31:07 UTC
I made a patch to add another test-case for adder in bug #585708. I tests a pipeline like:
live-src ! adder name=mix ! sink src ! mix.
and what hapens when seeking on it.

With the recent fixes the seeking fails on the live-src (as its currently supposed to). If one uses audiotestsrc is-live=true it actually succeeds and I also like the behaviour. What if we make live src to support seeking. A seek would configure the basetime for subsequent buffers and the eventual stop-time would cause then to return a GST_FLOW_UNEXPECTED.

Whats the use-case? I see two:
1) A dub-over in a video/audio editor. One plays a sequence in a lop (segmented seek from A to B) and records a new video/audio sequence for same region.

Here the looping would fail right now and one would seek one the sub-bins explicitely (or is there any other way).

2) Live FX. I play a song in buzztard and have a live source there where I sing or play guitar.

This right now never goes to EOS as the live-source does not send a eos. Configuring num-buffers and blocksize is not really feasible, as if that is combined e.g. with toggling loop on and off one does not know num-buffers beforehand. Right now I can only poll the playback position and stop from the application side.

Does anyone see a problem of livesources supporting seeks?
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-06-22 19:23:41 UTC
An alternative would be to change the current aggregation of gst_pad_push_event() to return TRUE if atleast one event suceeded.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2009-06-22 20:58:22 UTC
Created attachment 137205 [details] [review]
WIP for how adder works for me

The cheks around the flush_stop in forward_event_func() should be fine. I noone objects, I make that a commit of its own.

Next we need to discuss the negation of the result aggregation.

Finally I wonder why we only send the newsegment in case of a flushing seek. Adder has a quite unique way of timestamping outgoing buffers and without the newsegment loops are broken. They still loop, but the position does now warp back.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2009-06-23 21:00:36 UTC
Created attachment 137274 [details] [review]
WIP for how adder works for me

The flush_stop is fixed upstream.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2009-07-06 19:06:08 UTC
Making a release blocker regarding the newsegment part.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2009-07-07 17:55:42 UTC
Removing blocker, as newsegment change has been reverted.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-30 07:33:32 UTC
commit 3d73a7458a7030470f94aed4921d9256c0f0c250
Author: Stefan Kost <ensonic@users.sf.net>
Date:   Sat Oct 10 00:32:04 2009 +0300

    adder: make events succeed, if they succed on atleast one pad