GNOME Bugzilla – Bug 783532
encoder: regression in CBR mode encode
Last modified: 2017-06-09 20:03:01 UTC
The recent patches seems to brought a huge regression in BRC. Driver is generating the warning "WARNING: Rate control parameter is required for BRC" , which basically disabling the BRC algorithms. Probably the last three commits: commit f8afb1eea475d2d77b5b660609a0f02da401636f Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Date: Wed Jun 7 12:32:53 2017 +0200 libs: encoder: bitrate target percentage calculation If the rate control is set to Constant Bit Rate (CBR) the target percentage is 100%, otherwise is 70% commit 4b5ecca29c81d0219d83d3271c1aa5e25c3673d8 Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Date: Wed Jun 7 12:25:24 2017 +0200 libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor ratecontrol param Centralize the common configuration for the Rate Control parameter, thus can be overloaded per each specific encoder. commit 035efded759e181ec8591fc360758530bb757446 Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Date: Wed Jun 7 11:10:49 2017 +0200 libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor framerate param Since the framerate VA parameter is calculated equally among all the encoders, it is better to handle it in the base encoder class.
(In reply to sreerenj from comment #0) > The recent patches seems to brought a huge regression in BRC. > > Driver is generating the warning "WARNING: Rate control parameter is > required for BRC" , which basically disabling the BRC algorithms. > > Probably the last three commits: > I can't reproduce the warning. Could you tell me the pipeline you're using and the version of libva to reproduce?
Aha, I thought it is reproducible with all pipelines sorry :) Here you go: server: gst-launch-1.0 -v filesrc location= HoneyBee_1920x1080.I420 ! rawvideoparse format=i420 width=1920 height=1080 framerate=60/1 ! rtpvrawpay ! udpsink host=127.0.0.1 port=5000 sync=false client: gst-launch-1.0 udpsrc port=5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)1920, height=(string)1080, colorimetry=(string)BT709-2, payload=(int)96, ssrc=(uint)428940642, timestamp-offset=(uint)1245392745, seqnum-offset=(uint)15302, a-framerate=(string)60" ! rtpvrawdepay ! vaapih264enc rate-control=cbr bitrate=2000 ! fpsdisplaysink video-sink=fakesink text-overlay=false sync=false Or you can reproduce it with the below steps: Install rawvideosink from https://github.com/sreerenjb/gst-rawvideosrc gst-launch-1.0 rawvideosrc location=HoneyBee_1920x1080.I420 ! video/x-raw, format=I420, width=1920, height=1080 ! vaapih264enc rate-control=cbr bitrate=2000 quality-level=7 ! fakesink
Basically both of the above steps are for avoiding the extra memcopy(s) introduced by "filesrc + videoparse" combo.
Created attachment 353371 [details] [review] libs: encoder: fix to figure out if the given framerate is non-0 Since the variable framerate is calculated based on bit operation, we should figure it out in the same way.
@Sree, could you test with this patch?
If I understand correctly, the problem with these pipelines is because it doesn't set a framerate, thus GStreamer assigns 0/1 which means still image, and that might not be compatible with CBR nor VBR. Am I correct? in the case of the RTP, I don't know, but int the case of rawvideosrc might be a bug in it.
Created attachment 353376 [details] [review] libs: encoder: set framerate if bigger than 0/1 Just set the framerate parameter if the framerate numerator and denominator are bigger than zero. Otherwise, in Intel Gen6 driver, a warning is raised disabling the bitrate control. Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
Comment on attachment 353371 [details] [review] libs: encoder: fix to figure out if the given framerate is non-0 I prefer the other approach: not setting framerate if it is not bigger than 0/1
(In reply to Víctor Manuel Jáquez Leal from comment #8) > Comment on attachment 353371 [details] [review] [review] > libs: encoder: fix to figure out if the given framerate is non-0 > > I prefer the other approach: not setting framerate if it is not bigger than > 0/1 That's good. BTW, I surprised that I've already proposed a patch for RTP about this issue long time ago though it's not merged. I almost forgot this. See #758169 :)
Attachment 353376 [details] pushed as 94b41c8 - libs: encoder: set framerate if bigger than 0/1
(In reply to Hyunjun Ko from comment #5) > @Sree, could you test with this patch? Sorry I am late, anyway patch is in place and it fixed the issue too,,,thanks :)