Re: [Live-devel] RTSPClient w/significant frame loss

Just in case anyone else was actually following this thread, I thought I'd make my final post in this thread the conclusion of the matter: - Setting the packet reordering threshold time very low had a noticeable impact. I originally tried setting it to zero, but oddly my benchmarks were sligh

Re: [Live-devel] RTSPClient w/significant frame loss

I wasn't planning on contributing to this thread anymore (because I thought that I'd already said everything that I could), but you did bring up one worthwhile point: > That would seem to suggest that as soon as frame loss occurs, LIVE555 incurs > additional processing That is actually correct

Re: [Live-devel] RTSPClient w/significant frame loss

Ugh typosthis quote: > That means that in this case, LIVE555 (Step A) is consuming a maximum of > ~33ms per frame in order to achieve that frame rate. However, in the case of > adding the one decode call, which dropped frame rate down to 10fps, LIVE555 > (Step A) is consuming ~810ms total,

Re: [Live-devel] RTSPClient w/significant frame loss

Ross, I am attempting to make sense of what I am seeing, and this statement: > This is getting silly. You're doing a lot of mental 'flailing around'; yet > the answer is right in front of you: is not necessarily accurate. Up until this most recent example I provided, I reported 66% frame lo

Re: [Live-devel] RTSPClient w/significant frame loss

This is getting silly. You're doing a lot of mental 'flailing around'; yet the answer is right in front of you: > So I eliminated all memory allocation and memcpy of the 23K of data into the > new frame buffer from the receive buffer, and I was back to getting almost > zero frame loss. But as

Re: [Live-devel] RTSPClient w/significant frame loss

Hi Brad, I had done processing in afterGettingFrame() by copying the data to a Linux named PIPE on a ~300Mhz ARM based system. You can try few experiments. 1. Did you profile them time taken for memcpy in afterGettingFrame() ? 2. In every afterGettingFrame() call, instead of using the new

Re: [Live-devel] RTSPClient w/significant frame loss

Ross, Thank you for your reply. To your comments: 1. I am fairly confident the increase of the receive buffer is taking, because that change alone eliminated 100% of frame loss when the afterGettingFrame() method did nothing bug log NAL counts. I was getting near 30fps. 2. I do not think th

Re: [Live-devel] RTSPClient w/significant frame loss

> 1. I followed the FAQ's recommendations, which increased the receiveBuffer to > (VLC's recommended) 200. (Note, I also tried 40, same results as > 200, also note there are no truncated bytes). Note also that the "increaseReceiveBufferTo()" function returns the actual resulting OS

Re: [Live-devel] RTSPClient w/significant frame loss

One quick point of clarification about GOP sizeI think it is probably clear, but just in case it isn't: we are sending I-frames in our NAL 5s -- no differentials. The stream looks like this [7][8][5][7][8][5][7][8][5]... Each NAL 5 is an i-frame, 23K each. I hope that clarifies. Brad On

Re: [Live-devel] RTSPClient w/significant frame loss

Ross, Thanks for the reply. I appreciate the pointer to the additional information. I did read it and followed its advice, but in a nutshell, I'm still experiencing around 60% packet loss though doing very little processing in the afterGettingFrame() method callback in my MediaSink subclass. T

Re: [Live-devel] RTSPClient w/significant frame loss

> 1. What factors / culprits could be causing this massive frame loss? > > 2. Is there anything in the base RTSPClient or MediaSink subclasses (or > elsewhere) that can be configured to reduce frame loss? See You should also, of course,

[Live-devel] RTSPClient w/significant frame loss

Hello gang I am soldiering right along with my (now working) video processing pipeline, which constitutes pulling H.264 streaming video across the network via RTSP, and then decoding it using ffmpeg. The lion's share of my Live555 implementation resides in a RTSPClient subclass, and a Media