i.MX6 h264 encoder bitrate higher than asked in CBR mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 h264 encoder bitrate higher than asked in CBR mode

1,768 Views
jfp
Contributor II

Hi everybody,

I'm working for a video streaming application, and have to work in constant bitrate mode (5500 kbits/s).

Générally, it works well and the mesured bitrate is CBR +/- 200 kbits/s. Some times a little peak, but just on some images.

But we have some rare videos where the bitrate is about 6500 kbits/s, during one to two minutes !

As the video is not just streamed but also saved onto disk, I could extract frames and compute a real mesure.

For exemple, here is what we have the first 3 seconds. The GOP is 5, and mesures are computed every 5 images, so 200ms into the array

time (s)nb bits for 5 images (IPPPP)average bitrate (bits/s)
07889080
0,23089000
0,450393205723264
0,661634405460216
0,864354806162560
165738406460736
1,266007206543912
1,465302006564496
1,665793206569016
1,865384006555088
265964406564144
2,265310806569088
2,465754806584696
2,666040406590192
2,866164406591808
366239206592496

As we can see, the bitrate is 6500 kbits/s, instead of the programme 5500 kbits/s.

After 100 s, bitrate suddenly falls to 5500 kbits/s as set into the encoder open parameters, without resetting or doing something particular...

The scene, before or after this change, can be considered as static (some really few movement), and is allways the same.

My system version is resumed here :

- Linux kernel 3.14.38

- libfslvpuwrap3    version  1.0.61-r0

- firmware-imx-vpu-imx6q      version 1:5.2-r0

- libgstfsl-1.0-0    version   4.0.7-r0

- gst1.0-fsl-plugin     version 4.0.7-r0

And unfortunately I can not change it...

The gstreamer plugin uses the wrapper VPU_EncOpenSimp() function to open the encoder (which set to "0" initialDelay and VbvBufferSize, and others parameters).

Is there a known issue about such a problem ?
Is there something I can do to add some usefull informations ?

Thanks for any help you could offer.

Regards,

Jean-François

Tags (1)
0 Kudos
Reply
3 Replies

1,515 Views
jfp
Contributor II

Hi everybody,

I made some over tests, and know I'm not sure that it is a problem of the VPU itself.

At first time, someone made this remarks about the graph : it is like if the value of the bitrate parameter was wrong in the VPU... I don't think because the measured bitrate is really close to waht we asked.

But first over test I made : I decode the video and then reencode it with the same parameters (but with gst-launch instead of my software). The results is here :

pastedImage_1.png

This represents the bitrate in 10^3 kbits/s, computed every 5 images (so, every GOP).

The bitrate is a little lower, which I think is normal because this is not the original picture but an allready encoded one).

The scales are not exactly the sames but you can see that the global pattern of the curve is the same !

So it is not a problem of passing the parameter...

And then, an over test : I take the video and reencode it with VLC on Windows, which use the x264 software codec.
Here is the result :

pastedImage_2.png

This is more uggly than with the i.MX6 VPU encoder, and the bitrate is higher !

But you can see the pattern of the curve is similar, no (if we don't look at the end which is so ugly) ?

So My conclusion is that is should be an h264 limitation, not a VPU limitation, and it should come, perhaps, from some used parameters ?

Then I made one last test : reencode it but with a GOP of 10 instead of 5.

Here is the result :

pastedImage_3.png

There is less points on the horizontal axis because there is one point per GOP and GOP is bigger...

But it seems to work fine, with this parameter...

Is there anybody here which know h264 and could suggest me what I could test (changing some parameters other than the GOP ?) to have more accuracy over the output bitrate ?

Thanks for any idea and help you could offer !

Regards,

Jean-François

0 Kudos
Reply

1,515 Views
jfp
Contributor II

Hi,

Here is the complete graph of the video, to show you better this first phase where bitrate is really higher than expected.

pastedImage_1.png

Anything that someone could suggest would be a great help !

Thanks a lot and have a good day,

Jean-François

676 Views
marko1921
Contributor I

I see that you've done cool investigation. Unfortunately nobody answered your questions. Have you resolved problem with high bitrate? I have the same problem with IMX8M plus

0 Kudos
Reply