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 537361 - videomixer segment handler fail
videomixer segment handler fail
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 0.10.11
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-09 09:38 UTC by Luis de Bethencourt
Modified: 2008-09-25 15:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
a patch (1.46 KB, patch)
2008-09-03 09:50 UTC, Wim Taymans
committed Details | Review

Description Luis de Bethencourt 2008-06-09 09:38:14 UTC
Please describe the problem:
For the last week I've been coding a video application, small doubts
and little fixes have been done through irc, thanks wtay and thanks
thaytan (you rock!). Anyway, now I stuck. My application switchs
videos that loop, its a vj app.

You can check:
http://luisbg.users.ubuntustudio.org/freemix/

In the solo folder... I have a bin.py where the video bin is created,
this bin overrides the do_handle_message virtual method to capture
when the segment is done and do a seek to start the video again. This
bin is fed to a xvimagesink.... it works perfectly.

In the mix_1 folder... I have the same bin.py, feeding to a videomix
and this to the image sink. Also works perfectly.

In the mix_2 folder is where the problems start, when looping two
videos into the mixer... strange things happen, I would report the
outcome if it werent that everytime I run it a different thing
happens. But usually the shorter video loops, and when the second
finishes they both stall... or they both stall after the short one
finishes. Or the short one finishes and then only the long one is
played at high speed. Or they will pause, then continue, pause, then
continue.

original mail to the mailing list and link to bug reproducing codes in pygst:
http://sourceforge.net/mailarchive/message.php?msg_name=506b70dc0806050801l36b46ff6g7dbc16822df0dba7%40mail.gmail.com

Steps to reproduce:
feed to looping videos to a videomixer.

check code linked in:
http://luisbg.users.ubuntustudio.org/freemix/

Actual results:
when one of the videos finishes instead of looping again, both videos stop playback.

Expected results:
two videos should continue looping, and can be paused independently.

Does this happen every time?
yes

Other information:
Comment 1 Wim Taymans 2008-06-10 11:07:08 UTC
when you stop one input on videomixer, you have to unlink and release the pad of videomixer. Sending EOS to videomixer might also work. This needs to be done because else videomixer has no idea if it should wait for data or not.
Comment 2 Wim Taymans 2008-06-10 16:25:25 UTC
        * gst/videomixer/videomixer.c: (gst_videomixer_fill_queues),
        (gst_videomixer_blend_buffers):
        Use stream_time to synchronize the object properties.
        Use running_time of the master pad to timestamp outgoing buffers.
        Fix the initial segment event to extend an unknown amount of time.
        Fixes #537361.
Comment 3 Edward Hervey 2008-09-02 10:49:49 UTC
This broke the (segment) seeking behaviour that was introduced a few commits before.

It currently just outputs a NEW_SEGMENT event with start:0, stop:-1 ... even though it returned TRUE to a segment seek.

In response to a flushing seek from A to B, it should output a newsegment with:
* position : A
* stop - start : B - A

Comment 4 Wim Taymans 2008-09-03 09:50:53 UTC
Created attachment 117913 [details] [review]
a patch

I crafted this patch but I have no idea if it works because I did not test it nor do I have the needed apps to test it.
Comment 5 Wim Taymans 2008-09-25 15:11:36 UTC
        * gst/videomixer/videomixer.c: (gst_videomixer_fill_queues),
        (gst_videomixer_sink_event):
        Handle segments a little better. Fixes #537361.