[PATCH resend 4/5] winegstreamer: Find an appropriate demuxer for the source.

[Zebediah Figura]

On 4/6/20 4:20 PM, Derek Lesho wrote:
> 
> On 4/6/20 2:02 PM, Zebediah Figura wrote:
>> On 4/6/20 12:57 PM, Derek Lesho wrote:
>>> We can add a path later which uses decodebin as the demuxer, for use with formats not supported on windows.  (like Theora)
>> I still don't see a good reason why this can't be the general solution
>> for all formats.
>>
>>
> We've already extensively discussed this, and it seems mostly to be a 
> matter of preference.  From my view, it doesn't match windows, and I'd 
> prefer to keep the more accurate path as default.  Would you like me to 
> add the decodebin fallback before submitting or something?
> 

I don't think it's a matter of preference at all, or at least, not such
that both options are equally valid.

I think the attempt to zealously match Windows implementation details as
a top priority is misguided; that's never been the top priority of Wine.
As I understand, we should match implementation details where there's no
reason not to (e.g. using the same internal registry keys Windows uses)
or where applications require it. Hence, if we have a good reason to do
otherwise, and applications don't care, then I don't think we should
feel bound to match Windows implementation details.

Accordingly, what I'd like to see in terms of patches would be to first
fully implement a media source built on decodebin without worrying about
anything else. If applications are manually creating e.g. the MPEG-4
source, we can essentially redirect that to the same COM object. Only if
we ever find an application that depends on nontrivial details of
GetNativeMediaType() would we then bother replicating those details in
winegstreamer.

Since there's at least consensus that a decodebin source is desirable,
and it's the bulk of the code anyway, I think it'd be a good idea to
start with that.