mirror of
https://github.com/obsproject/obs-studio.git
synced 2024-09-20 21:13:04 +02:00
b427397aa9
A little bit of history about frame dropping: I did a large number of experiments with frame dropping in old versions of OBS1, and it's not an easy thing to deal with. I tried just about everything from standard i-frame delay, to large buffers, to dumping packets, to super-unnecessarily-complex things that just ended up causing more problems than they was worth. When I did my experiments, I found that the most ideal frame drop system (in terms of reducing the amount of total data that needed to be dropped) was in the 0.4xx days where I had a 3 second frame-drop buffer where I could calculate the actual buffer size in bytes, and then intellgently choose packets in that buffer to trim it down to a specific size while minimizing the number of p-frames and i-frames dropped, and preventing the actual impact of dropped frames on the stream. The downside of it was that it required too much extra latency, and far too many people complained about it, so it was removed in favor of the current system. The current system I just refer to just as 'packet dumping', which when combined with low keyframe intervals (like most services use these days), is the next-best method from my experience. Just dump the buffer when you reach a threshold of buffering (which I prefer to measure with time rather than in size), then wait for a new i-frame. Simple, effective, and reduces the risk of consecutive buffering, while still having fairly low impact on the stream output due to the low keyframe interval of services. By the way, audio will not (and should not ever) be dropped, lest you end up with syncing issues (among other nasty things) specific to server implementation. |
||
|---|---|---|
| .. | ||
| librtmp | ||
| CMakeLists.txt | ||
| flv-mux.c | ||
| flv-mux.h | ||
| obs-output-ver.h | ||
| obs-outputs.c | ||
| rtmp-helpers.h | ||
| rtmp-stream.c | ||