Actually, the call to AMRDeinterleaver::doStopGettingFrames() does
not ensure that the reception is stopped in every case. Sometimes
the fNeedAFrame attribute can be set to true when the input source
is still waiting for some RTP packet.
The rewritting of the function AMRDeinterleaver::doStopG
Dear Ross,
> The call to Medium::close(subsession->sink);
> in "subsessionAfterPlaying()" should be causing
> AMRDeinterleaver::doStopGettingFrames()
> to get called, and that should in turn be stopping the reception (and
> thus handling) of any more AMR/RTP packets.
Actually, the call to AMRDei
Hoping it can be helpful
I see what is happening to cause the crash, but unfortunately I don't
understand how it can be happening.
The call to
Medium::close(subsession->sink);
in "subsessionAfterPlaying()" should be causing
AMRDeinterleaver::doStopGettingFrames()
to get called
Dear Ross
> Are you sure that the crash can still occur, even if you omit the "-Q" option?
Unfortunately, yes it does. Please find below the log end generated from the
following command "OpenRTSP.exe -d 10 when the crash occurs. The call
stack is the same as the one I provide you before:
Recei
> 1/ What command-line arguments are you giving to "openRTSP"
(apart from the "rtsp://" URL)?
I'm using options "-Q -d x" for the test
where x is a duration which is smaller than the full length of the
stream. A change on the duration parameter has no impact on the
issue.
Are you sure that t
Dear Ross,
> 1/ What command-line arguments are you giving to "openRTSP" (apart from the
> "rtsp://" URL)?
I'm using options "-Q -d x" for the test
where x is a duration which is smaller than the full length of the stream. A
change on the duration parameter has no impact on the issue.
> 2/ Does
The call stack helps a little, but unfortunately still doesn't nail
down the problem for me.
A couple more questions:
1/ What command-line arguments are you giving to "openRTSP" (apart
from the "rtsp://" URL)?
2/ Does the crash happen for streams that contain other kinds of
audio, or just thos
Dear Ross
> This is helpful, but still not quite enough information, unfortunately. The
> closing of the audio subsession's stream *should*
> be stopping any additional processing related to the audio stream, so it
> that's not happening, then that will be the bug.
> It would be nice to know e
So my question is:
Would it be possible to force the call to shutdown at the first call
of subsessionByeHandler ?
Yes, it would certainly be 'possible'. However, I'm not going to do
that, because it's not the right thing to do. It's perfectly
reasonable (though uncommon) for the server to e
Dear Ross,
Unfortunately, I can not provide you for the stream that illustrates the
problem but I
did my investigation, and I think I'm close to find the reason why openRTSP is
crashing.
Actually I'm playing two different stream simultaneously using the lastest
release of
openRTSP. One MPEG
Actually you have solved for the recursive call to "shutdown()"
issued when calling "subsessionByeHandler()" function but it seems
it is not enough.
The "subsessionByeHandler()" close some media subsession's stream
with the following line "Medium::close(subsession->sink)", which
causes some med
"LIVE555 Streaming Media - development & use"
> Copie à :
> Objet : Re: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP
>
>
> >Thanks for your reactivity. Unfortunately the new version
> >(2010.11.10) does not solve for the issue
>
> That&#x
Thanks for your reactivity. Unfortunately the new version
(2010.11.10) does not solve for the issue
That's strange. Right now I can't see how the problem could still be
happening, so without a publically-accessible stream that illustrates
the problem, I'm not going to be able to fix it right
amp; use"
> Copie à :
> Objet : Re: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP
>
>
> OK, I think I figured out the problem, and have installed a new
> version (2010.11.10) of the "LIVE555 Streaming Media" code that
> should, I think, fix it. (N
OK, I think I figured out the problem, and have installed a new
version (2010.11.10) of the "LIVE555 Streaming Media" code that
should, I think, fix it. (Note that this was a problem only with the
"openRTSP" application, not with our RTSP client code in general.)
--
Ross Finlayson
Live Networ
er is not publically-accessible.
I can give you a capture file and the log file with debug data for investigation
Regards,
David
> Message du 09/11/10 à 20h36
> De : "Ross Finlayson"
> A : "LIVE555 Streaming Media - development & use"
> Copie à :
Thanks for the report.
Does the crash still happen if you omit the "-Q" option?
Can you post a (publically-accessible) "rtsp://" URL of a stream that
illustrates the problem?
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-dev
Dear All,
When launching the following command OpenRTSP.exe -Q -d 15 , the
OpenRTSP application
get crash every time I get the following protocol sequence at the end of the
streaming session
client -> serveur RSTP TEARDOWN
serveur -> client RTP
serveur -> client RTP
serveur -> client
18 matches
Mail list logo
