Hi to all,
I wrote a custom shared memory source. it inherits from FramedSource.
The shared memory is synchronized via Linux semaphores (simple
producer-consumer algorithm), but since I didn't want to subclass
TaskScheduler, I still use a "dummy" file descriptor-based communication
with live555. In pseudocode:
~~~Client (without live555):
wait on semaphore_empty (blocking)
copy frame in shared memory
write one byte in a dedicated FIFO (this should wake up live555'
TaskScheduler select())
post on semaphore_fill
~~~Server (with live555, in SharedMemSource::incomingPacketHandler1())
[turnOnBackgroundReadHandling is called in doGetNextFrame]
wait on semaphore_fill (blocking)
read one byte from the dedicated FIFO (to flush the FIFO buffer)
copy frame from shared memory
post on semaphore_empty
This works. Altought the blocking wait on semaphore_fill might make you
wonder, the client wakes up my source with the write() in the dedicated
FIFO and immediately posts on semaphore_fill, so the server almost never
waits, and if it does, it doesn't block for a really small time.
The problem is that, after a while (1 or 2 hours usually), the client
does its cycle and the server never wakes up. It *doesn't* get stuck on
the wait, I checked: it simply never wakes up, as if the client write()
was lost (but it *always* succeed on the client side) or the select()
didn't wake up even if the write succeeded.
I would like to emphasize this: the server *never* gets stuck forever on
its wait. When it gets stuck, the client is one frame ahead of the
server, incomingPacketHandler1() simply is never called anymore and the
wait is not even reached.
At this point, I have two questions:
1) In your knowledge, can the select() not wake up even if a write() on
the other side succeeded? If it can, how is it possible? Note that the
system is an embedded ARM processor, and it could get quite busy while
acquiring and streaming video.
2) First thing I do in SharedMemSource::incomingPacketHandler1() is to
check for isCurrentlyAwaitingData(). If it's false, I simply return
before doing all the cycle, and this happens quite often. What's the
meaning of isCurrentlyAwaitingData()? I mean, if the select() in
TaskScheduler returned, some data must be present on the
file/fifo/socket. How is it possible that the select() did return but
still there's no data available? I'm getting really confused on this.
Thanks and regards,
Cristiano Belloni.
--
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
bell...@imavis.com <mailto://bell...@imavis.com>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
