Yeah, I looked at this ages ago, it's roughly impossible to fix unless we decide we want to go with extension based mappings (we shouldn't). If you ever choose audio and guess wrong you get no video, but if you choose video and guess wrong you still get audio controls -- so video is the safest bet.

What particularly is the issue here?

What triggered me filing the issue is that right clicking on the player shows "Download the video file" or something similar instead of "Download the audio file". That was confusing.

Maybe we could simply change the text so it is agnostic of the type of media?

sgtm, that's much easier to fix :)

+rolfe@, +renganathan@

Rebecca, would you be fine to have context menu items using "media" instead of "video" or "audio" when we don't know if the <video> might be used for an audio file. In practice, that would be for MediaDocument that has a <video> because it can be used for audio files.

It could just be "download" if there's no need to disambiguate (unlike for linked images - where we have options for the link and the image itself) But "download media" is also fine with me for when we don't know.

Adding the downloads/some Chrome on Android people (+sidv & +rachelis with +talo +ktam as FYI) if they are going in a different direction.

No different direction here. :)

Moving this nonessential bug to the next milestone.

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

This issue has been moved once and is lower than Pri-1. Removing the milestone.

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

There's some cruddy logic to be unmangled here. Marking as M-58, given it is a polish milestone. 

Think this will be made redundant by the context menu redesign:
https://bugs.chromium.org/p/chromium/issues/detail?id=655359