From: Derek Lesho Subject: Re: [PATCH] winegstreamer: Fixup raw audio caps to be compatible with IMFMediaType. Message-Id: Date: Fri, 6 Nov 2020 15:01:16 -0600 In-Reply-To: References: <20201106181252.254864-1-dlesho@codeweavers.com> <55bd7125-2708-653f-63b2-1c7439a33aae@gmail.com> A few typos in my previous mail, fixed them up here. On 11/6/20 2:51 PM, Derek Lesho wrote: >> In both cases you're doing conversion from a type which may not be >> representable into a type which is. > No, in the case of the uncompressed video streams, the type is almost > definitely representable.  Think of it as a necessary hack for the > bypassing of the decoder MFT we are doing.  On the other hand, there > are plenty of cases where uncompressed audio may be read from a > container, and the fixup path would still be necessary in those cases. >>   The reasons for doing this >> conversion may be different, but there is no reason for the mechanism >> to be. > I would say there is, the conversion we're doing for the video streams > is unconditional, entirely specific to the media source output, and > doesn't output 1 fixed up caps structure per input caps structure.  On > the other hand, the audio and compressed type format would be > necessary any time we want to feed gstreamer buffers with those caps > to a media foundation component, and is a 1 to 1 conversion in every > case.  Examples of other areas where this would be necessary, off the > top of my head, would be a separate uncompressed-audio-emitting media > source from, say, a microphone, or any MFT which outputs compressed > media or raw audio, such as an encoder MFT. >> >> Moreover, the goals are not entirely orthogonal; not all video will be >> output in the four types you have listed. > All video streams that take the videoconvert enumeration path > (uncompressed video) won't need any transformation to align with an > IMFMediaType object.  The only potential incompatibility would be the > layout, but that problem would never surface with the current media > source since we are pretending that our output types have gone through > a standard media foundation decoder.  An instance where we would want > to put this type of code in the make_mf_compatible_caps path would be > a media source that provides uncompressed video on windows, such as > from a webcam or screen capture.  In the code for that kind of media > source, we'd unconditionally put the video caps through the > make_mf_compatible_caps path, and add code there to replace any > unsupported layout with its closest equivalent defined in media > foundation. >> >