[gstreamer-bugs] [Bug 610172] New: inconsistent h263pay/h263depay behaviour

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=610172
  GStreamer | gst-plugins-good | 0.10.17

           Summary: inconsistent h263pay/h263depay behaviour
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.17
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          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 target: ---
     GNOME version: ---


I am trying to decode h263 coming from a Bosch encoder. By coincidence I
noticed the following:

does NOT decode:
gst-launch udpsrc uri=udp://226.255.0.68:6000 caps="application/x-rtp,
clock-rate=(int)90000, encoding-name=(string)H263, media=(string)video,
payload=(int)34" ! rtph263depay ! ffdec_h263 ! xvimagesink
force-aspect-ratio=True sync=True


does decode:
gst-launch udpsrc uri=udp://226.255.0.68:6000 caps="application/x-rtp,
clock-rate=(int)90000, encoding-name=(string)H263, media=(string)video,
payload=(int)34" ! rtph263depay ! rtph263pay ! rtph263depay ! ffdec_h263 !
xvimagesink force-aspect-ratio=True sync=True

instead of just 

... ! rtph263depay ! ...
... ! rtph263depay ! rtph263pay ! rtph263depay ! ...

behaves better.

I can only guess at this time that feeding it through the payloader parses the
data in some format that the depayloader or decoder can handle better.

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