[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mplayer-dev-eng
Subject:    [MPlayer-dev-eng] [PATCH] Preliminary musepack support
From:       Amiaux Benoit <benoit.amiaux () laposte ! net>
Date:       2005-05-11 20:32:42
Message-ID: 200505112232.42934.benoit.amiaux () laposte ! net
[Download RAW message or body]

Hello,

I'm one of the guys who ported libmusepack to *nix.
Here's my opinion on the topic.
Current decoder is able to playback musepack-only audio files fine. Yes, sv7 
bitstream is bad. Yes, seeking is an issue. Current decoder has a slow but 
bit-perfect implementation of seeking. 
Another issue with seeking is that there are no limits to block dependencies. 
We had once a file with something like 1024 blocks dependencies, which 
obviously isn't nice for packetizing the bitstream. I wish you all good luck 
if you want to make a proper implementation around that in mpc-in-avi.
So what about musepack support in mplayer ?
A library of the encoder is currently in the making (which will be open-source 
too btw). Hopefully it'll make it much more easier to make a real bitstream 
for musepack, and why not, even choose nut or matroska as a 'native' 
container.
So if any of you wants to work on musepack, I can only suggest to either do it 
completely, come help us, and put up a new bitstream, we'll modify decoder 
lib accordingly, mplayer will be able to mux/demux/play it properly. 
Or mplayer could be restricted to play audio-only musepack files, and seeking 
will be relatively slow.
We already have vorbis in AVI, please no broken mpc in AVI.

Grettings,
Benoît Amiaux




_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng@mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[prev in list] [next in list] [prev in thread] [next in thread]