I was trying to exercise the winemp3 builtin codec using a Visual Basic control that essentially implements the Windows Media Player look (MSDXM.OCX). After specifying native quartz.dll for this app, I tested a few AVIs with mp3-encoded soundtracks. What I can notice is that the sound has very annoying jitters, and in addition, it crashes on a seek. Some people have noticed the jitters too (http://bugs.winehq.org/show_bug.cgi?id=3853). However, rather than trying to fix the wine fork of mpeglib, I was toying with the idea of reimplementing the codec as a libmad (GPL) wrapper. Are there any issues I should take into account before trying this?
Alex Villacís Lasso
Are there any issues I should take into account before trying this?
first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ? the second issue is that MAD is GPL... hence we cannot use it A+
Eric Pouech wrote:
Are there any issues I should take into account before trying this?
first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ?
I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect.
the second issue is that MAD is GPL... hence we cannot use it A+
Too bad. I was thinking about adding a configure check for libmad and linking to it, but then this would still disallow mixing the code. BTW, when was the winemp3 code forked form mpg123? Maybe it is high time for somebody (me?) to do a resync with the latest version of mpglib.
Alex Villacís Lasso
Alex Villacís Lasso wrote:
Eric Pouech wrote:
Are there any issues
I should take into account before trying this?
first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ?
I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect.
or simply, that the sequence of: - getting mp3 encoded data - pushing them to the decoder for decoding - pushing the decoded data to the speaker runs slower than the expected pace... which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1.
the second issue is that MAD is GPL... hence we cannot use it A+
Too bad. I was thinking about adding a configure check for libmad and linking to it, but then this would still disallow mixing the code. BTW, when was the winemp3 code forked form mpg123? Maybe it is high time for somebody (me?) to do a resync with the latest version of mpglib.
it's a couple of years old. at the time I looked for it, it was the only LGPL mp3 decoder that I found. A+
Eric Pouech wrote:
Alex Villacís Lasso wrote:
Eric Pouech wrote:
Are there any issues
I should take into account before trying this?
first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ?
I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect.
or simply, that the sequence of:
- getting mp3 encoded data
- pushing them to the decoder for decoding
- pushing the decoded data to the speaker
runs slower than the expected pace... which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1.
I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek.
On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated.
Alex Villacís Lasso
Alex Villacís Lasso wrote:
Eric Pouech wrote:
Alex Villacís Lasso wrote:
Eric Pouech wrote:
Are there any issues
I should take into account before trying this?
first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ?
I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect.
or simply, that the sequence of:
- getting mp3 encoded data
- pushing them to the decoder for decoding
- pushing the decoded data to the speaker
runs slower than the expected pace... which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1.
I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek.
On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated.
Alex Villacís Lasso
Some more tests. I downloaded the latest version of mpglib, and compared it against the wine fork. Aside from extra spaces and an one-time-only initialization in the wine code, the current mpglib code is almost identical to the wine fork. However, the standalone mpglib decodes the extracted samples correctly. This means that there is something about the Wine environment that disturbs mpglib enough so that decoding no longer works correctly. I also noticed that mpglib uses malloc() and free() from glibc even inside the wine copy (one malloc()/free() pair per sample block to be decoded). Could this be causing some interference (especially since the wine architecture decodes in a separate thread)? Maybe it is worth it to use HeapAlloc()/HeapFree() instead.
Alex Villacís Lasso
Some more tests. I downloaded the latest version of mpglib, and compared it against the wine fork. Aside from extra spaces and an one-time-only initialization in the wine code, the current mpglib code is almost identical to the wine fork. However, the standalone mpglib decodes the extracted samples correctly. This means that there is something about the Wine environment that disturbs mpglib enough so that decoding no longer works correctly. I also noticed that mpglib uses malloc() and free() from glibc even inside the wine copy (one malloc()/free() pair per sample block to be decoded). Could this be causing some interference (especially since the wine architecture decodes in a separate thread)? Maybe it is worth it to use HeapAlloc()/HeapFree() instead.
no, this should work out of the box A+
I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek.
this still doesn't prove that the decoder is to blame (it may well be). it shows that the upper layers of wine work "correctly" with indeo decoder. Moreover, the point I question the most is the way the decoder (mpglib) is integrated into winemp3, which is potentially the core of the issue (if any) A+
-
Alex Villacís Lasso -
Eric Pouech