This MR adds tests that examine the values of the samples output by the byte stream handlers.
It is marked as draft as it is dependent on the fixes included within MR !7569.
I've also renamed the tests as they previously exclusively tested the sample output timestamps. The tests now also look at the number of buffers included in a sample and total size of the buffers within a sample.
--
v5: mfplat/tests: Add tests for MP3 Byte Stream Output.
mfplat/tests: Add tests for Byte Stream Output.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7672
On Wed Apr 23 23:51:29 2025 +0000, Brendan McGrath wrote:
> > Just so I understand, SAR clock jumps to pts + \<time it actually took
> to play this sample/time it would take according to sample rate\> or it
> jumps blindly to pts + mf sample duration, ignoring actual playback
> time? I don't know how well sample duration is validated against actual
> buffer sizes.
> It will jump to PTS and then progress from there at the playback rate. I
> don't think it uses the duration value, just buffer size to determine
> duration (which is easy to calculate based on frame size and sample rate).
I should add that the clock stops once playback of the provided sample(s) are complete. It won't start again until it receives another sample. But if that happens, it seems to add an implicit discontinuity.
And after a discontinuity (either implicit as described above, or explicit via a sample attribute) it doesn't just jump forward anymore. It will instead insert a period of silence, so the clock will progress at the playback rate until the next PTS, and at that point it'll start playing the next sample.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101769
> Just so I understand, SAR clock jumps to pts + \<time it actually took to play this sample/time it would take according to sample rate\> or it jumps blindly to pts + mf sample duration, ignoring actual playback time? I don't know how well sample duration is validated against actual buffer sizes.
It will jump to PTS and then progress from there at the playback rate. I don't think it uses the duration value, just buffer size to determine duration (which is easy to calculate based on frame size and sample rate).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101767
> Is this an artifact of your tracing or OnClockRestart() is actually never used?
It was calling `OnClockStart`, but it turns out that was because I had hard-coded the value in my `MESourceStarted` and `MEStreamStarted` events. After changing these events to instead use `pvarStartPosition` passed in `IMFMediaSource::Start`, I get:
```
1330.024952|10088|source_mock_Start: format: {00000000-0000-0000-0000-000000000000} (GUID_NULL) position: <EMPTY>
1330.025598|10088|clock_sink_OnClockRestart: system time 13300255028
```
So sending those events with a hard-coded `VT_I8` value of zero caused `OnClockStart` to be called, but now those events have a value of `VT_EMPTY` and `OnClockRestart` is called.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7833#note_101766
--
v6: mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the object_id of the last object in the prototype chain that
mshtml: Define "create" from XMLHttpRequest constructor as a jscript prop
mshtml: Consolidate the functional constructors into a common struct
mshtml: Rename struct constructor to stub_constructor.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7779
This fixes "out of realized font handles" errors seen with Valve games like Half-Life 2 (which uses more than 1000 font handles).
The new limit of 5000 is roughly inspired by the Windows limit, although there are differences. On Windows 11 I can call `CreateFont()` (and then `SetMapMode()`, `SelectObject()`, `SetTextAlign()` to realize the font) exactly 5000 times before it hits the handle limit.
Under Wine, child fonts use handles as well, so the limit is usually hit before 5000 `CreateFont()` calls. But, there is caching so that `CreateFont()` calls with identical arguments do not count towards the limit. Ultimately the old limit of 256 was sufficient for almost all applications, and 5000 should be enough for all but the worst-behaved apps.
--
v2: win32u: Make font handle table dynamically growable.
win32u: Track free font handles through indices instead of pointers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7771
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v3: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v2: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885