After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729307 - vtenc_h264: bitrate is very wrong
vtenc_h264: bitrate is very wrong
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-01 06:00 UTC by Robert Swain
Modified: 2018-05-05 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Robert Swain 2014-05-01 06:00:23 UTC
It looks like perhaps the bitrate parameter should be bits per second instead of kilobits per second though it's not clear.

gst-launch-1.0 -ev videotestsrc num-buffers=1500 ! \
    video/x-raw,width=640,height=360,framerate=15/1 ! \
    timeoverlay ! vtenc_h264 bitrate=768 ! h264parse ! \
    mp4mux ! filesink location=test.mp4

The above would give 100s of video. It encodes in about 14s which is nice. The resulting file size is: 1380225 bytes which works out as 110kbps. Nowhere near 768000.

If I run it with bitrate=768000, the resulting file size is: 22373189 bytes which works out as 1.8Mbps, which is also way off.

I was curious whether the noise in the default smpte pattern was screwing the rate control when using bitrate=768000 so I tried also one of the easier patterns, 'ball'. That gave a file 837721 bytes large which works out as 67kbps.

For something possibly more realistic, I captured two minutes of what should have been 720p30 from the FaceTime HD camera in this current model 13" Retina MacBook Pro with bitrate=3000000 and I got 9Mbps. With bitrate=3000 I got 0.59Mbps with really awful quality.

Now, that camera is quite noisy and the framerate is very sensitive to dropping if you're not in really bright lighting conditions. But even so, it seems like something is wacky with the bitrate of this H264 encoder.
Comment 1 Sebastian Dröge (slomo) 2014-09-23 19:26:55 UTC
Is this still a problem with latest git master? My latest changes included some fixes for code that should've completely confused the bitrate estimation.
Comment 2 Robert Swain 2014-09-28 13:56:20 UTC
Now the pipeline above doesn't preroll for me.
Comment 3 Sebastian Dröge (slomo) 2014-09-28 16:36:25 UTC
Why not?
Comment 4 Vivia Nikolaidou 2018-05-05 16:11:28 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!