So, a huge thanks to Luca (lu_zero) who poked me to try fixing xine to play MP3 files with FFmpeg tonight, after even Patrick (bonsaikitten) was fooled by the mad useflag in xine-lib.
This time I started debugging the problem like a professional 😉 gdb at hand (thanks to picoxine that makes debugging xine more acceptable), verbose logs, emacs open on the code. I wanted to find the cause and try to fix it.
First I thought the problem was inside the FFmpeg glue code (I was sure FFmpeg itself wasn’t at fault, as mp3 always worked with it even when transcoding), but after a bit of debugging I found that the header was never sent (and that’s why it was crashing once upon a time when mad was not enabled, as it didn’t initialise the codec first).
So I started poking around with the flags and the data to be sent, as I wasn’t actually sure how demuxer and decoders worked.. but now that I analysed the flow I think I know a bit more about xine’s structure. I was able to play mp3 files, but I was eating away the first frame, the start of the audio was ruined, and streams didn’t play.
Then I actually looked at the flac demuxer (I know, bad idea, as it’s one of the most broken ones, but it’s an audio-only demuxer that uses FFmpeg to play, so it was kinda perfect for me to follow), and I found how the header buffer was actually forged, so I did the same in the mpgaudio demuxer. Bingo, ruined audio solved!
Still, streams didn’t play till I remembered that the codeflow I was following was inside a check for seekable input, and HTTP streams aren’t seekable at he moment. So I just added a bit of codeflow for the non-seekable case, et voilà , FFmpeg playing Japan-A-Radio! Isn’t it great?
Okay so what’s the bottom line of all this stuff? That from next snapshot (and thus 1.1.3 release of xine), even with mad disabled you will be able to play MP3 files. Not only, it takes one less plugin to do the job, so less memory used, less time required to load, and FFmpeg is quite fast, that’s for sure.
I’m satisfied of myself today 🙂
