> 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
--- 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
