> I would like to use live555 streaming multiple streams from one box, but each
> socket must be listen to another IP.
> Can you tell me is there a solution yet, or how can I solve that in the
> easiest way?
Yes, the easiest way to solve this is to make sure that multicast routing is
enabled on
> So, I've started to use the H264VideoStreamer class directly as you suggest
> and I get much further. However at a certain point after a number of
> successful sendRTPOverTCP calls, subsequent calls seem to fail and then
> never recover.
Your problem here is basically that you are trying to 'cra
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, November 19, 2011 2:51 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Access violation crash in rtspclient
2 adjustments to the library al
> 2 adjustments to the library allow me to tiptoe thru the call stack avoiding
> accessing destroyed or already deleted members and unwind this stack.
I'll be doing something similar to your first fix (but it most certainly will
not be using a "goto" :-)
> This gest me almost all the way out o
Hello,
I would like to use live555 streaming multiple streams from one box, but
each socket must be listen to another IP.
Can you tell me is there a solution yet, or how can I solve that in the
easiest way?
Best regards,
Gabor Molnar
from Hungary
_
I know there has in the past been requests for windows builds but windows
changes their and breaks their own build system so much, it is not worth it.
However, I use the FireBreath plugin framework
(http://www.firebreath.org/display/documentation/FireBreath+Home) and I really
like the way CMAK
2 adjustments to the library allow me to tiptoe thru the call stack avoiding
accessing destroyed or already deleted members and unwind this stack.
I do not suggest these at all, they are a hack, but it confirms for me what is
happening with the call stack.
Add an exit label with a dummy command
OK, I see what you're saying now. Yes, you're correct: There is a problem if
the RTCP "BYE" handler - called from within
"RTCPInstance::incomingReportHandler1()" - happens to delete the "RTCPInstance"
object, because we'll continue to execute the rest of the
"incomingReportHandler1()" member
> We are interested in RTP encapsulation of AAC 5.1 audio in the context of a
> European Union funded project. Current version of LIVE 555 does not support
> that.
Yes we do. We support both the receiving (using "MPEG4GenericRTPSource") and
sending (using "MPEG4GenericRTPSink") of AAC audio RT
I know that 99% of the time it is 'adjustments to' and 'missuse' that are the
problems people have with using live555, but unless they changed the way CPU's
work, we do have an issue.
(This issue is avoided in openRTSP by just exiting the process before the
access violation could hit.)
It boils
Hi Ross,
We are interested in RTP encapsulation of AAC 5.1 audio in the context of a
European Union funded project. Current version of LIVE 555 does not support
that. Is there a way that we can get help from you about this or if not what is
the best point to start?
Regards,
Huseyin
__
If your data stream arrives as a continuous buffer (its not easy to
tell where NALs start/end) use H264VideoStreamFramer, if your NALs are
separated & delivered one by one, use the
H264VideoStreamDiscreteFramer. You can cull the startcodes from the
NALs easily enough.
James
On Fri, Nov 18, 201
> The bye handler calls code resulting in Medium::Close. This ends up calling
> the destructor on the RTCP class and deletes the fKnowMembers.
Yes.
> The OnReceive is then attempted to be called
No, that shouldn't be happening, because the "RTCPInstance" destructor called
"stopNetworkReading(
13 matches
Mail list logo
