The high level tracking bug for all work pertaining to H.264/AAC & mp3.

Should bug 733812 be attached to this tracking bug?

Bug 714408 provides H.264, AAC and MP3 for B2G.

Please ensure that any dependencies that may affect developer docs have the dev-doc-needed keyword on them.

Do we have bugs tracking the desktop support for H.264/AAC & MP3 support somewhere? If so, could we link it up here?

Are H.264/AAC & MP3 required for Android for k9o?

(In reply to Lawrence Mandel [:lmandel] from comment #5) > Are H.264/AAC & MP3 required for Android for k9o? To answer my own question, yes. H.264/AAC & MP3 are required for Android. In addition, we will support the MP4 container. Also to be explicit, support for these codecs and containers will be handled on desktop via Flash fallback.

(In reply to Jason Smith [:jsmith] from comment #4) > Do we have bugs tracking the desktop support for H.264/AAC & MP3 support > somewhere? If so, could we link it up here? Not sure we do, but I don't think its 100% certain we should do this on the desktop.

(In reply to JP Rosevear [:jpr] from comment #7) > (In reply to Jason Smith [:jsmith] from comment #4) > > Do we have bugs tracking the desktop support for H.264/AAC & MP3 support > > somewhere? If so, could we link it up here? > > Not sure we do, but I don't think its 100% certain we should do this on the > desktop. As I said in comment 6, on desktop, support for these codecs and containers will be handled via Flash fallback. AFAIK we're all set on desktop.

(In reply to Lawrence Mandel [:lmandel] from comment #8) > (In reply to JP Rosevear [:jpr] from comment #7) > > (In reply to Jason Smith [:jsmith] from comment #4) > > > Do we have bugs tracking the desktop support for H.264/AAC & MP3 support > > > somewhere? If so, could we link it up here? > > > > Not sure we do, but I don't think its 100% certain we should do this on the > > desktop. > > As I said in comment 6, on desktop, support for these codecs and containers > will be handled via Flash fallback. AFAIK we're all set on desktop. I don't think what you've described works, so I don't we're set for desktop. I did testing recently with WSJ Live on Desktop with Ron (a tier 1 app for desktop) - we were erroring out saying the MIME type was not supported, as they are using mp4 to live stream content. Also, I just tested this equivalently on a MS blog too and this did not work either (see video at bottom of page): http://blogs.msdn.com/b/b8/archive/2012/06/08/building-a-rich-and-extensible-media-platform.aspx

If the fallback doesn't current work on desktop (I get the same failing behaviour at the link you provided) we need to understand the level of support that we will offer on desktop for k9o. We'll should also file a bug on this. (jsmith said he'd do just that.) cc Asa to comment on this scenario and if my understanding of using Flash fallback in this case is correct.

(In reply to Lawrence Mandel [:lmandel] from comment #10) > If the fallback doesn't current work on desktop (I get the same failing > behaviour at the link you provided) we need to understand the level of > support that we will offer on desktop for k9o. We'll should also file a bug > on this. (jsmith said he'd do just that.) > > cc Asa to comment on this scenario and if my understanding of using Flash > fallback in this case is correct. We will not support system codecs on Desktop for K9O. The assumption in that decision was that apps would simply implement fallback to Flash for audio and video that required 264/aac/mp3. This will require work on the part of the app developers. We don't have some automatic fallback. App developers using <video> and <audio> elements need to include the fallback object inside the video or audio elements.

(In reply to Asa Dotzler [:asa] from comment #11) > (In reply to Lawrence Mandel [:lmandel] from comment #10) > > If the fallback doesn't current work on desktop (I get the same failing > > behaviour at the link you provided) we need to understand the level of > > support that we will offer on desktop for k9o. We'll should also file a bug > > on this. (jsmith said he'd do just that.) > > > > cc Asa to comment on this scenario and if my understanding of using Flash > > fallback in this case is correct. > > We will not support system codecs on Desktop for K9O. The assumption in > that decision was that apps would simply implement fallback to Flash for > audio and video that required 264/aac/mp3. > > This will require work on the part of the app developers. We don't have some > automatic fallback. App developers using <video> and <audio> elements need > to include the fallback object inside the video or audio elements. Why not have an automatic fallback? That would prevent cases like I've identified in comment 9.

(In reply to Jason Smith [:jsmith] from comment #12) > Why not have an automatic fallback? That would prevent cases like I've > identified in comment 9. A couple of reasons. It's probably a violation of the spec which empowers developers to control the fall back. It's probably a lot of work. Developers are already doing this properly out on the Web and "the Web is the platform" :-)

(In reply to Asa Dotzler [:asa] from comment #13) > (In reply to Jason Smith [:jsmith] from comment #12) > > Why not have an automatic fallback? That would prevent cases like I've > > identified in comment 9. > > A couple of reasons. It's probably a violation of the spec which empowers > developers to control the fall back. It's probably a lot of work. Developers > are already doing this properly out on the Web and "the Web is the platform" > :-) In that case, let's update the title of this bug to reflect that.

Android part of this is irrelevant to basecamp - B2G is covered in bug 759506, suggesting we -

Mass closing as we are no longer working on b2g/firefox os.

Mass closing as we are no longer working on b2g/firefox os.