[Live-devel] Opportunity for unpredictable behaviour in MPEG2TransportStreamFramer

[Tim J Shackleton]

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