Opened 8 years ago
Closed 8 years ago
#13150 closed bug (fixed)
Some mp3 files fail to play on recent builds
Reported by: | vidrep | Owned by: | pulkomandy |
---|---|---|---|
Priority: | high | Milestone: | R1/beta1 |
Component: | Audio & Video/Codecs | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Some mp3 files fail to play on recent Haiku builds. hrev50818 x86_gcc2 Attached are screenshots and sample files which will show the issue.
Attachments (5)
Change History (12)
by , 8 years ago
Attachment: | screenshot1.png added |
---|
by , 8 years ago
Attachment: | VanillaFudge.mp3 added |
---|
by , 8 years ago
Attachment: | screenshot2.png added |
---|
by , 8 years ago
Attachment: | Moloch - Helping Hand.mp3 added |
---|
comment:1 by , 8 years ago
by , 8 years ago
Attachment: | 05 No Matter Where You Go . . . (Dialogue).mp3 added |
---|
file play in VLC but not mediaplayer
comment:2 by , 8 years ago
Milestone: | Unscheduled → R1/beta1 |
---|---|
Priority: | normal → high |
Make "some" into "most" -- all the MP3 files I have which worked on previous builds no longer play. They have a 4-second duration in MediaPlayer despite being of various multi-minute lengths. playfile
in Terminal yields:
BMediaTrack::ReadFrames: decoder returned error 0xffffffff (General system error) playback finished
comment:3 by , 8 years ago
" also get only the first second of sound on at least the youtube 480p video downloaded trough www.keepvid.com" that now work again on the hrev50919 build (perhaps worked some rev before). Still have problem with many mp3 that said.
comment:4 by , 8 years ago
Tested it and it works with hrev50791. So basically everything before the big ffmpeg update of hrev50795 works like a charm. Everything after is either completely broken or most partly broken (only plays a few mp3 files but not the majority of common files)
PS: Replaced the ffmpeg hpkgs from hrev50941 with the ones from hrev50791 and everything works. All my mp3s play without any issue :)
comment:5 by , 8 years ago
comment:6 by , 8 years ago
Problem tracked to here: http://cgit.haiku-os.org/haiku/tree/src/add-ons/media/plugins/ffmpeg/AVFormatReader.cpp#n260
We currently give ".mod" as a file name to ffmpeg when opening anything. This allows playing amiga MOD files, which ffmpeg doesn't have a better way to detect than the file extension. However, now MP3s are also detected as MOD files and played with libmodplug, which has no idea how to handle them.
I tried setting the parameter back to NULL, but then ffmpeg does not detect any format at all and nothing is played.
Setting it to ".mp3", the decoding works fine again.
So, for things to work properly in as much formats as possible, we should get either the MIME type or the file name to this function. Unfortunately, we only get a BDataIO at that level. We can cast it to a BFile, but that still doesn't get us to the filename, we would need a BEntry. An alternative is to sniff the data to try to detect the file type.
Yup, same thing i get on many mp3.
I also get only the first second of sound on at least the youtube 480p video downloaded trough www.keepvid.com
I am also linking an mp3 where i get something different from Vidrep. "File could not be opened, general system error".