[Live-devel] Increasing video latency for RTSP client

[Sergio Basurco]

Sorry, the last message was cut.

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.

@Jeff (or anyone listening)
... 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?

I'm on windoze.

El 25-Nov-15 a las 4:06 PM, Sergio Basurco escribió:
> Hi again,
>
> So it seems I do have a problem with CPU and non-multithreaded decoding.
>
> El 23-Nov-15 a las 5:41 PM, Sergio Basurco escribió:
>> Hi Jeff,
>>
>> 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.
>>
>> For me it was that one of the sources was streaming at a very high 
>> bitrate.
>>
>> Best,
>>
>> El 23-Nov-15 a las 12:42 PM, Jeff Shanab escribió:
>>> I work with 5Mp and larger streams a lot.
>>> 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.
>>>
>>> Decoding not keeping up. (Buffers on client side, watch client 
>>> memory to see this.)
>>>    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.
>>>    Reduce quality settings on stream,
>>>    Reduce framerate.
>>>    Reduce resolution.
>>>    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
>>>    Recompile the the decoder to use multiple threads.
>>>
>>> TCP vs UDP (Buffers on server side, usually delay->loss of 
>>> framerate->skips to catch back up->repeat.)
>>>   Network delay impacts the required buffer on the camera side more 
>>> if TCP transport is chosen.
>>>   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.
>>>   It also is just plain more work, try UDP transport.
>>>
>>> On Mon, Nov 23, 2015 at 3:06 AM, Sergio Basurco 
>>> <sergio.b at coherentsynchro.com> wrote:
>>>
>>>     Hello all,
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>     Is there something within Live555 that can cause/prevent such
>>>     delays?
>>>
>>>     Thank you,
>>>
>>>     -- 
>>>     Sergio Basurco,
>>>     Coherent Synchro
>>>
>>>     _______________________________________________
>>>     live-devel mailing list
>>>     live-devel at lists.live555.com <mailto:live-devel at lists.live555.com>
>>>     http://lists.live555.com/mailman/listinfo/live-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> live-devel mailing list
>>> live-devel at lists.live555.com
>>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>> -- 
>> Sergio Basurco,
>> Coherent Synchro
>
> -- 
> Sergio Basurco,
> Coherent Synchro

-- 
Sergio Basurco,
Coherent Synchro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20151125/25018264/attachment.html>