You dropped a 2GB video into OBS.... why?
Seemed like a logical way to use an OBS Config which was designed for livestreaming a programme involving a live captured HDMI source, to produce the intended programme which could be recorded, except using a pre-recorded file rather than the live HDMI capture.
Was that not logical?
OBS isn't a player or a video editor.
Indeed, and I'm not quite sure where I conveyed the impression that I thought it was a player OR a video editor.
There's no good reason to record such a long and large file and then load it into OBS.
There's an excellent reason to do it. The reason is that instead of live-streaming HDMI captured video streams you are instead broadcasting pre-recorded video, which can have a number of very credible uses for regular content producers releasing content in scheduled streamed events which may be curtailed by illness, technical difficulties, or problematic travel schedules for which pre-recorded content may be an apt substitution.
In this case the inability of the principal subject of the programme being unable to be in the recording facilities at the time the programme was put together was substituted by a video recording made to the length of the intended segment offsite, and then brought into OBS in the form of the resulting MP4 file.
Without a prior indication of OBS being incapable in some way of handling video files it was clearly designed to import and make use of, and no indication of a recording length limit or some other issue, why would I NOT think it was a logical methodology?
OBS for compositing, switching, livestreaming and recording.
Compositing... yes.
Switching... yes.
Livestreaming... well... that part would appear to be merely one of two options offered by the software and merely a technical opportunity at that when critically...
RECORDING... is the 'primary' function, surely - the programme is either streamed, or stored in real time (like a virtual recording head), or indeed both, but either way the function is essentially the same as recording. One path stores data in archive, the other forgets it as soon as the current frame becomes past tense. Volatile or non-volatile data, as it were.
Why would that seem to be an illogical expectation?
Does it not seem reasonable that a system which is designed to produce this kind of content AND record it as well as livestreaming it might be expected to be able to do both with synchronicity? Why would I expect the livestream display - or to be properly correct about it, the 'live monitor' of the recorded content - to go seconds out of sync with the recorded stream itself?
It's quite easy to record a file so heavy that Windows' default player chokes on it and stutters and pops. If VLC plays it, the file is OK.
Curiously enough, the file was not 'so heavy' that Windows default player chokes on it and stutters and pops. Only OBS is stuttering and popping. VLC plays the file just as well also, and indeed I've tried to produce this content using the video file loaded directly as a media file, and also as a VLC playlist. Same result. Recording is nearly perfect. Livestream 'preview' is stuttering and popping and frame dropping and slipping way out of A/V sync. Yet producing a recorded file that isn't desynchronising at all.]
If your audience can't play it, then you're streaming at too high a bitrate.
The audience love the file, thank you. It goes straight from the OBS recording into Handbrake to make it a bit skinnier, and then right on to Vimeo. Streams a charm.
Still doesn't explain why OBS is dropping frames and desynchronising AV which is what I'm trying to beg advice to work out, since I wouldn't like to be three quarters into a livestream using this same programme format, and find that it starts doing it with an hour long HDMI capture, like it did with the pre-captured MP4 file.
Logic tells me that playing back a one hour MP4 file of pre-recorded content as a source in OBS should be less intensive than capturing it in real time simultaneously with all the OBS broadcast function and composite recording, no?
