Clarify 4:2:0 support

[fhvwy]

The current specification disallows 4:2:0 streams ("The value of chroma_format_idc MUST be 0, 2, 3, or 4."), but the codec definition does otherwise support 4:2:0 straightforwardly (with chroma_format_idc = 1 like in H.26x). Currently the openapv encoder will accept 4:2:0 input and creates a 4:2:0 stream with chroma_format_idc = 1, even though the specification directly prohibits this. This creates confusion for users who will try to encode 4:2:0 content and get nonconforming streams output.

Can you therefore please clarify whether 4:2:0 is supported or not?

• If it is intended to be supported then the specification should be updated to allow it.
• If it is not intended to be supported then the reference encoder should not allow creation 4:2:0 streams.
• If it is intended as a future feature but not currently supported then suggest gating it behind a --non-standard-conforming flag or similar so that a naive user does not unexpectedly create a nonstandard 4:2:0 stream.

(Prompted by a user surprised when the ffmpeg decoder rejected a 4:2:0 stream created by the reference encoder. If the first or third of these options then I will add that support. If the second then the current behaviour is correct.)

[cpncf]

I believe that APV doesn't have a plan to support 4:2:0.
Since APV specification is well designed for recording mezzanine video with high fidelity color, 4:2:2 color format is required at least.
Actually there was no requirement related to 4:2:0 during standardization because the conventional mezzanine video codec uses mainly 4:2:2 or 4:4:4 color format. I don't think that users may confuse this because the usecase of APV codec is totally different from H.264/AVC.

[jamrial]

The API defines OAPV_CF_YCBCR420 and OAPV_CS_YCBCR420 (for all bit depths), which is unexpected. What exactly is output from the library when you pass it 4:2:0 input data through an oapv_imgb struct? Does the library rescale it to 4:2:2 and generate the corresponding stream accordingly, or does it intend to in the future? If not, then maybe those define should be removed.

I have also tried to encode 12bit 4:2:2 content and the output was broken. Similarly, the padl and padr fields in oapv_imgb appear to be unused. This makes me believe the library is currently still missing implementation of certain planned features, but it's not clarified in the installed header.

[kpchoi]

As you mentioned, *YCBCR420 seems to be unused in anywhere.
APV standard doesn't support 4:2:0, so that it doesn't define 420 profile.
I think that removing of the *YCBCR420 should be proposed to OpenAPV project community. It could be discussed later.
After that the *YCBCR420 could be removed. I would try to propose it.

OpenAPV project is fully compliant to 422-10 profile as written at front page, but I was told that 12bit 422 sequences could be encoded properly. If you have an issue related to 12bit 422 encoding, please raise a separated issue on the issue webpage with how to re-produce the broken error. It would be very helpful to make a concrete OpenAPV code.

And padl and padr fields are currently set to zero through this code line:

openapv/app/oapv_app_util.h

Line 315 in 3dc91c5

memset(imgb, 0, sizeof(oapv_imgb_t));

The fields can be used if it needs a padding area of the image buffer outside of library, for example, encoder or decoder application.
The current implemented encoder application is not using the variables but other implemention can utilize the variables for some purpose. For example, some H/W APV codec may use the variables for collaboration with pre-allocated H/W image buffer.

I can say that OpenAPV is growing everyday to make more solid code-base and to give better visual quality.
Lots of requirements are coming from ASWF folks.
FYI, Recently, I know that OpenAPV encoder and decoder library have been deployed to Android-16 with APV CTS test-sets.

[jamrial]

OpenAPV project is fully compliant to 422-10 profile as written at front page, but I was told that 12bit 422 sequences could be encoded properly. If you have an issue related to 12bit 422 encoding, please raise a separated issue on the issue webpage with how to re-produce the broken error. It would be very helpful to make a concrete OpenAPV code.

When i reviewed the FFmpeg wrapper submitted by Dawid Kozinski i noticed he added custom code to downscale 12bit input image data to 10bit before passing it to liboapv. If i removed that custom rescaling code, the resulting encoded bitstream looked completely wrong, and as such the final version upstreamed was one that only accepts 10bit input content and generates a 10bit APV stream.

Looking at the code in openapv/src/oapv.c#L1057, it seems to just be missing a case for 12bit content. And indeed, if i add 12bit versions of those functions, i seemingly get correct encoded 12bit output.

[kpchoi]

OpenAPV project is fully compliant to 422-10 profile as written at front page, but I was told that 12bit 422 sequences could be encoded properly. If you have an issue related to 12bit 422 encoding, please raise a separated issue on the issue webpage with how to re-produce the broken error. It would be very helpful to make a concrete OpenAPV code.

When i reviewed the FFmpeg wrapper submitted by Dawid Kozinski i noticed he added custom code to downscale 12bit input image data to 10bit before passing it to liboapv. If i removed that custom rescaling code, the resulting encoded bitstream looked completely wrong, and as such the final version upstreamed was one that only accepts 10bit input content and generates a 10bit APV stream.

Looking at the code in openapv/src/oapv.c#L1057, it seems to just be missing a case for 12bit content. And indeed, if i add 12bit versions of those functions, i seemingly get correct encoded 12bit output.

Could raise this with separated issue thread on issue page?
And then, OpenAPV developers will check.
AFAIK, there is no 12bit specific encoder and decoding operation, but it needs to be double-checked.

[fhvwy]

Would a change to add an experimental (or similarly named, please suggest) option to the encoder without which it will refuse to encode streams which are not officially supported (i.e. not 422-10) be accepted? The current state which will generate nonstandard output (such as 4:2:0 streams) with no warning is not ideal.