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.