h264 stream still high bit rate when no movement

Marc Marc at f1-outsourcing.eu
Tue Oct 19 17:46:16 UTC 2021

Hi Marianna, thanks for this detailed explanation again! Really appreciate it. This streaminglearningcenter.com is really interesting!

> Except that it seems you have roughly 1 key-frame per second, or 1 every
> 21.5 frames, so it also seems like you don't have a fixed KF interval
> but that the encoder is dynamically adding them "as needed".
> One way to reduce the bitrate is to increase the KF interval to 2-10
> seconds, since it is the frames that takes the most space. But that has
> it's disadvantages as well (buffering, seeking, HLS segment size) so you
> need to know what you are doing: is that live streaming, file saving,
> ...?
> I'm guessing you are using x264enc? You can also play with other
> settings like the speed presets (which set a lot of the parameters). But
> keep in mind it is always a trade off between quality, bitrate and
> processing time.
> Also take a look at
> https://streaminglearningcenter.com/encoding/how-to-choose-your-bitrate-
> control-technique.html
> which has a pretty good explanation about rate-control settings which is
> pretty much the most important thing defining the bitrate/quality. The
> example uses ffmpeg, but it is not difficult to translate to the
> gstreamer plugin version of x264.
> Basically if you use CBR (constant bitrate) you don't see any difference
> in the bitrate between moving and static scenes. And everything is bound
> to the bitrate you require. Normally higher bitrate=higher quality, but
> that curve flattens at some point (and the point depends mostly on the
> scene you are streaming). Normally the worst choice, unless your network
> is very constrained.
> If you use VBR (variable bitrate) you get the difference between moving
> and static, but still keep the requested average. Again it is a bit of a
> science to figure out the "correct" bitrate for the scene you have.
> Or you can use one of the quality based methods. Which means your
> bitrate can vary like crazy, because the encoder will make sure to use
> as many bits as it needs to keep the quality constant. And here you have
> to fiddle with a quality parameter. Best choice for quality, but might
> be hard to stream since you don't know the bandwidth you need/have. The
> good thing is that there are also options to constrain it (set a maximum
> bitrate), so you can keep it from "exploding".
> On 18.10.2021 15.38, gstreamer-devel-request at lists.freedesktop.org
> wrote:
> > I have around 9 I frames, and 206 P frames per 10s.
> > 1280x720 pixels, 25 fps
> >
> > Input #0, mpegts, from '/tmp/video.raw':
> >    Duration: 00:00:08.60, start: 9590.882000, bitrate: 2328 kb/s
> >    Program 1
> >      Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B),
> yuvj420p(pc, bt709, progressive), 1280x720, 25 fps, 25 tbr, 90k tbn,
> 180k tbc
> >      Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F),
> 44100 Hz, stereo, fltp, 90 kb/s
> --
> Best regards / Med venlig hilsen
> “Marianna Smidth Buschle”

More information about the gstreamer-devel mailing list