My Chrome browser also updated to 62 version and waiting for CEF and CEFSharp library roll-out with MP3 Code support.
Thanks,
Bhanuprakash.
[Google Chrome is up to date , Version 62.0.3202.62 (Official Build) (64-bit)]
Sorry to ask a stupid question, but the mentioned "Follow up Chrome CL will fix mime util code to allow mp3/mp4 use in chromium builds with proprietary_codecs=false.", has this been done? (I was thinking if it is https://chromium.googlesource.com/chromium/src.git/+/d69958f1aa564e532d7edc7f57f7ba4e6dd77f43, or if it hasn't taken place yet)
(Currently looking to build Chromium and CEF with MP3 support, so that's why I'm asking. :)
Thanks for a super-fast reply! Great, glad to see that it's moving forward. Bear with me for my ignorance on the Chromium codebase: I won't really have any use of this change until the CL has landed, right? (since the mime util code still won't allow mp3/mp4 use without that change)
(If so, maybe I'm better off by just compiling with proprietary_codecs=true for now, being aware of the potential legal consequences.)
Setting proprietary_codecs=true should work, but I can't speak to the legal stuff.
I think, as-is, even with proprietary_codecs=false you can probably play an mp3 in chromium, you just can't rely on HTMLMediaElement.canPlayType to say "probably" quite yet. I haven't tested this (my build is a mess at the moment), but might unblock you.
Added a vote for expedited resolution of this issue. MP3 support is key to our use of the CEF and this has become a critical blocking issue for our use. Any and all updates as to when M63 will be released would be greatly appreciated.
As Chris notes in c#10, in M64+ MP4 and MP3 are available in Chromium. While the container will demux and the codec will now play, we're still sorting out the mime-type issues though so canPlayType/isTypeSupported aren't accurate.
There will be no updates to M63 for this.
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/3323d0cc8bc471e6c2c354f854013df378165a33
commit 3323d0cc8bc471e6c2c354f854013df378165a33
Author: Łukasz Anforowicz <lukasza@chromium.org>
Date: Wed Dec 13 21:03:28 2017
Revert "Stop using findMediaFile(...) in LayoutTests"
This reverts commit 99e6ba383f1c2963eb5f3b93c5ef243c07a8240d.
Reason for revert: Caused test failures on Site Isolation Linux bot - https://crbug.com/794664 (as we're trying to make the bot's test steps part of CQ).
Original change's description:
> Stop using findMediaFile(...) in LayoutTests
>
> Historically, findMediaFile() helped choose the right extension based
> on what the browser could play. Chromium cannot play some proprietary
> formats (h264, aac, etc), so this check would choose the .ogv format
> in that case.
>
> But things have gotten crufty.
> 1) A long time ago we started running layout tests on builds that *do*
> include proprietary codecs
> 2) But we lie about that to the tests via
> media::RemoveProprietaryMediaTypesAndCodecsForTests()
> This makes debugging tests a pain because manual execution doesn't
> call this method and its easy to forget that the test wrapper does.
> 3) Lots of tests never bothered to call findMediaFile anway and just
> hardcoded the use of an mp4 with proprietary codecs, which worked
> because the method in #2 above only changes canPlayType responses,
> it doesn't remove the actual support for proprietary codecs.
> 4) findMediaFile is about to be busted anyway because it only queries the
> file mime type without supplying codec info. eg
> canPlayType("video/mp4") == "maybe" -> lets use the mp4!
> and even chromium will now "maybe" for this now that we no longer
> consider mp4 proprietary (though codecs like h264 still are!)
>
> So this patch does the following:
>
> 1) Deletes findMediaFile() and instead hardcode use of the ogg file. This
> maintains the existing behavior and avoids a massive rebaseline.
> 2) Delete media::RemoveProprietaryMediaTypesAndCodecsForTests(). Tests
> and manual runs now behave the same.
> 3) Delete ancient media-can-play-* LayoutTests that just call canPlayType
> with various codecs and are duplicated by content and chrome browser
> tests (which is a better place for these checks)
> 4) Updates mediasource-config-change-mp4-* expectations to expect that
> they should run and pass on *all* platforms (previously just android)
>
> There are still many tests that hard code the use of mp4 files. If we
> later desire to see LayoutTests run without proprietary codecs, someone
> can transition those tests. No one seems to mind at the moment.
>
> It is also not a goal to make LayoutTests try all the supported codecs.
> That is covered by unit/integration tests.
>
> Due to #2 above, a handful of tests in external/wpt/media-source now fail
> because they use mp4. Fixing these failures is tracked in Issue 794338.
>
> Change-Id: Ie357ae075c880b78d5ee9e95c1b7cc69d9d8a328
> BUG: 327115 , 746579 , 787575 , 568704 ,794338
> Reviewed-on: https://chromium-review.googlesource.com/807604
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Reviewed-by: Peter Beverloo <peter@chromium.org>
> Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#523821}
TBR=dalecurtis@chromium.org,peter@chromium.org,chcunningham@chromium.org
Change-Id: I9ee4026ddb9876083a0d2c33f62c006888ca08c0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/825762
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523873}
I'm trying to nail down when exactly Chromium will support MP3s out of the box. This issue is tagged with M-64, but the commits posted in this issue do not exist source control under any tags for version 64. I do see them under some version 65 tags, however.
Can someone definitively state what version the fix for MP3 support exists in? Thanks.
Chromium mp3 support technically exists in M64, in that if you try to play an MP3 via src="your_file.mp3" it will work.
But <audio>.canPlayType('...') will not report support for mp3 until M65.
Playback via MSE (and checking for support via isTypeSupported) will not be available in Chromium until M65.
Testing in Chromium 65.0.3316.0, it looks like mp4 is still not supported. There are a bunch of FFmpeggDemuxer errors that get logged trying to play http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4. See attached screenshot.
Should that be working?
Deleted:
Screen Shot 2018-01-08 at 2.41.54 PM.png
228 KB
Free codecs like VP9 can be played back in MP4 files using Chromium 65. Proprietary codecs like H264 and AAC (those in the video) still require Chrome due to licensing restrictions.
Sorry for the confusion. I try to call this out in the commit message in Comment 14, but there have been a lot of comments on this bug now, so its easy to miss.
Comment 1 by sarj...@gmail.com
, Oct 21 2017