Wrong channel layout for FLAC 3/1 channels on playback

[Mango]

Summary of the bug:

The eac3to dev said this is an ffmpeg bug.

eac3to and ffmpeg both write correct channel layout tags to the FLAC when converting from DTS-HDMA 3/1.

But ffmpeg 2.7 outputs this error while encoding :"Channel layout not supported by Flac, output stream will have incorrect channel layout".

eac3to doesn't output such error and the dev said there is no reason to, because this layout has been supported by FLAC for the past 9 years, since since FLAC 1.1.3 (27-Nov-2006) changelog:

Encoder can now take WAVEFORMATEXTENSIBLE WAVE files as input; decoder will output WAVEFORMATEXTENSIBLE WAVE files when necessary to conform to the latest Microsoft specifications. Now properly supports AIFF and WAVEFORMATEXTENSIBLE multichannel input, performing necessary channel reordering both for encoding and decoding.

WAVEFORMATEXTENSIBLE channel mask is also saved to a tag on encoding and restored on decoding for situations when there is no natural mapping to FLAC channel assignments.

LAV filers and MPC-HC play this fine.

But kodi with ffmpeg 2.6.3 decodes a PCM 2/2 channels instead of 3/1. (as said above, ffmpeg 2.7 writes the correct 3/1 channel tag, with Channel positions: Front: L C R, Back: C).

FFMPEG should read this tag to properly playback a 3/1 channel FLAC. (this may probably also concern some other non-default FLAC channel mappings).

How to reproduce:

Create a 3/1 channel FLAC with ffmpeg (tested 2.7) or eac3to. Channel layout is written correctly by both.

Play back with an ffmpeg based player (tested 2.6.3). Channel layout on playback is wrongly 2/2 PCM instead of 3/1.

[gjdfgh]

What the fuck? You are reporting this because it does not work correctly in 2.6? Just sue 2.7.

[Mango]

No, read the report.

FFMPEG 2.7 is affected. It reports error "Channel layout not supported by Flac, output stream will have incorrect channel layout", when it shouldn't as this feature has been supported by FLAC for the past 9 years since FLAC 1.1.3 (27-Nov-2006), read the changelog.

[gjdfgh]

But ffmpeg 2.7 outputs this error while encoding :"Channel layout not supported by Flac, output stream will have incorrect channel layout".

Create a 3/1 channel FLAC with ffmpeg (tested 2.7) or eac3to. Channel layout is written correctly by both.

So what is it?

Is it even an encoding or decoding issue?

[Mango]

It is both an encoding and decoding issue.

Encoding because it outputs an error for no reason, as the playback is fine with the players that read the WAVEFORMATEXTENSIBLE channel mask tag that FLAC supports since year 2006. eac3to FLAC encoding has no such issue.

Decoding because ffmpeg based players play back 2F/2R channels instead of 3F/1R (in this example, other channel layouts may be affected as well). Playback with players that read the WAVEFORMATEXTENSIBLE tag (LAV filers, MPC-HC...) have no such issue.

[Elon Musk]

What about if you mux it in non-flac container? Does it play correctly too?

Warning is there for the reason.

[gjdfgh]

I hope you're aware that said software uses ffmpeg for decoding.

[Mango]

Replying to richardpl:

What about if you mux it in non-flac container? Does it play correctly too?

If the FLAC is muxed in MKV it's the same results.

[Hendrik]

ffmpeg can read the metadata just fine. FFmpeg itself properly uses it afaik, and if any ffmpeg-based player does not use it, its a problem of that player.

The error message on encoding can probably be downgraded to a warning, though.

[Mango]

Replying to gjdfgh:

I hope you're aware that said software uses ffmpeg for decoding.

I said it is working with LAV filters and MPC-HC, because LAV filters dev told me he specifically went out of his way to fix this (reading the WAVEFORMATEXTENSIBLE tag) and that it now works properly and also with MPC-HC.

FFMPEG based players that didn't specifically fix this don't work (play 2/2 channels instead of 3/1).

[Elon Musk]

There should not be need to read that tag. Instead channel layout from demuxer should be used instead of whatever is provided by decoder.

[Hendrik]

Replying to richardpl:

There should not be need to read that tag. Instead channel layout from demuxer should be used instead of whatever is provided by decoder.

It should do that now when you use both avformat and avcodec, iirc.

[Carl Eugen Hoyos]

Replying to Mango:

FFMPEG reports error "Channel layout not supported by Flac, output stream will have incorrect channel layout", when it shouldn't as this feature has been supported by FLAC for the past 9 years since FLAC 1.1.3 (27-Nov-2006), read the changelog.

Please provide the flac command line (including console output) that encodes such a flac file.

[Mango]

Replying to cehoyos:

Replying to Mango:

FFMPEG reports error "Channel layout not supported by Flac, output stream will have incorrect channel layout", when it shouldn't as this feature has been supported by FLAC for the past 9 years since FLAC 1.1.3 (27-Nov-2006), read the changelog.

Please provide the flac command line (including console output) that encodes such a flac file.

It is just ffmpeg with input.dts output.flac (input.dts is a DTS-HDMA 3/1)

Samples here:

Source DTS-HDMA 3.1:
​https://mega.nz/#!hMcmUIAY!CL0LXV71vCrQhK4iobcw5jJPIaOxsvXdT33K5jLvYCE

FLAC 3.1:
​​https://mega.nz/#!8RtjRb7Z!rBoJgPVTlP2cXYiY_evW53eILHU8VKwJq21Vst5Qgss

[Mango]

For those who don't know what this is about, this was posted by the LAV developer:

The tag is WAVEFORMATEXTENSIBLE_CHANNEL_MASK, which contains a hexadecimal value which corresponds to the speaker positions listed here:

​​https://msdn.microsoft.com/en-us/library/windows/desktop/dd757714(v=vs.85).aspx

It's contained within the FLAC headers as a vorbis comment, but Matroska just shoves all the FLAC headers into Codec Private Data so you'll find it there too.

MakeMKV adds the tag to every FLAC encode it produces, but EAC3To and FFMPEG only add it if the layout doesn't match the defaults. The official FLAC encoders/decoders support the tag as well, as does LAV.

[Carl Eugen Hoyos]

Replying to Mango:

The official FLAC encoders/decoders support the tag as well

Please provide the flac command line that allows to encode a 3.1 wav source file together with the console output.

[gjdfgh]

​​https://mega.nz/#!8RtjRb7Z!rBoJgPVTlP2cXYiY_evW53eILHU8VKwJq21Vst5Qgss

You were talking about "FLAC" files, but this is a mkv file with a FLAC audio stream.

[Carl Eugen Hoyos]

Replying to Mango:

this layout has been supported by FLAC for the past 9 years, since since FLAC 1.1.3

Please reopen this ticket if you can explain how I can reproduce above claim (I failed).

[Mango]

Replying to cehoyos:

Replying to Mango:

this layout has been supported by FLAC for the past 9 years, since since FLAC 1.1.3

Please reopen this ticket if you can explain how I can reproduce above claim (I failed).

I have already explained it above.

Since FLAC 1.1.3 (27-Nov-2006) (read the changelog, above) FLAC supports all the channel layouts that are not supported by default using the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.

This means, the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag should be read if it exists to get the correct channel positions.

Without reading this tag, the 3/1 channels (3 front 1 back) is played back as 2/2 (2 front 2 back), which is wrong.

Thanks.

[Mango]

Replying to gjdfgh:

​​https://mega.nz/#!8RtjRb7Z!rBoJgPVTlP2cXYiY_evW53eILHU8VKwJq21Vst5Qgss

You were talking about "FLAC" files, but this is a mkv file with a FLAC audio stream.

Playback has the same issue with both.

If you need the FLAC you can just demux it.

[Carl Eugen Hoyos]

Replying to Mango:

Replying to cehoyos:

Replying to Mango:

this layout has been supported by FLAC for the past 9 years, since since FLAC 1.1.3

Please reopen this ticket if you can explain how I can reproduce above claim (I failed).

I have already explained it above.

Since FLAC 1.1.3 (27-Nov-2006) (read the changelog, above) FLAC supports all the channel layouts that are not supported by default using the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.

Sorry, you misunderstand: This isn't about the Changelog.
Please explain how such a file can be encoded with the flac command line utility.

[Mango]

Replying to cehoyos:

Replying to Mango:

Replying to cehoyos:

Replying to Mango:

this layout has been supported by FLAC for the past 9 years, since since FLAC 1.1.3

Please reopen this ticket if you can explain how I can reproduce above claim (I failed).

I have already explained it above.

Since FLAC 1.1.3 (27-Nov-2006) (read the changelog, above) FLAC supports all the channel layouts that are not supported by default using the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.

Sorry, you misunderstand: This isn't about the Changelog.
Please explain how such a file can be encoded with the flac command line utility.

This bug report is about playing back a FLAC with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, and not about encoding.

Encoding with ffmpeg works fine (it sets the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag). You can see the above attached (link) of the DTS-HDMA and the resulting FLAC encoded with ffmpeg.

But to answer your question "Please explain how such a file can be encoded with the flac command line utility.":

You feed the FLAC encoder a wav and when there is no corresponding default FLAC channel mapping it will save the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag. (again, this is also in the changelog above).

This is also what eac3to and ffmpeg do.

If you open the file with mediainfo, you will see the
Channel positions : Front: L C R, Back: C

In the same way,
ffmpeg.exe -i "FLAC 3.1-sample.mkv" out.wav
will again preserve the channel layout.

So: encoding works fine.

The problem is with playback. The ffmpeg based playback tools give 2/2 instead of 3/1 as channel layout. ffplay shows 4.0 instead of 3/1.

Please confirm that:

1. ffplay (and the ffmpeg based tools) will play the correct channel layout (=WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag).

2. and please have ffplay display the correct channel layout instead of "Stream #0:0: Audio: flac, 48000 Hz, 4.0, s32 (24 bit) (default)" , have it show 3/1 and even better, also "Channel positions : Front: L C R, Back: C" as mediainfo does.

With this information we can then confirm that playback will have the correct channel layout.

Thanks.

edit: the same applies to ffprobe, it doesn't display the correct channel layout.

[Carl Eugen Hoyos]

Replying to Mango:

This bug report is about playing back a FLAC with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, and not about encoding.

That's surprising given that you wrote ffmpeg 2.7 outputs this error while encoding in your original report.

Anyway: Is your issue reproducible with the following command line?

$ ffmpeg -i input out.wav

(ffmpeg is the relevant application, not ffplay or ffprobe)
If yes, please provide the complete, uncut console output and your input sample to make this a valid ticket.

[Mango]

Replying to cehoyos:

Replying to Mango:

This bug report is about playing back a FLAC with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, and not about encoding.

That's surprising given that you wrote ffmpeg 2.7 outputs this error while encoding in your original report.

Anyway: Is your issue reproducible with the following command line?

$ ffmpeg -i input out.wav

(ffmpeg is the relevant application, not ffplay or ffprobe)
If yes, please provide the complete, uncut console output and your input sample to make this a valid ticket.

Yes, you are right. I get this error in red when encoding to FLAC (I don't get the error when encoding to WAV). Here is the console output:

---

C:\Video>ffmpeg.exe -i "Source DTS-HDMA-3.1-sample.dts" out.flac
ffmpeg version 2.7 Copyright (c) 2000-2015 the FFmpeg developers

built with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av

isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-l
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enab
le-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --en
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --ena
ble-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc

--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enabl

e-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --ena
ble-decklink --enable-zlib

libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 41.100 / 56. 41.100
libavformat 56. 36.100 / 56. 36.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 16.101 / 5. 16.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100

Input #0, dts, from 'Source DTS-HDMA-3.1-sample.dts':

Duration: N/A, start: 0.000000, bitrate: N/A

Stream #0:0: Audio: dts (DTS-HD MA), 48000 Hz, 4.0, fltp

[flac @ 00000000047178a0] encoding as 24 bits-per-sample
[flac @ 00000000047178a0] Channel layout not supported by Flac, output stream wi
ll have incorrect channel layout.
Output #0, flac, to 'out.flac':

Metadata:

encoder : Lavf56.36.100
WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0x107
Stream #0:0: Audio: flac, 48000 Hz, 4.0, s32 (24 bit), 128 kb/s
Metadata:

encoder : Lavc56.41.100 flac

Stream mapping:

Stream #0:0 -> #0:0 (dts (dca) -> flac (native))

Press [q] to stop, ? for help
size= 4122kB time=00:00:12.32 bitrate=2741.0kbits/s
video:0kB audio:4114kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.197755%

---

For out.flac, mediainfo reports the correct channel positions (which means ffmpeg has set the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag correctly):

Channel positions : Front: L C R, Back: C

As said above, the problem is that with ffmpeg based players, the playback has a wrong channel mapping as they are showing it as 2/2 instead of 3/1 (which means the ffmpeg players are ignoring the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag).

Thanks.

[Carl Eugen Hoyos]

Replying to Mango:

ffmpeg version 2.7 Copyright (c) 2000-2015 the FFmpeg developers

Please test current FFmpeg git head unless you want to report a regression or a security issue that is not reproducible with current FFmpeg.

For out.flac, mediainfo reports the correct channel positions (which means ffmpeg has set the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag correctly):

So there is no bug? I will close the ticket, if there still is an issue, please explain how I can reproduce with current FFmpeg.
Or does ffmpeg -i out.flac show an incorrect channel layout?

[Mango]

As you can see, ffmpeg wrote in the metadata:

Metadata:

encoder : Lavf56.36.100
WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0x107
Stream #0:0: Audio: flac, 48000 Hz, 4.0, s32 (24 bit), 128 kb/s

ffplay and ffprobe don't show this, they only show:

Metadata:

ENCODER : Lavf56.36.100

Duration: 00:00:12.32, start: 0.000000, bitrate: 2740 kb/s

Stream #0:0: Audio: flac, 48000 Hz, 4.0, s32 (24 bit)

The WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0x107 is missing.

Thanks.

[Mango]

Replying to cehoyos:

Replying to Mango:

ffmpeg version 2.7 Copyright (c) 2000-2015 the FFmpeg developers

Please test current FFmpeg git head unless you want to report a regression or a security issue that is not reproducible with current FFmpeg.

For out.flac, mediainfo reports the correct channel positions (which means ffmpeg has set the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag correctly):

So there is no bug? I will close the ticket, if there still is an issue, please explain how I can reproduce with current FFmpeg.
Or does ffmpeg -i out.flac show an incorrect channel layout?

Like ffplay and ffprobe, ffmpeg -i out.flac fails to show the WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0x107 which was written by ffmpeg (and ffmpeg based players wrongly play is as 2/2 instead of 3/1 channels):

Metadata:

ENCODER : Lavf56.36.100

Duration: 00:00:12.32, start: 0.000000, bitrate: 2740 kb/s

Stream #0:0: Audio: flac, 48000 Hz, 4.0, s32 (24 bit)

But the tag IS there, as mediainfo shows and LAV plays it correctly with the 3/1 channel layout.

And as said above:

ffmpeg playback is the problem (2/2 channels instead of 3/1) + the red error on encoding

The only purpose of this red error seems to be to inform that ffmpeg will play it back with a wrong channel mapping. Other tools (i.ex LAV, mediainfo), show the right channel mapping with this ffmpeg encoded flac).

edit: Please fix this problem. Thanks.

[gjdfgh]

OK, so it's strictly about decoding. Makes things easier.

Looking at this sample file again, it says: WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x107

0x107 is 0x100 (back center) + 4 (front center) + 2 (right) + 1 (left)

So 4.0 is correct. This file is not 3.1.

[Hendrik]

Indeed, 4.0 is what ffmpeg uses for L/R/C/BC, so it reads this fine.
The default 4 channel FLAC mapping would be L/R/BL/BR, which ffmpeg would call "quad", not "4.0".

The first thing you should have done is compare a file which does NOT have such a tag to a file which does have one. Then you would have instantly noticed that the behavior changes, which means ffmpeg reads the tag perfectly.

[Mango]

Replying to gjdfgh:

OK, so it's strictly about decoding. Makes things easier.

Looking at this sample file again, it says: WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x107

0x107 is 0x100 (back center) + 4 (front center) + 2 (right) + 1 (left)

So 4.0 is correct. This file is not 3.1.

Yes, but the layout is 3/1 as shown by mediainfo
Channel(s): 4 channels
Channel positions: Front: L C R, Back: C

This is also how the hardware Yamaha receiver will play the source DTS-HDMA.

Hardware Yamaha receiver info with DTS-HDMA source: 3/1.
Hardware Yamaha receiver info with flac played back with kodi (ffmpeg): PCM 2/2.

LAV filters plays it correctly as 3/1.

Thanks.

[Hendrik]

What you think is 3/1 is what ffmpeg calls 4.0
Any other application failing to use ffmpeg correctly is their fault, not ffmpegs fault - so report it to Kodi if they handle it improperly.

Note that playing over HDMI is another topic entirely, HDMI does not properly carry a channel layout when playing raw PCM, thats entirely unrelated to how the audio was encoded.

[Cigaes]

I do not know that “3/1” is a standard notation for a channel layout. Anyway, the usual convention is to put the subwoofer separately, not the rear channels.

[gjdfgh]

Channel positions: Front: L C R, Back: C

What makes you think this is 3.1? The ".1" usually means there should be a sub-woofer (LFE), and neither center nor back center are sub-woofers. What you have here is probably a speaker setup problem with kodi and others.

HDMI does not properly carry a channel layout when playing raw PCM,

Huh? That's news to me.

[Hendrik]

Replying to gjdfgh:

HDMI does not properly carry a channel layout when playing raw PCM,

Huh? That's news to me.

Maybe audio drivers just fail at it or the two HDMI receivers I tested were bad at their job, but at least on Windows trying to send different layouts of the same channel count usually results in the same layout being used for all variants, which is why I added a mode to pad it with empty channels to one of the "standard" modes.

[Mango]

Replying to Cigaes:

I do not know that “3/1” is a standard notation for a channel layout. Anyway, the usual convention is to put the subwoofer separately, not the rear channels.

I would think DTS and Dolby have established standards, so if they use such mappings it is a standard notation for a channel layout ?

But yes, this is one of the less used layouts.

[Cigaes]

AFAIK, DTS and Dolby use a dot/full-stop, not a slash, and the number after the dot is the number of subwoofers. Please give a reference if you disagree.

[gjdfgh]

Maybe audio drivers just fail at it or the two HDMI receivers I tested were bad at their job, but at least on Windows trying to send different layouts of the same channel count usually results in the same layout being used for all variants, which is why I added a mode to pad it with empty channels to one of the "standard" modes.

That sounds rather bad. But maybe the receivers you tested simply didn't support the specific layout you tried (this seems to happen often with obscure layouts).

[Mango]

Replying to heleppkes:

What you think is 3/1 is what ffmpeg calls 4.0
Any other application failing to use ffmpeg correctly is their fault, not ffmpegs fault - so report it to Kodi if they handle it improperly.

Note that playing over HDMI is another topic entirely, HDMI does not properly carry a channel layout when playing raw PCM, thats entirely unrelated to how the audio was encoded.

Ok, so VLC, kodi, etc.. are at fault. I'll report this to them. Thanks.

As I understand there is nothing wrong So:

1. Can you remove the red error on encoding?

2. have ffplay and ffprobe show the correct 3/1 (next to 4.0) and Channel positions: Front: L C R, Back: C like mediainfo so that we can see this important information.

Thanks.

[Hendrik]

Replying to gjdfgh:

Maybe audio drivers just fail at it or the two HDMI receivers I tested were bad at their job, but at least on Windows trying to send different layouts of the same channel count usually results in the same layout being used for all variants, which is why I added a mode to pad it with empty channels to one of the "standard" modes.

That sounds rather bad. But maybe the receivers you tested simply didn't support the specific layout you tried (this seems to happen often with obscure layouts).

I think I first noticed the problem on a 5.0 (ie. default 5.1 without sub), which would somehow swallow the center channel when played like this, I would think thats not too obscure, but shrug. Padding with empty channel was easy and ensures compatibility. :)

[gjdfgh]

Can you remove the red error on encoding?

What, now it's about encoding again?

[Mango]

Replying to gjdfgh:

Can you remove the red error on encoding?

What, now it's about encoding again?

As posted above and in the above console output, ffmpeg shows this red error on encoding the source dts:

[flac @ 00000000047178a0] Channel layout not supported by Flac, output stream wi
ll have incorrect channel layout.

The eac3to developper said he will not add any warning when encoding with eac3to as there is absolutely nothing wrong with a 3/1 stream (he said to go bug the players). So this should also be removed from ffmpeg.

Furthermore, as I said above, 3/1 is supported by FLAC since version 1.1.3 in 2006 with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.

So it IS supported by FLAC, but not as one of the standard layouts, it is supported with WAVEFORMATEXTENSIBLE.

Thanks.

[Mango]

Replying to Cigaes:

AFAIK, DTS and Dolby use a dot/full-stop, not a slash, and the number after the dot is the number of subwoofers. Please give a reference if you disagree.

The hardware Yamaha receiver shows this information:

DTS-HD MSTR
Channel: 4.0 (3/1/---)

I think FFMPEG should show the same with the FLAC (as posted above), so we have all the information together with Channel positions: Front: L C R, Back: C , like mediainfo.

This information is important imho.

Thanks.

[Cigaes]

Read your own message: “4.0”, exactly what other people were telling you all along. The extra information “3/1/---” is redundant: 4.0 is exactly that, nothing else; ffmpeg's output is already cluttered enough without extra redundant information.

[gjdfgh]

I think FFMPEG should show the same with the FLAC (as posted above), so we have all the information together with Channel positions: Front: L C R, Back: C , like mediainfo.

Prove it.

[Mango]

Replying to Cigaes:

Read your own message: “4.0”, exactly what other people were telling you all along. The extra information “3/1/---” is redundant: 4.0 is exactly that, nothing else; ffmpeg's output is already cluttered enough without extra redundant information.

Yes you are right. 4.0 is FL+FR+FC+BC (3/1)

Thanks.

[Mango]

This leaves the problem of the red error on encoding, which should not be there:

[flac @ 00000000047178a0] Channel layout not supported by Flac, output stream wi
ll have incorrect channel layout.

4.0 (3/1) is supported by FLAC since version 1.1.3 in 2006 with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.

So it IS supported by FLAC, but not as one of the standard layouts, it is supported with WAVEFORMATEXTENSIBLE.

If the message should be kept, then is should be replaced with a warning (and not an error), perhaps something like "Some broken players may output this stream with an incorrect channel layout".

Ex:
LAV and MPC-HC play it correctly.
VLC and kodi play it wrong as 2F/2R

Thanks.

[gjdfgh]

Ex:

LAV and MPC-HC play it correctly.
VLC and kodi play it wrong as 2F/2R

Did you actually confirm that these ignore the channel layout?

[Mango]

Replying to gjdfgh:

Ex:

LAV and MPC-HC play it correctly.
VLC and kodi play it wrong as 2F/2R

Did you actually confirm that these ignore the channel layout?

Yes, listening to the audio clearly results in wrong channel positioning compared to the source DTS-HDMA or the FLAC with players that play it correctly.

[gjdfgh]

This is not the same thing. You could have fucked up the conversion. How is that so hard to understand.

[Mango]

Replying to gjdfgh:

This is not the same thing. You could have fucked up the conversion. How is that so hard to understand.

So ffmpeg could have fucked up (as you say) the conversion? Good I came here then to report the bug.

As I said, I tried converting with ffmpeg and eac3to. Results are the same.

And if some players play the flac right and some not, there is a problem with some players. No ?

As I said:

LAV and MPC-HC play it correctly.
VLC and kodi play it wrong as 2F/2R

This issue was also investigated and acknowledged by eac3to and LAV filter developers.

The LAV dev said he specifically had to fix LAV to use the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag. He also said MPC-HC was playing it correctly, but VLC was broken in this regard, and he also contributed to the VLC bug tracker to get this fixed.

edit: anyway, as per above, playback issues aren't ffmpeg's problems according to the people here. The problem now is the red error on encoding.

[Elon Musk]

I see no input file(s).
If this is still problematic, please provide files and way to reproduce issue.