Hi,
I have created a modified version of testMPEG2TransportStreamer which will play
out a carousel of SPTS files to a multicast address - and it works extremely
well except..
The problem that I have encountered is that the output stream contains PCR
information from the input source source
Re: [Live-devel] Play out PCR from gettimeofday rather thaHi Ross,
Thanks for your reply. You are quite right, the PCR is always more accurate
straight out of an encoder, so I have shelved that desperate idea which as it
turns out wasn't a problem anyway.
I have been inspecting the clips produ
Hi Ross,
I have been working on a DeviceSource that I'm feeding into an RTP sink
via the MPEG2TransportStreamFramer.
The DeviceSource never runs out of data to provide the framer, so it
runs for extended periods of time. What I am finding is that after a
reasonable period of operation, sudd
On 17/10/11 17:54, Ross Finlayson wrote:
Yes, but are you sure that a wrap-around is, in fact happening (and is
the cause of your problem)? A rough calculation shows that - at 10
Mbps - the "fTSPacketCount" variable (which counts 188-byte Transport
Stream 'packets') will wrap around in around 7
On 18/10/11 09:14, Tim J Shackleton wrote:
On 17/10/11 17:54, Ross Finlayson wrote:
Yes, but are you sure that a wrap-around is, in fact happening (and
is the cause of your problem)? A rough calculation shows that - at 10
Mbps - the "fTSPacketCount" variable (which counts 188-byte
Hi Ross,
I have been experimenting with a multicast to unicast RTSP relay, as
demonstrated in testOnDemandRTSPServer.
A behaviour I have noticed, is that the first client connects and
receives the stream correctly, and all subsequent connections do too -
they can SETUP, PLAY and TEARDOWN to
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)
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 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
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
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
11 matches
Mail list logo
