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@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.