Exposing functions for creating and copying oapv_imgb objects

[dkozinski]

There is a need to add/expose functions to the public API of the liboapv library that facilitate the use of oapv_imgb_t objects.
Specifically, these are functions for creating and copying oapv_imgb_t objects.

oapv_imgb_t *oapv_imgb_create(int w, int h, int cs);

void oapv_imgb_cpy(oapv_imgb_t *dst, oapv_imgb_t *src);

This will simplify the use of the opav API in client applications or projects using liboapv, such as ffmpeg.

After the creation of PR 20133 in the ffmpeg project repository ( https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20133 ), which contains an implementation of the liboapvdec.c wrapper for opav decoder, the argument was raised that the liboapv implementation is large, comparable to the native implementation. "The size of the wrapper is nearly as large as our native decoder."

This is largely due to the fact that a large part of the liboapvdec.c implementation consists of functions related to creating and copying the oapv_imgb_t object.

FFmpeg opav decoder wrapper (liboapvdec.c) contains implementations of the following functions: apv_imgb_create(..), apv_imgb_cpy(..), apv_imgb_cpy_shift_left(), apv_imgb_cpy_shift_right_8b(), apv_imgb_cpy_shift_left_8b(), apv_imgb_cpy_plane(), apv_imgb_getref(), apv_imgb_addref()

Moving them to the liboapv library would significantly reduce the amount of wrapper code in ffmpeg.

[kpchoi]

@dariusz-f

I think that you need to check whether ffmpeg has same functions internally.
The xxx_imgb_xxx functions are for application basically. I believe similar functions are already defined in ffmpeg and widely used it.
OpenAPV library needs to use oapv_imgb_t structure for interfacing with application code.
All you have to do is translating (setting the structure) from ffmpeg's own image structure.
Anyway, it would be better to use ffmpeg's internal image library if it is possible.

If the ffmpeg internal image library doesn't have same functionality with xxx_imgb_xxx() functions, and then the functions are re-consider to be global function. But I believe that ffmpeg has versatile image functions internally.

[dkozinski]

We managed to reduce the number of lines of code involved in creating and copying oapv_imgb objects. However, it may be worth considering exposing a function for creating oapv_imgb_t objects.

Using the liboapv library requires creating oapv_imgb_t objects. Creating oapv_imgb_t objects is much more than simple allocation, so creating them manually is prone to errors. Providing an API will free the library user from the need to manually create oapv_imgb_t objects and will make working with the library easier.

This isn't just about using liboapv in ffmpeg, but about using the library in general.

[kpchoi]

@dkozinski , could you address which file is the relevant source code in ffmpeg?
It could be reviewed first and then we could discuss more.

[dkozinski]

1. liboapvdec.c

https://code.ffmpeg.org/FFmpeg/FFmpeg/src/commit/7154a577236798c4719d8ea563b9ce04e654f15d/libavcodec/https://code.ffmpeg.org/FFmpeg/FFmpeg/src/commit/7154a577236798c4719d8ea563b9ce04e654f15d/libavcodec/liboapvdec.c

This is a link to the file from PR #20133 (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20133), which was closed by ffmpeg community. It is under discussion.

The latest version of this file isn't in the FFmpeg repository.

As mentioned, we managed to reduce the number of lines of code involved in creating and copying oapv_imgb objects, but I have this version only locally for now.

2. liboapvenc.c
https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/master/libavcodec/liboapvenc.c

If liboapv provided an API for creating oapv_imgb_t objects, the apv_imgb_create implementation in this file could also be removed and the number of lines of code reduced.

---

The same coud be done for reference applications provided by liboapv library.