On Mon, May 16, 2016 at 02:25:40PM -0700, Ross Finlayson wrote:
> > I did not move that line because I thought that the frame specific
> > header size had already been accounted for by the same code before
> > the overflowing frame had been retrieved from the source.
>
> Ah yes, you’re right. I’l
> I did not move that line because I thought that the frame specific
> header size had already been accounted for by the same code before
> the overflowing frame had been retrieved from the source.
Ah yes, you’re right. I’ll fix that next.
Ross Finlayson
Live Networks, Inc.
http://www.live555.co
On Mon, May 16, 2016 at 01:07:13PM -0700, Ross Finlayson wrote:
> > 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/MultiFramed
> 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:
Hi,
Some time ago (actually, in 2013):
http://lists.live555.com/pipermail/live-devel/2013-December/017843.html
I reported an issue with Vorbis RTP Sink: valgrind would whine that
the sendto syscall was accessing some uninitialized data, and the
RTSP clients (vlc, using live555 for RTP depacketiza
