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. The reasons for doing this conversion may be different, but there is no reason for the mechanism to be.
Moreover, the goals are not entirely orthogonal; not all video will be output in the four types you have listed.