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

[Ben Rush]

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
>> complicated/impossible
>> > with codecs that don’t support this, and of course audio.
>> >
>> >
>> >
>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160707/9bb09944/attachment.html>