Opened 12 years ago
Last modified 12 years ago
#1993 new enhancement
warn user when playing iso files directly (not using dvd-device)
Reported by: | Owned by: | reimar | |
---|---|---|---|
Priority: | unimportant | Component: | ad |
Version: | unspecified | Severity: | minor |
Keywords: | Cc: | compn, cehoyos | |
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
Description
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
and
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 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
Cc: | 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 by , 12 years ago
op_sys: | Other → All |
---|---|
Priority: | normal → unimportant |
rep_platform: | Other → All |
Severity: | major → enhancement |
Summary: | Bogus Error With Respect To Audio Format 0x50 Is Really Empty Stream → 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 by , 12 years ago
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 by , 12 years ago
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.
Please upload a sample to http://www.datafilehost.com/ and post the link here.