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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".