V3 pushed V2 => V3: - added a bunch of tests about effect of MF_MT_DEFAULT_STRIDE (positive value, negative value, no value) - Note: the tests results on windows are not pixel perfect compared to rgb32 frame (flipped or not) (checked the variations: there are of same nature as the one analyzed in V1 on gstreamer: smoothing on band vertical transition and right hand-side vertical bar...) the net results of the tests is: ``` | | | | MF output format | MF output format w/ | MF output format w/ | | | From | To | w/o stride | positive stride | negative stride | |-----------------+------+-----+------------------+---------------------+---------------------| | decode | WMV | YUV | no flip | no flip | no flip | | decode | WMV | RGB | flip | flip | flip | | color conv | YUV | RGB | no flip | no flip | flip | | video processor | YUV | RGB | flip | no flip | flip | ``` so it looks like it up to the caller of tranform to adapt the flipping (eg. decode seems to use only output type (rgb => flipped) without taking care of sign), while color_conv and video_processor seem to use sign of stride to enable (or not flip), but differ on behavior when stride isn't present Adapted callers to wg_transform to follow this.