<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="background-color: rgb(255, 255, 255);">
<p style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">
<span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;">Hi Emil,</span><br>
</p>
<p style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">
<span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><br>
</span></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif">Thanks for the suggestion. I added brief </font><font face="Calibri, Arial, Helvetica, sans-serif">message to each of the patch to explain what the patch does. Please see the new patch set I just submitted.</font></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><br>
</font></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><br>
</font></p>
<p>Hi Christian,</p>
<p><br>
</p>
<p><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">The un-used ref_pic related</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"> definitions are removed from this patch. </span><br>
</p>
<p><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size: 12pt;">For the concern of is_idr flag , I checked the </span>behavior<span style="font-size: 12pt;"> of Vaapi and the codes again. Vaapi treats both "idr-iframe" and "non-idr-iframe"
 same as i-frame in picture type, and it uses a separate flag to tell driver whether this iframe is idr or not. So from only the picture type, we can't tell whether it's idr or not. Since VCE needs this information, so I think we still need to add this flag.</span></font></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size: 12pt;"><br>
</span></font></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size: 12pt;">Regards,</span></font></p>
<p><font face="Calibri, Arial, Helvetica, sans-serif"><span style="font-size: 12pt;">Boyuan</span></font></p>
<br>
<div style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Christian König <deathsimple@vodafone.de><br>
<b>Sent:</b> July 1, 2016 8:21 AM<br>
<b>To:</b> Zhang, Boyuan; mesa-dev@lists.freedesktop.org<br>
<b>Subject:</b> Re: [PATCH 01/12] vl: add parameters for VAAPI encode</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Boyuan,<br>
<br>
as Emil wrote as well try to add some commit messages to the set. For <br>
this patch something like the following should do it:<br>
<br>
Allow to specify more parameters in the encoding interface which where <br>
previously just hardcoded in the encoder.<br>
<br>
Additional to that we need to reorder the patches a bit. First the <br>
interface changes, then the OMX changes to fill in the previously <br>
hardcoded values, then the radeon backend changes and then last the <br>
VA-API changes to use the new interface.<br>
<br>
Additional to that a few notes below.<br>
<br>
Am 30.06.2016 um 20:30 schrieb Boyuan Zhang:<br>
> Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com><br>
> ---<br>
>   src/gallium/include/pipe/p_video_state.h | 36 ++++++++++++++++++++++++++++++++<br>
>   1 file changed, 36 insertions(+)<br>
><br>
> diff --git a/src/gallium/include/pipe/p_video_state.h b/src/gallium/include/pipe/p_video_state.h<br>
> index d353be6..9cd489b 100644<br>
> --- a/src/gallium/include/pipe/p_video_state.h<br>
> +++ b/src/gallium/include/pipe/p_video_state.h<br>
> @@ -352,9 +352,29 @@ struct pipe_h264_enc_rate_control<br>
>      unsigned frame_rate_num;<br>
>      unsigned frame_rate_den;<br>
>      unsigned vbv_buffer_size;<br>
> +   unsigned vbv_buf_lv;<br>
>      unsigned target_bits_picture;<br>
>      unsigned peak_bits_picture_integer;<br>
>      unsigned peak_bits_picture_fraction;<br>
> +   unsigned fill_data_enable;<br>
> +   unsigned enforce_hrd;<br>
> +};<br>
> +<br>
> +struct pipe_h264_enc_motion_estimation<br>
> +{<br>
> +   unsigned motion_est_quarter_pixel;<br>
> +   unsigned enc_disable_sub_mode;<br>
> +   unsigned lsmvert;<br>
> +   unsigned enc_en_ime_overw_dis_subm;<br>
> +   unsigned enc_ime_overw_dis_subm_no;<br>
> +   unsigned enc_ime2_search_range_x;<br>
> +   unsigned enc_ime2_search_range_y;<br>
> +};<br>
> +<br>
> +struct pipe_h264_enc_pic_control<br>
> +{<br>
> +   unsigned enc_cabac_enable;<br>
> +   unsigned enc_constraint_set_flags;<br>
>   };<br>
>   <br>
>   struct pipe_h264_enc_picture_desc<br>
> @@ -363,17 +383,33 @@ struct pipe_h264_enc_picture_desc<br>
>   <br>
>      struct pipe_h264_enc_rate_control rate_ctrl;<br>
>   <br>
> +   struct pipe_h264_enc_motion_estimation motion_est;<br>
> +   struct pipe_h264_enc_pic_control pic_ctrl;<br>
> +<br>
>      unsigned quant_i_frames;<br>
>      unsigned quant_p_frames;<br>
>      unsigned quant_b_frames;<br>
>   <br>
>      enum pipe_h264_enc_picture_type picture_type;<br>
>      unsigned frame_num;<br>
> +   unsigned frame_num_cnt;<br>
> +   unsigned p_remain;<br>
> +   unsigned i_remain;<br>
> +   unsigned idr_pic_id;<br>
> +   unsigned gop_cnt;<br>
>      unsigned pic_order_cnt;<br>
>      unsigned ref_idx_l0;<br>
>      unsigned ref_idx_l1;<br>
> +   unsigned gop_size;<br>
> +   unsigned ref_pic_mode;<br>
>   <br>
>      bool not_referenced;<br>
> +   bool is_idr;<br>
<br>
Why can't this be inferred from the encoded picture type?<br>
<br>
> +   bool has_ref_pic_list;<br>
> +   bool enable_vui;<br>
> +   unsigned int ref_pic_list_0[32];<br>
> +   unsigned int ref_pic_list_1[32];<br>
> +   unsigned int frame_idx[32];<br>
<br>
I thought we wanted to drop the ref_pic_list handling for now. If that <br>
is still the case please drop those fields here as well.<br>
<br>
Regards,<br>
Christian.<br>
<br>
>   };<br>
>   <br>
>   struct pipe_h265_sps<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>