Unused img_format parameter in vl_video_encoder_init function

[vice]

c2_vpcodec/libvpcodec.cpp

Line 75 in 355a7f4

vl_codec_handle_t vl_video_encoder_init(vl_codec_id_t codec_id, int width, int height, int frame_rate, int bit_rate, int gop, vl_img_format_t img_format)

[OtherCrashOverride]

The library originates from Amlogic. They defined the API. The parameter likely exists to maintain compatibility with older/newer code.

[vice]

The code seems to be three libraries mixed together with some parts deleted and other commented out. Maybe they wanted to protect IP.

1. Low level code hardware dependent gx_enc_fast. GX is 64bit ARM family. Maybe a gx encoder version other than "fast" exists. Only video codec is found in this directory. We can't know if audio encoding for example is possible, at least this is not critical. m8 encoder is commented out in other parts of the code. This must be a library for a codec present in another hardware (S805?).
2. Amlogic hardware (model) abstraction layer library: AML_HWEncoder.cpp.
3. A higher level libvpcodec.cpp library. In his header file c2_include/vpcodec_1_0.h it mention some videophone codec:

   c2_vpcodec/include/vpcodec_1_0.h

   Line 2 in 355a7f4

   #define _INCLUDED_COM_VIDEOPHONE_CODEC

   So maybe this is a library for some (Android?) videophone product or demo. Does vp stands for videophone or videoprocessor?
4. Deleted util directory that included the commented out logger.

It is clear that the code is made by a third part that customized it before deliver. How do you get the code?

This code is useful to use the Odroid C2 video processor so how do you see its future? Is there a plan to clean, correct, adapt the code/and or incorporate upstream patches? Some interesting forks exists already that tries to correct an error in one and extend functionality in another.

[OtherCrashOverride]

How do you get the code?

The code was provided to HardKernel which then made it available to developers. As a convenience to other developers, I made my changes and example programs using the library available here (github).

so how do you see its future?

The future, as I currently understand it, is that proprietary libraries such as this will be migrated to the Linux V4L2 API as part of current mainlining efforts. I do not have any time frame estimates, and I am not involved in the mainlining process.

Is there a plan to clean, correct, adapt the code/and or incorporate upstream patches?

The intent of the repository is to serve as a known, tested, starting point for others. As mentioned earlier, this library should become obsolete once Amlogic mainline kernel integration is complete. Therefore, at this time, I do not have plans for further work on this library.

[vice]

Thanks for taking time to answer my questions in both issues.

I will do some experiments and adapt code in a personal fork while waiting for mainlined V4L2 driver.