[gstreamer-bugs] [Bug 607452] New: Failure to sync on rtpmp4vpay stream; sender; receiver mismatch

[GStreamer (bugzilla.gnome.org)]

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

           Summary: Failure to sync on rtpmp4vpay stream; sender;receiver
                    mismatch
    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 standardising to an RTP stream from an proprietary communcation format.

The barcosoapsrc is a wrapper around a SOAP interface that negociates the udp
address of an RTP stream.

GST_DEBUG=*barco*:5 gst-launch barcosoapsrc
location=pelco+soap://10.4.0.36:49152 ! rtpmp4vdepay ! mpeg4videoparse ! queue
! decodebin ! autovideosink

This gets the stream and decodes is as expected.

When taking this RTP stream, depayloading it as for decoding; but then
payloading it again and sending it out over the network; the resulting
payloaded stream that is recieved does not decode.

sending:
GST_DEBUG=*barco*:5 gst-launch barcosoapsrc
location=pelco+soap://10.4.0.36:49152 ! rtpmp4vdepay ! mpeg4videoparse ! queue
! rtpmp4vpay ! udpsink host=226.226.226.22 port=2266

receiving:
gst-launch udpsrc uri=udp://226.226.226.22:2266 caps="application/x-rtp,
clock-rate=(int)90000" ! queue ! rtpmp4vdepay ! queue ! decodebin !
autovideosink

veryfing with:

gst-launch udpsrc uri=udp://226.226.226.22:2266 caps="application/x-rtp,
clock-rate=(int)90000" ! queue ! rtpmp4vdepay ! fakesink dump=1
and 

gst-launch udpsrc uri=udp://226.226.226.22:2266 caps="application/x-rtp,
clock-rate=(int)90000" ! queue ! rtpmp4vdepay ! mpeg4videoparse ! fakesink
dump=1

seems to indicate that mpeg4videparse is blocking data (while it has been
parsed on the recieve side; directly from the encoder, see first command line).

However, when starting the reciever *before* the sender; data is being received
and decoded (with mpeg4videoparse).

Looks similar to the NAL 7/8 packets in H264.

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