On 18/12/12 13:52, Ross Finlayson wrote:
No. As you can see from the "MPEG2TransportUDPServerMediaSubsession"
implementation, a new "MPEG2TransportStreamFramer" is created (and
used as the data source) each time "createNewStreamSource()" is called
- i.e., each time we start reading from the in
> I have a hunch at this point that the TransportStreamFramer is not being
> reinitialized when a new client arrives
No. As you can see from the "MPEG2TransportUDPServerMediaSubsession"
implementation, a new "MPEG2TransportStreamFramer" is created (and used as the
data source) each time "creat
On 18/12/12 11:20, Ross Finlayson wrote:
Unfortunately I wasn't able to reproduce your problem at all. I ran
"testMPEG2TransportStreamer" to continuously stream a Transport Stream
file via multicast, and also ran "testOnDemandRTSPServer" to receive
this multicast stream, and use it as input fo
Unfortunately I wasn't able to reproduce your problem at all. I ran
"testMPEG2TransportStreamer" to continuously stream a Transport Stream file via
multicast, and also ran "testOnDemandRTSPServer" to receive this multicast
stream, and use it as input for a unicast RTSP server. I then kept runn
On 17/12/12 13:53, Ross Finlayson wrote:
First, I'll try to look into exactly what's happening. If there's a
bug in the supplied LIVE555 code, then I'll try to fix it.
Thanks Ross, I appreciate this greatly.
I have done a little further investigation myself and thought I'd share
it with yo
> I have just noticed something - when the first client connects, there is an
> IGMP membership report issued to join the group I have specified for any
> sources.
>
> However, when that first (and only) client tears down the session, there is
> no IGMP membership report for the 'Leave'.
That'
On 17/12/12 12:18, Ross Finlayson wrote:
If you do this, then, yes, the input source object will get closed
(and its destructor called) whenever the last RTSP client leaves.
This is the proper behavior, because we want the input source to be
closed when noone is requesting its data. (Similarl
On 17/12/12 12:18, Ross Finlayson wrote:
Since the "testOnDemandRTSPServer" demonstrates how to stream from
*files* to (unicast) clients, it does not 'demonstrate' multicast to
unicast RTSP relaying at all. Therefore, you must have modified the
supplied application's code in some (unspecified)
> I have been experimenting with a multicast to unicast RTSP relay, as
> demonstrated in testOnDemandRTSPServer.
Since the "testOnDemandRTSPServer" demonstrates how to stream from *files* to
(unicast) clients, it does not 'demonstrate' multicast to unicast RTSP relaying
at all. Therefore, you
