> 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
We noticed that a VLC release around two(?) years ago changed
the way audio/video is prioritised/synced which primarily affects
streaming (i.e. not file playout) in the way you described.
Previously audio had always played smoothly.
This more than likely has nothing to do with live555. You can v
2015-12-06 11:44 GMT+01:00 Ross Finlayson :
> What sort of time synchronization problem do you have when you play your
> stream using VLC (as a client)? Does audio/video start out in sync, but
> eventually
> drift out of sync? Or is VLC unable to play your audio+video stream at all?
VLC smoothly
> I set the presentation time of each audio and video frame to
> gettimeofday() value, so I suppose it is correct and aligned to 'wall
> clock'. I also verified these values in RTPSink layer and they are
> exactly the same as I set.
>
> I'm wondering what could be wrong in this kind of presentatio
2015-12-04 23:25 GMT+01:00 Ross Finlayson :
> If you are not getting proper audio/video synchronization at your receiver
> (e.g., VLC),
> then you ***must not*** be setting the presentation times correctly.
I set the presentation time of each audio and video frame to
gettimeofday() value, so I su
> The fTimestampBase
> is set as the random value, so there is no possibility to have similar
> timestamps in both subessions.
That is totally correct. Different media streams have different RTP timestamps
(perhaps with different timestamp frequencies, as is the case here), and the
mapping from
