[Bug 752694] rtpmux: allow the ssrc-property to decide ssrc on outgoing buffers

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=752694

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.7.1

--- Comment #17 from Olivier Crête <olivier.crete at ocrete.ca> ---
Thanks for finding this, added a couple more GST_OBJECT_LOCKs and pushed the
patches:

commit 58073eaa7ae5d7c7b93da89faea05e7f01ee58cd
Author: Olivier Crête <olivier.crete at collabora.com>
Date:   Mon Aug 31 21:10:16 2015 -0400

    rtpmux: Use default upstream event handling

    https://bugzilla.gnome.org/show_bug.cgi?id=752694

commit 43c213fc5db75dcf570ef1c224122307a0899911
Author: Olivier Crête <olivier.crete at collabora.com>
Date:   Mon Aug 31 21:05:03 2015 -0400

    rtpmux: As 0xFFFFFFFF is a valid ssrc, check if it has been set

    https://bugzilla.gnome.org/show_bug.cgi?id=752694

commit d5e26ab9099e5a46eda7e9b59f01c1efe463344d
Author: Havard Graff <havard.graff at gmail.com>
Date:   Wed Jul 22 09:47:22 2015 +0200

    gstrtpmux: allow the ssrc-property to decide ssrc on outgoing buffers

    By not doing this, the muxer is not effectively a rtpmuxer, rather a
    funnel, since it should be a single stream that exists the muxer.

    If not specified, take the first ssrc seen on a sinkpad, allowing upstream
    to decide ssrc in "passthrough" with only one sinkpad.

    Also, let downstream ssrc overrule internal configured one

    We hence has the following order for determining the ssrc used by
    rtpmux:

    0. Suggestion from GstRTPCollision event
    1. Downstream caps
    2. ssrc-Property
    3. (First) upstream caps containing ssrc
    4. Randomly generated

    https://bugzilla.gnome.org/show_bug.cgi?id=752694

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.