[Live-devel] Is there a mechanism for telling a client to switch streams?

Thu Jul 7 10:32:16 PDT 2016

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 you're "invisibly" switching between streams of
different 
rates. The client isn't aware of this.

>>> Ben Rush <ben at ben-rush.net> 07/07/16 6:42 PM >>>
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 <jshanab at jfs-tech.com> wrote:

> 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 put new stream URIs etc.
>
>
> On Thu, Jul 7, 2016 at 4:32 AM, Ralf Globisch <rglobisch at csir.co.za>
> wrote:
>
>> 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 using live555 with a bit of
>> effort.
>> In the system we developed we have live encoded video at multiple
>> qualities/rates and incoming RTCP reports determine which quality is
>> streamed to each client.
>>
>> There may be other ways of doing this, but for us the trick was to
have
>> a DeviceSource per client
>> (you need to set the reuseFirstSource to false in the
>> OnDemandServerMediaSubsession).
>> If you then have some shared buffers that stored the video of
multiple
>> qualities,
>> each device source can store which buffer it is currently pulling
video
>> from.
>> The more challenging part for me was to integrate a mechanism to
respond
>> to the RTCP reports.
>>
>> > ...and back to the latency concern: since these are nurses watching
>> webcam
>> feeds, even if there is a slight blip when jumping streams, we would
>> prefer
>> that to a stream being behind by a couple seconds (at most). Our
prefer
>> is
>> sub-second latency. So the transition being "smooth" isn't probably
as
>> crucial as I had lead you to believe.
>>
>> Sub-second is really hard, but in my experience this is more of a
>> client/play-out/player challenge.
>> There is no delay on the server side as you can stream each incoming
>> frame immediately.
>> You do need to consider how you intend to switch from one stream to
>> another:
>> - You'll need to wait for the next IDR in the target quality stream
>> (unless you don't mind artifacts), so how often are you going
>> to have IDRs in the stream
>> - keep in mind that IDR frames are much bigger than P-frames and
>> frequent insertion of IDRs will likely have an impact on the rate of
the
>> stream
>> - Switching to a lower quality you may/will still get a short spike
in
>> rate which may or may not be a problem.
>> In any case, if you switched to another RTSP stream, you would incur
>> this overhead anyway...
>>
>> Hope that helps,
>> Ralf
>>
>> On Wed, Jul 6, 2016, 6:39 PM Jeremiah Morrill
>> <Jeremiah.Morrill at econnect.tv>
>> wrote:
>>
>> > AFAIK, there’s no built in mechanism for adaptive streaming.
>> >
>> >
>> >
>> > There are some things you can do, but may not be flexible enough. 
For
>> > instance, if you have a low-res-h264 and high-res-h264 version of a
>> video,
>> > in the server code, you could switch which file you are reading
from,
>> seek
>> > to the same point in the media and start outputting those samples.
>> You
>> > will need to make sure you send out the SPS and PPS NALs that
belong
>> to the
>> > new stream first though.  Things get a little more
>> co>> > Again, AFAIK, your best bet may be a higher level application
strategy
>> of
>> > detecting packet loss and immediately dropping to a lower bitrate
url
>> in
>> > the background until enough of your client play-through buffer is
>> ready.
>> > This won’t be seamless, but I don’t think real-time protocols and
>> adaptive
>> > streaming mesh well.  You may be better off using something that is
>> made
>> > for this, like HLS, DASH or smooth-streaming.  Those methods of
>> streaming
>> > are tuned to download chunks of media (ex 2seconds worth), and if
it
>> cannot
>> > download them faster than real-time, it will start downloading the
>> smaller
>> > bitrate chunks of media.  The way the chunks are written are
specially
>> > designed to be seamless (specially in the context of audio).
>> >
>> >
>> >
>> > -Jer
>> > _______________________________________________
>> > live-devel mailing list
>> > live-devel at lists.live555.com
>> > http://lists.live555.com/mailman/listinfo/live-devel
>> >
>>
>> --
>> This message is subject to the CSIR's copyright terms and conditions,
>> e-mail legal notice, and implemented Open Document Format (ODF)
>> standard.
>> The full disclaimer details can be found at
>> http://www.csir.co.za/disclaimer.html.
>>
>> This message has been scanned for viruses and dangerous content by
>> Mail
>>
>> --
>> This message is subject to the CSIR's copyright terms and conditions,
>> e-mail legal notice, and implemented Open Document Format (ODF)
standard.
>> The full disclaimer details can be found at
>> http://www.csir.co.za/disclaimer.html.
>>
>> This message has been scanned for viruses and dangerous content by
>> MailScanner,
>> and is believed to be clean.
>>
>> Please consider the environment before printing this email.
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>

-- 
This message is subject to the CSIR's copyright terms and conditions,
e-mail legal notice, and implemented Open Document Format (ODF)
standard. 
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by
MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.