[FFmpeg-devel] Initial tickering at unifying ProRes encoder

[Clément Bœsch]

On Mon, Dec 11, 2023 at 10:15:09AM +0100, Anton Khirnov wrote:
> Quoting Clément Bœsch (2023-12-11 02:35:01)
> > Hello there,
> > 
> > I'm currently investigating an issue¹ affecting Kostya ProRes encoder
> > which is not reproducible with Anatoliy encoder (but it's too early to
> > say if the bug is not present there as well given the differences in
> > quantization, and it's also unclear if the issue is even actually
> > there in the first place and not in M2/M3 firmwares).
> > 
> > Since these encoders share more than similiarities, I've been looking
> > into their differences, and unifying their common codepaths was helpful
> > to my investigation.
> > 
> > Attached is an initial patchset working out their differences by either
> > sharing data or making code identical where relevant.
> 
> Do you have any comments on their respective strengths and weaknesses -
> when would one want to prefer one over the other?

Right now their strength is that having both is helping me debugging a
pretty obscure issue, but I agree that's not a good argument for users.

Kostya encoder has more parameters, and seems to have a more advanced
quantization model. Internally it implies a bunch of duplication of
code for predicting the frame sizes (thinking of the estimate vs encode
AC/DC functions), but that's just internal stuff that can be reworked and
that doesn't concern users.

Anatoliy has more checks to avoid writing out invalid data (referring to
the sanity checks around color management right now), and doesn't seem to
trigger the bug I'm investigating (but again, still unclear if it is
unaffected by it).

> And how feasible would it be to reduce that to a single encoder?

That's pretty much the direction I'm taking, making as much in common as
possible in the hope that they will converge to the same identical code,
and in the process points out the eventual issue I'm looking for.

-- 
Clément B.