[foms] Proposal: adaptive streaming using open codecs

[Andy Berkheimer]

Hello from YouTube land.  Most of my commentary on this thread has already
been said, though I'm happy to go into more detail about what I specifically
like / don't like if that would be helpful?

There is one point I hadn't seen raised yet:

On Wed, Oct 20, 2010 at 8:24 AM, Jeroen Wijering
<jeroen at longtailvideo.com>wrote:

>
> >> * *droppedFrames*: The total number of frames dropped for this playback
> session (read-only).
> >> * *decodedFrames*: The total number of frames decoded for this playback
> session (read-only).
> >
> > Yep, what Firefox has. Is this the metric you prefer? MY guess is that
> you'd be more interested in the performance around now (a window of X
> seconds) than globally, especially when the video stream has switched from
> low to high quality or vice versa.
>
> This metric is more "raw", so there's more to do with it. For example, I
> could setup my own sliding window and calculate the droppedFPS with it, e.g.
> for blacklisting heuristics with longer half-life times. I could also ignore
> sudden spikes in the total number of droppedFrames (probably CPU was shortly
> working on something else), etc.
>
> In most cases, both droppedFPS and currentFPS would be enough (compare;
> then blacklist if more than X% is dropped), so we could use this instead.
> Chris Double then has to update his patch though [1] ...


One issue we've run into is that there are often two very different reasons
for a video frame to be dropped in a client pipeline:
1) shedding work to maintain timeliness of video rendering
2) optimization when the video window is completely obscured or hidden - in
a background tab, etc.

Differentiating these cases is important for any adaptive heuristics as well
as monitoring and understanding aggregate client performance behavior.  If
#2 counts as a droppedFrame then quality problems are over-reported and
switching is likely to be too aggressive, if #2 is not counted as a
droppedFrame then problems are underreported and switching is likely to be
too conservative.  Which calls out for a third counter - hiddenFrames?

Also prefer to have these metrics expose the raw counter, rather than a more
nebulously defined instantaneous rate.  More flexibility, as Jeroen points
out.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101027/9133582f/attachment.htm