Raspivid bitrate gets 'stuck' at a much higher bitrate

[rodizio1]

As you probably know, the bitrate of the h264 stream is not 100% constant, even when setting a fixed bitrate. Depending on the environment and lighting, I found that sometimes, bitrate can go about 50% higher than set.

This is, however, usually only for brief moments, for example when quickly pointing the cam at the white ceiling (=not much to encode) and back into the room (=lots more information to encode) bitrate goes up for maybe half a second.

A more extreme way to produce these bitrate fluctuations is covering the cam so that it sees 'absolute black' and then uncovering the lens very quickly. In these situations, bitrate stays high (+50%) for several seconds. Not an issue in real-life though.

However, I have found that sometimes, the bitrate gets 'stuck' at those about +50%. Meaning, it stays like that forever, no matter what I do. Only way to resolve this is restarting raspivid.

What I can tell so far is, that it seems not depending on the Pi or the Cam model, I've seen this behaviour with a Pi2 and a Pi0 and Pi1A+ as well as with an official v1 cam, v2 cam and a v1 cam clone.

Regarding the firmware/kernel/userland I'm not sure, I've first noticed this with Rasbian 2017-07-05, but it could be that I just didn't notice before.

Is there anything I can do to narrow this down further?

[rodizio1]

Here is a video showing the issue:

https://m.youtube.com/watch?v=WjjS_RlfAag

The first number in the upper right corner (5521) is the bitrate raspivid is set to, the number below the live bitrate of the videostream. As the user moves the cam in and out of the light, the bitrate goes up to around 7000kbit-7400kbit and stays like that for a while.

[rodizio1]

@6by9

quoting you from here: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=145815&p=990579#p990599

If you see >25% above the target bitrate averaged over a second, I'd consider it a bug. Seeing spikes on individual frames is expected behaviour.

Could you please give some hints on how this could be further narrowed down?

[6by9]

I'd need the full raspivid command line that you're using as a start. The rate control algorithm is buried well down in the firmware, and isn't part of the stack that I'm overly familiar with.

If you can provide an output H264 stream that latched into the high bitrate mode, then it may be that decoding it and replaying that through the encoder also latches up and give me a useful reproducible test case. (It may be that the codec artefacts mean it doesn't latch up, but worth a shot).

[rodizio1]

It seems to happen regardless of options used (or atleast I couldn't find a pattern).

The commandline I'm using is: raspivid -w 1280 -h 720 -fps 48 -b 7500000 -g 5 -t 0 -cd H264 -n -fl -ih -pf high -if both -ex sports -mm average -awb horizon -o -

I'll try to do some more testing this week, thanks for your help.

[rodizio1]

Sorry for the late reply, finally had the chance to test and reproduce it.

Commandline used was: raspivid -w 1280 -h 720 -fps 48 -b 8400000 -g 5 -t 0 -cd H264 -n -fl -ih -pf high -if both -ex sports -mm average -awb horizon -o -

Here is the video you requested (sorry for the crappy filehoster, beware of ads): https://www.file-upload.net/en/download-13080000/video0.avi.html

This is the bitrate graph of the above video:

Here are some screenshots of the above video, when pointing the cam at the cloudy sky, bitrate goes down to around 2mbit, when pointing back down at some 'scenery', it climbs to around 15-16mbit and stays there for several seconds. Then, eventually, it goes down to around the set bitrate of 8.4mbit. Like written above, sometimes the bitrate stays high "forever", I haven't been able to reproduce that now, though.

[rodizio1]

Here is another video from a user of my EZ-Wifibroadcast distribution (Raspberrys used for flying FPV model aircraft) showing the issue. He is using the same raspivid settings, just with a different bitrate (around 6mbit). I have asked the user to also record the raspivid videostream directly (i.e. not with a 2nd camera recording the screen), I'll also try to supply that when I get the file.

https://www.youtube.com/watch?v=XJkGIyoKkvM&feature=youtu.be

[rodizio1]

Found another way to reproduce it:

• Point cam towards a TV running Southpark ;)
• Quickly point it towards a white wall above the TV

While the cam is pointed towards the TV, the bitrate is normal, i.e. around the set 8.2mbits. As soon as the cam is pointed towards the white wall, bitrate goes down to around 2-3mbit, then back up to 11-12mbit and stays there for several seconds.

Here is the video (beware of ads, sorry): https://www.file-upload.net/en/download-13080984/video1.avi.html

Bitrate graph of the video:

Screenshots:

[rodizio1]

Here is another video from a user of my EZ-Wifibroadcast distribution (Raspberrys used for flying FPV model aircraft) showing the issue. He is using the same raspivid settings, just with a different bitrate (around 6mbit). I have asked the user to also record the raspivid videostream directly (i.e. not with a 2nd camera recording the screen), I'll also try to supply that when I get the file.

This is the corresponding video file: https://drive.google.com/file/d/1a1eaVBPtbrrHTiVkQDeo_uooc0bw-nHG/view

In the meantime that user made another flight, where the bitrate variations also occured. Here, the bitrate goes up to about 10mbit for several seconds before it returns to the set bitrate of about 5.9mbit: https://youtu.be/Qb7Zw_SDOPg?t=3m10s

I've also tried a stock Raspbian 2018-03-13 image in the meantime (with rpi-update ran about a week ago, kernel 4.14.32) to make sure the problem is not related to my software or modifications. The problem also occurs there, I used the pipeviewer tool to display the bitrate:

raspivid -w 1280 -h 720 -fps 48 -b 8000000 -g 5 -t 0 -cd H264 -n -fl -ih -pf high -if both -ex sports -mm average -awb horizon -o - | pv -i 0.5 -r >> /dev/null

@6by9 mentioning you in case you didn't see the new posts after two months of silence from my side, not to push you :)

[6by9]

I'll have a look when I get a chance. If you're method to reproduce is as reliable as you imply, then there's a chance of finding out what is happening.

[rodizio1]

Here is another video showing the issue.

While the plane is on the ground in the grass, bitrate is about 3.7Mbit, after pointing the plane up in the sky, bitrate goes up to 10mbit.

https://youtu.be/UXBWK8ka1YA

[careyer]

@rodizio1 / @6by9 also suffering from the jitter in the fixed H264 bitrate. I am feeding the output of a thermal camera to the H264 hardware encoder and see large variances in bitrate depending on the image content - due to the thermal false color picture this is even more harsh than with visible light camera. Encoding works fine but the massive variances in bitrate (which should be more or less fixed) induce lots of lag when transmitting the data via wireless.

[JamesH65]

There is always going to be some jitter in the actual bitrate acheived, especially when moving from very different frame content as in your case, simply because large frame differences require more bits, and you cannot predict they are going to happen. You can compress more of course, but at the point of compressing you don't actually know how much to compress, and there isn't enough time when live encoding to pass over it multiple times to chose the exact compression factor required to hit the specific bitrate. This is why offline encoding systems have two passes, which is of course not possible with live encoding (unless maybe you have a REALLY fast encoder which we don't).

In your case I would be inclined to specifiy a much lower bitrate, with consequent lowering of quality, so the peaks are also lower. Or perhaps drop the resolution, although thermal cameras are not that high anyway so that may not be possible.

[rodizio1]

@JamesH65: Please read the issue and look at the graphs, videos and screenshots I provided. Your answer looks like you did not even read the headline or the first post.

Edit: Sorry James, I did not realize you were just replying to careyer. Anyway, the issue is not what careyer is describing (normal, because with live video, the codec cannot look into the future ...), it's that the bitrate stays high for several seconds (and sometimes for minutes or even longer).

[careyer]

Thank you very much for your comprehensive explanation which I can completely comprehend. I already reduced the bitrate to a bare minimum (resolution is already very low) because of that reason but I still see the effect that rodizio describes. Especially that often it tends to take very long to recover from the higher bitrate back to the lower bitrate floor. Sometimes it does never recover.

[Davidsastresas]

I can reproduce and confirm the observations made by rodizio on the same setup.

[F5OEO]

Can you provide a raw video in h264 to try to reencode or can you try to test https://github.com/F5OEO/avc2ts as I work mainly to obtain a CBR stream.

[JamesH65]

@rodizio1 I have read the first post, but in fact I was replying to @careyer post imediately before mine, not the thread as a whole. I am aware that the issue is not the jitter per-se, but getting stuck at a specific bitrate when it should have dropped down.