Spec errors for VideoFrame sizing exceeding implementation max

[chcunningham]

Presently Chrome has checks in VideoFrame creation paths like this

  if (coded_width > media::limits::kMaxDimension ||
      coded_height > media::limits::kMaxDimension ||
      coded_width * coded_height > media::limits::kMaxCanvas) {
    exception_state.ThrowTypeError(
        String::Format("Coded size %u x %u exceeds implementation limit.",
                       coded_width, coded_height));
    return nullptr;
  }

This isn't spec'ed. Its not a huge deal, as the limits are large enough that probably no one is hitting them yet, but we should spec it.

Open question whether the exact cutoff should be an impl detail vs some standardized number. @sandersdan @dalecurtis do you recall the origin of the current limits?

[padenot]

That's before the limits of e.g. the hardware encode in a chip, right?

[sandersdan]

These are Chrome implementation limits, not WebCodecs ones. There is a bug in our implementation where this can result in isConfigSupported() throwing TypeError instead of returning supported = false, but these will get fixed.

In cases outside of isConfigSupported(), probably the spec should allow implementations to throw OperationError or maybe NotSupportedError for any reason?

[chcunningham]

EC: WebAudio has used "at least" limits for baseline support, so we could set similar here, but then allow impls to throw above that.

@sandersdan @dalecurtis thoughts on the "at least". 16k? What's the max YouTube resolution these days?

[sandersdan]

I'm not very comfortable with setting large lower bounds; there is no reason an embedded device (say a smart watch) couldn't implement WebCodecs with a limit below 720p.

In practice implementations may be limited by the graphics API they are implemented on top of. 2x2K and 4x4K are common limits for GLES textures, for example. There are cases in Chrome where we can decode and display via <video> in a resolution that WebGL apps cannot match.