9 ms·

Why has Apple still not added the ability to view webms on iOS?

by Cknight70 9y ago

robert_foss 9y ago
Because Google is a direct competitor to them.
- vetinari 9y ago
  Apple traditionally ignored non MPEG codecs[1], VPx is ignored for the same reason, and not due to being developed by Google. [1] i.e. Vorbis, Theora, Flac, matroska containers, etc. Opus is supported in Safari for WebRTC because they have to, but is completely unavailable in other contexts.
  - ZeroGravitas 9y ago
    They didn't ignore Flac, they made an Apple-only knock-off of it.
    - DaiPlusPlus 9y ago
      I speculate they needed a DRM-capable container in case the rightsholders demanded DRM when iTunes started selling lossless audio files.
      - savoytruffle 9y ago
        ALAC did show up at the same time as the first AirPort Express in 2004, and it is the format used to transport audio over AirPlay (first called AirTunes). That may have been the original impetus.
    - dwaite 9y ago
      I was under the impression it was an AAC project that didn't get adoption outside the Apple ecosystem, not that it was Apple created. Do you know whether Apple was the submitter to ISO?
      - niftich 9y ago
        It sounds like when you say "an AAC project", you're thinking of MPEG-4 ALS [1], which was the codec chosen by MPEG for lossless audio in the mid-2000s and last updated in 2009. Despite ALS being blessed by MPEG, it never achieved much acceptance in the market. Its most direct ancestor was LPAC [2], developed at the Technical University of Berlin; but ALS included improvements from NTT Communication Science Laboratories and RealNetworks [3]. Apple developed Apple Lossless ("ALAC"), a different, unrelated [4] format, which was fairly similar to FLAC, but different in some minor ways (paraphrasing the FLAC dev's own words [4]). [1] https://en.wikipedia.org/wiki/Audio_Lossless_Coding https://en.wikipedia.org/wiki/Audio_Lossless_Coding [2] https://en.wikipedia.org/wiki/Lossless_predictive_audio_compression https://en.wikipedia.org/wiki/Lossless_predictive_audio_comp... [3] http://elvera.nue.tu-berlin.de/files/0737Liebchen2005.pdf http://elvera.nue.tu-berlin.de/files/0737Liebchen2005.pdf [4] https://hydrogenaud.io/index.php/topic,32111.msg279843.html#msg279843 https://hydrogenaud.io/index.php/topic,32111.msg279843.html#...
  - tzahola 9y ago
    Actually FLAC and Opus support was added to the Core Audio / AudioToolbox / AVFoundation APIs in iOS 11. Though the Opus decoder only supports raw packet decoding, i.e. you still need something to decode the container (usually ogg). Also, FLAC file decoding is horribly slow - compared to the FOSS reference decoder -, because for some reason the whole file is scanned through on the first read when using the AudioFile APIs (AudioFileReadPacketData). (I’m gonna make a demonstration project for this and send them a bugreport tomorrow.)
    - microcolonel 9y ago
      So bizarre to write their own decoder, especially given libFLAC is BSD licensed.
      - tzahola 9y ago
        It actually makes sense, because libFLAC has no public API for getting the compressed audio packets as is. Rice/huffmann/whatever decompression always happens inside libFLAC. With Apple’s AudioFile API you can decide whether you want the decompressed PCM samples, or the underlying compressed packets. You can get better energy efficiency if you offload the decompression step to the dedicated coprocessor. The difference is smaller than with hardware vs software h.264 decoding, but there is a difference. (For lossy codecs this also makes sense when you want to forward the compressed packets to a wireless speaker in order to avoid lossy recompression on Bluetooth transmission.)
    - tzahola 9y ago
      Fyi, here’s the demonstration project I talked about: https://github.com/tzahola/AudioFileFLACBug https://github.com/tzahola/AudioFileFLACBug
  - jsjohnst 9y ago
    Actually, VPx was technically an acquisition[0] by Google. Not sure it matters as they’ve evolved since, but it is somewhat notable none the less. [0] https://en.m.wikipedia.org/wiki/On2_Technologies https://en.m.wikipedia.org/wiki/On2_Technologies
acdha 9y ago
What user benefit would there have been? Any format added has a maintenance cost (ever notice how many security updates are found in AV code) so there would have had to be some compelling benefit versus the MPEG standards they already supported. That's especially important for battery-powered devices since the primary WebM codec (VP8) didn't offer a reason to switch from H.264 and would had to be implemented in software rather than using the optimized hardware on the device (this is why YouTube playback performance is so much worse on most systems unless you disable WebM support in your browser).
- gsich 9y ago
  User benefit? They can play videos, vs. they can't. Huge benefit for a vastly used codec.
  - untog 9y ago
    Vastly used? I'm not so sure about that. Vastly used in tandem with H264 when required? Absolutely. If iOS can hardware decode H264 but not WebM it actually isn't in the user's interest to support WebM, because it'll reduce incentive to provide H264 versions of content, which means iOS users will experience battery drain faster. It might not be particularly fair, but it does make sense.
    - wlesieutre 9y ago
      Native apps like VLC can play WebM on iOS with software decoding, but as you say it murders the battery. If Apple supported that in browsers I'd bet that Google or other companies would switch their video hosting over, much to the detriment of anyone who watches videos on an iPhone. It's an open standard so clearly they're doing the pro-consumer good thing!
      - gsich 9y ago
        It would give an incentive to Apple to support hardware decoding.
pornel 9y ago
The boring answer is that they've already invested in H.264, including hardware decoding support, and it works well enough for them, so they don't need to add support for VPx.
- deleted 9y ago
  [deleted]
abritinthebay 9y ago
Because it’s not as widely used as the hardware accelerated alternative?
deleted 9y ago
[deleted]
shmerl 9y ago
Because in general they are jerks when it comes to free codecs support. The fact that they joined AOM is a major shift from their previous behavior and it most likely happened because they realized they have little choice and not because they wanted to do the right thing.

Why has Apple still not added the ability to view webms on iOS?

robert_foss 9y ago

Because Google is a direct competitor to them.

vetinari 9y ago
Apple traditionally ignored non MPEG codecs[1], VPx is ignored for the same reason, and not due to being developed by Google. [1] i.e. Vorbis, Theora, Flac, matroska containers, etc. Opus is supported in Safari for WebRTC because they have to, but is completely unavailable in other contexts.
- ZeroGravitas 9y ago
  They didn't ignore Flac, they made an Apple-only knock-off of it.
  - DaiPlusPlus 9y ago
    I speculate they needed a DRM-capable container in case the rightsholders demanded DRM when iTunes started selling lossless audio files.
    - savoytruffle 9y ago
      ALAC did show up at the same time as the first AirPort Express in 2004, and it is the format used to transport audio over AirPlay (first called AirTunes). That may have been the original impetus.
  - dwaite 9y ago
    I was under the impression it was an AAC project that didn't get adoption outside the Apple ecosystem, not that it was Apple created. Do you know whether Apple was the submitter to ISO?
    - niftich 9y ago
      It sounds like when you say "an AAC project", you're thinking of MPEG-4 ALS [1], which was the codec chosen by MPEG for lossless audio in the mid-2000s and last updated in 2009. Despite ALS being blessed by MPEG, it never achieved much acceptance in the market. Its most direct ancestor was LPAC [2], developed at the Technical University of Berlin; but ALS included improvements from NTT Communication Science Laboratories and RealNetworks [3]. Apple developed Apple Lossless ("ALAC"), a different, unrelated [4] format, which was fairly similar to FLAC, but different in some minor ways (paraphrasing the FLAC dev's own words [4]). [1] https://en.wikipedia.org/wiki/Audio_Lossless_Coding https://en.wikipedia.org/wiki/Audio_Lossless_Coding [2] https://en.wikipedia.org/wiki/Lossless_predictive_audio_compression https://en.wikipedia.org/wiki/Lossless_predictive_audio_comp... [3] http://elvera.nue.tu-berlin.de/files/0737Liebchen2005.pdf http://elvera.nue.tu-berlin.de/files/0737Liebchen2005.pdf [4] https://hydrogenaud.io/index.php/topic,32111.msg279843.html#msg279843 https://hydrogenaud.io/index.php/topic,32111.msg279843.html#...
- tzahola 9y ago
  Actually FLAC and Opus support was added to the Core Audio / AudioToolbox / AVFoundation APIs in iOS 11. Though the Opus decoder only supports raw packet decoding, i.e. you still need something to decode the container (usually ogg). Also, FLAC file decoding is horribly slow - compared to the FOSS reference decoder -, because for some reason the whole file is scanned through on the first read when using the AudioFile APIs (AudioFileReadPacketData). (I’m gonna make a demonstration project for this and send them a bugreport tomorrow.)
  - microcolonel 9y ago
    So bizarre to write their own decoder, especially given libFLAC is BSD licensed.
    - tzahola 9y ago
      It actually makes sense, because libFLAC has no public API for getting the compressed audio packets as is. Rice/huffmann/whatever decompression always happens inside libFLAC. With Apple’s AudioFile API you can decide whether you want the decompressed PCM samples, or the underlying compressed packets. You can get better energy efficiency if you offload the decompression step to the dedicated coprocessor. The difference is smaller than with hardware vs software h.264 decoding, but there is a difference. (For lossy codecs this also makes sense when you want to forward the compressed packets to a wireless speaker in order to avoid lossy recompression on Bluetooth transmission.)
  - tzahola 9y ago
    Fyi, here’s the demonstration project I talked about: https://github.com/tzahola/AudioFileFLACBug https://github.com/tzahola/AudioFileFLACBug
- jsjohnst 9y ago
  Actually, VPx was technically an acquisition[0] by Google. Not sure it matters as they’ve evolved since, but it is somewhat notable none the less. [0] https://en.m.wikipedia.org/wiki/On2_Technologies https://en.m.wikipedia.org/wiki/On2_Technologies

acdha 9y ago

What user benefit would there have been? Any format added has a maintenance cost (ever notice how many security updates are found in AV code) so there would have had to be some compelling benefit versus the MPEG standards they already supported. That's especially important for battery-powered devices since the primary WebM codec (VP8) didn't offer a reason to switch from H.264 and would had to be implemented in software rather than using the optimized hardware on the device (this is why YouTube playback performance is so much worse on most systems unless you disable WebM support in your browser).

gsich 9y ago
User benefit? They can play videos, vs. they can't. Huge benefit for a vastly used codec.
- untog 9y ago
  Vastly used? I'm not so sure about that. Vastly used in tandem with H264 when required? Absolutely. If iOS can hardware decode H264 but not WebM it actually isn't in the user's interest to support WebM, because it'll reduce incentive to provide H264 versions of content, which means iOS users will experience battery drain faster. It might not be particularly fair, but it does make sense.
  - wlesieutre 9y ago
    Native apps like VLC can play WebM on iOS with software decoding, but as you say it murders the battery. If Apple supported that in browsers I'd bet that Google or other companies would switch their video hosting over, much to the detriment of anyone who watches videos on an iPhone. It's an open standard so clearly they're doing the pro-consumer good thing!
    - gsich 9y ago
      It would give an incentive to Apple to support hardware decoding.

pornel 9y ago

The boring answer is that they've already invested in H.264, including hardware decoding support, and it works well enough for them, so they don't need to add support for VPx.

deleted 9y ago
[deleted]

abritinthebay 9y ago

Because it’s not as widely used as the hardware accelerated alternative?

deleted 9y ago

[deleted]

shmerl 9y ago

Because in general they are jerks when it comes to free codecs support. The fact that they joined AOM is a major shift from their previous behavior and it most likely happened because they realized they have little choice and not because they wanted to do the right thing.