On 2/4/22 15:49, Rémi Bernon wrote:
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51931 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52391 Signed-off-by: Rémi Bernon rbernon@codeweavers.com
dlls/mf/tests/mf.c | 132 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+)
diff --git a/dlls/mf/tests/mf.c b/dlls/mf/tests/mf.c index ebf42bcad9c..03d0250d51a 100644 --- a/dlls/mf/tests/mf.c +++ b/dlls/mf/tests/mf.c @@ -5492,9 +5492,103 @@ static IMFSample *create_sample(const BYTE *data, ULONG size) return sample; }
+#define check_sample(a, b, c) check_sample_(__LINE__, a, b, c) +static void check_sample_(int line, IMFSample *sample, const void *expect_buf, ULONG expect_len) +{
- IMFMediaBuffer *media_buffer;
- DWORD length;
- BYTE *buffer;
- HRESULT hr;
- ULONG ret;
- hr = IMFSample_ConvertToContiguousBuffer(sample, &media_buffer);
- ok_(__FILE__, line)(hr == S_OK, "ConvertToContiguousBuffer returned %#x\n", hr);
- hr = IMFMediaBuffer_Lock(media_buffer, &buffer, NULL, &length);
- ok_(__FILE__, line)(hr == S_OK, "Lock returned %#x\n", hr);
- ok_(__FILE__, line)(expect_len == length, "got length %u\n", length);
- if (length && length == expect_len)
- {
ok_(__FILE__, line)(!memcmp(expect_buf, buffer, expect_len),
"unexpected buffer data\n");
- }
- hr = IMFMediaBuffer_Unlock(media_buffer);
- ok_(__FILE__, line)(hr == S_OK, "Unlock returned %#x\n", hr);
- ret = IMFMediaBuffer_Release(media_buffer);
- ok_(__FILE__, line)(ret == 1, "Release returned %u\n", ret);
+}
- static const BYTE wma_codec_data[10] = {0, 0x44, 0, 0, 0x17, 0, 0, 0, 0, 0}; static const BYTE wma_decoded_data[0x4000] = {0}; static const ULONG wma_block_size = 1487;
+static const BYTE wma_encoded_data[][1487] = +{
Sorry, I forgot to reply to this one. Would it make sense to have this blob in the resources like we occasionally do? Is it possible to reduce the size of it, and provide a way to regenerate it, or a note on how it was generated at least?
I realize that it's not pretty to add a whole wma stream, because you'll need to parse through first, using source methods, which means even more code.
If there is going to be more tests for WMx, and since decoders/encoders don't strictly belong to mf.dll, maybe moving this to additional test file is an option.