GNOME Bugzilla – Bug 582575
[rtph263depay] dropping only part of key frames on lost fragmets
Last modified: 2009-12-22 13:42:36 UTC
Please describe the problem: When an h263 frame fragment is lost the rtph263depayloader is only discarding the payload received since the beginning of the frame, accepting and sending to the decoder the following fragments, up to the marker bit, if no other errors are detected. Looking at rfc2190 no explicit rules seem to be defined, but some decoders could misbehave when receiving such incomplete data. If the rule is to keep as much infos as possible then the depayloader shouldn't drop the initial part of the frame. Steps to reproduce: 1. Launch an RTP pipeline sending to the local loopback RTP packets generated with rtph263pay. Dump the sent data with a tee. 2. Tcpdump on the loopback interface. 3. After some seconds, launch an RTP receiving pipeline on the same target connected, again, to the local loopback and depayloading data with rtph263depay. Dump the depayloaded data. 4. After some tries you'll catch a depayloading starting on the middle of a key frame (look at the tcpdump). Actual results: The key frame is partially reassembled starting from the first received packet. Expected results: They frame should be completely discarded. Does this happen every time? Yes. Other information:
Created attachment 134631 [details] [review] Patch to make rtph263depay dropping the whole packet. If the issue is valid the attached patch can be used to drop all the fragments of an uncomplete packet the same way rtph264depay does.
Created attachment 135551 [details] [review] Drop the whole frame if a packet is lost The old patch was initializing the START field to FALSE, so that the first key frame was always dropped.. here is a corrected version.
commit 251401aef1a38965e16bac04428aa19ef1810a2b Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Dec 22 14:41:35 2009 +0100 rtph263depay: add some fixmes commit 564581e1b88ecd5ec5da82c3cafb0e7a2d58b302 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Dec 22 14:35:13 2009 +0100 rtph263depay: baseclass handles timestamps for us commit 27ff4a8a4701c406524b1342ebcf2917168ac16a Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Dec 22 14:27:40 2009 +0100 rtph263depay: reset start variable properly commit 74b3439374d06460ddb6e8cffc679c8085e80d34 Author: Marco Ballesio <marco.ballesio@nokia.com> Date: Fri May 29 15:49:27 2009 +0300 Drop the whole frame if a packet is lost. Fixes #582575