On Wed, Oct 12, 2011 at 11:53 PM, Anton Khirnov <[email protected]> wrote: > > On Wed, 12 Oct 2011 18:40:48 -0600, John Brooks <[email protected]> > wrote: >> >> It's also worth noting that asfenc contains similar logic, for the >> same reason. I'd prefer to handle this in ff_put_wav_header somehow, >> but I don't really think it's worth the ABI issues. >> > > What ABI issues? > Those are all internal functions. >
Sorry, I was rushing off to dinner and didn't spend much time on that reply. I was thinking that ff_put_wav_header was used across libraries, but it looks like it is internal to libavformat. Would it be preferable to add a parameter indicating whether the result should be WAVEFORMAT or WAVEFORMATEX (codec requirements aside), instead of having this logic for both ASF and matroska? For some background: WAVEFORMAT is appropriate for PCM, but the structure is extended by WAVEFORMATEX, which adds the cbSize field and can have arbitrary data. WAVEFORMATEXTENSIBLE and others also exist, but aren't relevant to this patch. ff_put_wav_header is generating any of these structures based on which codec is in use, and will appropriately generate WAVEFORMAT for most PCM encodings. Matroska, and apparently ASF, expects WAVEFORMATEX, so not including the last 16-bit field will confuse some players. Adding cbSize with a value of 0 is the correct behavior in these cases. My testcase is something like "avconv -i test.mp3 -acodec pcm_mulaw test.mkv". Prior to this patch, libav and gstreamer can play that file, but VLC and mplayer will not. I hope that clears things up. - John _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
