One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster.
I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta:
https://brionv.com/log/2015/06/19/webm-and-ogg-energy-usage-on-ios-9-beta-wi...
The good news is that playback of buffered data at my target resolutions (360p for 32-bit, 720p for 64-bit) is barely under the "Low" mark on the energy drain meter! :D
The bad news is that H.264 playback with the native widget reports post-buffer-download energy drain even lower, at the "Zero" mark... if you can believe that!
(In both cases, reported drain is significantly higher during network download, at least on my fast wifi.)
But "Low" sounds pretty good... If folks would like to see more concrete measures, I can rig up my test to run continuously until the battery runs out and time it.
-- brion
On 19 June 2015 at 02:08, Brion Vibber bvibber@wikimedia.org wrote:
One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster.
I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta:
[Snip]
This is really impressive to see, thank you Brion. And yes, let's not try to achieve "zero". :-)
J.
Any idea if your work would also support dynamic bitrate switching?
On Fri, Jun 19, 2015 at 12:57 PM, James Forrester jforrester@wikimedia.org wrote:
On 19 June 2015 at 02:08, Brion Vibber bvibber@wikimedia.org wrote:
One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster.
I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta:
[Snip]
This is really impressive to see, thank you Brion. And yes, let's not try to achieve "zero". :-)
J.
James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Jun 19, 2015 at 10:00 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Any idea if your work would also support dynamic bitrate switching?
It should be easy to track the download rate and *downgrade* to a lower-bitrate source if we have playback discontinuities -- we have a pause anyway, so that's a chance to switch sources and seek back to the current position. There'll be a pause for 'buffering' at first, though.
Fully seamless resolution/bitrate switching as with HLS or MPEG-DASH is trickier, but doable. There is a DASH profile for WebM (used for instance by YouTube), so the tooling exists to produce suitable manifest files.
Mainly what would need to be done is figuring out how to handle the predictive timing for the switch and retooling the player to swap out decoders in mid-stream without discontinuities.
-- brion