chcunningham@, did you have any plans/ideas for this?

I'm open to it. In general I think developers shouldn't spend time debugging this API. The use case I could see is the API giving some unexpected answer and the internals page could show that the data is either sparse or not available for the requested stream type. 

fbeaufort@, is there another use case you had in mind?

The visualization should be really simple. We will change the DB scheme periodically, so this page will probably just print the DB row by row (or similar) to avoid maintenance burden.

Nope. You got it right!

Printing out the DB row by row would be more than enough for now.

From https://bugs.chromium.org/p/chromium/issues/detail?id=783153#c9,

    > Quick thought: Shall we just assume codecs="vp9" is equal to codecs="vp09.00.10.08" so that it returns supported = true at least in Chrome?
    I'd prefer not to. "vp9" has been used for some time to describe the full umbrella of vp9 profiles, levels, and bit depths - its not associated with vp09.00.10.08 (profile 0, level 1, bitdepth 8). I'd like to hold line on MediaCapabilities requiring fully specified mime strings. 
    But I think this is another thing we could surface via a chrome://media-internals tab for media capabilities. The tab could contain logs to explain why support was rejected for a given query.