Thanks for the testing. These changes will appear in the next release of the
software.
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-d
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 Transport
St
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
> If this wrap is in fact causing the issue, would you consider it a bug?
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 'packe
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
