> Recomputing the frame specific header offset as in the following > patch before reusing the overflow data seems to avoid the issue: > > diff -Naurdp live/liveMedia/MultiFramedRTPSink.cpp > live.fixed/liveMedia/MultiFramedRTPSink.cpp > --- live/liveMedia/MultiFramedRTPSink.cpp 2016-04-21 20:56:32.000000000 > +0200 > +++ live.fixed/liveMedia/MultiFramedRTPSink.cpp 2016-05-15 > 21:57:44.423448155 +0200 > @@ -201,6 +201,10 @@ void MultiFramedRTPSink::buildAndSendPac > void MultiFramedRTPSink::packFrame() { > // Get the next frame. > > + fCurFrameSpecificHeaderPosition = fOutBuf->curPacketSize(); > + fCurFrameSpecificHeaderSize = frameSpecificHeaderSize(); > + fOutBuf->skipBytes(fCurFrameSpecificHeaderSize); > + > // First, see if we have an overflow frame that was too big for the last pkt > if (fOutBuf->haveOverflowData()) { > // Use this frame before reading a new one from the source > @@ -214,9 +218,6 @@ void MultiFramedRTPSink::packFrame() { > // Normal case: we need to read a new frame from the source > if (fSource == NULL) return; > > - fCurFrameSpecificHeaderPosition = fOutBuf->curPacketSize(); > - fCurFrameSpecificHeaderSize = frameSpecificHeaderSize(); > - fOutBuf->skipBytes(fCurFrameSpecificHeaderSize); > fTotalFrameSpecificHeaderSizes += fCurFrameSpecificHeaderSize;
Gilles, Thanks for the report. (Actually, that last line "fTotalFrameSpecificHeaderSizes += fCurFrameSpecificHeaderSize;” also needs to be moved.) I’ve now installed a new version (2016.05.16) of the code that fixes this bug. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel