The crashes are very consistent. Not the frequency, but the location. When
they occur, 602 is always the last message printed. I've attached an output
example. Judging by the callstack it almost looks to me like the printf
would be the cause, but the same thing happens if I remove the debug output,
> The crashes are very consistent. Not the frequency, but the location. When
> they occur, 602 is always the last message printed. I've attached an output
> example. Judging by the callstack it almost looks to me like the printf would
> be the cause, but the same thing happens if I remove the de
> I would like to know if really there isn't any liveness timeout control in
> the backend part. Otherwise, it would be very helpful that you describe which
> control method are you using
Once the 'back-end' connection to the proxied stream has been established (as a
result of a successful "DES
Hello
I've been studying the behaviour of the backend liveness mechanism,
implemented in ProxyRTSPClient::sendLivenessCommand, and it seems that
there is no "timeout" to check if the liveness command response is
received. Sometimes the liveness command is sent but no response is
received, and
> FramedSource* H264LiveServerMediaSubsession::createNewStreamSource(unsigned
> /*clientSessionId*/, unsigned& estBitrate) {
> estBitrate = 1; // kbps, estimate
> // Create the video source:
>H264LiveStreamFramedSource* liveFramer =
> H264LiveStreamFramedSource::createNew(envir(),liveBu
If I write the read operations to a file. And the write operations to another
file in order to play them with a video player such as the ffplay. I get the
following outputs:
When I'm using a Ring buffer and I read fMaxSize bytes I get:
The doesn't show any error. That is expected because I'm not
>First, I assume that you have are feeding your input source object (i.e., the
>object that delivers H.264 NAL units) into a >"H264VideoStreamDiscreteFramer"
>object (and from there to a "H264VideoRTPSink").
I did the H264LiveServerMediaSubsession based on the
H264FileServerMediaSubssesion.
I'm
On 01/23/2013 01:27 AM, Ross Finlayson wrote:
We applied a fix to the StreamReplicator to decrease the
fNumDeliveriesMadeSoFar
variable if the replica being deactivated was also receiving a frame.
Ugh. I'm not thrilled by this hack, but right now I don't see a better
solution, so I've gone ahe
On 01/22/2013 09:51 PM, Ross Finlayson wrote:
Yes, I agree. In the next version of the software, this piece of code -
in "FileSink::afterGettingFrame()" - will become:
if (fOutFid == NULL || fflush(fOutFid) == EOF) {
// The output file has closed. Handle this the same way as if
the inp
