W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 12399] <video> Expose statistics for media elements

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Oct 2011 09:25:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RIdFx-0003E0-Cf@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399

--- Comment #22 from Philip Jägenstedt <philipj@opera.com> 2011-10-25 09:25:11 UTC ---
How does one measure the number of bytes going into the demuxer in a way that
makes sense cross-browser? The WebM demuxer Opera uses is a bit particular in
that it reads overlapping blocks from the input, not just consecutive blocks.
If one just counts the bytes going in, that would exceed the size of the entire
file after a single playthrough due to the overlap.

Another issue is that the demuxer is involved in QoS, skipping forward in the
input if there have been dropped frames in order to catch up. This would
influence the measurement of both incoming or outgoing bytes.

Even trying to measure something like the number of expected frames is a bit
hard, because when the demuxer skips forward to catch up it can't know how many
frames it just skipped, unless it spends time trying to figure that out and
thereby falling further behind.

Saying how many frames were decoded is not a problem, but anything upstream to
that in the pipeline seems a bit dodgy as long as one has some kind of QoS in
the demuxer. It perhaps shouldn't be surprising that it's hard for JavaScript
to adapt the quality when the decoding pipeline is trying to do the same
thing...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 October 2011 09:25:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC