[PATCH] winegstreamer: Fixup raw audio caps to be compatible with IMFMediaType.

[Derek Lesho]

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.
>>
>