2017-07-07 7:37 GMT+08:00 Mark Thompson <s...@jkqxz.net>:
>
>
> On 07/07/17 00:20, Steven Liu wrote:
>> 2017-07-07 7:12 GMT+08:00 Mark Thompson <s...@jkqxz.net>:
>>> On 06/07/17 23:32, Steven Liu wrote:
>>>> 2017-07-06 19:51 GMT+08:00 Mark Thompson <s...@jkqxz.net>:
>>>>> On 06/07/17 11:48, Steven Liu wrote:
>>>>>> From: Steven Liu <lingjiujia...@gmail.com>
>>>>>>
>>>>>> user need to control the idr_interval for qsv hevc
>>>>>>
>>>>>> Signed-off-by: Steven Liu <l...@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@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
should be ok.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
