[FFmpeg-devel] Musepack SV8 Final
Wed Mar 4 07:16:36 CET 2009
On Tue, Mar 03, 2009 at 05:54:54PM -0500, Justin Ruggles wrote:
> I saw a press release for Musepack SV8 Final on Hydrogenaudio. It
> mentions that SV8 audio could be supported in other containers such as
> MKV and NUT, so that caught my attention. After a quick look at the
> source code, it appears that such support is not included as part of the
> So I looked at the state of our MPC8 support. We have an SV8 format
> demuxer and SV8 audio decoder, but we do not support de/muxing it in
> other containers.
> I asked some questions on HA regarding a few things and got a reply from
> one of their developers.
> Regarding extradata (specifically MKV CodecPrivate), they said that all
> of the information in the SH packet except for the CRC is needed to
> initialize the decoder (I assume they are referring to libmpcdec). We
> only use the last 2 bytes of the SH packet for extradata.
That's because our decoder does not care about CRC, start silence or total
number of samples. I can change it to accept whole SH packet easily.
> The Matroska
> page says it's waiting on the spec to be finalized (which just happened
> in the last few days) before stating the format for CodecPrivate.
> Regarding packetization, the frame data within the AP packets should be
> repacketized within the new container, which is compatible with the way
> we handle it now.
Well, I don't like what they did with last packet - you can't distinguish
it from full packet and it does not contain padding data. That's why their
decoder tracks the number of samples and that probably will create troubles
for other containers since seeking should update number of decoded samples
It would be nice if someone told them it's wrong to do that way.
> As for identification, I got no reply about a wFormatTag, so I'm
> guessing WAV/AVI is out of the question. As for FOURCC, he/she
> recommended MPCK, which is also the magic number for the SV8 container
> So adding support SV8 in NUT and MKV would be trivial. Should we take
> the lead on the extradata/CodecPrivate matter or wait for an official
> statement from Matroska?
They will do it in their way (IIRC Matroska is known for its "unified"
codec handling) and it's better not to multiply variants beyond necessity.
> Also, using a FOURCC for audio looks possible,
> but there is a big FIXME above them currently... maybe those could be
> split into a separate list and only used if a wFormatTag is not found
> for containers that support it?
More information about the ffmpeg-devel