dalecurtis@, could you please assign this issue to someone in codec team?

Hmm we have software fallback for error cases. I'm not sure why this case didn't fall back properly. Dan you're looking at this code, can you see what's going wrong?

keiichiw@ can you provide the full chrome://media-internals log?

Here is the log on kevin:
https://paste.googleplex.com/5952367983853568

Thanks relevant logs are:

      {
        "time": 551.038999999997,
        "key": "info",
        "value": "Selected VpxVideoDecoder for video decoding, config: codec: vp9 format: 1 profile: vp9 profile2 coded size: [1280,768] visible rect: [0,0,1280,768] natural size: [1456,768] has extra data? true encryption scheme: Unencrypted rotation: 0°"
      },
      {
        "time": 551.0800000000017,
        "key": "pipeline_state",
        "value": "kPlaying"
      },
      {
        "time": 518.2790000000023,
        "key": "duration",
        "value": 10
      },
      {
        "time": 2898.3470000000016,
        "key": "error",
        "value": "video decoder reinitialization failed"
      },
      {
        "time": 2900.091999999997,
        "key": "pipeline_error",
        "value": "PIPELINE_ERROR_DECODE"
      },

Oh wait, is this an ARM chromebook? I don't think we have VP9.2 on ARM?

Yes, kevin is an ARM Chrome book whose hardware decoder doesn't support VP9.2. But, I think VP9.2 videos should be played by using software decoder there.

AFAIK, when a codec is not supported by hardware decoders, a software decoder should be used. It seems that this error happened at the time of the software decoder's re-initialization.

I thought the software decoders on Chrome supports VP9.2, so VP9.2 should be played even on ARM devices.

High bit depth VP9 software decode is not built on ARM (https://chromium.googlesource.com/chromium/src/+/4dfb389cc050ed024a8e5dfcefde555054985357/third_party/libvpx/source/config/linux/arm/vpx_config.h#89) and MIPS (https://chromium.googlesource.com/chromium/src/+/4dfb389cc050ed024a8e5dfcefde555054985357/third_party/libvpx/source/config/linux/mipsel/vpx_config.h#89).

Oh, software decoder also doesn't support VP9.2 on ARM devices. I misunderstood. Thanks.

I found a WebM's issue "Enable CONFIG_VP9_HIGHBITDEPTH on arm", which is recently closed with "WontFix".
https://bugs.chromium.org/p/webm/issues/detail?id=1544
They measured the performance on Samsung Galaxy S8+ and decided not to enable it for now.
But, how about ChromeBook? Is it reasonable to consider if we can enable it on ARM ChromeBook? 

Or, does libvpx use the same setting both on ARM android and ARM ChromeBook?

So https://bugs.chromium.org/p/webm/issues/detail?id=1544

is for the encoder, which I think is the current correct conclusion.

We have shipped VP9.2 for software on some high end devices arm devices. 

We could probably do the same for Arm chromebooks with the media capabilities api. Dale what do you think?

sgtm and all the folks who might object are on the thread :)

When you say it's enabled for high the arm, do you mean in chrome for Android?

I mean it was enabled in YT player for high end arm devices. Not Chrome for Android.

What disadvantages are there to enabling vp9.2 for arm? I.e. binary size, perf hit on 8bit content?

Yes, binary size will go up. Perf hit on 8bit was minor. But I don't have the numbers in front of me. 

I just wanted to get your thoughts on feasibility. Since it looks like it is plausible, we should probably setup a meeting to figure out who will come up with the documents needed for potentially turning this feature on in Chrome.

For arm chromebooks it's probably fine to just flip it. If we want to do so for Android I'll need to know the exact binary size hit.

johannkoenig@ do we have a recent binary size for Android?

+jianj@ who ran the webrtc performance numbers
Re comment #9 and the encoder performance hit: we can not enable highbd only for decode. It's all or nothing.

We could add a chromebook-specific set of configs with highbd. Probably best to leave android and ios alone.

If you want that it'd take me less than a day to do.

For sizes, if you give me a chrome gn config and build target I can run the size numbers.

To build chorme for ChromeOS, you can follow the way in go/simplechrome.
If you have any question, please ask here, or me/keiichiw@ offline.

Thank you.

I meant for the android size comparisons. If I know which binaries to build/check, I can get size numbers. There was a lot of confusion when I last tried to do this for desktop chrome.

You can use "kevin" or "arm-generic" as a representative of ChromeOS ARM devices.
You can get gn config by executing gn gen out_$SDK_BOARD/Release --args="$GN_ARGS && gn args" in "cros chrome-sdk" chroot.

dalecurtis@ said in comment #14 that the size difference for chromeos was not important. I was looking for help getting size information for Android.

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

commit c1dfa349b6b48cf172c07ee8c73b27c572377d38
Author: Johann <johann.koenig@duck.com>
Date: Fri Sep 14 21:34:29 2018

libvpx: support vp9.2 on chromeos arm

Fork the arm builds so we can enable vp9 profile 2 (high bit depth) on
chromeos devices without affecting other arm devices.

BUG= chromium:875773 

Change-Id: I23a9c2875a8585e2fd4e45ecc2a0e8b3ab317585
Reviewed-on: https://chromium-review.googlesource.com/1227217
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Johann Koenig <johannkoenig@google.com>
Cr-Commit-Position: refs/heads/master@{#591481}
[modify] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/BUILD.gn
[modify] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/generate_gni.sh
[modify] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/libvpx_srcs.gni
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vp8_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vp9_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vpx_config.asm
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vpx_config.c
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vpx_config.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vpx_dsp_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm-neon/vpx_scale_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vp8_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vp9_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vpx_config.asm
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vpx_config.c
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vpx_config.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vpx_dsp_rtcd.h
[add] https://crrev.com/c1dfa349b6b48cf172c07ee8c73b27c572377d38/third_party/libvpx/source/config/linux/chromeos-arm64/vpx_scale_rtcd.h

I think my part of this is done. Let me know if there is anything else you need on the libvpx side.

Should just work automatically now. So I think it's fixed.