> We understand that there is extra complexity, but we have all of that working
> and feel like it’s a better solution for us. It seems like the Live555
> libraries have the majority of the code necessary to make this work, and
> indeed I can push media to a server using VLC which I thought use
--- Begin Message ---
>
> No, we don’t support that model of communication (‘pushing’ media to a
> server), because it’s excessively complex, and non-standard.
The proxying solution doesn’t work if the encoder is behind NAT firewalls,
however, unless you add a non-standard extension to connect
> We’ve started the implementation of our own Source classes for both video and
> audio, and the workflow to connect them to the proper RtpSink classes as
> described in the FAQ and examples. We don’t see any examples that push to a
> server using RTSP
No, we don’t support that model of commun
> We are working on application, which is based on IOS platform
Note also that - as a consequence of the LGPL license (which the “LIVE555
Streaming Media” code uses - you cannot use this code in any iOS app that’s
distributed via Apple’s ‘app store’. See
http://live555.com/liveMedia/faq.html#c
--- Begin Message ---
We have a device that currently publishes a live RTP stream over UDP to a media
server. It has its own RTSP implementation right now, which goes through the
ANNOUNCE, SETUP, RECORD workflow to retrieve the UDP ports from the server,
then sends RTP frames using another libr
Ross,
I've been seriously poking at my (mostly) working MPEGTS FramedSource
and OnDemandMediaSubsession derivatives for my MPEGTS RTSP server. I
posted here
(http://lists.live555.com/pipermail/live-devel/2015-June/019441.html) a
few days ago from my gmail address (sorry about that). I quickly
> Thanks, but it looks like one was missed (I’ve only tried liveMedia, not the
> other components yet).
> Adding:
> friend class RTSPServer;
> to:
> GenericMediaServer::ClientConnection
> seems to fix the “cannot access protected member”.
Grumble… I can do this, but in principle a base class lik
And here’s the full patch that allows it to compile here:
Removing the cast on the background handler functions allowed it to compile,
but I expect using a fully qualified reference to the static function would do
the same.
I also see that RTSPServer::RTSPClientConnection includes
incomingReques
Thanks, but it looks like one was missed (I’ve only tried liveMedia, not the
other components yet).
Adding:
friend class RTSPServer;
to:
GenericMediaServer::ClientConnection
seems to fix the “cannot access protected member”.
The “illegal operation on bound member function expression” still persis
> I don’t have the ability to compile on other architectures so I can’t see if
> this is a Windows/nmake issue or otherwise.
Yes, I think it’s a Windows-specific issue; apparently this compiler is more
anal-retentive than others.
I’ve updated the code (adding some extra “friend” declarations to
Hi Ross.
I've just tried compiling the liveMedia library (on Windows using nmake) and
it’s failing with these errors (watch for wrapping):
RTSPServer.cpp(1268) : error C2276: '&' : illegal operation on bound member
function expression
RTSPServer.cpp(1268) : error C2660: 'TaskScheduler::setBackg
11 matches
Mail list logo
