[Bug 709711] video decoders - send upstream force_key_unit events when unable to decode

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=709711
  GStreamer | gst-plugins-base | 1.2.0

--- Comment #2 from Owen Williams <owilliams.cafex at gmail.com> 2013-10-10 08:14:50 UTC ---
That is true, sending additional key frames may make the situation worse where
packet loss is being caused by a continually congested network.  

I'm expecting these upstream force_key_unit events to result in PLI messages
being sent over RTCP to a remote sender.

RFC 4585 has the following to say about how the sender should behave when it
receives PLI

The sender MAY react to a PLI by transmitting an
   intra-picture to achieve resynchronization (making this message
   effectively similar to the FIR message as defined in [6]); however,
   the sender MUST consider congestion control as outlined in Section 7,
   which MAY restrict its ability to send an intra frame.


Sending the force_key_unit event should be interpreted by a sender as a polite
request from downstream that things aren't going too well.

In a non-real-world simulation of 20% packet loss I have the following pipeline
"vp8enc > identity drop-probability=0.2 > vp8dec".  Without the force_key_unit
events the video is shredded, whereas with it - its just about watchable.  

BTW we are intending to primarily use NAKs to fix packet loss, with this PLI as
a backup for when things really go amiss. 

I'm guessing, if this were implemented, you'd prefer it not to be switched on
by default and perhaps there to be some logic that waits for a set of corrupt
frames before sending first force_key_unit event.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.