AmberCutie's Forum
An adult community for cam models and members to discuss all the things!

Any Way to Configure OBS to Capture One Frame Per Second?

  • ** WARNING - ACF CONTAINS ADULT CONTENT **
    Only persons aged 18 or over may read or post to the forums, without regard to whether an adult actually owns the registration or parental/guardian permission. AmberCutie's Forum (ACF) is for use by adults only and contains adult content. By continuing to use this site you are confirming that you are at least 18 years of age.
Status
Not open for further replies.
Jun 27, 2017
1,139
625
163
For those times when your video upload performance is just bad, is there a way to configure a video capture device on OBS and have it take a snapshot once a second and upload that still image as the image for your broadcast? This would convert your broadcast from being a real-motion video into a sequence of still images. As long as your microphone continues to work, it would be much more enjoyable to watch a sequence of 1920x1080 pixel still images than to have a 240 fps video that constantly stutters, and that also takes out the audio during the frozen video sections.

There are probably ways to do this in the Logitech webcam software, and there may be ways to do this in OBS as well. What are some options for achieving this broadcast effect?
 
1 fps is really too low and is rejected ie by Chaturbate (and confirmed, I just tried in OBS ^^).
It would be rejected as well by viewers :/

Edit : I don't think that you would make an huge economy in streaming at 24fps a "1 fps source"

Though, it's easy to adjust your streaming fps in settings.
Use your keyboard to force the value, don't only select in the list :

"5" is also rejected by CB, 10 is accepted.
1586698708728.png

my adsl net is far too low, I usually use 20 fps and limit also bandwidth (so lose quality) then my stream can be 720p,
20 fps is a classic value used in cartoons (if you don't move too fast, viewers won't notice)
Reaching 180p using such tricks is just to forget
1586698291369.png
This gives an actual average total bitrate of 650Kbps more or less, staying under my own limit of 800Kbps, so I have no interruption of the stream.

Note also that an audio bitrate of 64 is the minimum you can consider with a sample rate of 44.1kHz
 
Last edited:
1 fps is really too low and is rejected ie by Chaturbate (and confirmed, I just tried in OBS ^^).
It would be rejected as well by viewers :/

As a viewer of many models with huge performance problems, I can say for sure I would accept 1920x1080 pixels at 1 fps and a clear microphone over a 480 fps that constantly stutters and takes out sound.

Though, it's easy to adjust your streaming fps in settings.
Use your keyboard to force the value, don't only select in the list :

"5" is also rejected by CB, 10 is accepted.

10 fps as a minimum CB will accept in OBS is a useful data point thanks!

So the problem I am noticing with many broadcasts that have this stutter problem is that their ISP is taking them from very high upload speeds to ZERO, and then back up to the high speed. That makes it impossible to get continuity at *any* realistic frame per second. It is not about average bandwidth. Is about overcoming the implications of the occasional zero bandwidth.
 
As a viewer of many models with huge performance problems, I can say for sure I would accept 1920x1080 pixels at 1 fps and a clear microphone over a 480 fps that constantly stutters and takes out sound.



10 fps as a minimum CB will accept in OBS is a useful data point thanks!

So the problem I am noticing with many broadcasts that have this stutter problem is that their ISP is taking them from very high upload speeds to ZERO, and then back up to the high speed. That makes it impossible to get continuity at *any* realistic frame per second. It is not about average bandwidth. Is about overcoming the implications of the occasional zero bandwidth.

I thought that most camsites buffer the stream and have a delay in broadcasting it for that purpose?
 
  • Like
Reactions: DoD404
you can do nothing against a "zero bandwtidth" :)

But the zero bandwidth might last for 1/2 of one second. So if you are updating a still image once a second, the unevenness in your upload speed can be hidden away from the viewer.
 
I thought that most camsites buffer the stream and have a delay in broadcasting it for that purpose?

Of course, but there are technical limitations to that. For example, if your video feed requires 5 Mbps upload speeds, they might be able to buffer a connection that goes from 3 Mbps to 6 Mbps. But they are not able to handle a connection where the upload speed goes to 0 Mbps for 1/2 a second. At some point if your upload speed looks like a sin wave with the trough at 0 Mbps, the viewer is going to perceive that. I have watched models where 720p60 works flawlessly, and within half an hour their connection degrades so that even 240 pixels staggers.
 
But the zero bandwidth might last for 1/2 of one second.

no. Not at all. 1 second is only 24 frames at 24 fps.
1/2 second losing frames happens very often with no side effect at all.
(It happens even between your own local dvd player connected directly to your TV set).

To produce this effect of stutering, it means that the "zero bandwidth" lasted for at least 10 or 15 seconds and certainly more around 30 secs : )
The buffers' sizes at every step (streamer before sending, server, client) are about 40 seconds each.
Depending on implementaion they fulfill half of buffer before beginning to render it in your browser, that makes the constant delay of 10 to 20 seconds you observe between chat and stream.
When you see stuttering, it means that the server tries to keep online a really broken connection.

I have watched models where 720p60 works flawlessly, and within half an hour their connection degrades so that even 240 pixels staggers.
flawlessly doesn't mean with enough margin. Think also that a stream flow is never very constant and depends on how the frames are encoded in real time.
This can vary a lot with the light, the model's moves, and many other factors...

In my case I can do 0.800Mpbs (checked with my router's bandwitdh graphics in real time).
If I do exactly 0.800Mbps, I would continuously be a bit limited without this time margin and the buffers would be empty ie every half hour or every hour.
This can appear flawless on a single check by a viewer, but it is not.
That's why I adjust to have an average of 0.650Mbps (makes 0.750Mbps when I make moving fast a lot of things on the screen ie...)

Edit: (Mbps unit adjusted... were Kbps) Btw thanks, while checking my adjustments, I noticed that 'they' increased my upload limit to around 1.100 Mbps xD
 
Last edited:
Depending on implementaion they fulfill half of buffer before beginning to render it in your browser, that makes the constant delay of 10 to 20 seconds you observe between chat and stream.
When you see stuttering, it means that the server tries to keep online a really broken connection.

10-20s seems really long, I rarely see a delay of more than 6-7 seconds in most rooms, and I've seen under 2s.
 
no. Not at all. 1 second is only 24 frames at 24 fps.
1/2 second losing frames happens very often with no side effect at all.
(It happens even between your own local dvd player connected directly to your TV set).

To produce this effect of stutering, it means that the "zero bandwidth" lasted for at least 10 or 15 seconds and certainly more around 30 secs : )
The buffers' sizes at every step (streamer before sending, server, client) are about 40 seconds each.
Depending on implementaion they fulfill half of buffer before beginning to render it in your browser, that makes the constant delay of 10 to 20 seconds you observe between chat and stream.
When you see stuttering, it means that the server tries to keep online a really broken connection.

I had a test upload of a 1920x1080 stream to the CB testbed where the upload was constantly cycling from 8 Mbps to 0 Mbps. The buffering scheme CB was using just did not handle that gracefully. In any case, I understand your point about how it is supposed to work. I find in practice that it is much less optimized than you suggest.
 
Status
Not open for further replies.