Nick,
The additions to the "RTCPInstance" class (to assign a RTCP "APP" packet
handler, and send an "APP" packet) look reasonable, and I'll probably add them
to the library soon.
The changes to "OnDemandServerMediaSubsession", however, don't look quite
right, and I'll need to think some more a
> Actually the delay seems to be proportional to the GOP size and I do not find
> any way to insert SPS and PPS...
Because you are not creating your 'front-end' RTSP server until you start
receiving frames from the 'back-end' server, you can easily get the SPS and PPS
NAL units - in encoded for
Actually the delay seems to be proportional to the GOP size and I do not
find any way to insert SPS and PPS...
So do you think the problem is in the RTSPClient? Do you think there is
a a way to avoid this behaviour? For me it is not a problem if we have a
latency at the beginning of the stream
might be I will do some test and let you know.
Thanks
Il 2015-01-27 13:15 Jeff Shanab ha scritto:
Since it is 1 to 2 seconds in delay which could be a "GOP" in size, Is
it possible since axis makes it optional to insert the SPS and PPS
that there is a delay getting the info necessary for th
Ross.
Attached is a patch that implements bidirectional RTCP APP
packet support between client and server.
The user is able to send an APP packet by calling
RTCPInstance::sendAppPacket() from the client or
OnDemandServerMediaSubsession::sendRTCPAppPacket()
on the server.
APP packets can be recei
