April 11, 2023
1:26 p.m.
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 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2471#note_29597