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 700600 - videomixer: Fix races in caps negotiation and re enable the unit test
videomixer: Fix races in caps negotiation and re enable the unit test
Status: RESOLVED DUPLICATE of bug 684237
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-18 19:47 UTC by Thibault Saunier
Modified: 2013-05-18 23:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
videomixer2: Protect flush_stop_pending with the collectpad stream lock (3.28 KB, patch)
2013-05-18 19:50 UTC, Thibault Saunier
none Details | Review
videomixer: Do not send flush_stop when receiving a seek (1.52 KB, patch)
2013-05-18 19:51 UTC, Thibault Saunier
none Details | Review
videomixer: Send caps event from the streaming thread (3.72 KB, patch)
2013-05-18 19:53 UTC, Thibault Saunier
none Details | Review
videomixer: Send a reconfigure event upstream if sinkpad caps are not usable (1.26 KB, patch)
2013-05-18 19:53 UTC, Thibault Saunier
none Details | Review
tests: Re-enable videomixer test (976 bytes, patch)
2013-05-18 19:54 UTC, Thibault Saunier
none Details | Review

Description Thibault Saunier 2013-05-18 19:47:11 UTC
I am ataching here a set of patch to do that.
Comment 1 Thibault Saunier 2013-05-18 19:50:48 UTC
Created attachment 244653 [details] [review]
videomixer2: Protect flush_stop_pending with the collectpad stream lock

And make sure to expect a flush-stop after a flush-start
Comment 2 Thibault Saunier 2013-05-18 19:51:49 UTC
Created attachment 244654 [details] [review]
videomixer: Do not send flush_stop when receiving a seek

There is no reason to send a flush-stop when receiving a seek event.
In the case of a flushing seek, we could eventually want to, but in
the code path were we check if the seek is "flushing", we have the
following comment that makes sense:

"we can't send FLUSH_STOP here since upstream could start pushing data
after we unlock mix->collect.
We set flush_stop_pending to TRUE instead and send FLUSH_STOP after
forwarding the seek upstream or from gst_videomixer_collected,
whichever happens first."
Comment 3 Thibault Saunier 2013-05-18 19:53:43 UTC
Created attachment 244656 [details] [review]
videomixer: Send caps event from the streaming thread

This way we avoid races in caps negotiation and we make sure
that the caps are sent after stream-start.
Comment 4 Thibault Saunier 2013-05-18 19:53:54 UTC
Created attachment 244657 [details] [review]
videomixer: Send a reconfigure event upstream if sinkpad caps are not usable
Comment 5 Thibault Saunier 2013-05-18 19:54:05 UTC
Created attachment 244658 [details] [review]
tests: Re-enable videomixer test
Comment 6 Nicolas Dufresne (ndufresne) 2013-05-18 22:03:34 UTC
This is a dup of https://bugzilla.gnome.org/show_bug.cgi?id=684237

After some testing, it seems better, though I still get the following pipeline to fail from time to time:

gst-launch-1.0 videotestsrc num-buffers=1 ! mix. videotestsrc num-buffers=1 ! alpha alpha=0.5 ! mix. videotestsrc num-buffers=1 ! mix. videomixer name=mix ! videoconvert ! xvimagesink

So I'm wondering if the re-enabled test won't fail also from time to time.
Comment 7 Thibault Saunier 2013-05-18 23:18:59 UTC
I have been running (In reply to comment #6)
> This is a dup of https://bugzilla.gnome.org/show_bug.cgi?id=684237

Sorry for the duplication, I didn't search properly before posting. I properly state that bug as a duplicate of the otherone, do I need to copy the patches there?
 
> After some testing, it seems better, though I still get the following pipeline
> to fail from time to time:
> 
> gst-launch-1.0 videotestsrc num-buffers=1 ! mix. videotestsrc num-buffers=1 !
> alpha alpha=0.5 ! mix. videotestsrc num-buffers=1 ! mix. videomixer name=mix !
> videoconvert ! xvimagesink

running

    while gst-launch-1.0 videotestsrc num-buffers=1 ! mix. videotestsrc \
    num-buffers=1 ! alpha alpha=0.5 ! mix. videotestsrc num-buffers=1 ! mix.\
    videomixer name=mix ! videoconvert ! xvimagesink; do echo "hey"; done

never fails here, could you please send a full debug log to see where it fails

> So I'm wondering if the re-enabled test won't fail also from time to time.

I have been running the test with .forever for +30mins without any failure.

*** This bug has been marked as a duplicate of bug 684237 ***