> On Oct 30, 2017, at 2:35 PM, Mark Woodard wrote:
>
> OK. So testRelay is a good starting basis.
Well, that depends on how the source stream is generated.
If the source stream comes from a RTSP server - i.e., is accessed using a
“rtsp://“ URL - then you wouldn’t use “testRelay” at all. Ins
> On Oct 30, 2017, at 1:48 PM, Mark Woodard wrote:
>
> OK, Ross, let me rephrase the question.
>
> Does the testRelay example accept RTP packets from a source and pass them on
> unchanged to the destination?
The “testRelay” demo application - as written - receives UDP packets (from a
multic
> On Oct 30, 2017, at 11:14 AM, Mark Woodard wrote:
>
> My source is the Milestone ONVIF Bridge, which I believe was built using
> Live555 libraries. It deals with RTP over UDP.
I have no idea whether or not the "Milestone ONVIF Bridge” was built using the
LIVE555 libraries. But if it’s a R
> Anyway, once I created the socket on the heap, my program worked with no
> errors. However, the code at the destination address does not recognize
> anything playable. I was under the impression that the testRelay sample was
> relaying the data as RTP/UDP. I'm pretty sure that's what the desti
> I have adapted the testRTSPClient sample to receive a stream from my UDP
> source. Now I need to relay the data to another UDP address.
Is your ‘UDP source’ a RTP/UDP source, or a raw-UDP source. If it’s the
former, then why not also relay the data as RTP/UDP packets (and why not use
the “LI
