Bug 95173

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.