[gstreamer-bugs] [Bug 580880] New: gstrtpjpegpay is not functioning properly; rtp jpeg payload is corrupted

[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=580880

  GStreamer | gst-plugins-good | Ver: git
           Summary: gstrtpjpegpay is not functioning properly; rtp jpeg
                    payload is corrupted
           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: marc.leeman at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
when using a MJPEG camera (http source), Axis 243SA mjpeg; I re-multicast it
with:

$ gst-launch souphttpsrc location="http://10.3.0.71/axis-cgi//mjpg/video.cgi"
typefind=true ! multipartdemux ! udpsink host=226.226.226.220 port=2277

This step is basically removing the http unicast and multicasting for easy
usage.

Inspecting the stream with 

$ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! jpegdec !
autovideosink

shows a clean stream of video.

The next step is to send the stream (UDP) and package it in RTP:

$ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! jpegdec !
jpegenc ! rtpjpegpay ! udpsink host=226.226.226.120 port=2277

the jpegdec followed by the jpegenc is mainly due to a missing jpegparse as
discussed on IRC.

Reading the re-encoded JPEG stream with

$ gst-launch udpsrc multicast-group=226.226.226.120 port=2277
caps="application/x-rtp,clock-rate=(int)90000" ! rtpjpegdepay ! jpegdec !
autovideosink

is fine again.

However, when re-sending the JPEG stream without re-encoding:
jpegbinrtp is a bin that uses a jpeg dec/enc trick to get the resolution needed
for rtpjpegpay

$ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! rtpjpegpay
silent=false ! udpsink host=226.226.226.120 port=2277Setting pipeline to PAUSED
...
Setup Streaming.
No decoding.
Setup streaming.
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Found caps "image/jpeg".
Unhandled stream type, ghosting pad.
Ghosting pad is not linked: <recv_video_00>.
Ghosting pad is a src: <recv_video_00>.
Ghosting pad is not linked: <recvp_video_00>.
Ghosting pad is a src: <recvp_video_00>.
New barcorecvp pad, name: <recvp_video_00>.
Setup streaming.
No decoding/save.
Setup streaming.
Found caps "image/jpeg".
JPEG Elementary Stream.
TS wrapping is not yet implemented for this type of stream.
The width/height caps are missing, reencoding.
Found caps "image/jpeg, width=(int)704, height=(int)576,
framerate=(fraction)0/1".
JPEG Elementary Stream.
TS wrapping is not yet implemented for this type of stream.
The width/height caps are present, ghosting.
Pad was detected with enc/dec loop.
Stream blocked.
Ghosting pad is not linked: <send_src_00>.
Ghosting pad is a src: <send_src_00>.
Ghosting pad is not linked: <sendp_src_00>.
Ghosting pad is a src: <sendp_src_00>.
New barcosendp pad, name: <sendp_src_00>.
<sendp_src_00> is a src pad, ghosting.
Ghosting pad is not linked: <mgs_src_00>.
Ghosting pad is a src: <mgs_src_00>.
Stream unblocked.
WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Internal data
flow problem.
Additional debug info:
gstbasesink.c(2867): gst_base_sink_chain_unlocked ():
/GstPipeline:pipeline0/GstUDPSink:udpsink0:
Received buffer without a new-segment. Assuming timestamps start from 0.

And re-subscribing to the stream; as described before, the image is completely
scrambled.

Steps to reproduce:
cf. supra


Actual results:
corrupted image

Expected results:
good image

Does this happen every time?
yes

Other information:
should have taken the normal bugzilla form.


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