fix: Force syncpoint on everysample
Description
This changes every sample to clearly state that they are sync points.
Motivation and Context
As the virtual camera always sends frames that are uncompressed and/or keyframes the best is to always mark these samples as such. When not doing this I was having issues in Resolume Arena that sometimes the OBS stream would show up and on other times it would not and the virtualcam filter would not transition into running state properly.
IMediaControl->Run() would only call into the Pause call on the filter but not the Run call, not always sometimes it would work, so I guess this memory was 'uninitialized' when not set explicitly.
How Has This Been Tested?
Running aforementioned software with and without this change. Tested on Windows 11, core i9.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
Is this considered standard practice, or a hack due to some other behaviour (either elsewhere in the library or in the app interacting with the virtual camera)?
From MSDN documentation: https://learn.microsoft.com/en-us/windows/win32/api/strmif/nf-strmif-imediasample-setsyncpoint
The filter that first generates the data in the sample should set this flag to TRUE or FALSE, as appropriate. For uncompressed video and PCM audio, set every sample to TRUE. For compressed video, set key frames to TRUE and delta frames to FALSE.
As only keyframes are recorded with this filter it should be marked as true for every frame.
Though we also clear-out the reference clock on an OBS source explicitly as otherwise we don't get updates on the graphics. So I would not be surprised if there is a bigger issue with the frame timing inside the capture filter.
@WizardCM can we get this in?
even if this is just more explicit than maybe set by default, it still would make sense to add this flag as it is the correct behaviour for these streams.
This still seems to be an issue for our users and our modified Virtual Camera with just this fix seems to solve it. Would be great if we could get this merged.
Users of what? Having a way to test this would be helpful to verify the issue and that this is the correct fix.
I'm sorry that was unclear. I'm one of the authors behind Resolume Arena when we use the OBS virtual camera without this fix we receive black video / no samples.
I suppose I'm okay with this as long as it's tested with other software to verify there's no potential regression (I doubt there will be but I'm just being paranoid I suppose)
I think most important devices to test this with are devices that have synchronization issues, such as the older USB 2.0 Elgato devices and USB 2.0 devices in general that have limited bandwidth.