[PATCH] Preliminary musepack support
Hi, the attached patch add muspack support (needs libmusepack 1.1). Seeking does not work at all, mpc-in-avi is half-working (if not to say quite broken, though it plays somehow - I guess that mencoder is to blame for that brokenness...) Greetings, Reimar Döffinger
Hi, On Wed, Feb 02, 2005 at 04:23:06PM +0100, Reimar Döffinger wrote:
the attached patch add muspack support (needs libmusepack 1.1). Seeking does not work at all, mpc-in-avi is half-working (if not to say quite broken, though it plays somehow - I guess that mencoder is to blame for that brokenness...)
Updated ad_mpc.c, should hopefully fix the case where some people got only noise. Greetings, Reimar Döffinger
Hi, On Mon, Feb 14, 2005 at 09:20:55PM +0100, Reimar Döffinger wrote:
On Wed, Feb 02, 2005 at 04:23:06PM +0100, Reimar Döffinger wrote:
the attached patch add muspack support (needs libmusepack 1.1). Seeking does not work at all, mpc-in-avi is half-working (if not to say quite broken, though it plays somehow - I guess that mencoder is to blame for that brokenness...)
Updated ad_mpc.c, should hopefully fix the case where some people got only noise.
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-( Greetings, Reimar Döffinger
On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar Döffinger wrote:
Hi, On Mon, Feb 14, 2005 at 09:20:55PM +0100, Reimar Döffinger wrote:
On Wed, Feb 02, 2005 at 04:23:06PM +0100, Reimar Döffinger wrote:
the attached patch add muspack support (needs libmusepack 1.1). Seeking does not work at all, mpc-in-avi is half-working (if not to say quite broken, though it plays somehow - I guess that mencoder is to blame for that brokenness...)
Updated ad_mpc.c, should hopefully fix the case where some people got only noise.
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
Both libs are horribly broken and need to be patched not to export generic-named symbols. 1000000000000l to the authors. Rich
Hi, On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar D?ffinger wrote:
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch? Greetings, Reimar Döffinger
Hi, On 5/10/05, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hi, On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar D?ffinger wrote:
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
As I don't quite see how I may comment on your code given my limited skills, I'd like to test it on both AMD-64 and i386 and report "evident" problems, like segfaults and horrible things like that. Is your patch "only" supposed to support _decoding_ of Musepack audio files and Musepack-in-AVI ? (meaning that MEncoder won't generate a proper AVI movie file if I use an external Musepack file as the audio track). Is the decoding of Matroska movie files also supposed to work with a Musepack audio track? Anyway, even though I never used Musepack, I'm happy to see that MPlayer will feature some kind of support for it, as our users have been looking forward to it. Regards, Guillaume
Hey, On Tuesday 10 May 2005 11:18, Guillaume POIRIER wrote:
Is the decoding of Matroska movie files also supposed to work with a Musepack audio track?
There's currently no support for Musepack in Matroska. The reason is that Musepack's current bitstream format has blocks depending on up to 32 prior blocks (or something like that). It was decided that we would wait for the next bitstream format to be finalized before we attempt putting Musepack into Matroska files. Unfortunately work on Musepack didn't quite continue, so I don't know whether or not this will ever happen. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
Hi, On 5/10/05, Moritz Bunkus <moritz@bunkus.org> wrote:
Hey,
On Tuesday 10 May 2005 11:18, Guillaume POIRIER wrote:
Is the decoding of Matroska movie files also supposed to work with a Musepack audio track?
There's currently no support for Musepack in Matroska. The reason is that Musepack's current bitstream format has blocks depending on up to 32 prior blocks (or something like that).
Out of curiosity, is that supposed to be a trick to save as much bits as possible, and rely as much as possible on the intelligence of the demuxer/decoder ? ... or is that bad design? Regards, Guillaume
Hey, On Tuesday 10 May 2005 11:40, Guillaume POIRIER wrote:
Out of curiosity, is that supposed to be a trick to save as much bits as possible, and rely as much as possible on the intelligence of the demuxer/decoder ?
No idea whatsoever. Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds
Guillaume POIRIER wrote:
Out of curiosity, is that supposed to be a trick to save as much bits as possible, and rely as much as possible on the intelligence of the demuxer/decoder ? ... or is that bad design?
everything that needs extradata is _very_bad_ design, imo. Codecs can be made very simple and efficient, look at mpeg1/2/3 and to a lesser extend ac3 and aac with adts syntax. Unfortunately there's a real craze to use extradata that takes nothing good and overcomplicates demuxing and decoding -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Novit� per telefonare risparmiando: Email.it Phone Card, clicca e scopri i vantaggi Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2689&d=10-5
On Tue, May 10, 2005 at 12:25:19PM +0200, Nico Sabbi wrote:
Guillaume POIRIER wrote:
Out of curiosity, is that supposed to be a trick to save as much bits as possible, and rely as much as possible on the intelligence of the demuxer/decoder ? ... or is that bad design?
everything that needs extradata is _very_bad_ design, imo.
Not at all. A custom dictionary/codebook can be INCREDIBLY useful for improving compression efficiency, and it's easy to do with 2pass encoding. These techniques are just underutilized by most common codecs due to conflicting requirements (e.g. broadcast) or lack of interest.
Codecs can be made very simple and efficient, look at mpeg1/2/3 and to
Look at how poorly they compress...
a lesser extend ac3 and aac with adts syntax. Unfortunately there's a
AAC has extradata. There's just some stupid way for including it repeatedly in the bitstream or using default values, either of which wastes space. I forget which..
real craze to use extradata that takes nothing good and overcomplicates demuxing and decoding
It doesn't complicate things at all, unless you do stupid things like making multiple packets of extradata... Rich
Hi, On Tue, May 10, 2005 at 11:18:26AM +0200, Guillaume POIRIER wrote:
On 5/10/05, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
As I don't quite see how I may comment on your code given my limited skills, I'd like to test it on both AMD-64 and i386 and report "evident" problems, like segfaults and horrible things like that.
Sure, seeking might cause segfaults though...
Is your patch "only" supposed to support _decoding_ of Musepack audio files and Musepack-in-AVI ? (meaning that MEncoder won't generate a proper AVI movie file if I use an external Musepack file as the audio track).
The only Muspack-in-AVI I saw and could test were those created my mencoder. Mencoder will create "something" when you specify a mpc file with -audiofile, but unfortunately mencoder saves only the lowest 2 bytes of the fourcc, so you have to add format 0x504D to codecs.conf, and the A-V sync values are complete nonsense since there is no frame API and whatever, and the bitrate that demux_audio gives is some arbitrary value, too. Playback works though.
Is the decoding of Matroska movie files also supposed to work with a Musepack audio track?
Never seen any samples... It would have to store the header of the musepack audio in the right place (separate from the stream). Greetings, Reimar Döffinger
Hi, On 5/10/05, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hi,
On 5/10/05, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hi, On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar D?ffinger wrote:
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
As I don't quite see how I may comment on your code given my limited skills, I'd like to test it on both AMD-64 and i386 and report "evident" problems, like segfaults and horrible things like that.
Ok, I tested on AMD-64, and it doesn't work.... for the very simple reason that I can't compile Musepack on AMD-64. I'll see if more experimental versions feature the A-64 port. Regards, Guillaume
Hi, On 5/12/05, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hi,
On 5/10/05, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hi,
On 5/10/05, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hi, On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar D?ffinger wrote:
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
As I don't quite see how I may comment on your code given my limited skills, I'd like to test it on both AMD-64 and i386 and report "evident" problems, like segfaults and horrible things like that.
Ok, I tested on AMD-64, and it doesn't work.... for the very simple reason that I can't compile Musepack on AMD-64. I'll see if more experimental versions feature the A-64 port.
I tested on i386 with libmusepack 1.1 and 1.2 without success. 1.1 isn't detected by configure, why 1.2 produces a link error at the very end of the compile process. If you need a log, I can re-run the test. Guillaume PS: with 1.1, that's what config.log reads: ============ Checking for musepack support ============ #include <mpcdec/mpcdec.h> int main(void) { mpc_streaminfo info; mpc_streaminfo_init(&info); return 0; } cc /tmp/mplayer-conf-22648-23852.c -o /tmp/mplayer-conf-19070-23852.o -lmpcd ec -lm /tmp/mplayer-conf-22648-23852.c:1:27: mpcdec/mpcdec.h: No such file or directory /tmp/mplayer-conf-22648-23852.c: In function `main': /tmp/mplayer-conf-22648-23852.c:2: error: `mpc_streaminfo' undeclared (first use in this function) /tmp/mplayer-conf-22648-23852.c:2: error: (Each undeclared identifier is reporte d only once /tmp/mplayer-conf-22648-23852.c:2: error: for each function it appears in.) /tmp/mplayer-conf-22648-23852.c:2: error: syntax error before "info" /tmp/mplayer-conf-22648-23852.c:2: error: `info' undeclared (first use in this f unction) ldd /tmp/mplayer-conf-19070-23852.o ldd: /tmp/mplayer-conf-19070-23852.o: No such file or directory and that's what is in /usr/local/include/musepack/ config_types.h huffman.h musepack.h requant.h decoder.h math.h reader.h streaminfo.h
On Tue, May 10, 2005 at 11:02:27AM +0200, Reimar Döffinger wrote:
Hi, On Wed, Mar 02, 2005 at 12:07:11PM +0100, Reimar D?ffinger wrote:
Another update - unfortunately there still is an naming clash between the random_int functions in libfaad2 and libmusepack - so MPlayer won't compile with gcc 3.3.x when you use both - with gcc 3.4.x it compiles but crashes when you use libfaad2 :-(
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
Yes, the fact that it demuxes random amounts of data rather than complete packets, and probably doesn't have correct timestamps whatsoever.. We need more valid demuxers, not more broken ones.. Rich
Hi, On Tue, May 10, 2005 at 12:14:18PM -0400, Rich Felker wrote:
On Tue, May 10, 2005 at 11:02:27AM +0200, Reimar Döffinger wrote:
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
Yes, the fact that it demuxes random amounts of data rather than complete packets, and probably doesn't have correct timestamps whatsoever.. We need more valid demuxers, not more broken ones..
Yes, that's what keeps both musepack-in-avi and seeking from working. But I won't be the one to fix it (and judging by the general activity in thsi area nobody will do that), so you only have the choice between getting a broken demuxer or none... So everybody vote, the majority wins *g* Greetings, Reimar Döffinger
On Tue, May 10, 2005 at 08:56:10PM +0200, Reimar Döffinger wrote:
Hi, On Tue, May 10, 2005 at 12:14:18PM -0400, Rich Felker wrote:
On Tue, May 10, 2005 at 11:02:27AM +0200, Reimar Döffinger wrote:
The naming clash seems to be fixed in the latest version of the lib. The attached patch uses it. Even though seeking is still completely broken, I would like to apply it soon (since I don't intend to fix it any time soon, like this others can improve on it more easily). Is that okay with you? Aynthing you dislike about this patch?
Yes, the fact that it demuxes random amounts of data rather than complete packets, and probably doesn't have correct timestamps whatsoever.. We need more valid demuxers, not more broken ones..
Yes, that's what keeps both musepack-in-avi and seeking from working. But I won't be the one to fix it (and judging by the general activity in thsi area nobody will do that), so you only have the choice between getting a broken demuxer or none... So everybody vote, the majority wins *g*
Just copy-and-paste the decoder code that reads a packet into the demuxer. I don't care if it's slow as hell as long as it has valid output. Someone can optimize it later.. Rich
On Tue, 10 May 2005 20:56:10 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote: [...]
Yes, the fact that it demuxes random amounts of data rather than complete packets, and probably doesn't have correct timestamps whatsoever.. We need more valid demuxers, not more broken ones..
Yes, that's what keeps both musepack-in-avi and seeking from working. But I won't be the one to fix it (and judging by the general activity in thsi area nobody will do that), so you only have the choice between getting a broken demuxer or none... So everybody vote, the majority wins *g*
I'm for committing it if it works, an hacky demuxer is better than no support at all. And iirc most of the limitations come from the file format (seeking requiring codec knowledge, unless i'm mixing it up with other broken audio formats) Ciao, Roberto
On Tue, May 10, 2005 at 09:23:05PM +0200, Roberto Togni wrote:
On Tue, 10 May 2005 20:56:10 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
[...]
Yes, the fact that it demuxes random amounts of data rather than complete packets, and probably doesn't have correct timestamps whatsoever.. We need more valid demuxers, not more broken ones..
Yes, that's what keeps both musepack-in-avi and seeking from working. But I won't be the one to fix it (and judging by the general activity in thsi area nobody will do that), so you only have the choice between getting a broken demuxer or none... So everybody vote, the majority wins *g*
I'm for committing it if it works, an hacky demuxer is better than no support at all. And iirc most of the limitations come from the file format (seeking requiring codec knowledge, unless i'm mixing it up with other broken audio formats)
Seeking requires codec knowledge for all raw formats. Same for mp3. Rich
Hi, On Tue, May 10, 2005 at 04:32:06PM -0400, Rich Felker wrote:
On Tue, May 10, 2005 at 09:23:05PM +0200, Roberto Togni wrote:
On Tue, 10 May 2005 20:56:10 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote: I'm for committing it if it works, an hacky demuxer is better than no support at all. And iirc most of the limitations come from the file format (seeking requiring codec knowledge, unless i'm mixing it up with other broken audio formats)
Seeking requires codec knowledge for all raw formats. Same for mp3.
Looks like it will be easier than I thought. The biggest problem is that frames are not byte-aligned :-( The format is as follows: You have a header (48, 64 or 200 bits), then follows the "normal" bitstream. The bistream consists or frames. Each frame starts with 20 bits frame lenght (in bits), which by the current decoder is only used for checking for errors in the stream. The most annoying thing is the order of the bytes in the bitstream: 3 2 1 0 7 6 5 4 11 10 9 8 etc... So here is what I intend to do if I get the time (I really wished I could get some help with that): The demuxer will split the stream into frames, removing the (IMHO pretty useless) 20 bits of framesize info (that belongs in the container IMHO), and aligning every frame to byte bounderies (max. 7 bits growth per frame). The decoder wil then decode frame per frame - seems to be possible, but not with the lib - so we need our own decoder. I'd like to have it in libavcodec, but I have zero experience with both libavcodec and programming a decoder. Comments and help qould be much appreciated. Greetings, Reimar Döffinger
Hi, On Wed, May 11, 2005 at 12:22:38PM +0200, Reimar D?ffinger wrote:
The most annoying thing is the order of the bytes in the bitstream: 3 2 1 0 7 6 5 4 11 10 9 8 etc...
I forgot to say that I also want to change this, by calling bswap on every dword, so that reading data at an arbitrary point is simple (as long as it's less that 26 bits). This means that on little endian when reading more than 8 bits at once another bswap will be necessary, but who cares *g* (it will be neccessary on at least on architecture anyway and this is easier to do. And why not once give be an advantage *g*) Greetings, Reimar Döffinger
Hi, On Wed, May 11, 2005 at 12:35:38PM +0200, Reimar D?ffinger wrote:
On Wed, May 11, 2005 at 12:22:38PM +0200, Reimar D?ffinger wrote:
The most annoying thing is the order of the bytes in the bitstream: 3 2 1 0 7 6 5 4 11 10 9 8 etc...
I forgot to say that I also want to change this, by calling bswap on every dword, so that reading data at an arbitrary point is simple (as long as it's less that 26 bits). This means that on little endian when reading more than 8 bits at once another bswap will be necessary, but who cares *g* (it will be neccessary on at least on architecture anyway and this is easier to do. And why not once give be an advantage *g*)
I decided to not do that part after all... I attached a preview version of the new version. It does not support bigendian machines up to now, but mpc-in-avi seems to work nicely (though you waste up to 31 bits per frame), including seeking. You need to patch the musepack decoder lib, though, and that patch is a bit broken atm (i.e. it will probably work only with MPlayer). Greetings, Reimar Döffinger
participants (7)
-
D Richard Felker III -
Guillaume POIRIER -
Moritz Bunkus -
Nico Sabbi -
Reimar Döffinger -
Rich Felker
-
Roberto Togni