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 738319 - rtpsession: fix Early Feedback Transmission
rtpsession: fix Early Feedback Transmission
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-10 18:07 UTC by Miguel París Díaz
Modified: 2018-11-03 14:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First patch to fix the problem (1.70 KB, patch)
2014-10-10 18:07 UTC, Miguel París Díaz
needs-work Details | Review
Patch v2 (7.54 KB, patch)
2014-10-13 15:36 UTC, Miguel París Díaz
committed Details | Review
0001-rtpsession-The-send-rtcp-signal-now-returns-a-G_TYPE.patch (1.02 KB, patch)
2015-01-22 10:05 UTC, Sebastian Dröge (slomo)
rejected Details | Review
0002-rtpsession-Delay-the-next-regular-RTCP-packet-after-.patch (2.25 KB, patch)
2015-01-22 10:05 UTC, Sebastian Dröge (slomo)
accepted-commit_now Details | Review
0003-WIP-should-we-also-try-to-deduplicate-NACK-and-FIR-a.patch (1.54 KB, patch)
2015-01-22 10:06 UTC, Sebastian Dröge (slomo)
none Details | Review
0001-rtpsession-Add-new-send-rtcp-full-signal.patch (2.00 KB, patch)
2015-01-25 17:01 UTC, Sebastian Dröge (slomo)
committed Details | Review
0002-rtpsession-Delay-the-next-regular-RTCP-packet-after-.patch (2.25 KB, patch)
2015-01-25 17:01 UTC, Sebastian Dröge (slomo)
committed Details | Review
0003-rtpsession-De-duplicate-FIR-feedback-messages-if-pos.patch (2.38 KB, patch)
2015-01-25 17:01 UTC, Sebastian Dröge (slomo)
none Details | Review
0004-rtpsession-De-duplicate-NACK-feedback-packets-if-pos.patch (5.27 KB, patch)
2015-01-25 17:01 UTC, Sebastian Dröge (slomo)
none Details | Review
0005-rtpsession-Deprecate-rtcp-immediate-feedback-thresho.patch (2.18 KB, patch)
2015-01-25 17:03 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Miguel París Díaz 2014-10-10 18:07:54 UTC
Created attachment 288248 [details] [review]
First patch to fix the problem

My work team and I have detected a problem which causes that a lot of NACK packets are sent when the limit of the network bandwidth is reached.

The NACK requests are caused because the jitterbuffer is requesting a lot of retransmissions. This behaviour is a bug related with:
https://bugzilla.gnome.org/show_bug.cgi?id=735378

Moreover, we have detected a bug in the implementation of the Early Feedback Transmission (RTCP) which must follow this part of the RFC: http://tools.ietf.org/html/rfc4585#section-3.5.2

The current implementation does not do Part 6, so a lot of early RTCP pakets are sent. We propose an initial patch which is closer to the RFC, but it does not follow "MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous tn" yet.
Comment 1 Olivier Crête 2014-10-10 19:40:50 UTC
Review of attachment 288248 [details] [review]:

More comments about what your changes are meant to do exactly would help, I'm not following exactly.

::: gst/rtpmanager/rtpsession.c
@@ -3815,3 @@
    */
-  if (sess->total_sources > sess->rtcp_immediate_feedback_threshold &&
-      sess->allow_early == FALSE) {

Why did you remove the check for the immediate feedback threshold ? That will just prevent sending feedback immediately.
Comment 2 Olivier Crête 2014-10-10 19:51:16 UTC
You can just set rtcp_immediate_feedback_threshold to 0 do what you want, no ? It's a property on RTPSession, See commit 6095d2a3f
Comment 3 Miguel París Díaz 2014-10-13 15:36:21 UTC
Hello,
we have compared the GStreamer implementation (rtpsession.c) with the RFC  http://tools.ietf.org/html/rfc4585#section-3.5.2 and we have noticed that steps 4a.2 and 6 were missed, which are very important for the correct behaviour.

I upload a new patch where I have tried to change as less as possible.
The solution that I propose is that rtp_session_send_rtcp() function returns TRUE if the related RTCP can be scheduled
Then it is called before registering NACKs or PLIs/FIRs, and if it returns FALSE, the RTCP is discarded.

By the moment, I do not use rtcp_immediate_feedback_threshold, but we can see how it must be used following the RFC.
Comment 4 Miguel París Díaz 2014-10-13 15:36:58 UTC
Created attachment 288397 [details] [review]
Patch v2
Comment 5 Wim Taymans 2014-10-22 11:15:26 UTC
commit e6504e3a65e2c99a7722bf3f396cc1b41917d65c
Author: Miguel París Díaz <mparisdiaz@gmail.com>
Date:   Fri Oct 10 19:50:06 2014 +0200

    rtpsession: fix Early Feedback Transmission
    
    In early retransmission we are allowed to schedule 1 regular RTCP packet
    at an earlier time. When we do that, we need to set allow_early to FALSE
    and ignore/drop (or merge) all future requests for early transmission.
    We now first check if we can schedule an early RTCP and if we can,
    actually prepare the data for the next RTCP interval.
    
    After we send the next regular RTCP after the early RTCP, we set
    allow_early to TRUE again to allow more early requests.
    
    Remove the condition for the immediate feedback for now.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738319
Comment 6 Wim Taymans 2014-10-22 13:43:59 UTC
Now we only need to make a choice for when to activate immediate or early feedback.
Comment 7 Tim-Philipp Müller 2014-10-24 19:52:23 UTC
Wim, any opinion on whether this is good to pick into the 1.4 branch? (risk/reward)
Comment 8 Wim Taymans 2014-10-27 10:03:53 UTC
not yet, we first need to add the immediate feedback again, marking as blocker.
Comment 9 Sebastian Dröge (slomo) 2015-01-21 21:00:21 UTC
Looking into that
Comment 10 Sebastian Dröge (slomo) 2015-01-22 09:56:07 UTC
If I'm not mistaken we currently *always* do immediate feedback. AFAIU immediate feedback means that it's always allowed to send up to one early RTCP packet before the next scheduled one, while in early feedback mode this might not be allowed every now and then (rules not 100% clear to me).

See the definition of allow_early in the RFC (allowing up to one early RTCP packet), the definitions of early RTCP packet, early rtcp mode and immediate feedback mode (1.1) and 3.3 a) vs b).

However this is also a bit weird still, as 3.3a) talks about reporting each event immediately. Which would not be true with my understanding (you can report one event immediately, then you have to wait until the next regular RTCP packet).
I would've expected immediate RTCP mode to mean that it is possible to send multiple early packets between the regular RTCP packets, but nothing in the RFC seems to support this view.


So if my understanding is correct, we would have the throttle sending of early packets if we're above the FB threshold. I don't see that in the RFC but it would be the implication, and I would guess that it would mean to only send an early packet every group_size/threshold packets.


Does someone have any additional insights?


FWIW, I also have some other fixes related to this. Attaching now.
Comment 11 Sebastian Dröge (slomo) 2015-01-22 10:05:07 UTC
Created attachment 295151 [details] [review]
0001-rtpsession-The-send-rtcp-signal-now-returns-a-G_TYPE.patch

Does this break ABI? But it would be the right thing to do ;)
Comment 12 Sebastian Dröge (slomo) 2015-01-22 10:05:34 UTC
Created attachment 295152 [details] [review]
0002-rtpsession-Delay-the-next-regular-RTCP-packet-after-.patch

Fixes a TODO Miguel added
Comment 13 Sebastian Dröge (slomo) 2015-01-22 10:06:01 UTC
Created attachment 295153 [details] [review]
0003-WIP-should-we-also-try-to-deduplicate-NACK-and-FIR-a.patch

See the two comments, should we and can we?
Comment 14 Olivier Crête 2015-01-22 15:00:47 UTC
Review of attachment 295151 [details] [review]:

::: gst/rtpmanager/rtpsession.c
@@ -318,3 +318,3 @@
       G_SIGNAL_RUN_LAST | G_SIGNAL_ACTION,
       G_STRUCT_OFFSET (RTPSessionClass, send_rtcp), NULL, NULL,
-      g_cclosure_marshal_generic, G_TYPE_NONE, 1, G_TYPE_UINT64);
+      g_cclosure_marshal_generic, G_TYPE_BOOLEAN, 1, G_TYPE_UINT64);

I'm pretty sure this is an ABI break. As the g_signal_emit_by_name() function takes an extra argument if you have a return value. I assume that if you use it without the extra argument, it may clobber whatever is on the stack at that point.
Comment 15 Sebastian Dröge (slomo) 2015-01-22 20:01:45 UTC
Good point! Thanks for sanity checking :) I guess we need to add a send-rtcp-full signal for this then

Any ideas on the other bits?
Comment 16 Olivier Crête 2015-01-22 20:22:30 UTC
Review of attachment 295152 [details] [review]:

I believe this is correct. You may want to explain why the "+= T_rr" in a comment, it took me a bit of time to understand what it was for.
Comment 17 Olivier Crête 2015-01-22 20:27:21 UTC
Review of attachment 295153 [details] [review]:

::: gst/rtpmanager/rtpsession.c
@@ +3108,3 @@
   gst_rtcp_packet_fb_set_media_ssrc (packet, 0);
 
+  /* FIXME: RFC 4585 3.5.2 5) Check retained packets if we duplicate one here? */

This is trivial to implement, we should probably just do it,

@@ +3179,3 @@
     return;
 
+  /* FIXME: RFC 4585 3.5.2 5) Check retained packets if we duplicate one here? */

This one is non-trivial, as we probably want to suppress packets that only describe NACKs that have already been sent even if the RTCP packet is not identical. For example, if "1 2 5" is received, the first nack would be "3 4", but if 4 is later received, a nack with just "3" should probably be suppressed even though it's not identical. Or maybe I'm over-thinking this.
Comment 18 Olivier Crête 2015-01-22 20:34:27 UTC
What's the use-case for send-rtcp-full ? The way I originally designed it, "send-rtcp" was just a polite request to send an early RTCP packet, but with no guarantees that one will actually be sent before the next timeout. Actually filling the packets is delayed to the "on-sending-rtcp" signal.

So even if the early rtcp is "refused", the next RTCP packet may be soon enough to be useful, so that the early nature may not matter. The code filling the rtcp packet would be responsible for deciding if one has happened fast enough, or if too much time has passed and a different kind of action is required.
Comment 19 Sebastian Dröge (slomo) 2015-01-22 21:16:19 UTC
(In reply to comment #17)
> @@ +3179,3 @@
>      return;
> 
> +  /* FIXME: RFC 4585 3.5.2 5) Check retained packets if we duplicate one here?
> */
> 
> This one is non-trivial, as we probably want to suppress packets that only
> describe NACKs that have already been sent even if the RTCP packet is not
> identical. For example, if "1 2 5" is received, the first nack would be "3 4",
> but if 4 is later received, a nack with just "3" should probably be suppressed
> even though it's not identical. Or maybe I'm over-thinking this.

Well, it's definitely a solveable problem :) I just wasn't sure if those two cases were left out on purpose, or were forgotten. I'll look into that then.

(In reply to comment #18)
> What's the use-case for send-rtcp-full ? The way I originally designed it,
> "send-rtcp" was just a polite request to send an early RTCP packet, but with no
> guarantees that one will actually be sent before the next timeout. Actually
> filling the packets is delayed to the "on-sending-rtcp" signal.
> 
> So even if the early rtcp is "refused", the next RTCP packet may be soon enough
> to be useful, so that the early nature may not matter. The code filling the
> rtcp packet would be responsible for deciding if one has happened fast enough,
> or if too much time has passed and a different kind of action is required.

It would be mostly convenience. You would already know that the next RTCP packet will be too late, and don't need to calculate that yourself from the time when on-sending-rtcp happens.


What's your understanding of the immediate RTCP situation, what I wrote in comment 10? I have the feeling I missed something obvious in the RFC that explains the missing piece :)
Comment 20 Olivier Crête 2015-01-22 22:15:51 UTC
After over 8 years doing RTP, I think I just understood the meaning of immediate vs early feedback today, I'll try to explain how I understand it now:

(In reply to comment #10)
> If I'm not mistaken we currently *always* do immediate feedback. AFAIU
> immediate feedback means that it's always allowed to send up to one early RTCP
> packet before the next scheduled one, while in early feedback mode this might
> not be allowed every now and then (rules not 100% clear to me).

The original idea is that we do immediate feedback if the number of session members is less than "rtcp-immediate-feedback-threshold" (by default 3), but one could set that to 0 and disable immediate feedback entirely. I now think I didn't understand it correctly.

I think that from a "endpoint source code" point of view, "early" and "immediate" feedback are the same. The difference is the aggregate behaviour. If the group is small enough, then you send feedback packets frequently enough that everything that happened between two RTCP packets can (statistically) be reported in the next packet. For example, not many more than 16 RTP packets can have been lost between two RTCP packet, so the NACK is enough. But if your group is larger, than you send RTCP packets much less frequently, you cut it down in half if you go from 2 to 4 members, then you can't individually send feedback for each event from each endpoint, but as an aggregate you do, so maybe going from 2 to 4, you switched from immediate to early mode, but the code in each endpoint is still the same.

> However this is also a bit weird still, as 3.3a) talks about reporting each
> event immediately. Which would not be true with my understanding (you can
> report one event immediately, then you have to wait until the next regular RTCP
> packet).
> I would've expected immediate RTCP mode to mean that it is possible to send
> multiple early packets between the regular RTCP packets, but nothing in the RFC
> seems to support this view.

Sending as many RTCP packets as is needed was also my initial reading. But I think it's actually not correct. One of the guiding principles of the RTP/RTCP RFCs is to limit the bandwidth occupied by RTCP to a specific limit. Using the AVPF profile, when trr-int=0, you send RTCP packets as often as is possible within the bandwidth limit. So sending a single extra packet would exceed the limit, which is a big no no. So then it makes sense that sending immediately an early packet just means that the next packet is sent early, not that you get to send an extra packet.
Comment 21 Miguel París Díaz 2015-01-22 22:55:42 UTC
Hello,
the point here is that the RFC might be written in a better way xD. We also had the same feelings than you Sebastian ;).

Kurento team studied  the RFC and GStreamer code some months ago (we were focused on the point-to-point case). We got our own conclusions, but the most relevant is the related with this question:
How many RTCP packets can be sent between two Regular RTCP packets?
  - Following the RFC only one: the early packet (point-to-point case).
  - GStreamer allowed sent all app requests (because did not follow Part 6 (see comment #1)

For our use cases, both cases did not match with a useful way to sent NACKs. Why?
  - Following the RFC only a NACK can be sent.
  - GStreamer sent each NACK in a independent packet wasting a lot of bandwidth (if the max_delay used for scheduling and set by jitterbuffer is too small).

We have our own patches (out of the RFC) that work fine for us. These changes are in the "middle" of both last cases.

I have to say that I can have forgotten some detail, but anyway I think that we could work together to improve GStreamer source and do some suggestion to change the RFC if we consider it suitable ;).

Regards!!
Comment 22 Sebastian Dröge (slomo) 2015-01-23 07:16:12 UTC
Thanks Olivier, that actually makes sense, especially considering my second patch! So all that is left here is to update my patches and merge them, and then we're good. Will do that soon. And then also deprecate the threshold property as it has no meaning anymore.


Miguel, I don't think it would be a good idea to intentionally deviate from the RFC, and I think what Olivier said is what is actually intended there.
Comment 23 Sebastian Dröge (slomo) 2015-01-25 17:01:23 UTC
Created attachment 295378 [details] [review]
0001-rtpsession-Add-new-send-rtcp-full-signal.patch
Comment 24 Sebastian Dröge (slomo) 2015-01-25 17:01:24 UTC
Created attachment 295379 [details] [review]
0002-rtpsession-Delay-the-next-regular-RTCP-packet-after-.patch
Comment 25 Sebastian Dröge (slomo) 2015-01-25 17:01:45 UTC
Created attachment 295380 [details] [review]
0003-rtpsession-De-duplicate-FIR-feedback-messages-if-pos.patch
Comment 26 Sebastian Dröge (slomo) 2015-01-25 17:01:51 UTC
Created attachment 295381 [details] [review]
0004-rtpsession-De-duplicate-NACK-feedback-packets-if-pos.patch
Comment 27 Sebastian Dröge (slomo) 2015-01-25 17:03:06 UTC
Created attachment 295382 [details] [review]
0005-rtpsession-Deprecate-rtcp-immediate-feedback-thresho.patch
Comment 28 Olivier Crête 2015-01-25 21:18:16 UTC
Review of attachment 295380 [details] [review]:

::: gst/rtpmanager/rtpsession.c
@@ +3101,3 @@
+  if (gst_rtcp_buffer_get_first_packet (&rtcp, &packet)) {
+    /* FIXME: Do we also need to compare the ssrc in the packet with the
+     * source's ssrc? */

I think so, the packet we're trying to duplicate could also have come from another peer in the group, and there could be multiple senders.
Comment 29 Olivier Crête 2015-01-25 21:55:21 UTC
Review of attachment 295381 [details] [review]:

I'm not sure I understand your code exactly, if we sent a nack with "23" as lost and then we discover that 5 is lost, will it is "235" or just "5" ?
Comment 30 Olivier Crête 2015-01-25 21:58:01 UTC
Review of attachment 295378 [details] [review]:

Still not a fan of this API change, maybe instead returning a boolean, it should return the delay until the next RTCP packet, "0" meaning now. I assume that the first thing any implementation that receives FALSE will do is to check when the next scheduled packet is  and if it's soon enough, then it's as good as now. I still think that any implementation that makes a different between right now and "soon enough" is doing it wrong.
Comment 31 Sebastian Dröge (slomo) 2015-01-26 09:39:17 UTC
(In reply to comment #28)
> Review of attachment 295380 [details] [review]:
> 
> ::: gst/rtpmanager/rtpsession.c
> @@ +3101,3 @@
> +  if (gst_rtcp_buffer_get_first_packet (&rtcp, &packet)) {
> +    /* FIXME: Do we also need to compare the ssrc in the packet with the
> +     * source's ssrc? */
> 
> I think so, the packet we're trying to duplicate could also have come from
> another peer in the group, and there could be multiple senders.

But if it is from another peer, we shouldn't send another request, right? Someone requested FIR already and that should give us a new keyframe too.

(In reply to comment #29)
> Review of attachment 295381 [details] [review]:
> 
> I'm not sure I understand your code exactly, if we sent a nack with "23" as
> lost and then we discover that 5 is lost, will it is "235" or just "5" ?

If we observed a NACK with "23" and now we want to send one with "5", we will send one with "5". But if we observed one for "235" and we now want to send one for "456" then we will send one for "46" only. There is no merging done here, only filtering of seqnums that were already requested. The merging is done in rtp_source_register_nack().


Note that this is about observing feedback from others in the group, not from ourselves. If someone else in the group requested retransmission for something we care about, then we don't have to do that again as it will just increase traffic for no good reason. Same goes for PLI and FIR.
Comment 32 Sebastian Dröge (slomo) 2015-01-26 09:42:32 UTC
(In reply to comment #30)
> Review of attachment 295378 [details] [review]:
> 
> Still not a fan of this API change, maybe instead returning a boolean, it
> should return the delay until the next RTCP packet, "0" meaning now. I assume
> that the first thing any implementation that receives FALSE will do is to check
> when the next scheduled packet is  and if it's soon enough, then it's as good
> as now. I still think that any implementation that makes a different between
> right now and "soon enough" is doing it wrong.

But it will already pass the "soon enough" as parameter (max-delay) to that API. So the user of the API will tell it when "soon enough" ends, and if it's not possible to send anything until then, FALSE is returned.

Why would any implementation that receives FALSE check when the next scheduled packet would be, to do what? It already knows at that point that this specific feedback it wanted to send is going to be late.
Comment 33 Sebastian Dröge (slomo) 2015-01-26 16:00:16 UTC
(In reply to comment #31)
> (In reply to comment #28)
> > Review of attachment 295380 [details] [review] [details]:
> > 
> > ::: gst/rtpmanager/rtpsession.c
> > @@ +3101,3 @@
> > +  if (gst_rtcp_buffer_get_first_packet (&rtcp, &packet)) {
> > +    /* FIXME: Do we also need to compare the ssrc in the packet with the
> > +     * source's ssrc? */
> > 
> > I think so, the packet we're trying to duplicate could also have come from
> > another peer in the group, and there could be multiple senders.
> 
> But if it is from another peer, we shouldn't send another request, right?
> Someone requested FIR already and that should give us a new keyframe too.

It's not clear to me what this SSRC is actually doing there. Also when retaining RTCP packets, we store them next to the source that has the corresponding media ssrc, so it might be correct here already.

What are these FIR packets? Are they this?
https://tools.ietf.org/html/rfc2032#section-5.2.1
If they are supposed to be this, I think we are creating and parsing them wrong currently.
Comment 34 Olivier Crête 2015-01-26 17:30:24 UTC
(In reply to comment #31)
> If we observed a NACK with "23" and now we want to send one with "5", we will
> send one with "5". But if we observed one for "235" and we now want to send one
> for "456" then we will send one for "46" only. There is no merging done here,
> only filtering of seqnums that were already requested. The merging is done in
> rtp_source_register_nack().

I think if someone already announced that "5" was lost, and we didn't receive 456, then we should nack 456, otherwise the sender will think that one lost 5 and the other lost 46 but not 5, which may be confusing. As for large groups, NACKs may only be used statically, not as a request for an immediate retransmission.

(In reply to comment #32)
> But it will already pass the "soon enough" as parameter (max-delay) to that
> API. So the user of the API will tell it when "soon enough" ends, and if it's
> not possible to send anything until then, FALSE is returned.

Oops, forget what I said then, I had completely forgotten about that... ++ on the patch

(In reply to comment #33)
> What are these FIR packets? Are they this?
> https://tools.ietf.org/html/rfc2032#section-5.2.1
> If they are supposed to be this, I think we are creating and parsing them wrong
> currently.

No, they're in RFC 5104 3.5.1.. Google Hangouts was using them instead of PLI at some point, but I understand that their correct use is really for stream switching.
Comment 35 Sebastian Dröge (slomo) 2015-01-26 17:48:25 UTC
(In reply to comment #34)
> (In reply to comment #31)
> > If we observed a NACK with "23" and now we want to send one with "5", we will
> > send one with "5". But if we observed one for "235" and we now want to send one
> > for "456" then we will send one for "46" only. There is no merging done here,
> > only filtering of seqnums that were already requested. The merging is done in
> > rtp_source_register_nack().
> 
> I think if someone already announced that "5" was lost, and we didn't receive
> 456, then we should nack 456, otherwise the sender will think that one lost 5
> and the other lost 46 but not 5, which may be confusing. As for large groups,
> NACKs may only be used statically, not as a request for an immediate
> retransmission.

If we're talking about a group with more receivers than one, we have multicast, right? In that case if some other receiver requested "5" again, and we want "456" now, we can skip "5" as we would receive the retransmission for the other one too (because it goes to the multicast group).

Or am I missing something here? There's the same reasoning for PLI and FIR btw, we don't send our request because someone else in the multicast group did already which would also get us the result without requesting anything.

> (In reply to comment #33)
> > What are these FIR packets? Are they this?
> > https://tools.ietf.org/html/rfc2032#section-5.2.1
> > If they are supposed to be this, I think we are creating and parsing them wrong
> > currently.
> 
> No, they're in RFC 5104 3.5.1.. Google Hangouts was using them instead of PLI
> at some point, but I understand that their correct use is really for stream
> switching.

Oh good, that's not confusing at all ;) I'll check against that RFC what would be the correct behaviour here.
Comment 36 Olivier Crête 2015-01-26 19:40:35 UTC
I don't think you should read the NACK as a request, but as a status report. You're just saying, "I didn't receive packet x,y,z", not "please re-send packets x,y,z". In the multicast case, if you have a large group, the sender could look at how many nacks it got for each packet for example. Although I understand NACKs can't be used for very large groups. So maybe I've over-thinking this
Comment 37 Sebastian Dröge (slomo) 2015-03-15 15:02:03 UTC
This is not really a blocker anymore. Any regressions are gone and we just have to implement things more correctly now.
Comment 38 Sebastian Dröge (slomo) 2015-03-20 18:51:38 UTC
Related to this, see bug #746543
Comment 39 GStreamer system administrator 2018-11-03 14:54:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/134.