[gstreamer-bugs] [Bug 582575] New: [rtph263depay] dropping only part of key frames on lost fragmets

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Thu May 14 00:39:30 PDT 2009


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=582575

  GStreamer | gst-plugins-good | Ver: git
           Summary: [rtph263depay] dropping only part of key frames on lost
                    fragmets
           Product: GStreamer
           Version: git
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: marco.ballesio at nokia.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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:


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=582575.




More information about the Gstreamer-bugs mailing list