[PATCH 6/7] quartz/tests: Add tests for MPEG audio decoder sample processing.
Zebediah Figura (she/her)
zfigura at codeweavers.com
Thu May 5 15:58:15 CDT 2022
On 5/4/22 02:58, Anton Baskanov wrote:
> On 04.05.2022 04:18, Zebediah Figura (she/her) wrote:
>> On 5/3/22 13:28, Anton Baskanov wrote:
>>> Signed-off-by: Anton Baskanov <baskanov at gmail.com>
>>> ---
>>> dlls/quartz/tests/mpegaudio.c | 83
>>> +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 83 insertions(+)
>>>
>>> diff --git a/dlls/quartz/tests/mpegaudio.c
>>> b/dlls/quartz/tests/mpegaudio.c
>>> index def5dc90238..0044d3bef6f 100644
>>> --- a/dlls/quartz/tests/mpegaudio.c
>>> +++ b/dlls/quartz/tests/mpegaudio.c
>>> @@ -846,6 +846,7 @@ struct testfilter
>>> struct strmbase_source source;
>>> struct strmbase_sink sink;
>>> const AM_MEDIA_TYPE *mt;
>>> + unsigned int got_sample;
>>> };
>>> static inline struct testfilter *impl_from_strmbase_filter(struct
>>> strmbase_filter *iface)
>>> @@ -919,11 +920,39 @@ static HRESULT testsink_connect(struct
>>> strmbase_sink *iface, IPin *peer, const A
>>> return S_OK;
>>> }
>>> +static HRESULT WINAPI testsink_Receive(struct strmbase_sink *iface,
>>> IMediaSample *sample)
>>> +{
>>> + struct testfilter *filter =
>>> impl_from_strmbase_filter(iface->pin.filter);
>>> + unsigned int i;
>>> + BYTE *data;
>>> + HRESULT hr;
>>> + LONG size;
>>> +
>>> + ++filter->got_sample;
>>> +
>>> + size = IMediaSample_GetSize(sample);
>>> + ok(size == 3072, "Got size %lu.\n", size);
>>> + size = IMediaSample_GetActualDataLength(sample);
>>> + ok(size == 768, "Got valid size %lu.\n", size);
>>> +
>>> + hr = IMediaSample_GetPointer(sample, &data);
>>> + ok(hr == S_OK, "Got hr %#lx.\n", hr);
>>> + for (i = 0; i < size / 2; ++i)
>>> + {
>>> + short value;
>>> + memcpy(&value, &data[i * 2], 2);
>>> + ok(abs(value) <= 1, "Got value %d.\n", value);
>>
>> I don't know if we really need to bother with validating the output data.
>>
>> (If we do, though, it seems a bit more idiomatic to just alias "data"
>> with a "const short *" pointer.)
>>
>
> Oh, I didn't realize that we are compiling with -fno-strict-aliasing, so
> I thought that this would break the aliasing rules.
Indeed, it'd be hard to do any win32 programming at all with strict
aliasing :-)
More information about the wine-devel
mailing list