RESOLVED FIXED 207622
MediaSource.isTypeSupported() says "video/mp4;codecs=\"avc3.42C015\"" is not supported, but it is
https://bugs.webkit.org/show_bug.cgi?id=207622
Summary MediaSource.isTypeSupported() says "video/mp4;codecs=\"avc3.42C015\"" is not ...
Robert Bryer
Reported 2020-02-12 03:42:05 PST
The current Safari Technology Preview (Release 100 (Safari 13.2, WebKit 14610.1.2.1)) rejects the AVC3 codec string "video/mp4;codecs=\"avc3.42C015\"" with MediaSource.isTypeSupported(). In my current production version of Safari (13.0.3) it's accepted. It looks like this only affects AVC3 because changing it to AVC1 returns true, like "video/mp4;codecs=\"avc1.42C015\"". And it does still play AVC3; if I ignore the codec error, it plays these videos fine without issue.
Attachments
Patch (2.34 KB, patch)
2020-02-16 11:39 PST, Peng Liu
no flags
Patch (4.28 KB, patch)
2020-02-17 14:40 PST, Peng Liu
no flags
Fix layout test failures on the Mac debug build (4.12 KB, patch)
2020-02-18 11:15 PST, Peng Liu
no flags
Radar WebKit Bug Importer
Comment 1 2020-02-13 10:16:24 PST
Alexey Proskuryakov
Comment 2 2020-02-13 10:56:30 PST
I can reproduce this on macOS Mojave with STP 99. I cannot reproduce with shipping Safari/WebKit, so this looks like a regression. I cannot reproduce on macOS Catalina. MediaSource.isTypeSupported("video/mp4;codecs=\"avc3.42C015\"")
Peng Liu
Comment 3 2020-02-16 11:39:46 PST
Darin Adler
Comment 4 2020-02-16 12:29:16 PST
Comment on attachment 390889 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=390889&action=review > Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:35 > #import "ContentType.h" > +#import <pal/spi/mac/AVFoundationSPI.h> > + > #import <pal/cf/CoreMediaSoftLink.h> > #import <pal/cocoa/AVFoundationSoftLink.h> These should be sorted in a single block. > Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:71 > + outputCodecs = [PAL::getAVStreamDataParserClass() outputMIMECodecParameterForInputMIMECodecParameter:outputCodecs]; This needs to be indented.
Eric Carlson
Comment 5 2020-02-17 06:02:37 PST
Comment on attachment 390889 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=390889&action=review >> Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:71 >> + if ([PAL::getAVStreamDataParserClass() respondsToSelector:@selector(outputMIMECodecParameterForInputMIMECodecParameter:)]) >> + outputCodecs = [PAL::getAVStreamDataParserClass() outputMIMECodecParameterForInputMIMECodecParameter:outputCodecs]; > > This needs to be indented. We don't want to change the behavior of video.canPlayType, so I would put this into MediaPlayerPrivateMediaSourceAVFObjC::supportsType.
Peng Liu
Comment 6 2020-02-17 12:06:28 PST
Comment on attachment 390889 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=390889&action=review >> Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:35 >> #import <pal/cocoa/AVFoundationSoftLink.h> > > These should be sorted in a single block. Soft-link headers need to be included after other headers. The style checking errors will go away after we land the patch for http://webkit.org/b/207834. >>> Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:71 >>> + outputCodecs = [PAL::getAVStreamDataParserClass() outputMIMECodecParameterForInputMIMECodecParameter:outputCodecs]; >> >> This needs to be indented. > > We don't want to change the behavior of video.canPlayType, so I would put this into MediaPlayerPrivateMediaSourceAVFObjC::supportsType. I see. Do we need to remove the similar code section in AVStreamDataParserMIMETypeCache::canDecodeExtendedType() after we add it into MediaPlayerPrivateMediaSourceAVFObjC::supportsType()? I suppose yes.
Peng Liu
Comment 7 2020-02-17 14:40:56 PST
WebKit Commit Bot
Comment 8 2020-02-17 18:31:45 PST
Comment on attachment 390982 [details] Patch Clearing flags on attachment: 390982 Committed r256804: <https://trac.webkit.org/changeset/256804>
WebKit Commit Bot
Comment 9 2020-02-17 18:31:47 PST
All reviewed patches have been landed. Closing bug.
Jacob Uphoff
Comment 10 2020-02-18 07:52:34 PST
Looks like the changes in https://trac.webkit.org/changeset/256804/webkit caused 50+ crashes on macOS debug. Results: https://build.webkit.org/results/Apple-Catalina-Debug-WK2-Tests/r256824%20(2379)/results.html Build: https://build.webkit.org/builders/Apple-Catalina-Debug-WK1-Tests/builds/2532 ASSERTION FAILED: !outputCodecs.isEmpty() This is found in the changes that were made in the revision.
Jacob Uphoff
Comment 11 2020-02-18 07:55:44 PST
Reverted r256804 for reason: This broke 50+ media tests on mac debug Committed r256828: <https://trac.webkit.org/changeset/256828>
Peng Liu
Comment 12 2020-02-18 11:15:34 PST
Created attachment 391071 [details] Fix layout test failures on the Mac debug build
WebKit Commit Bot
Comment 13 2020-02-18 14:52:07 PST
The commit-queue encountered the following flaky tests while processing attachment 391071 [details]: editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: morrita@google.com, rniwa@webkit.org, and tony@chromium.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 14 2020-02-18 14:52:43 PST
Comment on attachment 391071 [details] Fix layout test failures on the Mac debug build Clearing flags on attachment: 391071 Committed r256856: <https://trac.webkit.org/changeset/256856>
WebKit Commit Bot
Comment 15 2020-02-18 14:52:45 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.