diff mbox

[FFmpeg-devel,1/2] opus_pvq: add resynth support and band encoding cost function

Message ID 20170412222635.26793-1-atomnuker@gmail.com
State Accepted
Commit 3f1c527bf55537eb15da4c1384c0f4a08b08e1f3
Headers show

Commit Message

Rostislav Pehlivanov April 12, 2017, 10:26 p.m. UTC
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
---
 libavcodec/opus_pvq.c | 154 ++++++++++++++++++++++++++++++++++++++++++++------
 libavcodec/opus_pvq.h |   3 +
 2 files changed, 141 insertions(+), 16 deletions(-)

Comments

Carl Eugen Hoyos April 12, 2017, 10:50 p.m. UTC | #1
2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:

> +        /* Undo the sample reorganization going from time order to frequency order */
> +        if (B0 > 1)
> +            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
> +                                     B0<<recombine, longblocks);

Is this the same code as in opus/celt/bands.c?
Who wrote it?

Carl Eugen
Rostislav Pehlivanov April 13, 2017, 2:02 a.m. UTC | #2
On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>
> > +        /* Undo the sample reorganization going from time order to
> frequency order */
> > +        if (B0 > 1)
> > +            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
> > +                                     B0<<recombine, longblocks);
>
> Is this the same code as in opus/celt/bands.c?
> Who wrote it?
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

This exact line is also on line 1206 of the same file for PVQ decoding .
Most of the PVQ encoder is copied from our decoder since they're very
similar. This commit just copies more.
The reason why you can find the same string in libopus is because that
decoder was cut down, modified and ported as our native decoder. I have
used no libopus code in my encoder, I did everything from scratch plus
whatever code the decoder had.
Carl Eugen Hoyos April 13, 2017, 6:13 a.m. UTC | #3
2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>>
>> > +        /* Undo the sample reorganization going from time order to
>> > frequency order */
>> > +        if (B0 > 1)
>> > +            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
>> > +                                     B0<<recombine, longblocks);
>>
>> Is this the same code as in opus/celt/bands.c?
>> Who wrote it?
>
> This exact line is also on line 1206 of the same file for PVQ decoding .
> Most of the PVQ encoder is copied from our decoder since they're very
> similar. This commit just copies more.

> The reason why you can find the same string in libopus is because that
> decoder was cut down, modified and ported as our native decoder.

Then I suggest you add the missing copyright notices to the decoder
and the encoder.

Thank you for the explanation, Carl Eugen
Paul B Mahol April 13, 2017, 6:44 a.m. UTC | #4
On 4/13/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>> On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>
>>> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>>>
>>> > +        /* Undo the sample reorganization going from time order to
>>> > frequency order */
>>> > +        if (B0 > 1)
>>> > +            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
>>> > +                                     B0<<recombine, longblocks);
>>>
>>> Is this the same code as in opus/celt/bands.c?
>>> Who wrote it?
>>
>> This exact line is also on line 1206 of the same file for PVQ decoding .
>> Most of the PVQ encoder is copied from our decoder since they're very
>> similar. This commit just copies more.
>
>> The reason why you can find the same string in libopus is because that
>> decoder was cut down, modified and ported as our native decoder.
>
> Then I suggest you add the missing copyright notices to the decoder
> and the encoder.

Your suggestions should always be ignored.
Carl Eugen Hoyos April 13, 2017, 7:10 a.m. UTC | #5
2017-04-13 8:44 GMT+02:00 Paul B Mahol <onemda@gmail.com>:
> On 4/13/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>>> On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>
>>>> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>>>>
>>>> > +        /* Undo the sample reorganization going from time order to
>>>> > frequency order */
>>>> > +        if (B0 > 1)
>>>> > +            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
>>>> > +                                     B0<<recombine, longblocks);
>>>>
>>>> Is this the same code as in opus/celt/bands.c?
>>>> Who wrote it?
>>>
>>> This exact line is also on line 1206 of the same file for PVQ decoding .
>>> Most of the PVQ encoder is copied from our decoder since they're very
>>> similar. This commit just copies more.
>>
>>> The reason why you can find the same string in libopus is because that
>>> decoder was cut down, modified and ported as our native decoder.
>>
>> Then I suggest you add the missing copyright notices to the decoder
>> and the encoder.
>
> Your suggestions should always be ignored.

Would you like to elaborate or are you just trolling?

Carl Eugen
Rostislav Pehlivanov April 13, 2017, 7:51 a.m. UTC | #6
On 13 April 2017 at 07:13, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> > On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >
> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> >>
> >> > +        /* Undo the sample reorganization going from time order to
> >> > frequency order */
> >> > +        if (B0 > 1)
> >> > +            celt_interleave_hadamard(f->scratch, X, N_B >>
> recombine,
> >> > +                                     B0<<recombine, longblocks);
> >>
> >> Is this the same code as in opus/celt/bands.c?
> >> Who wrote it?
> >
> > This exact line is also on line 1206 of the same file for PVQ decoding .
> > Most of the PVQ encoder is copied from our decoder since they're very
> > similar. This commit just copies more.
>
> > The reason why you can find the same string in libopus is because that
> > decoder was cut down, modified and ported as our native decoder.
>
> Then I suggest you add the missing copyright notices to the decoder
> and the encoder.
>
> Thank you for the explanation, Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

There's nothing to do:
> * Copyright (c) 2012 Andrew D'Addesio
> * Copyright (c) 2013-2014 Mozilla Corporation
> * Copyright (c) 2017 Rostislav Pehlivanov <atomnuker@gmail.com>

Mozilla relicensed the decoder to LGPL when it was ported.
Carl Eugen Hoyos April 14, 2017, 4:50 a.m. UTC | #7
2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> On 13 April 2017 at 07:13, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>> > On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> >
>> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>> >>
>> >> > +        /* Undo the sample reorganization going from time
>> >> > order to frequency order */
>> >> > +        if (B0 > 1)
>> >> > +            celt_interleave_hadamard(f->scratch, X,
>> >> > N_B >> recombine,
>> >> > +                                     B0<<recombine, longblocks);
>> >>
>> >> Is this the same code as in opus/celt/bands.c?
>> >> Who wrote it?
>> >
>> > This exact line is also on line 1206 of the same file for PVQ decoding .
>> > Most of the PVQ encoder is copied from our decoder since they're very
>> > similar. This commit just copies more.
>>
>> > The reason why you can find the same string in libopus is because that
>> > decoder was cut down, modified and ported as our native decoder.
>>
>> Then I suggest you add the missing copyright notices to the decoder
>> and the encoder.

> There's nothing to do:
>> * Copyright (c) 2012 Andrew D'Addesio
>> * Copyright (c) 2013-2014 Mozilla Corporation
>> * Copyright (c) 2017 Rostislav Pehlivanov <atomnuker@gmail.com>
>
> Mozilla relicensed the decoder to LGPL when it was ported.

Sorry, I don't understand:
You write above that FFmpeg's opus decoder is based on libopus,
this also explains the similar code I saw (above). libopus is - afaict -
copyright Xiph.Org Foundation.
I suggested to add this copyright to our codec and your answer
is that there is nothing to do but I don't see Xiph mentioned: What
am I missing?
You then continue that the code was relicensed to LGPL: How is
that related to the missing copyright notice?

Thank you, Carl Eugen
Rostislav Pehlivanov April 14, 2017, 11:11 a.m. UTC | #8
On 14 April 2017 at 05:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> > On 13 April 2017 at 07:13, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >
> >> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> >> > On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com>
> wrote:
> >> >
> >> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com
> >:
> >> >>
> >> >> > +        /* Undo the sample reorganization going from time
> >> >> > order to frequency order */
> >> >> > +        if (B0 > 1)
> >> >> > +            celt_interleave_hadamard(f->scratch, X,
> >> >> > N_B >> recombine,
> >> >> > +                                     B0<<recombine, longblocks);
> >> >>
> >> >> Is this the same code as in opus/celt/bands.c?
> >> >> Who wrote it?
> >> >
> >> > This exact line is also on line 1206 of the same file for PVQ
> decoding .
> >> > Most of the PVQ encoder is copied from our decoder since they're very
> >> > similar. This commit just copies more.
> >>
> >> > The reason why you can find the same string in libopus is because that
> >> > decoder was cut down, modified and ported as our native decoder.
> >>
> >> Then I suggest you add the missing copyright notices to the decoder
> >> and the encoder.
>
> > There's nothing to do:
> >> * Copyright (c) 2012 Andrew D'Addesio
> >> * Copyright (c) 2013-2014 Mozilla Corporation
> >> * Copyright (c) 2017 Rostislav Pehlivanov <atomnuker@gmail.com>
> >
> > Mozilla relicensed the decoder to LGPL when it was ported.
>
> Sorry, I don't understand:
> You write above that FFmpeg's opus decoder is based on libopus,
> this also explains the similar code I saw (above). libopus is - afaict -
> copyright Xiph.Org Foundation.
> I suggested to add this copyright to our codec and your answer
> is that there is nothing to do but I don't see Xiph mentioned: What
> am I missing?
> You then continue that the code was relicensed to LGPL: How is
> that related to the missing copyright notice?
>
> Thank you, Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Point is, I have used only code from libavcodec/opus_pvq.c from the FFmpeg
project. I don't have to do anything as all credit has been given where
due. If libavcodec/opus_pvq.c's license header is wrong, it's not and
wasn't my problem, the code's been in libavcodec for 4 years now. You'll
have to submit a separate patch if you believe that's the case. And I
advise you to contact all the authors as well as libav from whom this code
was merged first.
As I see no technical issues not license issues I've pushed the patch.
Carl Eugen Hoyos April 14, 2017, 12:30 p.m. UTC | #9
2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> On 14 April 2017 at 05:50, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>> > On 13 April 2017 at 07:13, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> >
>> >> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>> >> > On 12 April 2017 at 23:50, Carl Eugen Hoyos <ceffmpeg@gmail.com>
>> wrote:
>> >> >
>> >> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com
>> >:
>> >> >>
>> >> >> > +        /* Undo the sample reorganization going from time
>> >> >> > order to frequency order */
>> >> >> > +        if (B0 > 1)
>> >> >> > +            celt_interleave_hadamard(f->scratch, X,
>> >> >> > N_B >> recombine,
>> >> >> > +                                     B0<<recombine, longblocks);
>> >> >>
>> >> >> Is this the same code as in opus/celt/bands.c?
>> >> >> Who wrote it?
>> >> >
>> >> > This exact line is also on line 1206 of the same file for PVQ
>> decoding .
>> >> > Most of the PVQ encoder is copied from our decoder since they're very
>> >> > similar. This commit just copies more.
>> >>
>> >> > The reason why you can find the same string in libopus is because that
>> >> > decoder was cut down, modified and ported as our native decoder.
>> >>
>> >> Then I suggest you add the missing copyright notices to the decoder
>> >> and the encoder.
>>
>> > There's nothing to do:
>> >> * Copyright (c) 2012 Andrew D'Addesio
>> >> * Copyright (c) 2013-2014 Mozilla Corporation
>> >> * Copyright (c) 2017 Rostislav Pehlivanov <atomnuker@gmail.com>
>> >
>> > Mozilla relicensed the decoder to LGPL when it was ported.
>>
>> Sorry, I don't understand:
>> You write above that FFmpeg's opus decoder is based on libopus,
>> this also explains the similar code I saw (above). libopus is - afaict -
>> copyright Xiph.Org Foundation.
>> I suggested to add this copyright to our codec and your answer
>> is that there is nothing to do but I don't see Xiph mentioned: What
>> am I missing?
>> You then continue that the code was relicensed to LGPL: How is
>> that related to the missing copyright notice?

> Point is, I have used only code from libavcodec/opus_pvq.c from
> the FFmpeg project. I don't have to do anything as all credit has
> been given where due.

I don't understand:
The file opus_pvq.c contains copyright notices from Andrew
D'Addesio and Mozilla. If you have used code from opus_pvq.c,
shouldn't you add these copyright notices to the opus encoder?

> If libavcodec/opus_pvq.c's license header is wrong, it's not and
> wasn't my problem, the code's been in libavcodec for 4 years now.

This is (of course!) true, it is the problem of all FFmpeg developers
(including the two of us who realized it first).

> You'll have to submit a separate patch if you believe that's the case.

Since you explained above who the actual authors of opus_pvq.c are,
I was hoping you would fix the copyright notice: I don't know who
wrote it (but from a very quick look, your analysis that it was written
by the libopus authors is correct and makes sense).
Why don't you want to fix it?

> And I advise you to contact all the authors as well as libav from
> whom this code was merged first.

We know that the avconv developers are violating the
copyright of many people, we fix that in the FFmpeg code as
soon as we are aware of it, there are many examples in gitlog.
I don't see how this case would be different.

> As I see no technical issues not license issues I've pushed the patch.

I am not sure that this was such a good idea (esp. as you have
explained the issue) but fortunately, this the license issues can still
be fixed.

Carl Eugen
Carl Eugen Hoyos April 14, 2017, 12:34 p.m. UTC | #10
2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos <ceffmpeg@gmail.com>:
> 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:

>> Point is, I have used only code from libavcodec/opus_pvq.c from
>> the FFmpeg project. I don't have to do anything as all credit has
>> been given where due.
>
> I don't understand:
> The file opus_pvq.c contains copyright notices from Andrew
> D'Addesio and Mozilla. If you have used code from opus_pvq.c,
> shouldn't you add these copyright notices to the opus encoder?

Or did you mean that you only used code that was already
present in libavcodec/opus_pvq.c without copying anything
to the new files you wrote (what "using" implied to me)?

Carl Eugen
wm4 April 14, 2017, 12:50 p.m. UTC | #11
On Fri, 14 Apr 2017 14:30:28 +0200
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> We know that the avconv developers are violating the
> copyright of many people, we fix that in the FFmpeg code as
> soon as we are aware of it, there are many examples in gitlog.
> I don't see how this case would be different.

Defamation is not only against the CoC - it's also illegal. In addition
to this, your behavior is quite embarrassing to the FFmpeg behavior,
especially since your dictatorship over the bug tracker makes you
sometimes seem "representative" of FFmpeg - which you are not, but
nonetheless hurts our reputation.
Rostislav Pehlivanov April 14, 2017, 4:18 p.m. UTC | #12
On 14 April 2017 at 13:34, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos <ceffmpeg@gmail.com>:
> > 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>
> >> Point is, I have used only code from libavcodec/opus_pvq.c from
> >> the FFmpeg project. I don't have to do anything as all credit has
> >> been given where due.
> >
> > I don't understand:
> > The file opus_pvq.c contains copyright notices from Andrew
> > D'Addesio and Mozilla. If you have used code from opus_pvq.c,
> > shouldn't you add these copyright notices to the opus encoder?
>
> Or did you mean that you only used code that was already
> present in libavcodec/opus_pvq.c without copying anything
> to the new files you wrote (what "using" implied to me)?
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yes, that is what I mean.
Initially, all code from opus_pvq.c was in opus_celt.c. To tidy the decoder
and reuse the code there for the encoder, I created opus_pvq.c, copying the
header and keeping all the copyright as is. I then implemented encoding
functionality (modifying existing code and writing new code) and added my
copyright there as well. That's all.
Clément Bœsch April 14, 2017, 9:27 p.m. UTC | #13
On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
[...]
> We know that the avconv developers are violating the
> copyright of many people, we fix that in the FFmpeg code as
> soon as we are aware of it, there are many examples in gitlog.

This is a serious accusation, what are you referring to?

Please be careful when using "we" in such declaration, you are mistaken if
you think this attitude represents the FFmpeg project.
Carl Eugen Hoyos April 14, 2017, 10:28 p.m. UTC | #14
2017-04-14 23:27 GMT+02:00 Clément Bœsch <u@pkh.me>:
> On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
> [...]
>> We know that the avconv developers are violating the
>> copyright of many people, we fix that in the FFmpeg code as
>> soon as we are aware of it, there are many examples in gitlog.
>
> This is a serious accusation, what are you referring to?

To the same (many) commits in the avconv repository that
violate the copyright of FFmpeg developers as many times
before - sorry, I don't understand: Are you implying you don't
remember such a commit?

> Please be careful when using "we" in such declaration, you are
> mistaken if you think this attitude represents the FFmpeg project.

I see your point about "we" but don't you agree that our gitlog
implies exactly this: That we - FFmpeg - believe that such commits
exist?

Carl Eugen
Carl Eugen Hoyos April 14, 2017, 10:29 p.m. UTC | #15
2017-04-14 14:50 GMT+02:00 wm4 <nfxjfg@googlemail.com>:

> especially since your dictatorship over the bug tracker makes you

This reminds me: Who is supposed to fix the regressions
that you create and that users report on trac?

Please try to refrain from such accusations.

Thank you, Carl Eugen
Carl Eugen Hoyos April 14, 2017, 10:35 p.m. UTC | #16
2017-04-14 18:18 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
> On 14 April 2017 at 13:34, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos <ceffmpeg@gmail.com>:
>> > 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov <atomnuker@gmail.com>:
>>
>> >> Point is, I have used only code from libavcodec/opus_pvq.c from
>> >> the FFmpeg project. I don't have to do anything as all credit has
>> >> been given where due.
>> >
>> > I don't understand:
>> > The file opus_pvq.c contains copyright notices from Andrew
>> > D'Addesio and Mozilla. If you have used code from opus_pvq.c,
>> > shouldn't you add these copyright notices to the opus encoder?
>>
>> Or did you mean that you only used code that was already
>> present in libavcodec/opus_pvq.c without copying anything
>> to the new files you wrote (what "using" implied to me)?

> Yes, that is what I mean.
> Initially, all code from opus_pvq.c was in opus_celt.c. To tidy the decoder
> and reuse the code there for the encoder, I created opus_pvq.c, copying the
> header and keeping all the copyright as is. I then implemented encoding
> functionality (modifying existing code and writing new code) and added my
> copyright there as well. That's all.

Thank you for the clarification, patch sent.

Carl Eugen
wm4 April 14, 2017, 11:49 p.m. UTC | #17
On Sat, 15 Apr 2017 00:29:44 +0200
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-14 14:50 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
> 
> > especially since your dictatorship over the bug tracker makes you  
> 
> This reminds me: Who is supposed to fix the regressions
> that you create and that users report on trac?

I know nothing of such regressions, which apparently marks your total
failure to properly drainage issues on the bug tracker and reporting
issues to the responsible developers. What are you doing on the bug
tracker again, other than detracting people from the ffmpeg project?

> Please try to refrain from such accusations.

It's not an accusation if it's fact.
wm4 April 14, 2017, 11:58 p.m. UTC | #18
On Sat, 15 Apr 2017 00:28:19 +0200
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-14 23:27 GMT+02:00 Clément Bœsch <u@pkh.me>:
> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
> > [...]  
> >> We know that the avconv developers are violating the
> >> copyright of many people, we fix that in the FFmpeg code as
> >> soon as we are aware of it, there are many examples in gitlog.  
> >
> > This is a serious accusation, what are you referring to?  
> 
> To the same (many) commits in the avconv repository that
> violate the copyright of FFmpeg developers as many times
> before - sorry, I don't understand: Are you implying you don't
> remember such a commit?

Of course you keep repeating your defamation without providing proof,
ever.

> > Please be careful when using "we" in such declaration, you are
> > mistaken if you think this attitude represents the FFmpeg project.  
> 
> I see your point about "we" but don't you agree that our gitlog
> implies exactly this: That we - FFmpeg - believe that such commits
> exist?

You don't speak for the FFmpeg project (fortunately).
Ivan Kalvachev April 15, 2017, 12:14 a.m. UTC | #19
On 4/15/17, wm4 <nfxjfg@googlemail.com> wrote:
> On Sat, 15 Apr 2017 00:28:19 +0200
> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-14 23:27 GMT+02:00 Clément Bœsch <u@pkh.me>:
>> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
>> > [...]
>> >> We know that the avconv developers are violating the
>> >> copyright of many people, we fix that in the FFmpeg code as
>> >> soon as we are aware of it, there are many examples in gitlog.
>> >
>> > This is a serious accusation, what are you referring to?
>>
>> To the same (many) commits in the avconv repository that
>> violate the copyright of FFmpeg developers as many times
>> before - sorry, I don't understand: Are you implying you don't
>> remember such a commit?
>
> Of course you keep repeating your defamation without providing proof,
> ever.

http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution

I found the above link in the "Reintroducing FFmpeg to Debian" thread (2014).
It still works :D

I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio)
about proper attribution to the changes done by multiple Libav developers when
merging ffvp9. (AKA who exactly changed what).
wm4 April 15, 2017, 12:35 a.m. UTC | #20
On Sat, 15 Apr 2017 03:14:12 +0300
Ivan Kalvachev <ikalvachev@gmail.com> wrote:

> On 4/15/17, wm4 <nfxjfg@googlemail.com> wrote:
> > On Sat, 15 Apr 2017 00:28:19 +0200
> > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >  
> >> 2017-04-14 23:27 GMT+02:00 Clément Bœsch <u@pkh.me>:  
> >> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
> >> > [...]  
> >> >> We know that the avconv developers are violating the
> >> >> copyright of many people, we fix that in the FFmpeg code as
> >> >> soon as we are aware of it, there are many examples in gitlog.  
> >> >
> >> > This is a serious accusation, what are you referring to?  
> >>
> >> To the same (many) commits in the avconv repository that
> >> violate the copyright of FFmpeg developers as many times
> >> before - sorry, I don't understand: Are you implying you don't
> >> remember such a commit?  
> >
> > Of course you keep repeating your defamation without providing proof,
> > ever.  
> 
> http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution
> 
> I found the above link in the "Reintroducing FFmpeg to Debian" thread (2014).
> It still works :D
> 
> I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio)
> about proper attribution to the changes done by multiple Libav developers when
> merging ffvp9. (AKA who exactly changed what).

Legally, all these copyright headers are meaningless, as long as the
license is correct.

If they weren't, FFmpeg would be in trouble for changing the copyright
headers of all files added by Libav from "Libav" to "FFmpeg".

It's possible that Libav is not always careful with attribution, but
it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
it was ported from MPlayer GPL code, and the author could not be
contacted. Recently, I contacted the same author about relicensing the
same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
explicitly denied relicensing. So if I had been cehoyos, I probably
wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
not cehoyos). I think nowadays af_pan.c certainly does not violate the
original author's copyright though, because absolutely all code was
removed/replaced.
Carl Eugen Hoyos April 15, 2017, 5:55 a.m. UTC | #21
2017-04-15 2:35 GMT+02:00 wm4 <nfxjfg@googlemail.com>:

> Legally, all these copyright headers are meaningless, as long as the
> license is correct.

You are joking, right?

> If they weren't, FFmpeg would be in trouble for changing the copyright
> headers of all files added by Libav from "Libav" to "FFmpeg".

Nobody is talking about the project name.

> It's possible that Libav is not always careful with attribution, but
> it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
> it was ported from MPlayer GPL code, and the author could not be
> contacted. Recently, I contacted the same author about relicensing the
> same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> explicitly denied relicensing. So if I had been cehoyos, I probably
> wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
> not cehoyos). I think nowadays af_pan.c certainly does not violate the
> original author's copyright though, because absolutely all code was
> removed/replaced.

Do I understand correctly that you are neither defaming Clement nor
doing something that is illegal?

Carl Eugen
wm4 April 15, 2017, 1:06 p.m. UTC | #22
On Sat, 15 Apr 2017 07:55:50 +0200
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-15 2:35 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
> 
> > Legally, all these copyright headers are meaningless, as long as the
> > license is correct.  
> 
> You are joking, right?

Well, are you joking? While it may seem so, you apparently aren't.

> > If they weren't, FFmpeg would be in trouble for changing the copyright
> > headers of all files added by Libav from "Libav" to "FFmpeg".  
> 
> Nobody is talking about the project name.

OK?

> > It's possible that Libav is not always careful with attribution, but
> > it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
> > it was ported from MPlayer GPL code, and the author could not be
> > contacted. Recently, I contacted the same author about relicensing the
> > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> > explicitly denied relicensing. So if I had been cehoyos, I probably
> > wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
> > not cehoyos). I think nowadays af_pan.c certainly does not violate the
> > original author's copyright though, because absolutely all code was
> > removed/replaced.  
> 
> Do I understand correctly that you are neither defaming Clement nor
> doing something that is illegal?

Is that some sort of trick question? I'm doing neither. But what _you_
do is defaming the entire Libav project (and possibly me), which is
illegal and against the FFmpeg CoC.
Jean-Baptiste Kempf April 15, 2017, 1:53 p.m. UTC | #23
Hi,

On Sat, 15 Apr 2017, at 02:35, wm4 wrote:
> > I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio)
> > about proper attribution to the changes done by multiple Libav developers when
> > merging ffvp9. (AKA who exactly changed what).
> 
> Legally, all these copyright headers are meaningless, as long as the
> license is correct.

+1
Especially in countries with civil laws that have inalienable moral
author rights (where FFmpeg and its forks were always developed)

> If they weren't, FFmpeg would be in trouble for changing the copyright
> headers of all files added by Libav from "Libav" to "FFmpeg".

+1
See the copyright on collaborative projects.

> It's possible that Libav is not always careful with attribution, but
> it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
> it was ported from MPlayer GPL code, and the author could not be
> contacted.

Refusal to answer does not allow in any way relicensing.

> Recently, I contacted the same author about relicensing the
> same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> explicitly denied relicensing. So if I had been cehoyos, I probably
> wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
> not cehoyos). I think nowadays af_pan.c certainly does not violate the
> original author's copyright though, because absolutely all code was
> removed/replaced.

Rewriting based on the same ideas also does not change the copyright.
It is a derivative work under the Berne convention.
I know it's not cool, but that's the international IP laws.
Carl Eugen Hoyos April 15, 2017, 2:33 p.m. UTC | #24
2017-04-15 15:06 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
> On Sat, 15 Apr 2017 07:55:50 +0200
> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-04-15 2:35 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
>>
>> > Legally, all these copyright headers are meaningless, as long as the
>> > license is correct.
>>
>> You are joking, right?
>
> Well, are you joking? While it may seem so, you apparently aren't.

I am not joking:
The first paragraph of all open source licenses I know of say something
similar to "you may distribute this source code as long as you
don't change above copyright notice". If you say now that this
copyright notice is meaningless, you are either joking or - well,
you can imagine.

>> > If they weren't, FFmpeg would be in trouble for changing the copyright
>> > headers of all files added by Libav from "Libav" to "FFmpeg".
>>
>> Nobody is talking about the project name.
>
> OK?

We are not talking about the project name in the license text
(it of course has to be adjusted), I am talking about the
copyright notice above.

>> > It's possible that Libav is not always careful with attribution, but
>> > it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
>> > it was ported from MPlayer GPL code, and the author could not be
>> > contacted. Recently, I contacted the same author about relicensing the
>> > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
>> > explicitly denied relicensing. So if I had been cehoyos, I probably
>> > wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
>> > not cehoyos). I think nowadays af_pan.c certainly does not violate the
>> > original author's copyright though, because absolutely all code was
>> > removed/replaced.
>>
>> Do I understand correctly that you are neither defaming Clement nor
>> doing something that is illegal?
>
> Is that some sort of trick question? I'm doing neither.

Clement says that he wrote the code he committed by himself and
that it is not based on MPlayer code. You say he violated somebody's
copyright: Who is defaming anybody here?

> But what _you_ do is defaming the entire Libav project

No.
I am (to quote you) stating "facts" namely that 1) FFmpeg's
gitlog contains many commits that indicate avconv developers
have not correctly given attribution to FFmpeg developers
when moving or copying code and 2) that other commits in
addition to those linked by Ivan (probably myself in the past,
I didn't remember) exist.

> (and possibly me),

I don't remember doing this.

> which is illegal

Please stop calling my actions illegal

Carl Eugen
Carl Eugen Hoyos April 15, 2017, 2:37 p.m. UTC | #25
2017-04-15 15:53 GMT+02:00 Jean-Baptiste Kempf <jb@videolan.org>:
> Hi,
>
> On Sat, 15 Apr 2017, at 02:35, wm4 wrote:
>> > I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio)
>> > about proper attribution to the changes done by multiple Libav developers when
>> > merging ffvp9. (AKA who exactly changed what).
>>
>> Legally, all these copyright headers are meaningless, as long as the
>> license is correct.
>
> +1
> Especially in countries with civil laws that have inalienable moral
> author rights (where FFmpeg and its forks were always developed)

I believe you are mixing up things here:
We had a discussion in the past where you (most likely correctly)
argued that no copyright notice is necessary to "get" (I don't know
a better word) copyright, and I said it is still nice(r) to have copyright
notices on new files written by a developer. This is not what this
discussion is about.

I sincerely hope you are not implying that it is ok to remove
"(c) Jean-Baptiste Kempf" from the top of GPL (or LGPL) files
you wrote when copying them into another open-source project.

Carl Eugen
wm4 April 15, 2017, 4:04 p.m. UTC | #26
On Sat, 15 Apr 2017 16:33:41 +0200
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-04-15 15:06 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
> > On Sat, 15 Apr 2017 07:55:50 +0200
> > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >  
> >> 2017-04-15 2:35 GMT+02:00 wm4 <nfxjfg@googlemail.com>:
> >>  
> >> > Legally, all these copyright headers are meaningless, as long as the
> >> > license is correct.  
> >>
> >> You are joking, right?  
> >
> > Well, are you joking? While it may seem so, you apparently aren't.  
> 
> I am not joking:

Oh that's unfortunate.

> The first paragraph of all open source licenses I know of say something
> similar to "you may distribute this source code as long as you
> don't change above copyright notice". If you say now that this
> copyright notice is meaningless, you are either joking or - well,
> you can imagine.

So changing the project name (like FFmpeg does it all the time) does
not constitute changing the copyright notice? Or does FFmpeg violate
the law? Or are you joking?

Some files don't even have a name in the copyright notice. And I bet no
file lists all copyright headers in the notice. Thus it's meaningless.

What really counts is who actually has the copyright on a piece of
code.

> >> > It's possible that Libav is not always careful with attribution, but
> >> > it's the same with FFmpeg. For example, af_pan.c is LGPL, even though
> >> > it was ported from MPlayer GPL code, and the author could not be
> >> > contacted. Recently, I contacted the same author about relicensing the
> >> > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> >> > explicitly denied relicensing. So if I had been cehoyos, I probably
> >> > wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
> >> > not cehoyos). I think nowadays af_pan.c certainly does not violate the
> >> > original author's copyright though, because absolutely all code was
> >> > removed/replaced.  
> >>
> >> Do I understand correctly that you are neither defaming Clement nor
> >> doing something that is illegal?  
> >
> > Is that some sort of trick question? I'm doing neither.  
> 
> Clement says that he wrote the code he committed by himself and
> that it is not based on MPlayer code. You say he violated somebody's
> copyright: Who is defaming anybody here?

http://ffmpeg.org/pipermail/ffmpeg-devel/2011-November/116431.html

Panning was later reimplemented in libswresample (independently?
unknown), and some time after that, this code was removed and replaced
by using libswresample API.

> > But what _you_ do is defaming the entire Libav project  
> 
> No.
> I am (to quote you) stating "facts" namely that 1) FFmpeg's
> gitlog contains many commits that indicate avconv developers
> have not correctly given attribution to FFmpeg developers
> when moving or copying code and 2) that other commits in
> addition to those linked by Ivan (probably myself in the past,
> I didn't remember) exist.
> 
> > (and possibly me),  
> 
> I don't remember doing this.

There are a lot of good doctors who specialize in memory problems.

> > which is illegal  
> 
> Please stop calling my actions illegal

Can you tell me why I should do this? Or are you joking?
wm4 April 15, 2017, 4:06 p.m. UTC | #27
On Sat, 15 Apr 2017 15:53:36 +0200
"Jean-Baptiste Kempf" <jb@videolan.org> wrote:

> > Recently, I contacted the same author about relicensing the
> > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> > explicitly denied relicensing. So if I had been cehoyos, I probably
> > wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm
> > not cehoyos). I think nowadays af_pan.c certainly does not violate the
> > original author's copyright though, because absolutely all code was
> > removed/replaced.  
> 
> Rewriting based on the same ideas also does not change the copyright.
> It is a derivative work under the Berne convention.
> I know it's not cool, but that's the international IP laws.

Well, that's not good. I bet this happened a lot when libswscale was
relicensed from GPL to LGPL. (But I don't have specific cases at hand.)

I'm fairly sure that ideas themselves are not copyrightable, though.
Ronald S. Bultje April 15, 2017, 8:15 p.m. UTC | #28
Hi,

On Fri, Apr 14, 2017 at 8:14 PM, Ivan Kalvachev <ikalvachev@gmail.com>
wrote:

> I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio) [..]


Keep me out of this discussion, I want nothing to do with this.

Ronald
diff mbox

Patch

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index ce93c4731d..508555531b 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -389,10 +389,10 @@  static inline float celt_decode_pulses(OpusRangeCoder *rc, int *y, uint32_t N, u
  * Faster than libopus's search, operates entirely in the signed domain.
  * Slightly worse/better depending on N, K and the input vector.
  */
-static void celt_pvq_search(float *X, int *y, int K, int N)
+static int celt_pvq_search(float *X, int *y, int K, int N)
 {
-    int i;
-    float res = 0.0f, y_norm = 0.0f, xy_norm = 0.0f;
+    int i, y_norm = 0;
+    float res = 0.0f, xy_norm = 0.0f;
 
     for (i = 0; i < N; i++)
         res += FFABS(X[i]);
@@ -407,8 +407,8 @@  static void celt_pvq_search(float *X, int *y, int K, int N)
     }
 
     while (K) {
-        int max_idx = 0, phase = FFSIGN(K);
-        float max_den = 1.0f, max_num = 0.0f;
+        int max_idx = 0, max_den = 1, phase = FFSIGN(K);
+        float max_num = 0.0f;
         y_norm += 1.0f;
 
         for (i = 0; i < N; i++) {
@@ -416,8 +416,8 @@  static void celt_pvq_search(float *X, int *y, int K, int N)
              * to it, attempting to decrease it further will actually increase the
              * sum. Prevent this by disregarding any 0 positions when decrementing. */
             const int ca = 1 ^ ((y[i] == 0) & (phase < 0));
+            const int y_new = y_norm  + 2*phase*FFABS(y[i]);
             float xy_new = xy_norm + 1*phase*FFABS(X[i]);
-            float y_new  = y_norm  + 2*phase*FFABS(y[i]);
             xy_new = xy_new * xy_new;
             if (ca && (max_den*xy_new) > (y_new*max_num)) {
                 max_den = y_new;
@@ -433,6 +433,8 @@  static void celt_pvq_search(float *X, int *y, int K, int N)
         y_norm  += 2*phase*y[max_idx];
         y[max_idx] += phase;
     }
+
+    return y_norm;
 }
 
 static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_t K,
@@ -441,8 +443,10 @@  static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_
     int y[176];
 
     celt_exp_rotation(X, N, blocks, K, spread, 1);
-    celt_pvq_search(X, y, K, N);
+    gain /= sqrtf(celt_pvq_search(X, y, K, N));
     celt_encode_pulses(rc, y,  N, K);
+    celt_normalize_residual(y, X, N, gain);
+    celt_exp_rotation(X, N, blocks, K, spread, 0);
     return celt_extract_collapse_mask(y, N, blocks);
 }
 
@@ -844,7 +848,7 @@  static void celt_stereo_is_decouple(float *X, float *Y, float e_l, float e_r, in
 static void celt_stereo_ms_decouple(float *X, float *Y, int N)
 {
     int i;
-    const float decouple_norm = 1.0f/sqrtf(2.0f);
+    const float decouple_norm = 1.0f/sqrtf(1.0f + 1.0f);
     for (i = 0; i < N; i++) {
         const float Xret = X[i];
         X[i] = (X[i] + Y[i])*decouple_norm;
@@ -860,9 +864,9 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
     const uint8_t *cache;
     int dualstereo, split;
     int imid = 0, iside = 0;
-    //uint32_t N0 = N;
+    uint32_t N0 = N;
     int N_B = N / blocks;
-    //int N_B0 = N_B;
+    int N_B0 = N_B;
     int B0 = blocks;
     int time_divide = 0;
     int recombine = 0;
@@ -883,6 +887,7 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
                 f->remaining2 -= 1 << 3;
                 b             -= 1 << 3;
             }
+            x[0] = 1.0f - 2.0f*(x[0] < 0);
             x = Y;
         }
         if (lowband_out)
@@ -922,7 +927,7 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
             tf_change++;
         }
         B0 = blocks;
-        //N_B0 = N_B;
+        N_B0 = N_B;
 
         /* Reorganize the samples in time order instead of frequency order */
         if (B0 > 1)
@@ -977,19 +982,20 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
 
             if (dualstereo) {
                 if (itheta == 0)
-                    celt_stereo_is_decouple(X, Y, f->block[0].lin_energy[band], f->block[1].lin_energy[band], N);
+                    celt_stereo_is_decouple(X, Y, f->block[0].lin_energy[band],
+                                            f->block[1].lin_energy[band], N);
                 else
                     celt_stereo_ms_decouple(X, Y, N);
             }
         } else if (dualstereo) {
              inv = itheta > 8192;
-             if (inv)
-             {
+             if (inv) {
                 int j;
-                for (j=0;j<N;j++)
+                for (j = 0; j < N; j++)
                    Y[j] = -Y[j];
              }
-             celt_stereo_is_decouple(X, Y, f->block[0].lin_energy[band], f->block[1].lin_energy[band], N);
+             celt_stereo_is_decouple(X, Y, f->block[0].lin_energy[band],
+                                     f->block[1].lin_energy[band], N);
 
             if (b > 2 << 3 && f->remaining2 > 2 << 3) {
                 ff_opus_rc_enc_log(rc, inv, 2);
@@ -1153,8 +1159,124 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
             /* Finally do the actual quantization */
             cm = celt_alg_quant(rc, X, N, (q < 8) ? q : (8 + (q & 7)) << ((q >> 3) - 1),
                                 f->spread, blocks, gain);
+        } else {
+            /* If there's no pulse, fill the band anyway */
+            int j;
+            uint32_t cm_mask = (1 << blocks) - 1;
+            fill &= cm_mask;
+            if (!fill) {
+                for (j = 0; j < N; j++)
+                    X[j] = 0.0f;
+            } else {
+                if (!lowband) {
+                    /* Noise */
+                    for (j = 0; j < N; j++)
+                        X[j] = (((int32_t)celt_rng(f)) >> 20);
+                    cm = cm_mask;
+                } else {
+                    /* Folded spectrum */
+                    for (j = 0; j < N; j++) {
+                        /* About 48 dB below the "normal" folding level */
+                        X[j] = lowband[j] + (((celt_rng(f)) & 0x8000) ? 1.0f / 256 : -1.0f / 256);
+                    }
+                    cm = fill;
+                }
+                celt_renormalize_vector(X, N, gain);
+            }
+        }
+    }
+
+    /* This code is used by the decoder and by the resynthesis-enabled encoder */
+    if (dualstereo) {
+        int j;
+        if (N != 2)
+            celt_stereo_merge(X, Y, mid, N);
+        if (inv) {
+            for (j = 0; j < N; j++)
+                Y[j] *= -1;
+        }
+    } else if (level == 0) {
+        int k;
+
+        /* Undo the sample reorganization going from time order to frequency order */
+        if (B0 > 1)
+            celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
+                                     B0<<recombine, longblocks);
+
+        /* Undo time-freq changes that we did earlier */
+        N_B = N_B0;
+        blocks = B0;
+        for (k = 0; k < time_divide; k++) {
+            blocks >>= 1;
+            N_B <<= 1;
+            cm |= cm >> blocks;
+            celt_haar1(X, N_B, blocks);
         }
+
+        for (k = 0; k < recombine; k++) {
+            cm = ff_celt_bit_deinterleave[cm];
+            celt_haar1(X, N0>>k, 1<<k);
+        }
+        blocks <<= recombine;
+
+        /* Scale output for later folding */
+        if (lowband_out) {
+            int j;
+            float n = sqrtf(N0);
+            for (j = 0; j < N0; j++)
+                lowband_out[j] = n * X[j];
+        }
+        cm = av_mod_uintp2(cm, blocks);
     }
 
     return cm;
 }
+
+float ff_celt_quant_band_cost(CeltFrame *f, OpusRangeCoder *rc, int band, float *bits,
+                              float lambda)
+{
+    int i, b = 0;
+    uint32_t cm[2] = { (1 << f->blocks) - 1, (1 << f->blocks) - 1 };
+    const int band_size = ff_celt_freq_range[band] << f->size;
+    float buf[352], lowband_scratch[176], norm1[176], norm2[176];
+    float dist, cost, err_x = 0.0f, err_y = 0.0f;
+    float *X = buf;
+    float *X_orig = f->block[0].coeffs + (ff_celt_freq_bands[band] << f->size);
+    float *Y = (f->channels == 2) ? &buf[176] : NULL;
+    float *Y_orig = f->block[1].coeffs + (ff_celt_freq_bands[band] << f->size);
+    OPUS_RC_CHECKPOINT_SPAWN(rc);
+
+    memcpy(X, X_orig, band_size*sizeof(float));
+    if (Y)
+        memcpy(Y, Y_orig, band_size*sizeof(float));
+
+    f->remaining2 = ((f->framebits << 3) - f->anticollapse_needed) - opus_rc_tell_frac(rc) - 1;
+    if (band <= f->coded_bands - 1) {
+        int curr_balance = f->remaining / FFMIN(3, f->coded_bands - band);
+        b = av_clip_uintp2(FFMIN(f->remaining2 + 1, f->pulses[band] + curr_balance), 14);
+    }
+
+    if (f->dual_stereo) {
+        ff_celt_encode_band(f, rc, band, X, NULL, band_size, b / 2, f->blocks, NULL,
+                            f->size, norm1, 0, 1.0f, lowband_scratch, cm[0]);
+
+        ff_celt_encode_band(f, rc, band, Y, NULL, band_size, b / 2, f->blocks, NULL,
+                            f->size, norm2, 0, 1.0f, lowband_scratch, cm[1]);
+    } else {
+        ff_celt_encode_band(f, rc, band, X, Y, band_size, b, f->blocks, NULL, f->size,
+                            norm1, 0, 1.0f, lowband_scratch, cm[0] | cm[1]);
+    }
+
+    for (i = 0; i < band_size; i++) {
+        err_x += (X[i] - X_orig[i])*(X[i] - X_orig[i]);
+        err_y += (Y[i] - Y_orig[i])*(Y[i] - Y_orig[i]);
+    }
+
+    dist = sqrtf(err_x) + sqrtf(err_y);
+    cost = OPUS_RC_CHECKPOINT_BITS(rc)/8.0f;
+    *bits += cost;
+
+    OPUS_RC_CHECKPOINT_ROLLBACK(rc);
+
+    return lambda*dist*cost;
+}
diff --git a/libavcodec/opus_pvq.h b/libavcodec/opus_pvq.h
index d414b47a42..045015406b 100644
--- a/libavcodec/opus_pvq.h
+++ b/libavcodec/opus_pvq.h
@@ -38,4 +38,7 @@  uint32_t ff_celt_encode_band(CeltFrame *f, OpusRangeCoder *rc, const int band,
                              float *lowband, int duration, float *lowband_out, int level,
                              float gain, float *lowband_scratch, int fill);
 
+float ff_celt_quant_band_cost(CeltFrame *f, OpusRangeCoder *rc, int band,
+                              float *bits, float lambda);
+
 #endif /* AVCODEC_OPUS_PVQ_H */