[PATCH 2/5] mfreadwrite/reader: Add a passthrough transform.

[Nikolay Sivov]

On 3/18/22 16:27, Giovanni Mascellani wrote:
> On Windows media sources typically produce compressed data, so
> the source reader automatically adds a transform to decompress it.
> On Wine media sources already care about decompressing data, so
> there is no need for a transform. However, some applications
> expect it anyway (e.g., to edit transform attributes) and fail
> if it's not present.
>
> Therefore, this patch adds a trivial passthrough transform
> implementation to please such programs.

This is obviously bad, being a hack.

>   static HRESULT source_reader_create_decoder_for_stream(struct source_reader *reader, DWORD index, IMFMediaType *output_type)
>   {
>       MFT_REGISTER_TYPE_INFO in_type, out_type;
> @@ -1862,6 +2347,8 @@ static HRESULT WINAPI src_reader_SetCurrentMediaType(IMFSourceReader *iface, DWO
>       hr = source_reader_set_compatible_media_type(reader, index, type);
>       if (hr == S_FALSE)
>           hr = source_reader_create_decoder_for_stream(reader, index, type);
> +    else if (hr == S_OK)
> +        hr = source_reader_add_passthrough_transform(reader, index, reader->streams[index].current);
>       if (SUCCEEDED(hr))
>           hr = source_reader_setup_sample_allocator(reader, index);
>   

I'd like this to keep working as close to how it should be as possible, 
and being able to use wine's module on Windows too for testing.

What happens on Windows, when you set current media type to compressed 
type that source provides, or if some source provides raw output as 
winegstreamer does?
What should happen to e.g. WAV streams? Why should it get a dummy 
transform in such cases?

I understand why this would be necessary for compatibility, but we 
should narrow down the impact of this hack first, using it only for 
winegstreamer source, and only when appropriate. Dummy transform code 
also should be moved to winegstreamer, because that's where the need for 
such hack comes from.