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
Stream 'packets') will wrap around in around 7 days. But anyway, if
this is a plausible occurrence, then it's probably something we
should allow for.
Fantastic. I am going to run side by side binaries, one with the
existing unsigned, and one with the u_int64_t. I have been playing
out content with a mux rate of 8,000kbit/sec and I was seeing the
problem occur after about a week and a half and by my math that seems
to agree with a calculated value of 9.3 days.
Hi Ross,
My test was thwarted by an unexpected shortage of electrons about
halfway through, but has now completed. I have run both a task based on
the current live555 source, and a task with a modified source tree using
u_int64_t side by side, playing out a loop of MPEG2 content that never
closes or ends via a DeviceSource.
The task that isn't using 64bit integers has, as expected, lost it's
mind and is spending a lot of time blocking and using every scrap of CPU
available as it tries to play out the MPEG at a ridiculously high rate.
The modified version is still working as per normal.
The only modifications I have made are as follows:
In MPEG2TransportStreamFramer.cpp, class 'PIDStatus' I have changed
lastPacketNum to u_int64_t.
In include/MPEG2TransportStreamFramer.hh I have changed tsPacketCount,
fTSPacketCount and fTSPCRCount types to u_int64_t.
Regards,
Tim Shackleton
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
