As others have noted, you shouldn’t really focus on ‘telling a client to switch
streams’; there’s no standard mechanism for this (probably for good reason).
1/ If you are streaming just to one client, then it’s better to have the
*server* adapt the parameters of the stream (e.g., based on RTCP
It seems I didn't express myself clearly enough.
In the approach I suggested a continuous valid standard-conformant RTP
stream is sent to the client,
so your existing RTSP player will be able to play back the stream. You
don't need to redirect the client
to another RTSP stream.
On the server side
In general though it appears as though there's nothing that "standard RTSP
players" respect, right? Whatever we do we will most likely need to write
out own player?
On Thu, Jul 7, 2016, 8:53 AM Jeff Shanab wrote:
> Why not add a metadata subsession then you can put whatever you like in,
> for e
Why not add a metadata subsession then you can put whatever you like in,
for example, an XML payload.
In security cameras they put motion data, analytics, dewarp parameters,
multicamera calibration etc.
Small amounts of information have also been put into the SEI But it sounds
like you want to pu
Hi Ben,
> That's why I was curious if there was a standard mechanism for telling
an rtsp client to switch to a
different stream (in the case where the server is dictating the
"adaptive" nature).
There's no standard mechanism for that as far as I know.
It is possible to implement what you want us
