Seems it is CPU resource limitation. Is it possible to synchronize audio and
video tracks after such CPU resource limitations, during record process. I
mean, how to determine that desynchronisation happened in playing process?
Maybe some RTCP packet data information can help or something else?
> any client for each camera runs in a separate thread
>
Note that you don't need to do this. Instead, it is possible (and, in fact,
much easier) to have multiple RTSP clients running in a single thread, using a
single event loop. Note how the "testRTSPClient" code does this.
> Valgrind tell
> Brickcom WCB-100Ap LIVE555 Streaming Media v2009.01.26
Is this running the most up-to-date version of Brickcom's firmware?
One of the implications of the LGPL is that Brickcom must, upon request,
upgrade their firmware to use the latest version of the "LIVE555 Streaming
Me
Dear All,
I'm using Live555 to realize a C++ RTPS client for IP cameras. I'm using most
of the testRTSPClient code.I used Poco library and Poco::Thread class too.In
other words any client for each camera runs in a separate thread that owns his
instance of Live555 objects (any thread uses an in
> If I use VLC to capture the rtsp stream and save to disk, this then plays
> back without any problems and is smooth so I'm not quite sure what is going
> on.
> Any ideas on where I should look to solve the problem?
The code for the "QuickTimeFileSink" class - which is what we use to record
".
Thanks for the note. I'll likely add such an option to "openRTSP" sometime in
the future. (It's not a high priority, though; I'd prefer that people fix
their servers.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing