CBR mode HEVC encoding output is not satisfactory. Not even getting 50% accurate result. Tested with gstreamer-vaapi and libyami. I will try to give a genuine test case for proper results. 4k Video Sample: Foreman_H264.mp4 Create raw sample file: gst-launch-1.0 -q filesrc location= Foreman_H264.mp4 ! qtdemux ! queue ! h264parse ! vaapidecode ! vaapipostproc format=i420 ! checksumsink2 dump-output=TRUE Do CBR mode encoding, bitrate set to 20mbps: gst-launch-1.0 filesrc location= dump_output.yuv ! videoparse format=i420 width=3840 height=2160 framerate=30/1 ! vaapih265enc rate-control=cbr bitrate=20480 ! h265parse ! matroskamux ! filesink location=sample_4k_hevc.mkv Check the bitrate of encoded stream with gst-discoverer: gst-discoverer-1.0 sample_4k_hevc.mkv Expected output bitrate = ~20mbps What we get from encoded stream = ~7mbps Tests can be done with libyami project too. Issues reproducible. H264 CBR is working fine with above test case. Few links if someone want to reproduce exact test case failures ---------------------------------------------------------------- gstreamer-vaapi git master: https://cgit.freedesktop.org/gstreamer/gstreamer- vaapi/ checksumsink2 git master: https://github.com/sreerenjb/gst-checksumsink
the reason is FPS calculation change in VAAPI driver. this require yami and gstreamer change accordingly.
(In reply to Pengfei from comment #1) > the reason is FPS calculation change in VAAPI driver. this require yami and > gstreamer change accordingly. If you are talking about the timescale/time-tick calculation, this is done correctly in gstreamer-vaapi. What missing could be PACKED_SEI headers from upper level....
(In reply to sreerenj from comment #2) > (In reply to Pengfei from comment #1) > > the reason is FPS calculation change in VAAPI driver. this require yami and > > gstreamer change accordingly. > > If you are talking about the timescale/time-tick calculation, this is done > correctly in gstreamer-vaapi. > > What missing could be PACKED_SEI headers from upper level.... sure, Yami recaculate the FPS as the following: float fps = vui_time_scale / vui_num_units_in_tick ; RC logic use HRD info if HRD parameter is preset or default HRD info if HRD parameter is not preset. PACKED_SEI is not used in RC logic during the encoding process. thanks, Pengfei
(In reply to Pengfei from comment #3) > (In reply to sreerenj from comment #2) > > (In reply to Pengfei from comment #1) > > > the reason is FPS calculation change in VAAPI driver. this require yami and > > > gstreamer change accordingly. > > > > If you are talking about the timescale/time-tick calculation, this is done > > correctly in gstreamer-vaapi. > > > > What missing could be PACKED_SEI headers from upper level.... > > > sure, Yami recaculate the FPS as the following: > float fps = vui_time_scale / vui_num_units_in_tick ; Yup, this is a difference in HRD from h264 to h265 spec, and gst-vaapi has correct code i guess. > RC logic use HRD info if HRD parameter is preset or default HRD info if HRD > parameter is not preset. > > PACKED_SEI is not used in RC logic during the encoding process. Yup, What I mean is: The parser/decoder/demuxers might be extracting the SEI headers for finding the bitrate. So even if the CBR encode operation is correct, the decoders/demuxers might be misinterpreting the bitrate values because of missing SEI... I will double check it.. > > thanks, > Pengfei
It seems the gst-discoverer is wrongly advertising the bitrate. Tested the 4mbps and 20mbps samples(encoded with vaapih265enc manually((size_of_video_in_bits/number_of_frames)*fps) and using ffmpeg, both giving required bitrate correctly. So i am closing this bug as invalid. Thanks.
Created attachment 124684 [details] attachment-31676-0.html sick leave to see the docotor today. i can not read the mail. Call me 138-1179-1589 if needed.
BTW, Other than the bitrate issue, the quality of encoded stream while enabling cbr mode is poor for hevc encoder comparing with h264 encoder. Create h265 sample: gst-launch-1.0 videotestsrc num-buffers=200 ! "video/x-raw, format=I420, width=1280, height=720, framerate=30/1" ! videoconvert ! videoscale ! vaapih265enc rate-control=cbr bitrate=4096 ! h265parse ! matroskamux ! filesink location=sample_h265.mkv create h264 sample: gst-launch-1.0 videotestsrc num-buffers=200 ! "video/x-raw, format=I420, width=1280, height=720, framerate=30/1" ! videoconvert ! videoscale ! vaapih264enc rate-control=cbr bitrate=4096 ! h264parse ! matroskamux ! filesink location=sample_h264.mkv play the samples with ffplay: ffplay sample_h265.mkv ffplay sample_h264.mkv There are many visible artifacts in h265 sample comparing with h264. Could be related with packed_sei though.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.