- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Oct 2011 09:25:13 +0000
- To: public-html-bugzilla@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