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) |
0 | 7889080 | |
0,2 | 3089000 | |
0,4 | 5039320 | 5723264 |
0,6 | 6163440 | 5460216 |
0,8 | 6435480 | 6162560 |
1 | 6573840 | 6460736 |
1,2 | 6600720 | 6543912 |
1,4 | 6530200 | 6564496 |
1,6 | 6579320 | 6569016 |
1,8 | 6538400 | 6555088 |
2 | 6596440 | 6564144 |
2,2 | 6531080 | 6569088 |
2,4 | 6575480 | 6584696 |
2,6 | 6604040 | 6590192 |
2,8 | 6616440 | 6591808 |
3 | 6623920 | 6592496 |
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
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 :
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 :
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 :
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
Hi,
Here is the complete graph of the video, to show you better this first phase where bitrate is really higher than expected.
Anything that someone could suggest would be a great help !
Thanks a lot and have a good day,
Jean-François