On Tue Apr 11 09:31:12 2023 +0000, Rémi Bernon wrote:
I think the difference with video_processor is related to the media types attributes, rather than something unconditional like this. For instance, it is possible to force the frame orientation by explicitly specifying `MF_MT_DEFAULT_STRIDE` attribute in both cases. The tests don't do that, but maybe it should. The default for color_converter seems to be a positive `MF_MT_DEFAULT_STRIDE` value, and it even exposes it in the current media type as the test shows, outputting the same orientation as the input NV12 frame. The video_converter doesn't add a default value, but behaves as if it was negative by default for RGB, reversing the output compared to the NV12 frame input.
in fact there might be two issues to take care of (covering also your next comment): - various decoders are now exposed to potentially negative heights, which some of them are not prepared for (eg. h264 or dmo) - orientation when MF_MT_DEFAULT_STRIDE isn't specified in MediaType (color_converter and videoconverter may provide behave differently)
so I wonder which design is better: - hide completly the flip information to decoders (passing abs(height)) and handle in wg_transform only - expose the flip request to decoders in case they are able to handle it? (and fallback to flip in wg_transform if they don't handle it)
looks like we maybe need some more tests for various stride values