[FFmpeg-devel] [PATCH] avcodec/qsvenc_hevc: add idr_interval option

Steven Liu lingjiujianke at gmail.com
Fri Jul 7 02:44:40 EEST 2017


2017-07-07 7:37 GMT+08:00 Mark Thompson <sw at jkqxz.net>:
>
>
> On 07/07/17 00:20, Steven Liu wrote:
>> 2017-07-07 7:12 GMT+08:00 Mark Thompson <sw at jkqxz.net>:
>>> On 06/07/17 23:32, Steven Liu wrote:
>>>> 2017-07-06 19:51 GMT+08:00 Mark Thompson <sw at jkqxz.net>:
>>>>> On 06/07/17 11:48, Steven Liu wrote:
>>>>>> From: Steven Liu <lingjiujianke at gmail.com>
>>>>>>
>>>>>> user need to control the idr_interval for qsv hevc
>>>>>>
>>>>>> Signed-off-by: Steven Liu <lq at onvideo.cn>
>>>>>> ---
>>>>>>  libavcodec/qsvenc_hevc.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
>>>>>> index 7d4d55bb61..c063e27eea 100644
>>>>>> --- a/libavcodec/qsvenc_hevc.c
>>>>>> +++ b/libavcodec/qsvenc_hevc.c
>>>>>> @@ -214,6 +214,7 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>>>>>>  static const AVOption options[] = {
>>>>>>      QSV_COMMON_OPTS
>>>>>>
>>>>>> +    { "idr_interval", "Distance (in I-frames) between IDR frames", OFFSET(qsv.idr_interval), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
>>>>>>      { "load_plugin", "A user plugin to load in an internal session", OFFSET(load_plugin), AV_OPT_TYPE_INT, { .i64 = LOAD_PLUGIN_HEVC_SW }, LOAD_PLUGIN_NONE, LOAD_PLUGIN_HEVC_HW, VE, "load_plugin" },
>>>>>>      { "none",     NULL, 0, AV_OPT_TYPE_CONST, { .i64 = LOAD_PLUGIN_NONE },    0, 0, VE, "load_plugin" },
>>>>>>      { "hevc_sw",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = LOAD_PLUGIN_HEVC_SW }, 0, 0, VE, "load_plugin" },
>>>>>>
>>>>>
>>>>> Sure, I guess?
>>>>>
>>>>> Though, what use-case do you intend this option for in H.265?  It already generates IRAP frames at the GOP interval, and unlike H.264 there isn't any confusion about whether they are usable as seek points.
>>>> hmm, some user report to me they can not split mpegts segment by
>>>> keyframe when they use qsv h.265, i sent this patch to them, it can be
>>>> split.
>>>
>>> Then adding this option to set sounds like an appalling hack.  What are the actual symptoms of this problem?  Can you provide an example?
>> Just use command line to split hls format.  after the patch sent to
>> the user, they just response an that's ok and no more response :(>
>>>>>
>>>>> (I can't actually remember exactly what types of NAL units it generates with and without this option; I'll have a look later.)
>>>>>
>>>
>>> Using the hardware encoder on Linux for Skylake, the very first frame is IDR_W_RADL, then subsequent frames are all TRAIL_N/TRAIL_R, or CRA to start a new GOP.  (It need not be the same on all versions of the encoder, though.)
>> Yes, maybe the problem is different versions' result.
>
>
> Hmm.  The frame type information from libmfx is really oriented towards H.264, so the H.265 types don't obviously map for key frames.
>
> Does this fix it?  (Also an appalling hack (will fail if libmfx generates an intra frame inline), but detecting the IRAP cases properly shouldn't be too bad if this is the problem.)
>
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 5eb506f..ea5f32f 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1088,8 +1088,8 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
>          new_pkt.pts  = av_rescale_q(bs->TimeStamp,       (AVRational){1, 90000}, avctx->time_base);
>          new_pkt.size = bs->DataLength;
>
> -        if (bs->FrameType & MFX_FRAMETYPE_IDR ||
> -            bs->FrameType & MFX_FRAMETYPE_xIDR)
> +        if (bs->FrameType & MFX_FRAMETYPE_I ||
> +            bs->FrameType & MFX_FRAMETYPE_xI)
>              new_pkt.flags |= AV_PKT_FLAG_KEY;
>
>  #if FF_API_CODED_FRAME
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


should be ok.


More information about the ffmpeg-devel mailing list