libdshowcapture icon indicating copy to clipboard operation
libdshowcapture copied to clipboard

fix: Force syncpoint on everysample

Open sandercox opened this issue 2 years ago • 7 comments

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.

sandercox avatar Mar 07 '23 21:03 sandercox

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)?

WizardCM avatar Mar 24 '23 09:03 WizardCM

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.

sandercox avatar Mar 24 '23 09:03 sandercox

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.

sandercox avatar Mar 24 '23 09:03 sandercox

@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.

sandercox avatar May 08 '23 08:05 sandercox

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.

sandercox avatar Sep 09 '24 22:09 sandercox

Users of what? Having a way to test this would be helpful to verify the issue and that this is the correct fix.

Fenrirthviti avatar Sep 10 '24 00:09 Fenrirthviti

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.

sandercox avatar Sep 10 '24 10:09 sandercox

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)

Lain-B avatar Nov 09 '24 21:11 Lain-B

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.

Lain-B avatar Nov 09 '24 21:11 Lain-B