> Thanks. I have gotten it to crash 4 or 5 times now and in all cases the
> Packet is in varying states of destruction. The previous observation about
> max packet size was not repeatable. This points to a race condition.
Note that a 'race condition' is unlikely, because each "TaskScheduler" ru
] On Behalf Of Ross Finlayson
Sent: Tuesday, March 12, 2013 8:54 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Access violation in ReorderingpacketBuffer::freepacket
Unfortunately you're probably going to track this down yourself, unless you can
get the cr
Unfortunately you're probably going to track this down yourself, unless you can
get the crash to happen with the "testRTSPClient" demo application.
However, you mentioned before that your crash happened after you introduced a
"new brand of camera", so you might want to begin by investigating wha
I am trying to solve a crash in my code that shows up at the line indicated in
MyultiFramedRTPSource.cpp from the 2013.03.07 livee555 code. I had this same
issue with the 2012.02.29, so I updated. When I inspected the packet before the
update, it was always the fBuf value that was 0xddd but
