I'm adapting live555 to stream from a live source and using
testMPEG2TransportStreamer.cpp and
<http://www.live555.com/liveMedia/faq.html#liveInput>http://www.live555.com/liveMedia/faq.html#liveInput
as reference.
I got all necessary code to startup a RTP server and start playing
and put on my source code.
As explained on the FAQ, i substitue ByteStreamFileSource
and MPEG2TransportStreamFramer layers by the DeviceSource one.
That's correct. However, it's also a good idea to deliver - to the
"RTPSink" object - a sufficiently large chunk of MPEG Transport
Stream data to make efficient use of each outgoing RTP packet.
(Packing just a single 188-byte Transport 'packet' into each outgoing
RTP packet will work, but is inefficient.) To overcome this, either
have your 'DeviceSource' accumulate a reasonable number (usually 7)
of Transport 'packets' before delivering them, or else insert a
"MPEG2TransportStreamAccumulator" object (see, for example, the
source code in "wis-streamer": http://www.live555.com/wis-streamer/ )
Using DDD to degub a segmentation fault bug, i found thats is caused
by a call to socketErr() made by writeSocket() ( more precisely, "if
(setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL,(const char*)&ttl,
sizeof ttl) < 0)" line call).
If this is correct, then it may be caused by a bad 'socket' parameter
(perhaps a socket that has already been closed. However, I don't see
what could be causing this...
How could DeviceSource changes impact on socket issues??
Unfortunately I don't see how they could. Sorry.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
