Last Comment Bug 748351 - Meta: H.264/AAC & mp3 on B2G and Android
: Meta: H.264/AAC & mp3 on B2G and Android
Status: NEW
[k9o:p1:fx15?]
: meta
Product: Tracking
Classification: Other
Component: Kilimanjaro (show other bugs)
: ---
: x86 All
: -- normal
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 787226 787227 759945 761762 761786 761814 762730 764022 781405 782508 790125 790126
Blocks: k9o-web-platform html5test 719694
  Show dependency treegraph
 
Reported: 2012-04-24 07:21 PDT by Sheila Mooney
Modified: 2014-02-20 18:22 PST (History)
28 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---
+


Attachments

Description Sheila Mooney 2012-04-24 07:21:56 PDT
The high level tracking bug for all work pertaining to H.264/AAC & mp3.
Comment 1 Jason Smith [:jsmith] 2012-04-24 21:44:34 PDT
Should bug 733812 be attached to this tracking bug?
Comment 2 cajbir (:cajbir) 2012-05-22 15:40:36 PDT
Bug 714408 provides H.264, AAC and MP3 for B2G.
Comment 3 Eric Shepherd [:sheppy] 2012-05-30 13:00:45 PDT
Please ensure that any dependencies that may affect developer docs have the dev-doc-needed keyword on them.
Comment 4 Jason Smith [:jsmith] 2012-06-01 07:38:37 PDT
Do we have bugs tracking the desktop support for H.264/AAC & MP3 support somewhere? If so, could we link it up here?
Comment 5 Lawrence Mandel [:lmandel] (use needinfo) 2012-06-05 12:56:04 PDT
Are H.264/AAC & MP3 required for Android for k9o?
Comment 6 Lawrence Mandel [:lmandel] (use needinfo) 2012-06-06 12:35:37 PDT
(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.
Comment 7 JP Rosevear [:jpr] 2012-06-12 07:48:06 PDT
(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.
Comment 8 Lawrence Mandel [:lmandel] (use needinfo) 2012-06-12 08:21:47 PDT
(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.
Comment 9 Jason Smith [:jsmith] 2012-06-12 09:50:20 PDT
(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
Comment 10 Lawrence Mandel [:lmandel] (use needinfo) 2012-06-12 10:10:04 PDT
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.
Comment 11 Asa Dotzler [:asa] 2012-06-12 11:14:46 PDT
(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.
Comment 12 Jason Smith [:jsmith] 2012-06-12 11:28:00 PDT
(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.
Comment 13 Asa Dotzler [:asa] 2012-06-12 11:30:24 PDT
(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" :-)
Comment 14 Jason Smith [:jsmith] 2012-06-12 11:45:05 PDT
(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.
Comment 15 JP Rosevear [:jpr] 2012-07-19 05:38:35 PDT
Android part of this is irrelevant to basecamp - B2G is covered in bug 759506, suggesting we -

Note You need to log in before you can comment on or make changes to this bug.