On Mon Sep 25 20:24:31 2023 +0000, Alfred Agrell wrote:
This function's immediate caller is GStreamer itself; we can't change that. It may be possible to push the 'is it actually different' check later, but not earlier. And that 'later' part looks full of multithreading already, I'd rather not make it even trickier. Another approach would be adding a colorimetry=(string)2:0:0:0 somewhere in wg_transform_create(); if it's already there, avdec_mpeg2video adding one won't do anything. But the clean way to do that would be in wg_format_to_caps(), which is impossible. The wg_format is created from an AM_MEDIA_TYPE, which most likely contains a VIDEOINFOHEADER, which does not support colorimetry. AM_MEDIA_TYPE can contain VIDEOINFOHEADER2 that contains some color-related fields in the DXVA_ExtendedFormat field in the control flags, but I can't quite make sense of which (if any) of those bits is colorimetry, and we can't rely on in-the-wild programs accepting VIH2 anyways. The less clean way would be hardcoding a 'if input format is WG_MAJOR_TYPE_VIDEO_MPEG1, add colorimetry 2:0:0:0 to output format' somewhere, but that's at least as ugly as the current approach. And if some other MPEG file contains a colorimetry other than 2:0:0:0 (I don't know if that's possible), we're gonna get unexpected format changes again. The ideal solution would be converting all queued frames to the new format (or, if some frames have already been sent, queueing the format change too), so format changes don't cause trouble, but that's a bit beyond the scope of this MR. Since there already is some colorimetry removal in winegstreamer (for example that commit you linked), I'd say removing it from here too is the cleanest general solution (unless I'm missing some other possible solution). Though it may be wiser to refactor that caps filtering into a separate function.
I meant the caller of `wg_transform_read_data`, which receives the format change error status. The quartz flavor, `wg_transform_read_quartz`, doesn't support it and prints the error message.
It should be possible to support the format change in quartz_parser `transform_sink_receive`, keeping the current wg_format around and passing a wg_format pointer to that function, *then* comparing whether the two formats are actually compatible, and call `wg_transform_set_output_format`.