[PATCH v4 3/3] mfplat: Add MFCreateFile stub.
Zebediah Figura
z.figura12 at gmail.com
Fri Nov 2 17:48:46 CDT 2018
On 11/2/18 5:34 PM, Sven Baars wrote:
> On 02-11-18 21:55, Zebediah Figura wrote:
>> On 11/2/18 3:27 PM, Sven Baars wrote:
>>> Signed-off-by: Sven Baars <sven.wine at gmail.com>
>>> ---
>>> v3: Actually read the file and handle all flags.
>>> v4: Rebased on the previous patch.
>>>
>>> dlls/mfplat/main.c | 78 ++++++++++++++++++++++-
>>> dlls/mfplat/mfplat.spec | 2 +-
>>> dlls/mfplat/tests/Makefile.in | 2 +
>>> dlls/mfplat/tests/mfplat.c | 114 ++++++++++++++++++++++++++++++++++
>>> dlls/mfplat/tests/resource.rc | 24 +++++++
>>> dlls/mfplat/tests/test.mp4 | Bin 0 -> 1554 bytes
>>> include/mfapi.h | 2 +
>>> 7 files changed, 220 insertions(+), 2 deletions(-)
>>> create mode 100644 dlls/mfplat/tests/resource.rc
>>> create mode 100644 dlls/mfplat/tests/test.mp4
>>>
>>> diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c
>>> index 7865a8935f..130597e8e7 100644
>>> --- a/dlls/mfplat/main.c
>>> +++ b/dlls/mfplat/main.c
>>> @@ -850,6 +850,8 @@ typedef struct _mfbytestream
>>> mfattributes attributes;
>>> IMFByteStream IMFByteStream_iface;
>>> IMFAttributes IMFAttributes_iface;
>>> +
>>> + HANDLE file;
>>> } mfbytestream;
>>> static inline mfbytestream *impl_from_IMFByteStream(IMFByteStream
>>> *iface)
>>
>> This strikes me as a little janky. Arguably it could make sense, but
>> I'd like to get a sense of how MFCreateMFByteStreamOnStream would fit
>> in with this (plus any other APIs that create byte stream objects).
>> Taking a less cursory look at the API of IMFByteStream, my intuition
>> leads me to think it would make more sense just to create separate
>> objects; there doesn't seem to be a lot of room for shared code.
>>
>>
> Hi Zebediah,
>
> I thought the same, but a lot may be shared (at least the IMFAttributes
> interface that I added), and for now, not doing this would mean I have
> to duplicate another 500 lines of code. Maybe it would be better if the
> person who actually implements MFCreateMFByteStreamOnStream duplicates
> this code? I'm happy to copy-paste everything if you think that's better.
>
> Sven
>
>
Even if there's a lot of shared code, it may be better just to use
common helper functions. Anyway, besides possibly
IMFAsyncCallback/IMFAsyncResult handling, it looks like most of
IMFByteStream is a thin veneer over specific I/O methods.
Besides, with regard to IMFAttributes, as I think over it a bit
more—since here the interface in question doesn't actually derive from
IMFAttributes, I think we could simplify the code considerably by using
existing mfattributes methods in the vtbl directly, with the exception
of IUnknown methods.
More information about the wine-devel
mailing list