LPCM 5.1/7.1 in M2TS channel order are incorrect
LPCM 5.1/7.1 in M2TS channel order is incorrect
Samples for 7.1: http://streams.videolan.org/issues/8526/
Samples for 5.1: http://streams.videolan.org/issues/8529/
Activity
added Component::Decoders Severity::normal Type::bug Version::master git + 1 deleted label
changed milestone to %2.1.0 release
LPCM 5.1 channel order is broken as well.
Sample: http://streams.videolan.org/incoming/LPCM_5.1_on_Track2-sound_pano_test.m2ts
Track #2 (closed) is the one with LPCM 5.1.
-
More samples, remuxed to TS and M2TS with only the LPCM track:
http://streams.videolan.org/incoming/LPCM_5.1-sound_pano_test.m2ts
http://streams.videolan.org/incoming/LPCM_5.1-sound_pano_test.ts
See #8529 (closed) for the noise issue.
-
Now that #8529 (closed) is fixed, we might be able to hear the wrong mapping...
A related issue, not sure if it requires a separate ticket- there's a regression in channel order with the Mac 2.1.0 nightlies not limited to m2ts. I first noticed it on a video with a TrueHD 6 channel encoding, but it also happens with these test files: http://www.lynnepublishing.com/surround/www_lynnemusic_com_surround_test.wma http://www.lynnepublishing.com/surround/www_lynnemusic_com_surround_test.ac3
2.0.7 nightlies working as intended.
Original author: gamnark
-
Got it. #8589 (closed) for the 2.1.0 specific issue.
Original author: gamnark
-
Order is "Left, Right, Center, Left surround, Rear surround left, Rear surround right, Right surround, LFE"
There are always 2,4,6 or 8 channels in the bitstream. So, for ex. mono second channel samples are always set to zero.
So, for ex. 5.1 channel order is L,R,C,LS,RS,lfe (6 channels), and for 5.0 L,R,C,LS,RS,x where x is "empty" channel
assigned to @etix and unassigned @MigrationBot