GNOME Bugzilla – Bug 730750
[vaapiencoder_h264] fix some sps fields creation for encode
Last modified: 2017-08-09 08:56:32 UTC
Created attachment 277179 [details] [review] patch for the modifications on the sps creation Some sps fields had fixed value or aren't coded. This patch aim to enable them. The time-scale was also modified to match the real encoding parameter. test pipeline => gst-launch-1.0 -v videotestsrc num-buffers=200 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! vaapiencode_h264 rate-control=vbr cpb-length=2000 bitrate=2000 ! qtmux ! filesink location=test.mp4 I have compared the sps created with the one done by ffmpeg with the same kind of parameters.
Review of attachment 277179 [details] [review]: Overall, I am OK with the proposed changes except for those I have commented on. Does your firmware strictly define what comes out of the hardware or could this be more flexible to honour what comes from VAEncSequenceParameterBufferH264 and VAEncPictureParameterBufferH264? Would it be possible to (privately) know what features the HW offer and more precisely what coding tools can be configured? For direct_8x8_inference_flag = TRUE, that should be OK. However, there should be a way for your HW to honour that flag too. :) ::: gst-libs/gst/vaapi/gstvaapiencoder_h264.c @@ +1148,2 @@ g_assert (encoder->log2_max_frame_num >= 4); + encoder->log2_max_frame_num = 4; This needs to be calculated from the maximum IDR period. Currently, the FrameNum wraps on new IDR frames, and this is set to 512. That's precisely 9. :) @@ +1151,3 @@ encoder->log2_max_frame_num - 4; /* picture order count */ + seq_param->seq_fields.bits.pic_order_cnt_type = 2; POC type = 2 imposes additional requirements which need to be tracked of. This is additional work that does not really worth it, is it? Is your HW bound to only support POC type = 2, or can it bear user-defined headers to be inserted instead? @@ +1200,3 @@ if (seq_param->vui_fields.bits.timing_info_present_flag) { seq_param->num_units_in_tick = GST_VAAPI_ENCODER_FPS_D (encoder); + seq_param->time_scale = 2000000000; Some people use the VUI timing_info to derive a framerate. Using that value (2000000000) is not very convenient for 30fps for instance.
Any update???
Moving to Product:GStreamer, Component:gstreamer-vaapi
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!