Opened 9 years ago

Last modified 8 years ago

#1993 new enhancement

warn user when playing iso files directly (not using dvd-device)

Reported by: ewilde@… Owned by: reimar
Priority: unimportant Component: ad
Version: unspecified Severity: minor
Keywords: Cc: compn, cehoyos
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


There are numerous notes on the Internet about mplayer and mencoder returning the error:

Cannot find codec for audio format 0x50

This is a bogus error. In actuality, the file in question contains an empty first stream. Apparently, mplayer/mencoder tries to open the stream and ends up using the stream ID for the actual audio stream as the format number. Since AAC streams are typically numbered beginning with a steam ID of 0x50, using the stream ID as the format number causes mplayer/mencoder to emit the bogus error message about audio format 0x50.

Here are two dumps from ffmpeg:

Input #0, mpeg, from '.../Alias_S01E22.iso':

Duration: 00:45:02.94, start: 0.280633, bitrate: 5372 kb/s

Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 32:27 DAR 16:9], 8500 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0.1[0x80]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s


Input #0, mpeg, from '.../Alias_S01E21.iso':

Duration: 00:00:00.96, start: 0.280633, bitrate: -2147483 kb/s

Stream #0.0[0x1c0]: Audio: mp2, 0 channels
Stream #0.1[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 32:27 DAR 16:9], 8500 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0.2[0x80]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s

The first is a perfectly good input file which is handled just fine by mplayer/mencoder. The second is a broken file that mplayer/mencoder cannot handle.

Admittedly, one can fix the problem by using "-aid 80" on the command line. However, the bogus error message about the wrong audio format has cost countless people thousands of lost hours chasing down a problem which is non-existent. At the very least, a proper error message should be generated to the effect that the first stream is essentially empty.

And, if one wants to really handle things properly, one should take the empty stream in stride and play the 0x50 stream when an empty first stream is detected. This is exactly what other players do.

Finally, despite the "-aid 80" option being used, the audio ends up seriously out of sync with the video on the "broken" file whereas the "OK" file plays fine. This is not the case with other players so clearly mplayer is still being confused by the empty stream. Even when the "copy" option is used with mencoder, mencoder manages to break the audio stream so that it becomes out of sync. Since "copy" is supposed to be an "exact" copy breaking the audio stream in this manner is very disturbing.

Change History (5)

comment:1 Changed 9 years ago by cehoyos

  • Cc cehoyos@… added

Please upload a sample to and post the link here.

comment:2 Changed 9 years ago by compn

  • Cc patriotact@… added

if it works in ffmpeg, does it work with mplayer -demuxer lavf ?

the correct way to play dvdiso is mplayer dvd:// -dvd-device file.iso
its only dumb luck that mplayer plays .isos and gives trouble.

comment:3 Changed 8 years ago by compn

  • op_sys changed from Other to All
  • Priority changed from normal to unimportant
  • rep_platform changed from Other to All
  • Severity changed from major to enhancement
  • Summary changed from Bogus Error With Respect To Audio Format 0x50 Is Really Empty Stream to warn user when playing iso files directly (not using dvd-device)

changing this bug to warning the user of shooting himself in the foot.

feature request: automatically play .iso file as -dvd-device .

comment:4 Changed 8 years ago by ewilde@…

OK, fair enough. But, this isn't really a DVD. Its a single track off of a DVD that was extracted using a sheep cloning program (if you get my drift). Probably, the extraction is broken and shouldn't be putting the empty stream on the front but hey, that's the way it does it.

I think my main point was that there are literally thousands of people out there, going back years and years, who have experienced this problem. So, maybe we are all idiots. But, there are a lot of us idiots. If you can warn us or, better yet, just handle it, you'd be saving us all a whole lot of grief and, in the process, making your software better too.

So, do whatever you think is best or easiest. You have my two cents worth. I'll eventually upload a sample file, if you still want it. I just haven't had time yet. Thanks for taking the time to consider the problem, even though I didn't document it fully.

comment:5 Changed 8 years ago by compn

yes, a sample would help us.

and yeah a warning message or even a check for this empty audio stream would be nice. assuming we get the sample. thanks for letting us know how the file was created. sounds very broken.

Note: See TracTickets for help on using tickets.