GNOME Bugzilla – Bug 598377
rtpmanager: only forward the lost event to the last seen payloadnumber
Last modified: 2009-10-14 10:45:43 UTC
In a case where you have multiple payloadnumbers arriving with the same ssrc, and you have packetloss, the lost-event will be forwarded using the default event-handling, meaning the lost-event won't necessarily arrive at the decoder that is active. Make the rtpptdemux forward all events on all pads, except for the lost-event, that only gets forwarded on the active (last seen payloadnumber) pad.
Created attachment 145404 [details] [review] patch
Another option is to have the element receiving the lost packet event filter out the events with the wrong pt.
We should probably include the pt for which we generated the lost packet event in the PacketLost event. commit 58b9de4cca8b0f9da0742202e190457801118d33 Author: Håvard Graff <havard.graff at tandberg.com> Date: Wed Oct 14 12:28:55 2009 +0200 rtpptdemux: only forward the lost-event to the last seen pt-number forward all events on all pads except for the PacketLost event, which we want to forward to the last seen pt pad. Fixes #598377
Sure, but the lost packet event should be thought of as a "replacement buffer", and then it make sense that it, just like the buffers, are redirected according to its (assumed) payloadnumber. However, at the moment there is no payloadnumber info on the event, only seqnum, timestamp and duration. Also, when using the default handling in the basedepayloader, the lost-event is translated to a newsegment, and that can't have any knowledge of payloadnumbers. So I guess the other option would be: 1. Add payloadnumber to the lost-event. (priv-last_pt) 2. Add a filtering on the basedepayloader, checking if the lost-event received matches the configured pt. What makes me a bit sceptical of this approach is that you would be sending the lost events to all depayloaders (with the same ssrc), making them do accept or decline. In my head this is similar to sending all buffers to all depayloaders, making them do the job that the ptdemux is there to do.
You are right, we should only filter in ptdemux. Adding the pt to the event is still a good idea, though. Only the jitterbuffer what timestamps it used from what pt to generate the PacketLost event.
agreed! :)