[vlc-devel] HttpLive: ChooseSegment function

[David Glaude]

Le 12 mars 2012 15:27, Robert Forsman <bob.forsman at ericsson.com> a écrit :
> On Mon, 12 Mar 2012 08:06:33 -0400
> Jean-Paul Saman <jpsaman at videolan.org> wrote:
>
>> The HLS httplive module makes some choices that could need an option,
>> so that the user can choose where to start. For instance:
>> - start with high quality stream (or low quality stream)
>
> The super-fancy elite solution would be to memorize the bandwidth you
> got the last time you connected to a particular IP or network range.

Might not be that smart... to the best of my knowledge both Windows
Media Player and Quicktime have some smart attitude where they try to
remember wich protocole (RTP or over HTTP) and/or bandwidth
capabilities.
The thing is that you can not garantee that the network condition will
be the same between one start and another start of VLC... even for the
same destination (better use name than IP). One connection might be
over 3G while the next one is WIFI. Including an hidden state (memory
of past experience) make it hard for problem reproduction. Stateless
is best.

> A simpler alternative could be to just have an option that specifies a
> ceiling for the starting bandwidth.  You pick the highest bandwidth
> option that is <= the ceiling,

This is the way you can configure Windows Media Player and/or
Quicktime where you indentify the kind of connectivity you have
(Modem/DSL/T1/LAN/...) with an associated bandwidth. That set a limit
that you do not want Windows Media Player to go above. Else you can
configure "auto detect" where the Player does 3 small connection to
estimate your bandwidth for downloading from the publishing point and
then guess the best bandwidth for you (WMP is suppose to adapt
dynamicaly from one video stream/audio stream to another based on the
"bad" experience. I have whitness this but it is far from perfect
heuristic).

> or the lowest bandwidth available if
> none of the options are <=ceiling.

Not sure you want to autorise the use of a bandwidth above your ceiling...
Windows Media Player will happily give you audio only or 1 fps (
"image mode" =?= I frame only ) if there is no video stream with a low
enough bandwidth to fit below your ceiling.

> Once the connection is started the adaptation logic would take over and
> adjust the session to the ACTUAL bandwidth.

So what you are talking about is a "hint start bandwidth" and maybe
you want to let the user specify this (even if that could be annoying
as variable depending on connectivity). So leaving that to undefine or
zero might mean: "use your own heuristic".

I am talking about hard limit.

The theory for both Smooth Streaming and HTTP Live Streaming is that
the player is capable/suppose to do a "fast start" by starting as fast
as possible from the lowest video bitrate. That "fast start" is also
valid for "fast seeking" into the stream.

Once again, rather than to decide on one "universal" heuristic, you
may want to let the user decide on "fast start/seek" vs "good quality
always but slower start/seek".

I think there is still a lot of research to be done on heuristic for
viewing HTTP based multi-bitrate/quality video chuncked video:
SmoothStreaming (Microsoft), HLS (Apple), Dynamic Streaming  (Adobe)
and DASH (Standard).

The logic might be "shared" between all of those protocol.
The best option is to have an heuristic with parameter and try to
guess/test default value that best work.
Then without recompilation, it will be possible to adapt the behaviour
(help end-user) by setting a few parameter to non default value.

> ... unless you want to have a hard rate limit to be nice to your
> housemates.  We don't want to cripple Stan's Halo match, eh?

The user may want a hard "high" limit and a hard "low" limit.

The reason for high limit might be:
* Bandwidth cost (or fairness)
* Avoid overestimation from the heuristic
* Avoid quality oscillation.

The reason for low limit might be:
* Avoid quality oscillation
* Prefer quality against buffer overrun

Having both a low and a high let the user permit to fix a specific
bitrate version and do a raw dump of the video (for archiving and/or
transcoding). In such case, it is obvious that fixed quality is
prefered over buffer overrrun.

I hope it help. ;-)