GNOME Bugzilla – Bug 749122
vp8enc: vp9enc: target bitrate is not working as expected
Last modified: 2015-05-12 13:01:40 UTC
When using this pipeline: gst-launch-1.0 v4l2src num-buffers=300 ! vp8enc resize-allowed=true target-bitrate=100000 deadline=1000000 threads=1 cpu-used=16 end-usage=cbr ! video/x-vp8 ! webmmux ! filesink location=/tmp/test_1.4.webm Output bitrate of output file is about the a half (or the third part sometimes) of the target-bitrate, but using the same pipeline in with gstreamer 1.4.5 the bitrate is closer to the target bitrate. * With gstreamer 1.5 I get a file of 274772 * With gstreamer 1.4.5 I get a file of 411905 The duration of the file is the same in both cases 33.3 seconds
The number with 1.4.5 is obviously the correct one, with that bitrate and duration it should be around that many bytes. Going to take a look in a bit.
Oops, I completely forgot to file this one, but I confirm.
Created attachment 303201 [details] [review] vp[89]enc: Don't set timebase from the framerate The framerate very often is just an indication of the ideal framerate, not the actual framerate of the stream. By just using the framerate, we confuse the rate control algorithm algorithm as multiple frames will map to the same PTS or have durations of 0.
Created attachment 303202 [details] [review] vp[89]enc: Don't set timebase from the framerate The framerate very often is just an indication of the ideal framerate, not the actual framerate of the stream. By just using the framerate, we confuse the rate control algorithm algorithm as multiple frames will map to the same PTS or have durations of 0.
Created attachment 303203 [details] [review] vp[89]enc: Use nanoseconds as default timebase It's not clear why 90kHz as in RTP would be a better choice.
This is just a guess, so please test the patches. My camera apparently gives an almost constant framerate stream here somehow... but if it wasn't I can see how this would cause interesting problems like a completely confused rate control algorithm.
For the last patch, it might break things. Not entirely sure. This RTP 90kHz thing was added as part of https://bugzilla.gnome.org/show_bug.cgi?id=695709 Tom, are you sure the timebase gets into the resulting bitstream and can cause problems with some software if too high?
Using both patches now I get 407798 bytes for the same test. Using just first patch 237754.
I have already make the test in https://bugzilla.gnome.org/show_bug.cgi?id=695709 And it works with a quality that seems to be correct (I haven't measured it).
My comment about bug #695709 is only for the timebase, we're definitely not reintroducing the bug there :) It's just not clear if a higher timebase might cause other software to fail. Can you run only with the first patch and put an identity silent=false before the encoder, and run gst-launch with -v? I'd like to see the timestamps and caps :)
Created attachment 303212 [details] log.txt Log running example with -v and adding an identity before the encoder
I've tried to force variations in framerate variating the light that the camera received.
Not sure what the problem is in your case. Can you print the pts and durations that are calculated before vpx_codec_encode() and give me a log with the buffer timestamps and those values?
Why do you say that I have a problem? It seems to work fine with the patches.
It should also work fine with only the first patch, i.e. the one in comment 4 but not the one in comment 5. If it only works with both together, then there's a problem somewhere that I don't understand and we should fix that. It's not clear of the patch in comment 5 is acceptable yet, and in theory it shouldn't make a difference for your problem.
Ok, understood, I'll send the logs you requested.
Created attachment 303242 [details] duration and pts logs Log printing calculated duration and pts.
Is that log with only the first patch?
Yes, and the resulting file has 260713 bytes.
Ok, there was something very stupid. Fixed that now ;) See newly attached patch. Does this work for you now (with these two patches, but not the one from comment 5)? These two are pushed now: commit a0b69c8dac4fed558845b3251105395ae94b8059 Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue May 12 12:13:16 2015 +0300 vp[89]enc: Properly convert between GStreamer and encoder timebase ... by switching numerator and denominator when scaling. https://bugzilla.gnome.org/show_bug.cgi?id=749122 commit eb365cc3bb9361469ce11f7fe99f26c892b0663e Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon May 11 13:33:26 2015 +0300 vp[89]enc: Don't set timebase from the framerate The framerate very often is just an indication of the ideal framerate, not the actual framerate of the stream. By just using the framerate, we confuse the rate control algorithm algorithm as multiple frames will map to the same PTS or have durations of 0. https://bugzilla.gnome.org/show_bug.cgi?id=749122
Created attachment 303250 [details] [review] vp[89]enc: Properly convert between GStreamer and encoder timebase ... by switching numerator and denominator when scaling.
Patch https://bug749122.bugzilla-attachments.gnome.org/attachment.cgi?id=303250 does not apply over current master a0b69c8
Ok, sorry it is already merged. With the two patches already merged I get similar results, now 190258 bytes.
Sorry, I test against the wrong module. It works correctly now, I get 428096. Thanks for the fix.
Ok, so with the patches in git and not applying any additional patches, it's all good now? Just to be sure :)
Yes, that's it :)
Ok great, thanks for testing :)
Comment on attachment 303203 [details] [review] vp[89]enc: Use nanoseconds as default timebase Let's ignore this one for now then