Detailed low-level codec information is not provided through the media element. You can test if a browser can play a certain file using the canPlayType()
method with the mime-type/codec as argument, but this is a general query which won't give specifics about a particular file, just the (potential) capability of the browser.
The audioTracks
property you refer to (which also is supported in Safari) lists available audio tracks in a file that the browser already has decoded, ie. is able to read and handle. The track data is more "semantic" description type (type of track (main, translation, ..), language etc.), not anything about the coded used for the original data.
The only way to detect this low-level information is to load the video file (or part of it) using XMLHttpRequest (comes with CORS requirements) or a FileReader, as a byte buffer (ArrayBuffer) and manually parse it. Doable, but it provides for many pitfalls.
Generally, when the browser skips the first choice and uses secondary, third etc. choices, it means the browser cannot play that specific file which means it do have a problem with the file, but for this browser.
The best approach is to select codecs that works with most browsers in one or more combinations, and always make sure the video is rendered into one of those formats directly, or as a minimum converted into such a format.