[PATCH 2/2] winegstreamer: Allow some audio resampling in the default pipeline.

[Rémi Bernon]

On 10/27/21 22:34, Zebediah Figura (she/her) wrote:
> On 10/27/21 10:25, Rémi Bernon wrote:
>> Planet Coaster requests an output format with 44100 rate for user
>> provided music, which may not match what the files are decoded to.
>>
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
> 
> This one looks good, although it'd be nice for this description to be in 
> the code itself.
> 
> It could also be split into front and backend parts.
> 

So it ends up being a little bit more complicated than that, and I don't 
think hardcoding a list of supported audio format is the right way to do 
it. In order to support all possible user music formats, we would have 
to hardcode all possible variations of media types.

As far as I could see (and with tests from 
https://source.winehq.org/patches/data/219024) native streams only 
enumerate their native media types. Then, more media types are supported 
by the IMFSourceReader, but probably using a dynamically allocated 
decoder / converter MF transforms, or using MF topology elements which I 
believe are doing more advanced logic than what 
src_reader_SetCurrentMediaType does.

Doing it this way would mean instantiating an audio_converter MF 
transform for instance, and would then make the audioresampler element 
useless. This seems to be the direction existing code is generally 
going, but it kind of defeat the idea of using GStreamer and its 
dynamically created pipelines.

Another way I can see to make this dynamic, using an always present 
audioresampler element, would be instead to change the way we match 
IMFSourceReader stream media types, by delegating the type matching to 
winegstreamer, and GStreamer through gst_pad_query_caps calls. I'm not 
sure how we can do that, maybe with a custom IMFMediaTypeHandler, but 
it's not supposed to do this.
-- 
Rémi Bernon <rbernon at codeweavers.com>