[MPlayer-dev-eng] [PATCH] WAVE_FORMAT_EXTENSIBLE doesn't get added by mplayer during dumping to multichannel WAV

[Jason Tackaberry]

On Sun, 2010-02-21 at 00:39 +0100, Reimar Döffinger wrote:
> I'd prefer it if you used
> af_fmt2bits(ao_data.format)
> also to calculate frame_size instead of adding a global variable.

Ok.


> Also it should be a bit more maintainable and possibly closer
> to the "history" behind it to do
[...]

Sure.

Updated patch attached.


> ex falsum quodlibet?
> (SCNR, it took me a moment to figure out that you didn't mean
> "if channels is in the range with lower limit 8 and upper limit 5")

I admit to having paused a moment when typing my last email to verify
the expression wasn't nonsense. :)


> The real challenge would be to test on big-endian, 32 and 64 bit and
> all supported formats and playback in all kinds of alternative players
> etc, but that would be overkill.

I'd be surprised to learn it doesn't work on 64-bit, but I'm at least
able to test that (and will do tomorrow).  However I don't have access
to a big-endian box (having only recently decommissioned the last SPARC
server in my lab at work), so hopefully someone else can test that.


> And I'm against adding an option until someone finds a real issue.
> However, above code snippet reminds you, unless MPlayer specifically
> supports the "EXTENSIBLE" format, it's impossible that both AF_FORMAT_S32_LE
> and AF_FORMAT_FLOAT_LE will work with it.

Fair point.  It should be pretty straightforward to fix the demuxer to
understand WAVE_FORMAT_EXTENSIBLE at least enough to get the proper
format value from it.  I'll do that and attach a patch shortly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ao_pcm-waveformatextensible.diff
Type: text/x-patch
Size: 5645 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100220/3fa13e81/attachment.bin>