[Bug 659915] New: MP2T RTP payloader rejects buffers exceeding MTU

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Sep 22 23:34:17 PDT 2011


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

           Summary: MP2T RTP payloader rejects buffers exceeding MTU
    Classification: Platform
           Product: GStreamer
           Version: 0.10.32
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mpaklin at hotmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Is RTP payloader element supposed to handle buffers that exceed their
configured MTU?
I thought that it should - it uses GstAdapter for that. However for some reason
buffers that are larger than the MTU are outright rejected on input.

A simple test to confirm it shows

gst-launch filesrc blocksize=20000 location=test.ts ! rtpmp2tpay mtu=10000 !
fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

** (gst-launch-0.10:5332): CRITICAL **: file
..\..\..\Source\gstreamer\libs\gst\base\gstadapter.c: line 450: assertion `
size > 0' failed Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 5456312000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...


While changing block size from 20000 to 2000 works just fine.

gst-launch filesrc blocksize=2000 location=test.ts ! rtpmp2tpay mtu=10000 !
fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 3134179000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...


The cause for this is in gst_basertppayload_is_filled(), which does the
following
  if (size > payload->mtu)
    return TRUE;
Claiming that the payload is "full" because the input size exceeds MTU. This
does not look right to me, but the check is obviously intentional.
The fact that the payload is full triggers the flushing, which results in an
attempt to send an empty payload and that is the root cause the assert shown
above.

The question that I have - is this behavior by design?
Do I expect it to do something that it is not designed for?

The test was done with the same results on Fedora Core 15 (0.10.32) and Windows
(0.10.28).

Regards,
-- Max Paklin.

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


More information about the gstreamer-bugs mailing list