Currently, the pixels field for a rendition in the API response is whatever value is contained in the pixels field for the API request. I think this is confusing. Instead, the pixels field for a rendition in the API response should contain the value calculated by the verifier so that the user of the verifier can compare the value with an expected value.
The verifier already calculates the pixels, but this information is incorporated into the pixels_pre_verification and pixels_post_verification fields with the former being the ratio b/w the expected pixels (indicated in the request) and the pixels calculated based on metadata and the latter being the ratio b/w the expected pixels and the pixels calculated based on reading the frames.
Note that while working on this issue we should also look into whether the pixels calculated by the verifier matches up with the pixels calculated by LPMS. I saw in some local testing with a verifier + broadcaster + orchestrator an API response with pixels_post_verification: 6.0 which would imply that the verifier calculated a different # of pixels than the expected value passed to the verifier by the broadcaster which is calculated by LPMS (on the orchestrator)...
Currently, the pixels field for a rendition in the API response is whatever value is contained in the pixels field for the API request. I think this is confusing. Instead, the pixels field for a rendition in the API response should contain the value calculated by the verifier so that the user of the verifier can compare the value with an expected value.
The verifier already calculates the pixels, but this information is incorporated into the
pixels_pre_verificationandpixels_post_verificationfields with the former being the ratio b/w the expected pixels (indicated in the request) and the pixels calculated based on metadata and the latter being the ratio b/w the expected pixels and the pixels calculated based on reading the frames.Note that while working on this issue we should also look into whether the pixels calculated by the verifier matches up with the pixels calculated by LPMS. I saw in some local testing with a verifier + broadcaster + orchestrator an API response with
pixels_post_verification: 6.0which would imply that the verifier calculated a different # of pixels than the expected value passed to the verifier by the broadcaster which is calculated by LPMS (on the orchestrator)...