> 2/ Since I am sinking with UDP multicast, there is no concept of "a client
> establishing a connection. As such would I need to send out the prop-sets
> (VPS+SPS+PPS) before sending out every incoming frame or every i-frame or at
> some kind of interval as a background handler ?
I suggest se
Thank you for your response.
1/ Re: your response
Re: a
I just want to clear the air on the misunderstanding/miscommunication reg.
modification of supplied code. I did not modify the supplied source code. I
took testRTSPClient.cpp and made my own version of it, which follows the
example of func
> Re#2.
> a> In trying to implement the FAQ recommendation of using
> fmtp_spropvps(),sps,pps and then passing the values to
> parseSPropParameterSets, I tried to follow the code in
> H265VideoRTPSink::auxSDPLine and createNew functions and removed the parts of
> code that look for a fragmente
properly, I may not need the MPEGTS wrapper in
order for a VLC client to be able to play it. Is my understanding correct ?
Re: licensing terms. Yes. The end product for deployment will have subclasses
to any changes to the live555 code. For example, I subclass mediasession to
create a new obje
> Questions:
> 1. Am I pursing the right strategy to accomplish my final objective - namely,
> playing MPEGTS stream over multicast UDP, the video source being the proxy
> server.
Perhaps. An alternative approach, of course, would be for your RTSP client
application to read directly from the s
I am working on a project that uses the live555 proxy server to receive 4K
video streams from a H.265 IP camera sent over a radio link to efficiently
redistribute them over RTSP. I am able to connect a VLC client and play the
RTSP stream from the proxy server. An additional customer requirement
