-12913 is kVTVideoDecoderNotAvailableNowErr.

The problem seems to be sandbox-related.  It disappears when running with --disable-gpu-sandbox.

Perhaps feeding InitializeVideoToolboxInternal() with SPS and PPS data taken from a different file would do the trick?

Another video failing the same way on macOS 10.13: http://www.viewster.com/movie/1130-15481-000/a-house-with-a-view-of-the-sea/

I tried using the SPS and PPS data from the video above to warm up the sandbox, but now InitializeVideoToolboxInternal() is giving me the same VTDecompressionSessionCreate() error, and it still doesn't work when actually trying to play the video later on.

Interestingly, on macOS 10.12, with this change I'm getting the same VT error during sandbox warm-up and yet the session is created correctly when trying to play the video.

--- a/media/gpu/vt_video_decode_accelerator_mac.cc
+++ b/media/gpu/vt_video_decode_accelerator_mac.cc
@@ -191,10 +191,11 @@ bool CreateVideoToolboxSession(const uint8_t* sps,
 bool InitializeVideoToolboxInternal() {
   // Create a hardware decoding session.
   // SPS and PPS data are taken from a 480p sample (buck2.mp4).
-  const uint8_t sps_normal[] = {0x67, 0x64, 0x00, 0x1e, 0xac, 0xd9, 0x80, 0xd4,
-                                0x3d, 0xa1, 0x00, 0x00, 0x03, 0x00, 0x01, 0x00,
-                                0x00, 0x03, 0x00, 0x30, 0x8f, 0x16, 0x2d, 0x9a};
-  const uint8_t pps_normal[] = {0x68, 0xe9, 0x7b, 0xcb};
+  const uint8_t sps_normal[] = {0x67, 0x42, 0xc0, 0x1e, 0xd9, 0x01, 0xa1,
+                                0xff, 0x93, 0x01, 0x6a, 0x02, 0x02, 0x02,
+                                0x80, 0x00, 0x00, 0x03, 0x00, 0x80, 0x00,
+                                0x00, 0x0f, 0x47, 0x8b, 0x17, 0x24};
+  const uint8_t pps_normal[] = {0x68, 0xcb, 0x8c, 0xb2};
   if (!CreateVideoToolboxSession(sps_normal, arraysize(sps_normal), pps_normal,
                                  arraysize(pps_normal), true)) {
     DLOG(WARNING) << "Failed to create hardware VideoToolbox session";

I went for tuning the sandbox for 10.13 in https://chromium-review.googlesource.com/c/chromium/src/+/677290.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0710753b51f9c81b9ab8b11a29240c437053109

commit e0710753b51f9c81b9ab8b11a29240c437053109
Author: Wojciech Dzierżanowski <wdzierzanowski@opera.com>
Date: Fri Sep 22 15:49:30 2017

Allow lookup of videodecoder service to fix HW video decoding on macOS 10.13

Tha macOS sandbox has apparently changed in 10.13.  If we don't allow
lookup of the global Mach service com.apple.coremedia.videodecoder,
VTDecompressionSessionCreate() fails with
kVTVideoDecoderNotAvailableNowErr for some videos.

Bug:  767037 
Change-Id: I4fee235d3808a504d57660976ef96b3a0a0f54d7
Reviewed-on: https://chromium-review.googlesource.com/677290
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503747}
[modify] https://crrev.com/e0710753b51f9c81b9ab8b11a29240c437053109/content/browser/gpu.sb

This is not Pri-3, it's Pri-1/0, we need to see about merging this to stable since otherwise as users upgrade to 10.13 we're losing hardware decode and thus wasting a ton of power here. +rsesek for commentary about security concerns merging this all the way back to 61.

Meant to set MR-62 first.

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I realize this isn't all videos, but 10.13 is still rolling out and metrics show about a ~30% unsupported parameters rate (!) on 10.13 vs ~0% on 10.12:

https://uma.googleplex.com/timeline_v2?sid=a4c24a73ccf0e0c9201254dc0a4171ae

+M61, M62 TPMs as FYI.

There's no risk to merging this.

M61 went out to Stable at 100% this morning for Desktop and we're not planning any further stable release unless critical issue arise. We can take this merge in for M61 after change is well baked in M62 Beta and it can go out with future M61 respin (if any). Does this sound good?

When merging, please note that this depends on https://chromium-review.googlesource.com/611409, which introduced the 'macos-1013' constant in the sandbox configuration.

Thanks for the pointer. I've pinged that bug.

Approving merge to M62. Branch:3202

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e297cef04c45ec224334d11717f02daa11633ca

commit 8e297cef04c45ec224334d11717f02daa11633ca
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Sep 29 01:38:12 2017

Merge M62: "Allow lookup of videodecoder service to fix HW video decoding on macOS 10.13"

Tha macOS sandbox has apparently changed in 10.13.  If we don't allow
lookup of the global Mach service com.apple.coremedia.videodecoder,
VTDecompressionSessionCreate() fails with
kVTVideoDecoderNotAvailableNowErr for some videos.

TBR=wdzierzanowski@opera.com

(cherry picked from commit e0710753b51f9c81b9ab8b11a29240c437053109)

Bug:  767037 
Change-Id: I4fee235d3808a504d57660976ef96b3a0a0f54d7
Reviewed-on: https://chromium-review.googlesource.com/677290
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503747}
Reviewed-on: https://chromium-review.googlesource.com/691050
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#500}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/8e297cef04c45ec224334d11717f02daa11633ca/content/browser/gpu.sb

Tested this issue on Mac OS 10.13 using chrome latest beta M62-62.0.3202.45 by following steps mentioned in the original comment, observed GpuVideoDecoder is used as expected under chrome://media-internals. 

Note: Unable to reproduce this issue on reported version of chrome #63.0.3221.0 as well.

wdzierzanowski@ Could you please let us know is there anything missing from our end? Attaching screen shot of #62.0.3202.45 behavior for reference.

Thanks!

Deleted: GPUVideoDecoder.png 545 KB

	GPUVideoDecoder.png 545 KB View Download

The above video (http://www.viewster.com/movie/1130-15481-000/a-house-with-a-view-of-the-sea/) is playing fine without any issues on Latest Canary#63.0.3232.0 as well as on Beta#62.0.3202.45 with the above fix for Mac OS X 10.13 (17B25c). Where the same video is failed to load on both reported version of Chrome#63.0.3221.0 as well as on Previous Beta#62.0.3203.38. So i'm assuming this issue has been fixed now (Not seeing the above mentioned error in 'chrome://media-internals' as well as in 'Console').

wdzierzanowski@, Appreciate if you confirm the same.

Thank you!

The verification is to check in chrome://media-internals that GpuVideoDecoder is used and not FFmpegVideoDecoder.  So I think you've verified it correctly.

About the error emitted by vt_video_decode_accelerator_mac.cc -- sorry, I should have mentioned it's only visible in Debug builds.

I'm curious about the inability to reproduce the issue in 63.0.3221.0 though.  Could it be that a macOS update fixed it and we don't need https://chromium-review.googlesource.com/677290 anymore?  I did originally check on a version of macOS that was available to developers before the official release.

I'll take another look and if I can confirm it, I propose to revert the fix from M63, but keep it on M62 for a while, at least until metrics can confirm it's not an issue anymore in M63.  WDYT dalecurtis@?

Firefox folk mentioned at FOMS that they had a similar issue that Apple fixed, so it may be fixed and we can revert this now. I'm traveling so can't verify at the moment though.

Ah, 17B25c is 10.13.1 beta, right?  That sounds like that Apple fix is indeed on its way to the general public.

I checked again in 63.0.3221.0 on the 17A365 build of macOS 10.13, and I can still reproduce the issue.

So it seems we still need to keep the sandbox fix for some time.