Fixing "The total received frame size exceeds the client's buffer size"

[Jan Ekholm]

Hi,

So I see the error below in my code that works like a proxy. It receives a stream from a remote
camera, optionally does some magic with it and then multicasts it onwards. The multicasting is
done using a PassiveServerMediaSubSession, H264VideoRTPSink and H264VideoStreamFramer
in addition to what MediaSubsession->initiate() sets up. I see a lot of:

MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (693). 1023 bytes of trailing data will be dropped!
MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (794). 959 bytes of trailing data will be dropped!
MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (490). 1329 bytes of trailing data will be dropped!
MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (1269). 685 bytes of trailing data will be dropped!

The final recipient does not get any data (tested with testRTSPClient).

If I change the H264VideoStreamFramer to a H264VideoStreamDiscreteFramer then I see none
of the above errors and then testRTSPClient gets data, but it is not playable by, say, VLC.
If I have openRTSP save the stream and then stream the saved file with testH264VideoStreamer,
then I get nothing streamed at all. So the data seems corrupt somehow.

Anyway, how are the buffers *really* set? I've set OutPacketBuffer::maxSize to all kinds of huge
values, even in the RTPSink code, but that has no effect. The buffer handling is a little bit
clumsy, if I may be honest. Lots of email threads say to set the buffer size using some
bufferSize parameter to the sink (the error is from a source) or use OutPacketBuffer::maxSize,
but none works.

[Ross Finlayson]

Post by Jan Ekholm
If I change the H264VideoStreamFramer to a H264VideoStreamDiscreteFramer

Yes, you MUST do this, because your input source (from the RTSP client's "H264VideoRTPSource") consists of a sequence of discrete NAL units, rather than an unstructured byte stream. I.e., you MUST feed your RTSP client "MediaSubsession"s "readSource()" into a "H264VideoStreamDiscreteFramer", NOT a "H264VideoStreamFramer".

Post by Jan Ekholm
then I see none
of the above errors and then testRTSPClient gets data, but it is not playable by, say, VLC.

That's because your "H264VideoRTPSink" does not know the H.264 SPS and PPS NAL units for the stream.

To fix this, create your "H264VideoRTPSink" using one of the "createNew()" versions that take the SPS/PPS NAL units as parameter. E.g.
H264VideoRTPSink::createNew(envir(), rtpGroupsock, 96, clientMediaSubsession.fmtp_spropparametersets());
I.e., in this case you're taking the encoded SPS/PPS NAL unit information that your RTSP client already got from the downstream server (camera).


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

[Jan Ekholm]

Post by Ross Finlayson

Post by Jan Ekholm
If I change the H264VideoStreamFramer to a H264VideoStreamDiscreteFramer

Yes, you MUST do this, because your input source (from the RTSP client's "H264VideoRTPSource") consists of a sequence of discrete NAL units, rather than an unstructured byte stream. I.e., you MUST feed your RTSP client "MediaSubsession"s "readSource()" into a "H264VideoStreamDiscreteFramer", NOT a "H264VideoStreamFramer".

Post by Jan Ekholm
then I see none
of the above errors and then testRTSPClient gets data, but it is not playable by, say, VLC.

That's because your "H264VideoRTPSink" does not know the H.264 SPS and PPS NAL units for the stream.
To fix this, create your "H264VideoRTPSink" using one of the "createNew()" versions that take the SPS/PPS NAL units as parameter. E.g.
H264VideoRTPSink::createNew(envir(), rtpGroupsock, 96, clientMediaSubsession.fmtp_spropparametersets());
I.e., in this case you're taking the encoded SPS/PPS NAL unit information that your RTSP client already got from the downstream server (camera).

With those two changes it works. Thank you for the help. There is btw no H264VideoRTPSink::createNew() version that takes
the arguments you mention, you need to add the profile-level-id too, but it seems to work ok by using the value from:

unsigned int profileLevelId = m_subsession->attrVal_int( "profile-level-id" );

[Ross Finlayson]

Post by Jan Ekholm
With those two changes it works. Thank you for the help. There is btw no H264VideoRTPSink::createNew() version that takes
the arguments you mention, you need to add the profile-level-id too

No, you're using an old version of the code. You should upgrade!


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

[Jan Ekholm]

Post by Ross Finlayson

Post by Jan Ekholm
With those two changes it works. Thank you for the help. There is btw no H264VideoRTPSink::createNew() version that takes
the arguments you mention, you need to add the profile-level-id too

No, you're using an old version of the code. You should upgrade!

Aha, I see that the new version has removed the parameter. It was a bit redundant.
Are there any changelogs for changes like these?

[Ross Finlayson]

Post by Jan Ekholm
Are there any changelogs for changes like these?

http://www.live555.com/liveMedia/public/changelog.txt


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/