On Mon, Jan 03, 2022 at 09:29:40PM +0100, Paul B Mahol wrote: > On Mon, Jan 3, 2022 at 9:14 PM Michael Niedermayer > wrote: > > > On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote: > > > On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer < > > michael@niedermayer.cc> > > > wrote: > > > > > > > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote: > > > > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes > > > > wrote: > > > > > > > > > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer > > > > > > wrote: > > > > > > > > > > > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf > > wrote: > > > > > > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote: > > > > > > > > >> It would be nice to have a public date set a few days into > > the > > > > > > future. > > > > > > > > > > > > > > > > > > yes, i intended to do that, unless people wanted a ASAP/NOW > > > > branch > > > > > > > > > > > > > > > > So what are the open topics, besides the Audio Channel Layout > > API? > > > > > > > > > > > > > > the mov issue was fixed, channels dont seem to happen > > > > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44 > > > > > > > that ive reported 1 day after the patch was posted and pinged 11 > > days > > > > > > later > > > > > > > > > > > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] > > > > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in > > > > single > > > > > > substream > > > > > > > 221074 sF 1123 0:00 To ffmpeg-devel (3,5K) └─> > > > > > > > > > > > > > > thats not branch blocking, a bugfix is just a normal backport > > > > > > > I dont have the file that > > 946493eb3e072b499909f606625480c928834a44 > > > > fixes > > > > > > > so trying to fix it is like working blindfolded, thats why ive > > so far > > > > > > > waited for the author to respond and take a look > > > > > > > > > > > > > > > > > > > As far as I can tell, the recent mlpdec changes seem to be > > intended to > > > > > > fix playback of streams made by our own experimental encoder, and > > not > > > > > > independent samples. > > > > > > > > How can that be reproduced ? > > > > I tried with a 5.1 stream and the decoded output is not changing with > > this > > > > patch > > > > > > > > > > > > > > So perhaps those should be reverted for a stable release (or > > > > > > generally), seeing as there is no response 2 months later, and no > > > > > > indication what they actually fix. > > > > > > > > > > > > The available whitepapers and bitstream syntax document on > > TrueHD/MLP > > > > > > also do not seem to support more then 2 channel in the first > > > > > > substream, limiting it to a stereo presentation in the first, up > > to 6 > > > > > > channel in the second, and up to 8 channel in the third substream > > (and > > > > > > 16 in the extended substream) > > > > > > > > > > > > > > > > This statement is not in sync with reality. > > > > > > > > > > I have sample that 946... fixes, single stream with > 2 channels. > > > > > > > > Iam not sure i understand what you mean exactly but > > > > > > > > the sample which it breaks is here: > > > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd > > > > > > > > can you look into this issue, you as author of the change maybe > > > > remember why you did it and so are better qualified to adjust it. > > > > > > > > > > Sorry but that sample was never decoded properly. As it is not mono and > > it > > > is not stereo. > > > > around the time of 3.2 it was decoded as mono and it sounds reasonable > > after that until 946... it was decoded as stereo with only the left channel > > after 946... it now doesnt decode at all > > > > it would be nice if we could support this kind of file > > > > To really support it, it needs both streams to be presented. yes thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle