[gstreamer-bugs] [Bug 580749] New: Undefined/Strange/Odd behaviour when encountering encoder specific extension in rtph263pay

[GStreamer (bugzilla.gnome.org)]

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=580749

  GStreamer | gst-plugins-good | Ver: 0.10.22
           Summary: Undefined/Strange/Odd behaviour when encountering
                    encoder specific extension in rtph263pay
           Product: GStreamer
           Version: 0.10.22
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: marc.leeman at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


In the setup, I am using gstreamer to receive h263 rtp from a Bosh Dinion XF DN
IP camera.

When sending the stream to a hardware encoder after being repackaged by
gstreamer, the hardware decoder chokes on the gstreamer stream.

The issue seems about the adding of 00 00 00 00 by Bosh in the H263 stream.

After running rtph263depay and repayloading it with rtph263pay; some strange
issues are centred around the packet containing the end marker bit and the PSC
(Picture Start Code).

In the original encoder; each end frame is immediately followed by a PSC frame.
In the gstreamer code; we have 
- 1. Invalid h263 packet (determined by wireshark). The issue seems to by
around the fact that the payload is only 4 bytes long (consistently)
- 2. end of frame. The payload contains the 00 00 00 00 bytes
- 3. PSC frame.

When inspecting the h263pay code; there seems to be some knowledge about this
since gst_rtp_h263_pay_gobfiner explicitly checks for four 0x00 bytes. If it
does, it returns the last byte before these padded bytes.

It then packages there bytes before the padding; uses the 00 00 00 00 bytes for
the end of frame packet en then continues.

In the original stream, the 00 00 00 00 bytes are also used in the end of frame
packet; but are not split off from the original payloaded stream.

I've patched the code to drop this 'garbage' from the stream; equally able to
decode the stream using ffmpeg_h263 (still not solving my hw decoder issue
though). The size of the packets seems more logical; though this might break
Bosh HW decoders (considering the 00 00 00 00 seems to be an extension their
own).

I am wondering what the approach should be in this case, under the assumption
that the 00 00 00 00 really is a vendor incompatibility in the payload stream
as I'm being told. Somehow; the cross over of this from the payload to the rtp
domain seems not quite correct (especially considering the 2-byte 4-byte n-byte
packet payloads in the RTP frame transition sequence) and considering that the
00 00 00 00 in the original stream is considered normal (black box) payload
without special treatment (looks the preferred approach to me).


-- 
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=580749.