RTP payloader rejects buffers exceeding MTU

[Max Paklin]

Hello,

Is RTP payloader elements 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 the
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).
Please advise.

Thanks,
-- Max.