On Mon, 9 Dec 2024, Ronald S. Bultje wrote:

Hi,

On Mon, Dec 9, 2024 at 9:17 AM Martin Storsjö <mar...@martin.st> wrote:

On Mon, 9 Dec 2024, Ronald S. Bultje wrote:

> Secondly, can we share checkasm_check_pixel in a more general location so
> other codecs can use it too?

Ideally, yes.

But the problem is in the way multi-bitdepth codecs are handled in
ffmpeg/checkasm, compared to how it is done in dav1d. In dav1d we have the
pixel typedefs, and each of the checkasm test files are compiled multiple
times for each bitdepth that is enabled, so there is one, consistent
cross-test definition of what a pixel is and what the bitdepth is, etc.

In the ffmpeg checkasm tests (and multi-bitdepth decoders), there's no
abstraction for this, but we have DSP functions taking uint8_t*, where it
actually is working on maybe-uint8_t-maybe-uint16_t data - depending on
the configuration. And this macro that I'm using here (and in HEVC)
depends on a function local variable named "bit_depth", which is handled
separately in each test file.

So yes, we could share it, but it relies on assumptions about local
variables that may or may not be done differently between each test. Then
again, the issue only arises when you'd try to use the macro in another
test file, so if someone does that, they'd notice the need for a matching
"bit_depth" variable.


I think that's acceptable, possibly with some additional documentation. I'm
just thinking about how to trivially expose this to other codecs with
minimal duplication. For example, I'd love to use this in checkasm/vp9dsp.

Ok, let's try to do that then (and I'll have a quick look at checkasm/vp9dsp if it matches the structure used in hevc/vvc).

// Martin
_______________________________________________
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".

Reply via email to