<div dir="ltr"><div><div>Yup, libavcodec. (56.13.100)<br><br></div>Someone else here enabled the slice decoding threads, I'd end up googling it to remind myself.<br><br></div>I was kinda surprised that when I still had plenty of CPU that a single decoding thread was not enough but once I gave it some more thoiught, it makes sense. You gotta finish before the next one comes in. Once you hit the limit of the clock speed can do (remember we are using co-processors for math, gpu decoding and we have to move stuff from memory to cache to card etc.) Parallelization is the only way to get done faster. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 10:24 AM, Sergio Basurco <span dir="ltr"><<a href="mailto:sergio.b@coherentsynchro.com" target="_blank">sergio.b@coherentsynchro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Sorry, the last message was cut.<br>
<br>
The delay still appears even when only decoding a single camera. The
only program able to properly decode is VLC. So it's not a network
or hardware problem. I do believe though that the decoder cannot
keep up.<br>
<br>
@Jeff (or anyone listening)<br>
... I will get into multithreaded decoding. This might not belong
here but maybe you can redirect me to the right direction. Working
with 5MP and larger streams, did you by any chance work with Libav?
<br>
<br>
I'm on windoze.<br>
<br>
<div>El 25-Nov-15 a las 4:06 PM, Sergio
Basurco escribió:<br>
</div>
<blockquote type="cite">
Hi again,<br>
<br>
So it seems I do have a problem with CPU and non-multithreaded
decoding. <br>
<br>
<div>El 23-Nov-15 a las 5:41 PM, Sergio
Basurco escribió:<br>
</div>
<blockquote type="cite">
Hi Jeff, <br>
<br>
Thanks a lot for your input. Indeed it was CPU not keeping up.
We have had good experiences with threads dedicated for decoding
sessions with streams of even more than 5MP. Problems come up
when we have too many of these, of course there is so much you
can ask the CPU.<br>
<br>
For me it was that one of the sources was streaming at a very
high bitrate. <br>
<br>
Best,<br>
<br>
<div>El 23-Nov-15 a las 12:42 PM, Jeff
Shanab escribió:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>I work with 5Mp and larger streams a lot. <br>
</div>
This is probably not a live555 issue but there are 2
things that come to mind that the larger streams stress
without using a lot of CPU.<br>
<br>
</div>
<div>Decoding not keeping up. (Buffers on client side,
watch client memory to see this.)<br>
</div>
<div> Single threaded decoding can take more time to
decode than the duration between frames when they get
large. This can happen even with less than 50% of a
single core.<br>
</div>
<div> Reduce quality settings on stream,<br>
</div>
<div> Reduce framerate.<br>
</div>
<div> Reduce resolution.<br>
</div>
<div> Skip most or all the decoding. printing out the
framesize, timestamp and type once every 60 keyframes or
a keyframe only and see if it eliminates the delay<br>
</div>
<div> Recompile the the decoder to use multiple threads.<br>
</div>
<div><br>
</div>
<div>TCP vs UDP (Buffers on server side, usually
delay->loss of framerate->skips to catch back
up->repeat.)<br>
</div>
Network delay impacts the required buffer on the camera
side more if TCP transport is chosen.<br>
It may have to resend so it hangs on until the ACK. If
the buffer is small and gets full the camera starts to
drop frames.<br>
</div>
It also is just plain more work, try UDP transport.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 23, 2015 at 3:06 AM,
Sergio Basurco <span dir="ltr"><<a href="mailto:sergio.b@coherentsynchro.com" target="_blank"></a><a href="mailto:sergio.b@coherentsynchro.com" target="_blank">sergio.b@coherentsynchro.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
all,<br>
<br>
I'm trying to decode RTSP H264 streams, there is an IP
camera that has 5MP frames. I used to have lots of
decoding errors and this was due to the receive buffer
size. Using the increaseReceiveBufferTo(...) function I
managed to fix the decoding artifacts.<br>
<br>
Now however, I have an ever-increasing video delay, it
starts small but keeps delaying over time. I don't know
what could be causing this. The program does very little
else so I don't think the computer cannot keep up.<br>
<br>
Is there something within Live555 that can cause/prevent
such delays?<br>
<br>
Thank you,<span><font color="#888888"><br>
<br>
-- <br>
Sergio Basurco,<br>
Coherent Synchro<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
live-devel mailing list
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Sergio Basurco,
Coherent Synchro</pre>
</blockquote>
<br><span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Sergio Basurco,
Coherent Synchro</pre>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Sergio Basurco,
Coherent Synchro</pre>
</font></span></div>
<br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br></div>