This is much easier to see with a video that starts immediately with noticeable motion, because the effect only occurs for a short period. I have updated the steps to reproduce in the original issue post to make them easier to find. The combination of both "Restart playback when source becomes active" and "Close file when inactive" are required. I can reproduce this in OBS Studio 27.1.3 and a build from git at commit 1017cd5 with the updated steps to reproduce in this comment. I'm happy to provide my test recording if anyone on the OBS team would like it. So this absolutely appears to be a genuine bug that may be hard to visually identify (depending on the test video), but is easily visible under test conditions (numbering the test video frames and stepping through the frames of the resulting recording). After 60 frames of the recording, the test video plays back at the correct speed, but only every other frame - so the frames end up being displayed as 31,31,33,33,35,35,37,37 (etc) The last displayed frame of the previous run is again recorded for 30 frames, but this time is followed by the test video playing back at half speed for 60 frames of the recording (30 frames of the test video). Source enabled again (approx 1.5s later). Source again disabled in the middle of playback The last displayed frame of the previous run through the video is recorded for 30 frames, followed by a correctly playing video starting at frame 1 Source was enabled shortly thereafter (approx 0.5s). Source was disabled in the middle of playback. Hit record on OBS, poked the button a few times.įirst run through test video: 1:1 match between frames of test video and frames of OBS recording. Configuration otherwise identical to previous log. Took my previous test video, ran ffmpeg across it to visually number the frames, and output as mp4. My log, should it be helpful in narrowing down what set of things causes this: I did sometimes notice the first couple of frames seem to stutter (which makes sense, if the media is having to be reopened every time), but nothing lasting beyond the first second or so.
lying? They're not, but even if they were, why would you antagonize the people from whom you are asking for help (and some of the only people that would be able to actually, y'know, fix a real bug, if found)? Seems like that'd be more likely to make people less interested in working with you or investigating your problem.Īctual OBS support content: I set up a media source as directed, and spent a good 20 minutes turning it on and off trying to reproduce this, with varied 'on' and 'off' lengths of time, without success. Why wouldn't the log be useful?ĭo you think when a maintainer says "I need a log to troubleshoot this" that they're just. This is a problem that is obviously not experienced by everyone (I somehow doubt you're the only one that uses the media source and has it restart), there's obviously something about your environment which is triggering this, and the OBS log has all sorts of useful information about your environment.
If this is validated and better replication steps are found outside "do this and maybe it will break" we can certainly reopen this. We will likely need more information and this should be triaged through our support channels first, which have been provided. When you ignore our bug report process and leave out critical information, it means we can't take action. We reserve the github issues for confirmed and replicable issues, and regularly ask that users go through our support channels first if those are not available. This means, unfortunately, that we cannot take any action if it's an issue that is only occurring on your system.
I understand that you're frustrated by us closing this issue which you believe to be a bug, but you did not provide sufficient replication steps, you did not provide a log (which I should add is a required field, so you consciously chose to ignore that step by entering a bullet in the field instead of a valid link), and we were not able to replicate the issue.
0 kommentar(er)
