[PATCH] winegstreamer: Fixup raw audio caps to be compatible with IMFMediaType.
Derek Lesho
dlesho at codeweavers.com
Fri Nov 6 14:51:21 CST 2020
On 11/6/20 2:32 PM, Zebediah Figura wrote:
> On 11/6/20 2:20 PM, Derek Lesho wrote:
>> On 11/6/20 2:13 PM, Zebediah Figura wrote:
>>
>>> This is done in a rather inconsistent way relative to how video streams
>>> are handled.
>> Yes, because the goals are different for each of the paths. The video
>> path is just an enhancement to report video formats in a defined order
>> as if they were coming from a decoder, since right now we're skipping
>> the decoder MFT step. The step for fixing up the audio caps is meant to
>> be a generic solution for any caps which are un-representable as a
>> IMFMediaType object. This same path is used for compressed h.264 video
>> on my local branch for example.
>>
> 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 re-presentable. 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 video or raw
audio, such 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 we are pretending that our output types have gone through a stand
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 this 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.
>
More information about the wine-devel
mailing list