[FFmpeg-devel] 5.0 release

[Michael Niedermayer]

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 at 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 <h.leppkes at gmail.com>
> > wrote:
> > >
> > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > <michael at niedermayer.cc> 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

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220103/875377bb/attachment.sig>