> On Dec 11, 2015, at 12:46 AM, Piotr Piwko
> wrote:
>
> 2015-12-10 11:12 GMT+01:00 Ross Finlayson :
>> LIVE555-based applications use a single-threaded event loop (i.e., using
>> events - rather than threads - for concurrency).
>> See http://live555.com/liveMedia/faq.html#control-flow
>
> So
2015-12-10 11:12 GMT+01:00 Ross Finlayson :
> LIVE555-based applications use a single-threaded event loop (i.e., using
> events - rather than threads - for concurrency).
> See http://live555.com/liveMedia/faq.html#control-flow
So probably, this is the reason. I notice that if I stream only audio
> I'm wondering how live555 handles two subsessions? Is getting each
> frame done in one execution thread, or each subsession has it's own
> dedicated thread?
LIVE555-based applications use a single-threaded event loop (i.e., using events
- rather than threads - for concurrency). See
http://liv
2015-12-07 5:53 GMT+01:00 Ralf Globisch :
> try to increase VLC's network jitter buffer.
I did it and unfortunately there is no improvement. I've also checked
other receivers (mplayer, ffplay) and behavior is very similar.
> If the time stamps are far apart, the issue is on the server side or net
