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 774908 - multifdsink removing slow client corrupts matroska stream
multifdsink removing slow client corrupts matroska stream
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.10.1
Other Linux
: Normal normal
: 1.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-23 12:31 UTC by Jan Alexander Steffens (heftig)
Modified: 2016-12-05 09:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test script (1.88 KB, text/x-python)
2016-11-23 12:31 UTC, Jan Alexander Steffens (heftig)
  Details
[PATCH] multihandlesink: Update bufpos in a separate pass (2.79 KB, patch)
2016-11-23 14:00 UTC, Jan Alexander Steffens (heftig)
committed Details | Review
[PATCH] multifdsink: Add a test involving a slow client (5.81 KB, patch)
2016-11-29 16:00 UTC, Jan Alexander Steffens (heftig)
committed Details | Review

Description Jan Alexander Steffens (heftig) 2016-11-23 12:31:02 UTC
Created attachment 340593 [details]
test script

The attached test script creates a producer pipeline feeding a matroska video stream into a multifdsink and 5 consumer pipelines that demux the matroska stream.

The 3rd consumer is then paused, and when the multifdsink ejects the client because it doesn't read fast enough, the stream sent to the 4th and 5th consumers is corrupted. The matroskademux elements complain:

ebml-read.c:141:gst_ebml_peek_id_length:<matroskademux4> Invalid EBML ID size tag (0x0) at position 542310 (0x84666)
ebml-read.c:141:gst_ebml_peek_id_length:<matroskademux3> Invalid EBML ID size tag (0x0) at position 542310 (0x84666)

If the script is adjusted to pause the 2nd consumer, then the 3th, 4th and 5th consumers receive a corrupted stream.

If the script is adjusted to pause the 1st consumer, everything is fine.

GStreamer 1.10.1
Arch Linux x86_64
Comment 1 Jan Alexander Steffens (heftig) 2016-11-23 13:12:51 UTC
I suspect this might have something to do with the loop in gst_multi_handle_sink_queue_buffer getting restarted due to the cookie change, and the clients before the ejected one now have a larger bufpos than the client behind the ejected one.
Comment 2 Jan Alexander Steffens (heftig) 2016-11-23 14:00:32 UTC
Created attachment 340601 [details] [review]
[PATCH] multihandlesink: Update bufpos in a separate pass

If a client gets dropped and the iteration gets restarted, bufpos is
incremented again for all clients that preceded the dropped one, causing
havoc.

Adjust the bufpos for all clients first before trying to drop any.
Comment 3 Sebastian Dröge (slomo) 2016-11-29 11:19:33 UTC
Comment on attachment 340601 [details] [review]
[PATCH] multihandlesink: Update bufpos in a separate pass

Makes sense to me, would it be difficult to make a test (there's a multihandlesink test)?
Comment 4 Jan Alexander Steffens (heftig) 2016-11-29 16:00:40 UTC
Created attachment 340983 [details] [review]
[PATCH] multifdsink: Add a test involving a slow client

Here; should fail without the patch and pass with it.
Comment 5 Sebastian Dröge (slomo) 2016-11-29 17:15:13 UTC
commit 9bdf7ff6d09fcc308d87196228b9b4d0b84977a0
Author: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Date:   Tue Nov 29 16:26:22 2016 +0100

    multifdsink: Add a test involving a slow client
    
    https://bugzilla.gnome.org/show_bug.cgi?id=774908

commit 8b9ebd8f8844fb720243b099bf743100dff5acea
Author: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Date:   Wed Nov 23 14:35:04 2016 +0100

    multihandlesink: Update bufpos in a separate pass
    
    If a client gets dropped and the iteration gets restarted, bufpos is
    incremented again for all clients that preceded the dropped one, causing
    havoc.
    
    Adjust the bufpos for all clients first before trying to drop any.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=774908