On Thu Nov 30 21:42:02 2023 +0000, Zebediah Figura wrote:
> The codec_data introduced in 1/6 isn't validated in the tests. Why is that?
Because WMV version 1 doesn't have codec data.
```
$ gst-launch-1.0 -vvv filesrc location=dlls/wmvcore/tests/test.wmv ! asfdemux ! avdec_wmv1 ! fakesink
[...]
/GstPipeline:pipeline0/avdec_wmv1:avdec_wmv1-0.GstPad:sink: caps = video/x-wmv, wmvversion=(int)1, width=(int)64, height=(int)48, pixel-aspect-ratio=(fraction)1/1, format=(string)WMV1
$ gst-launch-1.0 -vvv filesrc location=waga.wmv ! asfdemux ! avdec_wmv3 ! fakesink
[...]
/GstPipeline:pipeline0/avdec_wmv3:avdec_wmv3-0.GstPad:sink: caps = video/x-wmv, wmvversion=(int)3, format=(string)WMV3, width=(int)1280, height=(int)720, codec_data=(buffer)4ff1080100, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)10000000/333333
```
(Its absense is tested by the cbFormat check in compare_media_types().)
But yes, certainly suboptimal. I'd be happy to test it if someone can find a suitable test file.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54462
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v27: ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
Various new tests for CreateProcess showing a couple of issues
in current implementation.
--
v4: kernelbase: Reset std handles gotten by GetStartupInfo().
ntdll: Restrict cases for std handle inheritance in CreateProcess().
kernel32/tests: Add more tests about CreateProcess.
kernel32/tests: Enable CreateProcess() tests on 64bit compilation.
kernel32/tests: Introduce a new infrastructure for testing CreateProcess().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4441