Re: [FFmpeg-devel] [PATCH] qsvenc: do not re-execute encoding on all positive status codes

[Ivan Uskov]

Hello Mark,

Thursday, November 3, 2016, 10:55:05 PM, you wrote:

> From: Anton Khirnov 

> It should only be done for DEVICE_BUSY/IN_EXECUTION

> (cherry picked from commit 0956fd460681e8ccbdae19f135f0d3970bf95c2f)
> Fixes ticket #5924.
> ---
>  libavcodec/qsvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 7445d5b..ac443c1 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -982,7 +982,7 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf, 
> bs, sync);
>  if (ret == MFX_WRN_DEVICE_BUSY)
>  av_usleep(500);
-} while (ret >> 0);
> +} while (ret == MFX_WRN_DEVICE_BUSY || ret == MFX_WRN_IN_EXECUTION);

>  if (ret < 0) {
>  av_packet_unref(&new_pkt);

I'm agree, existing check is not correct.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

[Ivan Uskov]

Hello Mark,

Friday, July 15, 2016, 1:37:54 PM, you wrote:

MT> On 15/07/16 07:15, Chao Liu wrote:
>> Ivan Uskov  nablet.com> writes:
>> 
>>>
>>> Hello All,
>>>
>>> After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  
>> decoding
>>> aborts  with  crash,  there  are many incorrect places appeared. The 
>> attached
>>> patch fixes the issues but keeps new method of the 'sync' variable 
>> allocation
>>> introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.
>>>
>>> Please review.
>>>
>> 
>> I had the same crashes. After reading the code, you are certainly right.
>> Why nobody review this commit?

MT> Presumably noone was particularly interested at the time, and the submitter 
did
MT> not pursue it.

MT> Looking at it now, the change looks mostly ok to me.  The error paths could
MT> maybe be cleaned up a bit, but I think that's mostly a preexisting problem. 
 Can
MT> we loop without *sync being set?  If so, removing the av_freep(&sync); 
inside
MT> the loop makes it leak in that case.

MT> A slightly clearer commit message might help too.  Maybe something like:

MT> ---
MT> lavc/qsvdec: Fix decoding following incorrect merge

MT> Decoding was broken by d30cf57a7b2097b565db02ecfffbdc9c16423d0e - the
MT> merge didn't properly handle the sync pointers, so it always
MT> segfaulted after submitting a frame to libmfx.
MT> ---

If  you are use qsv, I would like to recommend to roll-back to version before
d30cf57a7b2097b565db02ecfffbdc9c16423d0e
Really  the  d30cf57a7b2097b565db02ecfffbdc9c16423d0e is useless and only
makes code complex and work slow, the sync variable is not mandatory to be
allocated  on  heap  at  all.  libav  guys  did a big mistake when have added
such "feature".



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Questions about Video Memory in qsv decoders

[Ivan Uskov]

Hello 张玉晓,

Friday, July 22, 2016, 4:10:36 AM, you wrote:

张> I have a question when learning ffmpeg qsv decoder and Intel media sdk.

张> The intel media sdk suggest to use Video Memory while doing Hardware
张> decoding, use System Memory while doing Software decoding.

张> FFmpeg only used System Memory to decode with qsv (Intel msdk) in file
张> libavcodec/qsvdec.c. Is there any problem when use Video Memory? 

As qsv modules maintainer I can confirm, yes, there are problems.

First (objective) problem that in common case there are 3 qsv components
should be linked by a pipeline through GPU memory: 
*qsv video decoder
*qsv vpp filter
*qsv video encoder
But current ffmpeg architecture have restrictions to share one common qsv
session between libavcodec and libavfilter.

Second  (subjective) problem that nobody in ffmpeg community is interested to
advance  QSV  codecs. Most of  patches at this year provided by me or by my
colleagues (including tries to solve issue with GPU memory) were rejected or
ignored silently. Moreover, if you will try to clone a latest ffmpeg you found 
qsv
decoder broken, it crashes at any try of use. The patch to fix it was posted
by me at April 25 but was ignored.

If it is acceptable for your purposes I would like to recommend you to look
libav. The qsv-related modules in libav should be more advanced this time.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

[Ivan Uskov]

Hello Mark,

Saturday, July 23, 2016, 11:42:46 PM, you wrote:

MT> On 23/07/16 20:33, Ivan Uskov wrote:
>> If  you are use qsv, I would like to recommend to roll-back to version before
>> d30cf57a7b2097b565db02ecfffbdc9c16423d0e
>> Really  the  d30cf57a7b2097b565db02ecfffbdc9c16423d0e is useless and only
>> makes code complex and work slow, the sync variable is not mandatory to be
>> allocated  on  heap  at  all.  libav  guys  did a big mistake when have added
>> such "feature".

MT> Are you sure that works correctly with all streams, maybe one with some
MT> sort of delay?  It looks like you can add multiple things to the fifo in
MT> one call and but then only ever remove one, so using the stack to hold
MT> them across invocations is not appropriate (though failure may be very 
subtle).
Yes, I'm sure.
There are following arguments:
1. Intel's samples by itself use general variable for the 'sync' arg, not
heap allocated.
2. Intel documentation says nothing special for this arg.
3. I did several qsv-based transcoders for windows and linux no any issues
without this questionable trick.
4. A fifo object used previously to keep 'sync' handles already keeps data on
heap :-)

There only one known issue into initial implementation, the fifo size may be not
enough an there is no check for overflow. So at some cases wrapper may
overwrite sync entries in fifo and some decoded frames may be lost. But it is
not related with discussed problem.

MT> (Note that I'm not sufficiently familiar with Media SDK to confidently
MT> assert anything about how this code should behave, so please don't read too 
much into what I say.)

MT> In general I think if you are happy that the previous implementation in
MT> ffmpeg was correct then please do revert, because the code as it is now is 
completely broken.
Ok, will do.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Questions about Video Memory in qsv decoders

[Ivan Uskov]

Hello Michael,

Sunday, July 24, 2016, 12:16:59 AM, you wrote:

MN> On Sat, Jul 23, 2016 at 11:19:59PM +0300, Ivan Uskov wrote:
>> Hello 张玉晓,
>> 
>> Friday, July 22, 2016, 4:10:36 AM, you wrote:
>> 
>> 张> I have a question when learning ffmpeg qsv decoder and Intel media sdk.
>> 
>> 张> The intel media sdk suggest to use Video Memory while doing Hardware
>> 张> decoding, use System Memory while doing Software decoding.
>> 
>> 张> FFmpeg only used System Memory to decode with qsv (Intel msdk) in file
>> 张> libavcodec/qsvdec.c. Is there any problem when use Video Memory? 
>> 
>> As qsv modules maintainer I can confirm, yes, there are problems.
>> 
>> First (objective) problem that in common case there are 3 qsv components
>> should be linked by a pipeline through GPU memory: 
>> *qsv video decoder
>> *qsv vpp filter
>> *qsv video encoder
>> But current ffmpeg architecture have restrictions to share one common qsv
>> session between libavcodec and libavfilter.
>> 
>> Second  (subjective) problem that nobody in ffmpeg community is interested to
>> advance  QSV  codecs. Most of  patches at this year provided by me or by my
>> colleagues (including tries to solve issue with GPU memory) were rejected or
>> ignored silently. Moreover, if you will try to clone a latest ffmpeg you 
>> found qsv
>> decoder broken, it crashes at any try of use. The patch to fix it was posted
>> by me at April 25 but was ignored.

MN> which patches should be applied to fix the issues ?
MN> can you repost them ?
Currently I believe that broken merge from libav should be not improved/fixed
by some way but just reverted because it provides nothing helpful, only
complexity. I will provide new patch soon.

MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] qsvdec.c: Revert "Merge commit '3c53627ac17fc6bdea5029be57da1e03b32d265d'"

[Ivan Uskov]

Hello All,

This reverts commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e, reversing
changes made to acc155ac55baa95d1c16c0364b02244bc04d83a8.
The commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e provided irrelevant
code complexity and decoding slowdown. But main disadvantage of this commit is 
decoder crash.
So it should be reverted.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-Revert-Merge-commit-3c53627ac17fc6bdea5029be57da1e03.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/qsv: remove MFX_EXTBUFF_CODING_OPTION3

[Ivan Uskov]

Hello Zeranoe,

Saturday, June 18, 2016, 7:33:12 AM, you wrote:

zgc> From: Kyle Schwarz 

zgc> 4th generation Intel CPUs don't support MFX_EXTBUFF_CODING_OPTION3.

zgc> This patch fixes bug #5324.
zgc> ---
zgc>  libavcodec/qsvenc.c | 18 --
zgc>  1 file changed, 18 deletions(-)

zgc> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
zgc> index 132cf47..a561df8 100644
zgc> --- a/libavcodec/qsvenc.c
zgc> +++ b/libavcodec/qsvenc.c
zgc> @@ -132,9 +132,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc>  #if QSV_HAVE_CO2
zgc>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
zgc> print_profile(info->CodecProfile), info->CodecLevel);
zgc> @@ -186,12 +183,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc> info->ICQQuality, co2->LookAheadDepth);
zgc>  }
zgc>  #endif
zgc> -#if QSV_HAVE_QVBR
-else if (info->>RateControlMethod == MFX_RATECONTROL_QVBR) {
zgc> -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
zgc> -   co3->QVBRQuality);
zgc> -}
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame: 
%"PRIu16"\n",
zgc> info->NumSlice, info->NumRefFrame);
zgc> @@ -577,12 +568,6 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  .Header.BufferSz = sizeof(co2),
zgc>  };
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 co3 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
zgc> -.Header.BufferSz = sizeof(co3),
zgc> -};
zgc> -#endif
zgc>  
zgc>  mfxExtBuffer *ext_buffers[] = {
zgc>  (mfxExtBuffer*)&extradata,
zgc> @@ -590,9 +575,6 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  #if QSV_HAVE_CO2
zgc>  (mfxExtBuffer*)&co2,
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -(mfxExtBuffer*)&co3,
zgc> -#endif
zgc>  };
zgc>  
zgc>  int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
First, I'm not sure that "4th generation Intel CPUs don't support 
MFX_EXTBUFF_CODING_OPTION3".
Do you have any reference which says it? The documentation says:
"This structure is available since SDK API 1.11.", i.e. it depended by API
level but not by CPU generation.
For any case I believe it is wrong to remove code if some issues are appearing
on old CPUs. Especially if we already have got a pre-processor condition to 
disable
MFX_EXTBUFF_CODING_OPTION3 by correct way. If you have got some
constructive suggestions to improve disabling MFX_EXTBUFF_CODING_OPTION3 by
condition (possible in real-time code, not by preprocessor) please provide.
But stupid disabling of a feature is not the good solution.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Ivan Uskov]

Hello All,

I have discovered the following issue:
Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based h264 
decoder uses.
The crash does appear inside the

int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
{
H264Context *h = avctx->priv_data;
return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
}

It is obvious, that casting to H264Context cannot be used for qsv decoder
because there is QSVH2645Context. Similar issue will appear for CUVID
decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
(MediaCodecH264DecContext uses), possible another cases existing.

The caller function is

static int has_decode_delay_been_guessed(AVStream *st)
{
if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
if (!st->info) // if we have left find_stream_info then nb_decoded_frames 
won't increase anymore for stream copy
return 1;
#if CONFIG_H264_DECODER
if (st->internal->avctx->has_b_frames &&
   avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
st->internal->avctx->has_b_frames)
return 1;
#endif
if (st->internal->avctx->has_b_frames<3)
return st->nb_decoded_frames >= 7;
else if (st->internal->avctx->has_b_frames<4)
return st->nb_decoded_frames >= 18;
else
return st->nb_decoded_frames >= 20;
}
...which called by update_initial_timestamps()

Have anybody the idea how it can be correctly fixed?
Looks like has_decode_delay_been_guessed() should be corrected.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API

[Ivan Uskov]

Hello All,

This patch applies same changes as commit 
e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
filter uses to restore annex-B prefixes. 

Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h2645.c-switch-to-the-new-BSF-API.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Ivan Uskov]

Hello Michael,

Sunday, July 24, 2016, 11:11:32 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> I have discovered the following issue:
>> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> h264 decoder uses.
>> The crash does appear inside the
>> 
>> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> {
>> H264Context *h = avctx->priv_data;
>> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> }
>> 
>> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> because there is QSVH2645Context. Similar issue will appear for CUVID
>> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> (MediaCodecH264DecContext uses), possible another cases existing.
>> 
>> The caller function is
>> 
>> static int has_decode_delay_been_guessed(AVStream *st)
>> {
>> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> if (!st->info) // if we have left find_stream_info then 
>> nb_decoded_frames won't increase anymore for stream copy
>> return 1;
>> #if CONFIG_H264_DECODER
>> if (st->internal->avctx->has_b_frames &&
>>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> st->internal->avctx->has_b_frames)
>> return 1;
>> #endif
>> if (st->internal->avctx->has_b_frames<3)
>> return st->nb_decoded_frames >= 7;
>> else if (st->internal->avctx->has_b_frames<4)
>> return st->nb_decoded_frames >= 18;
>> else
>> return st->nb_decoded_frames >= 20;
>> }
>> ...which called by update_initial_timestamps()
>> 
>> Have anybody the idea how it can be correctly fixed?
>> Looks like has_decode_delay_been_guessed() should be corrected.

MN> this code is not new, this is in git since 4 years
MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
MN> Date:   Mon Jul 2 23:16:59 2012 +020

MN> why does it cause a problem now ?

MN> why does libavformat use hw h264 decoding ?
I do not know that is reason why I'm asking.
I just run ffmpeg like
ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv -vcodec 
h264_qsv -y ./result.mp4
..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
*avctx)

When I replace
#if CONFIG_H264_DECODER
to
#if 0
...all working fine.

I can not say when exactly the issue appeared, about several weeks ago all
worked correct. But current build is broken at this place.


MN> this seems like a bad idea to me, as libavcodec would use
MN> hw decoding too potentially resulting in multiple hw decoders
MN> running at the same time for no good reason.

MN> the one in libavformat is just used to parse a few header values
MN> ideally that should be done in the AVParser for h264 ...

MN> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Ivan Uskov]

Hello Michael,

Sunday, July 24, 2016, 11:25:29 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>> 
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> >> Hello All,
>> >> 
>> >> I have discovered the following issue:
>> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> >> h264 decoder uses.
>> >> The crash does appear inside the
>> >> 
>> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> >> {
>> >> H264Context *h = avctx->priv_data;
>> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> >> }
>> >> 
>> >> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> >> because there is QSVH2645Context. Similar issue will appear for CUVID
>> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> >> (MediaCodecH264DecContext uses), possible another cases existing.
>> >> 
>> >> The caller function is
>> >> 
>> >> static int has_decode_delay_been_guessed(AVStream *st)
>> >> {
>> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> >> if (!st->info) // if we have left find_stream_info then 
>> >> nb_decoded_frames won't increase anymore for stream copy
>> >> return 1;
>> >> #if CONFIG_H264_DECODER
>> >> if (st->internal->avctx->has_b_frames &&
>> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> >> st->internal->avctx->has_b_frames)
>> >> return 1;
>> >> #endif
>> >> if (st->internal->avctx->has_b_frames<3)
>> >> return st->nb_decoded_frames >= 7;
>> >> else if (st->internal->avctx->has_b_frames<4)
>> >> return st->nb_decoded_frames >= 18;
>> >> else
>> >> return st->nb_decoded_frames >= 20;
>> >> }
>> >> ...which called by update_initial_timestamps()
>> >> 
>> >> Have anybody the idea how it can be correctly fixed?
>> >> Looks like has_decode_delay_been_guessed() should be corrected.
>> 
>> MN> this code is not new, this is in git since 4 years
>> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
>> MN> Date:   Mon Jul 2 23:16:59 2012 +020
>> 
>> MN> why does it cause a problem now ?
>> 
>> MN> why does libavformat use hw h264 decoding ?
>> I do not know that is reason why I'm asking.
>> I just run ffmpeg like
>> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
>> -vcodec h264_qsv -y ./result.mp4
>> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
>> *avctx)
>> 
>> When I replace
>> #if CONFIG_H264_DECODER
>> to
>> #if 0
>> ...all working fine.
>> 
>> I can not say when exactly the issue appeared, about several weeks ago all
>> worked correct. But current build is broken at this place.

MN> can you use git bisect to figure out when this issue appeared?
Ok, I'll try, it will take some time.
MN> was the decoder used in libavformat previously also the hw instead of
MN> sw decoder ?
There are no appropriate methods in hw decoder to be called from libavformat.
So hw decoder exactly was never used.


MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Ivan Uskov]

Hello Michael,

Sunday, July 24, 2016, 11:25:29 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>> 
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> >> Hello All,
>> >> 
>> >> I have discovered the following issue:
>> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> >> h264 decoder uses.
>> >> The crash does appear inside the
>> >> 
>> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> >> {
>> >> H264Context *h = avctx->priv_data;
>> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> >> }
>> >> 
>> >> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> >> because there is QSVH2645Context. Similar issue will appear for CUVID
>> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> >> (MediaCodecH264DecContext uses), possible another cases existing.
>> >> 
>> >> The caller function is
>> >> 
>> >> static int has_decode_delay_been_guessed(AVStream *st)
>> >> {
>> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> >> if (!st->info) // if we have left find_stream_info then 
>> >> nb_decoded_frames won't increase anymore for stream copy
>> >> return 1;
>> >> #if CONFIG_H264_DECODER
>> >> if (st->internal->avctx->has_b_frames &&
>> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> >> st->internal->avctx->has_b_frames)
>> >> return 1;
>> >> #endif
>> >> if (st->internal->avctx->has_b_frames<3)
>> >> return st->nb_decoded_frames >= 7;
>> >> else if (st->internal->avctx->has_b_frames<4)
>> >> return st->nb_decoded_frames >= 18;
>> >> else
>> >> return st->nb_decoded_frames >= 20;
>> >> }
>> >> ...which called by update_initial_timestamps()
>> >> 
>> >> Have anybody the idea how it can be correctly fixed?
>> >> Looks like has_decode_delay_been_guessed() should be corrected.
>> 
>> MN> this code is not new, this is in git since 4 years
>> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
>> MN> Date:   Mon Jul 2 23:16:59 2012 +020
>> 
>> MN> why does it cause a problem now ?
>> 
>> MN> why does libavformat use hw h264 decoding ?
>> I do not know that is reason why I'm asking.
>> I just run ffmpeg like
>> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
>> -vcodec h264_qsv -y ./result.mp4
>> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
>> *avctx)
>> 
>> When I replace
>> #if CONFIG_H264_DECODER
>> to
>> #if 0
>> ...all working fine.
>> 
>> I can not say when exactly the issue appeared, about several weeks ago all
>> worked correct. But current build is broken at this place.

MN> can you use git bisect to figure out when this issue appeared?
The problem commit is
Sun Jun 12 13:24:27 2016 +0200| [1534ef87c74cc66a117bf61c467641c2129bc964] | 
committer: Clément Bœsch

There are lot changes but this modification made the issue visible:
==
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index c011527..0de6d91 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
 -60,7 +60,7  const uint16_t ff_h264_mb_sizes[4] = { 
256, 384, 512, 768 };
 int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
 {
 H264Context *h = avctx->priv_data;
-return h ? h->sps.num_reorder_frames : 0;
+return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
 }
==
I.e. _before_it_worked_wrong_too_ but silently. After the H264Context was
modified and new construction h->ps.sps-> was added it has become critical.


MN> was the decoder used in libavformat previously also the hw instead of
MN> sw decoder ?


MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Ivan Uskov]

Hello Chao,

Tuesday, July 26, 2016, 9:04:49 AM, you wrote:

> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
> There is sth. I don't understand. Not sure whether it's related..
> In ffmpeg, we decode the frame in a loop
> , it
> sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns busy.
> In intel media SDK sample_decode, it calls SyncOperation when
> MFXVideoDECODE_DecodeFrameAsync returns busy.

> Could this be the cause?
The documentation for MFXVideoDECODE_DecodeFrameAsync says:
=
MFX_WRN_DEVICE_BUSY
Hardware device is currently busy. Call this function again in a few 
milliseconds.
=
So if documented way does not work it looks like we have issue inside SDK.
But I will try to double check sample_decode code.

By the way, what is your platform? Linux? Do you use a patched kernel
recommended by Intel for specific sdk version?


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix double free and null dereferences in the qsv decoder

[Ivan Uskov]

Hello Yuli,

Wednesday, July 27, 2016, 6:21:41 PM, you wrote:

> This patch fixes the h264_qsv decoder issues mentioned
> in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.

> The patch may be tested by specifying h264_qsv as the decoder to ffplay
> for an h264 encoded file.

> ffplay -vcodec h264_qsv foo.mts

> Signed-off-by: Yuli Khodorkovskiy 
> ---
>  libavcodec/qsvdec.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 9125700..b462887 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -408,7 +408,7 @@ static int do_qsv_decode(AVCodecContext *avctx, 
> QSVContext *q,
>  return ff_qsv_error(ret);
>  }
>  n_out_frames = av_fifo_size(q->async_fifo) / 
> (sizeof(out_frame)+sizeof(sync));
> -
> +av_freep(&sync);
I'm sorry but it is not actual more. There was the roll-back for
sync allocations on heap at July 24, now there is old good way uses again.

>  if (n_out_frames > q->async_depth || (flush && n_out_frames) ) {
>  AVFrame *src_frame;
>  
> @@ -555,16 +555,18 @@ void ff_qsv_decode_reset(AVCodecContext *avctx, 
> QSVContext *q)
>  }
>  
>  /* Reset output surfaces */
> -av_fifo_reset(q->async_fifo);
+if (q->>async_fifo)
> +av_fifo_reset(q->async_fifo);
>  
>  /* Reset input packets fifo */
> -while (av_fifo_size(q->pkt_fifo)) {
+while (q->>pkt_fifo && av_fifo_size(q->pkt_fifo)) {
>  av_fifo_generic_read(q->pkt_fifo, &pkt, sizeof(pkt), NULL);
>  av_packet_unref(&pkt);
>  }
>  
>  /* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
>  }
>  
>  int ff_qsv_decode_close(QSVContext *q)


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix null dereferences in the qsv decoder

[Ivan Uskov]

Hello Yuli,

Friday, July 29, 2016, 6:00:44 PM, you wrote:

> This patch fixes the h264_qsv decoder issues mentioned
> in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.

> The patch may be tested by specifying h264_qsv as the decoder to ffplay
> for an h264 encoded file.

> ffplay -vcodec h264_qsv foo.mts

> Signed-off-by: Yuli Khodorkovskiy 
> ---
>  libavcodec/qsvdec.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 9125700..98585e3 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -555,16 +555,18 @@ void ff_qsv_decode_reset(AVCodecContext *avctx, 
> QSVContext *q)
>  }
>  
>  /* Reset output surfaces */
> -av_fifo_reset(q->async_fifo);
+if (q->>async_fifo)
> +av_fifo_reset(q->async_fifo);
>  
>  /* Reset input packets fifo */
> -while (av_fifo_size(q->pkt_fifo)) {
+while (q->>pkt_fifo && av_fifo_size(q->pkt_fifo)) {
>  av_fifo_generic_read(q->pkt_fifo, &pkt, sizeof(pkt), NULL);
>  av_packet_unref(&pkt);
>  }
>  
>  /* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
>  }
>  
>  int ff_qsv_decode_close(QSVContext *q)
Really, makes sense.
Looks good for me.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API

[Ivan Uskov]

Hello Michael,

Sunday, August 7, 2016, 8:18:54 PM, you wrote:

> On Sun, Jul 24, 2016 at 10:05:27PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> This patch applies same changes as commit 
>> e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
>> of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
>> filter uses to restore annex-B prefixes. 
>> 
>> Please review.
>>   
>> 
>> -- 
>> Best regards,
>>  Ivan  mailto:ivan.us...@nablet.com

>>  qsvdec_h2645.c |  138 
>> -
>>  1 file changed, 107 insertions(+), 31 deletions(-)
>> db4e17da2ddf056018cd049164c77f0073fde1bc  
>> 0001-libavcodec-qsvdec_h2645.c-switch-to-the-new-BSF-API.patch
>> From 70b9f600ffbdc67010aca757dd4cf401f3377078 Mon Sep 17 00:00:00 2001
>> From: Ivan Uskov 
>> Date: Sun, 24 Jul 2016 14:04:36 -0400
>> Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API This
>>  patch applies same changes as commit 
>> e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
>>  of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
>>  filter uses to restore annex-B prefixes.

> Is it correct to say that this commit is
> "Based-on: e3dfef8e3c85a64dbe6388117303f5819fa3c6a2 by Anton Khirnov" ?
Yes, in general it based on this commit, only minor adaptations (ffmpeg use
different function names into the qsvdec.c)


> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop issue

[Ivan Uskov]

Hello Jun,

Thursday, August 11, 2016, 10:59:51 AM, you wrote:

> From cafa70e97ce48b65e2a4a99782f6ce3557fef755 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 11 Aug 2016 15:34:01 +0800
> Subject: [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop
>  issue.

> the merge commit 1b04ea1 "avconv: create simple filtergraphs earlier"
> will init the filtergraphs earlier, then init the QSV transcode can't
> suppose the nb_filters's value, else lead to the QSV transcode performance
> drop.

> Signed-off-by: Jun Zhao 
> ---
>  ffmpeg_qsv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

> diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> index 95a2351..acc54dd 100644
> --- a/ffmpeg_qsv.c
> +++ b/ffmpeg_qsv.c
> @@ -210,8 +210,7 @@ int qsv_transcode_init(OutputStream *ost)
>  
>  /* check if the decoder supports QSV and the output only goes to this 
> stream */
>  ist = input_streams[ost->source_index];
-if (ist->nb_filters || ist->hwaccel_id != HWACCEL_QSV ||
-!ist->dec || !ist->dec->pix_fmts)
+if (ist->hwaccel_id != HWACCEL_QSV || !ist->dec || !ist->dec->pix_fmts)
>  return 0;
>  for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; 
> pix_fmt++)
>  if (*pix_fmt == AV_PIX_FMT_QSV)
Thank, makes sense.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation

[Ivan Uskov]

Hello nablet,

Saturday, September 17, 2016, 11:32:26 AM, you wrote:

> From: Anton Khirnov 

> Signed-off-by: nablet developer 
> ---
>  libavutil/Makefile |   3 +
>  libavutil/hwcontext.c  |   3 +
>  libavutil/hwcontext.h  |   1 +
>  libavutil/hwcontext_internal.h |   1 +
>  libavutil/hwcontext_qsv.c  | 791
> +
>  libavutil/hwcontext_qsv.h  |  52 +++
>  6 files changed, 851 insertions(+)
>  create mode 100644 libavutil/hwcontext_qsv.c
>  create mode 100644 libavutil/hwcontext_qsv.h

> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 1e06176..76da7d4 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -35,6 +35,7 @@ HEADERS = adler32.h 
>hwcontext.h   \
>hwcontext_cuda.h  \
>hwcontext_dxva2.h \
> +  hwcontext_qsv.h   \
>hwcontext_vaapi.h \
>hwcontext_vdpau.h \
>imgutils.h\
> @@ -154,6 +155,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o   
>  
>  OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
>  OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
> +OBJS-$(CONFIG_QSV)  += hwcontext_qsv.o
>  OBJS-$(CONFIG_LZO)  += lzo.o
>  OBJS-$(CONFIG_OPENCL)   += opencl.o opencl_internal.o
>  OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
> @@ -166,6 +168,7 @@ SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
>  
>  SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
>  SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
> +SKIPHEADERS-$(CONFIG_QSV)  += hwcontext_qsv.h
>  SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
>  SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
>  SKIPHEADERS-$(HAVE_ATOMICS_GCC)+= atomic_gcc.h
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 1e9e913..be1d73e 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -35,6 +35,9 @@ static const HWContextType *hw_table[] = {
>  #if CONFIG_DXVA2
>  &ff_hwcontext_type_dxva2,
>  #endif
> +#if CONFIG_QSV
> +&ff_hwcontext_type_qsv,
> +#endif
>  #if CONFIG_VAAPI
>  &ff_hwcontext_type_vaapi,
>  #endif
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index 4e9da02..5e2af09 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -29,6 +29,7 @@ enum AVHWDeviceType {
>  AV_HWDEVICE_TYPE_CUDA,
>  AV_HWDEVICE_TYPE_VAAPI,
>  AV_HWDEVICE_TYPE_DXVA2,
> +AV_HWDEVICE_TYPE_QSV,
>  };
>  
>  typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
> index cf832fe..079e42b 100644
> --- a/libavutil/hwcontext_internal.h
> +++ b/libavutil/hwcontext_internal.h
> @@ -101,6 +101,7 @@ struct AVHWFramesInternal {
>  
>  extern const HWContextType ff_hwcontext_type_cuda;
>  extern const HWContextType ff_hwcontext_type_dxva2;
> +extern const HWContextType ff_hwcontext_type_qsv;
>  extern const HWContextType ff_hwcontext_type_vaapi;
>  extern const HWContextType ff_hwcontext_type_vdpau;
>  
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> new file mode 100644
> index 000..13be5b0
> --- /dev/null
> +++ b/libavutil/hwcontext_qsv.c
> @@ -0,0 +1,791 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "config.h"
> +
> +#if CONFIG_VAAPI
> +#include "hwcontext_vaapi.h"
> +#endif
> +#if CONFIG_DXVA2
> +#include "hwcontext_dxva2.h"
> +#endif
> +
> +#include "buffer.h"
> +#include "common.h"
> +#include "hwcontext.h"
> +#include "hwcontext_internal.h"
> +#include "hwcontext_qsv.h"
> +#include "mem.h"
> +#include "pixfmt.h"
> +#include "pixdesc.h"
> +#include "time.h"
> +
> +typedef struct QSVDe

[FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

[Ivan Uskov]

Hello All,

After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  decoding
aborts  with  crash,  there  are many incorrect places appeared. The attached
patch fixes the issues but keeps new method of the 'sync' variable allocation
introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.

Please review.


  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-Restoring-decoding-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Ivan Uskov]

Hello All,

The   attached  patch  does  fixes  the  issue  of  frames  duplication when
elementary h.264 stream decodes by qsvdec.

Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h2645.c-Bug-fixed-wrong-ticks_per_.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Ivan Uskov]

Hello Derek,

Monday, April 25, 2016, 4:50:28 PM, you wrote:

DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
>> elementary h.264 stream decodes by qsvdec.

DB> Could you perhaps elaborate in the commit message, and a code comment, on
DB> why it must be 2? Where does that value come from, etc.
I do not see a necessity for additional comments because
AVCodecContext::ticks_per_frame is public API and already enough documented:
https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

[Ivan Uskov]

Hello All,

Monday, April 25, 2016, 6:50:18 PM, you wrote:

HL> On Mon, Apr 25, 2016 at 5:44 PM, Ivan Uskov  wrote:
>> Hello Derek,
>>
>> Monday, April 25, 2016, 4:50:28 PM, you wrote:
>>
>> DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>>>> The   attached  patch  does  fixes  the  issue  of  frames  duplication 
>>>> when
>>>> elementary h.264 stream decodes by qsvdec.
>>
>> DB> Could you perhaps elaborate in the commit message, and a code comment, on
>> DB> why it must be 2? Where does that value come from, etc.
>> I do not see a necessity for additional comments because
>> AVCodecContext::ticks_per_frame is public API and already enough documented:
>> https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a
>>

HL> Its not about what the field does, but why this is needed here. So
HL> please explain why its set here, and only for this case.
A have added brief comment to patch and to code, please review the attached 
patch.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-Bug-fixed-wrong-ticks_per_frame.-For-H.264-stream-ti.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

[Ivan Uskov]

Hello Derek,

Tuesday, April 26, 2016, 7:13:19 PM, you wrote:

DB> On 4/26/2016 4:45 PM, wm4 wrote:
>> I can see that this code is run only for h264, and I can see that you
>> set the field to 2. The added comment adds no new information and is
>> useless.

DB> The ticks_per_frame docu literally says "should be 2 for h.264" or 
something.

DB> I only thought it should be in the commit message instead of something akin
DB> to "fix bug".
Since it was added to commit message too, it is not the issue, right?
I  left  the "bug fixed" because it was really the bug which force decoder to
produce doubled frames output.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/qsv: fix coding options

[Ivan Uskov]

Hello Kyle,

Saturday, May 28, 2016, 8:07:07 AM, you wrote:

zgc> From: Kyle Schwarz 

zgc> ---
zgc>  libavcodec/qsvenc.c | 34 ++
zgc>  1 file changed, 2 insertions(+), 32 deletions(-)

zgc> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
zgc> index 132cf47..b4821fc 100644
zgc> --- a/libavcodec/qsvenc.c
zgc> +++ b/libavcodec/qsvenc.c
zgc> @@ -132,9 +132,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc>  #if QSV_HAVE_CO2
zgc>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
zgc> print_profile(info->CodecProfile), info->CodecLevel);
zgc> @@ -186,13 +183,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc> info->ICQQuality, co2->LookAheadDepth);
zgc>  }
zgc>  #endif
zgc> -#if QSV_HAVE_QVBR
-else if (info->>RateControlMethod == MFX_RATECONTROL_QVBR) {
zgc> -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
zgc> -   co3->QVBRQuality);
zgc> -}
zgc> -#endif
zgc> -
zgc>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame: 
%"PRIu16"\n",
zgc> info->NumSlice, info->NumRefFrame);
zgc>  av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
zgc> @@ -567,31 +557,11 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  .PPSBuffer = pps_buf, .PPSBufSize = sizeof(pps_buf)
zgc>  };
zgc>  
zgc> -mfxExtCodingOption co = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION,
zgc> -.Header.BufferSz = sizeof(co),
zgc> -};
zgc> -#if QSV_HAVE_CO2
zgc> -mfxExtCodingOption2 co2 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2,
zgc> -.Header.BufferSz = sizeof(co2),
zgc> -};
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 co3 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
zgc> -.Header.BufferSz = sizeof(co3),
zgc> -};
zgc> -#endif
zgc> -
zgc>  mfxExtBuffer *ext_buffers[] = {
zgc>  (mfxExtBuffer*)&extradata,
zgc> -(mfxExtBuffer*)&co,
zgc> +(mfxExtBuffer*)&q->extco,
zgc>  #if QSV_HAVE_CO2
zgc> -(mfxExtBuffer*)&co2,
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -(mfxExtBuffer*)&co3,
zgc> +(mfxExtBuffer*)&q->extco2,
zgc>  #endif
zgc>  };
zgc>  
Could you please explain what exactly you are trying to fix by this patch?
I do not like this changes by two reasons:
1.   The   dump_video_param()   intended   to   dump   parameters  returned  by
MFXVideoENCODE_GetVideoParam();  You can  not use q->extco and q->extco2 here
because  are  can be differ that values really used by encoder, here internal
adjustments possible.
2. Disabling preprocessor conditions does break compatibility with different 
MSDK
versions.  For  example  MFX_EXTBUFF_CODING_OPTION2  existing since MSDK 1.6,
MFX_EXTBUFF_CODING_OPTION3 existing since MSDK 1.11



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Intel QSV MPEG2 video decoder

[Ivan Uskov]

Hello Hendrik,

Thank you very much for the review, we will try to split one big invalid
patch to sequence of small valid changes.

Tuesday, June 30, 2015, 12:03:10 AM, you wrote:

HL> On Mon, Jun 29, 2015 at 10:57 PM, Ivan Uskov  wrote:
>> Hello All,
>>
>> I'm software developer of Nablet GmbH. We were requested by Intel to
>> integrate all possible QSV-accelerated codecs and VPP modules into ffmpeg.
>> This is my first commit which adding the QSV MPEG2 video decoder codec, I 
>> hope I did all or at least all most right.
>> The 0001-Patch-for-QSV-components-by-Intel-applied.patch was received
>> from Intel, so unfortunately it is not possible to split it to
>> separate small patches.
>>

HL> The first patch is full of errors. It reverts changes from ffmpeg
HL> mainline, it contains a dupe file (configure.orig), it contains
HL> non-GPL compatible license headers.
HL> Its not possible to apply it in any form unless it is severly cleaned
HL> up and split - no matter if its from Intel or anyone, clean patches
HL> are mandatory.

HL> - Hendrik
HL> ___
HL> ffmpeg-devel mailing list
HL> ffmpeg-devel@ffmpeg.org
HL> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch to enable QSV acceleration under linux platform

[Ivan Uskov]

Hello All,

Unlike Windows, under linux a valid display handle should be specified
to open a QSV/MFX session.
The attached patch does find appropriate display handle and transfers
it to Intel's MFX library.


  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-Adding-QSV-MFX-session-initialization-for-linux-plat.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch to enable QSV acceleration under linux platform

[Ivan Uskov]

Hello Michael,

I'm sorry, what exactly documentation should be added regarding this
patch? As I can see there is no any standalone topic about QSV into
current /doc. Can modifications of Changelog be enough?

Tuesday, June 30, 2015, 5:42:56 PM, you wrote:

MN> On Tue, Jun 30, 2015 at 05:24:54PM +0300, Ivan Uskov wrote:
>> +
>> +/**
>> + * @brief translate MSDK error codes to ffmpeg error codes
>> + */
>>  int ff_qsv_error(int mfx_err)
>>  {
>>  switch (mfx_err) {
>> @@ -77,6 +89,22 @@ int ff_qsv_error(int mfx_err)
>>  }

MN> The documentation addition should be in a seperate patch


>>  }
>>  

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch to enable QSV acceleration under linux platform

[Ivan Uskov]

Hello Michael,

Thank you very much, there is fixed patch attached, please look.

Tuesday, June 30, 2015, 7:21:53 PM, you wrote:

MN> On Tue, Jun 30, 2015 at 06:28:08PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> I'm sorry, what exactly documentation should be added regarding this
>> patch? As I can see there is no any standalone topic about QSV into
>> current /doc. Can modifications of Changelog be enough?

MN> your patch adds comments like "translate MSDK error codes to ffmpeg error 
codes"
MN> these should be in a seperate patch as they are unrelated
MN> to " enable QSV acceleration under linux platform"

MN> sorry if i wasnt clear




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-Extending-QSV-MFX-session-initialization-for-linux-p.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch to correct QSV encoder's quality presets set

[Ivan Uskov]

Hello All,

There is a patch attached to more correct map QSV encoder quality presets.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-The-set-of-performance-presets-has-been-corrected-to.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.

[Ivan Uskov]

Hello All,

There is patch which fixes too strong frame height rounding for case
when progressive frame sequence encodes by QSV.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.

[Ivan Uskov]

Hello Hendrik,

The harm of hard-coded alignment 32 that typical 1280x720 progressive
video should be encoded as 1280x736. I.e. absolutely superfluous
stripe of macroblocks should be encoded.
I can see that CODEC_FLAG_INTERLACED_DCT currently checks into
dnxhddata.c
dnxhdenc.c
dvenc.c
libx264.c
libxavs.c
mpegvideo_enc.c
nvenc.c
Why it can not be used by similar way in qsvenc.c?



Saturday, July 4, 2015, 4:34:32 PM, you wrote:

HL> On Sat, Jul 4, 2015 at 2:38 PM, Ivan Uskov  wrote:
>> Hello All,
>>
>> There is patch which fixes too strong frame height rounding for case
>> when progressive frame sequence encodes by QSV.

HL> Is there any harm in always using 32 alignment for the height?
HL> Because the flag you are checking there is not correct. In fact, there
HL> is no reliable global interlaced flag.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.

[Ivan Uskov]

Hello Michael,

For any case there is need a way to encode h.264 with or without
active frame_mbs_only_flag into SPS.
If I understanding correct, the purpose of CODEC_FLAG_INTERLACED_DCT
is exactly for this.


Monday, July 6, 2015, 3:26:16 AM, you wrote:

MN> the CODEC_FLAG_INTERLACED_DCT flag is intended for the user to be
MN> able to choose the CODING mode, that is it allows (not forced)
MN> interlaced DCT CODING
MN> the flag says nothing about the content being interlaced.

MN> allowing interlaced coding just by common sense implies that the
MN> material is probably interlaced

MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: A warning message when library will work at partial hardware acceleration

[Ivan Uskov]

Hello All,

There is the patch attached which add warning message for case when
QSV/MFX encoder has been initialized to work with partial hardware
acceleration.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c-A-warning-message-when-library-w.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Subject: [PATCH] libavcodec/qsv.c: Linux-only code part has been moved to separate function in order to avoid the "ISO C90 forbids mixed declarations and code" compiler warning.

[Ivan Uskov]

Hello All,

Unfortunately, previous patch for  libavcodec/qsv.c at the commit
db89f45535aa3e99bceb5f6bf957c90e7ca39841 does initiate the compiler warning
"ISO C90 forbids mixed declarations and code" under linux platform,
because there is declaration block under preprocessor condition. Looks
like it can not be re-arranged by graceful way into one function.
I believe the best way to fix it is moving linux-related code into own
separate function. Suggested patch does this.
Please review. Thank.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsv.c-Linux-only-code-part-has-been-moved.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: incorrect loop condition has been fixed.

[Ivan Uskov]

Hello All,

 For example, the encoder may return MFX_WRN_INCOMPATIBLE_VIDEO_PARAM
 warning i.e. ret==5 old loop implementation will repeat several times
 until output  buffer overflow. New implementation explicitly uses
 loop only for device busy case.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c-incorrect-loop-condition-has-bee.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello All,

There is another place into libavcodec/qsvenc.c where height may be
aligned to 32 for the case when alignment to 16 is enough. It can be
reason of superfluous frame copying. The attached patch does solve
this issue. Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Ooops, missed that you modified the file recently. Will prepare
another patch.
By the way, now I can not compile master repo under --enable-libmfx config,
there is compiler error appears:
libavcodec/qsvenc_hevc.c:71:5: error: too few arguments to function 
‘ff_hevc_extract_rbsp’
Are there some update should be soon?

Also, do you know a real reason to make
  q->width_align = avctx->codec_id == AV_CODEC_ID_HEVC ? 32 : 16;
into the qsvenc.c? I did not check it yet and never work with Intel
HEVC before but all Intel's samples never perform such check, width
alignment in latest Intel's samples is always 16...


Thursday, July 9, 2015, 3:18:58 PM, you wrote:

MN> On Thu, Jul 09, 2015 at 02:24:43PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> There is another place into libavcodec/qsvenc.c where height may be
>> aligned to 32 for the case when alignment to 16 is enough. It can be
>> reason of superfluous frame copying. The attached patch does solve
>> this issue. Please review.

MN> does not apply cleanly

MN> Applying: libavcodec/qsvenc.c: Fix for too agressive height
MN> alignment during frame encoding which may be reason of superflous frame 
copying.
MN> Using index info to reconstruct a base tree...
MN> Falling back to patching base and 3-way merge...
MN> Auto-merging libavcodec/qsvenc.h
MN> Auto-merging libavcodec/qsvenc.c
MN> CONFLICT (content): Merge conflict in libavcodec/qsvenc.c
MN> Failed to merge in the changes.
MN> Patch failed at 0001 libavcodec/qsvenc.c: Fix for too agressive
MN> height alignment during frame encoding which may be reason of superflous 
frame copying.

MN> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Ok, I will take care.

Thursday, July 9, 2015, 5:47:22 PM, you wrote:

MN> Its not my code nor my change, i do not know what the correct value
MN> is.
MN> This change was merged by me and originates from libav. I tried to
MN> merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
MN> ill try to fix that but i dont have a libmfx setup here ATM so

MN> If you can check and if needed correct it, that would help alot!



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.

[Ivan Uskov]

Hello Michael,

Please review the attached updated patch about height alignment.

The qsvenc_hevc.c compiles now thanks.
But same command line that I use for h264_qsv does fail for hevc_qsv
with error "[hevc_qsv @ 0x25a7620] Unexpected NAL type in the extradata: 52"
Here can be lot reasons including too old MXF library (I'm use 2015R4
but latest 2015R6).
It is just info, I will review qsvenc_hevc.c later when all known minor defects 
of qsvenc.c will fixed.


Thursday, July 9, 2015, 5:47:22 PM, you wrote:

MN> This change was merged by me and originates from libav. I tried to
MN> merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’
MN> ill try to fix that but i dont have a libmfx setup here ATM so

MN> If you can check and if needed correct it, that would help alot!

MN> Thanks

MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync

[Ivan Uskov]

Hello All,

Current implementation of handling MFXVideoENCODE_EncodeFrameAsync()
return codes allows unhanded silent warnings and unclear error
reporting if the function return some non-successful code.
The attached patch solves this issue and makes troubleshooting more
easy. Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvenc.c-improving-handling-for-return-co.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.

[Ivan Uskov]

Hello All,

Current QSV engine implementation does allocate but never does release
a display handler under linux platforms.
The attached patch solved this issue, please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsv.c-Issue-fixed-QSV-engine-does-not-rel.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.

[Ivan Uskov]

Hello Gwenole,

As I can see the current implementation of qsv-accelerated components
already allows to use external MXF session created by main application.
Please look the AVQSVContext structure into \libavcodec\qsv.h, example of
its allocation into the \doc\examples\qsvdec.c and how
AVCodecContext::hwaccel_context uses into the 
libavcodec\qsvenc.c::ff_qsv_enc_init()

Only when external session not specified the qsv engine forced to
search appropriate device by itself and open an internal session.

Tuesday, July 14, 2015, 12:26:41 AM, you wrote:

GB> Note it would also be interesting to provide a means to import a
GB> VADisplay from the user through an additional function. e.g. in view
GB> to interop VA decode to MSDK encode and/or video processing.

GB> Regards,



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Refactoring to move common QSV-related code part into libavcodec/qsvdec.c

[Ivan Uskov]

Hello All,

Current implementation of qsvdec_h264.c does contain initialization
code which is common for all qsv-based decoders. The attached patch
moves common code into qsvdec.c. The declaration ff_qsv_decode_init
has been unified with ff_qsv_encode_init.
Please review.

  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-Refactoring-to-move-common-QSV-related-code-part-int.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello All,

Current implementation of libavcodec/qsvdec_h264.c does use external
SPS parser. It does not optimal since MFX library has own unified way
to parse headers of all supported formats. This performs by one
MFXVideoDECODE_DecodeHeader() call.
The suggested patch does replace stream specific code to one universal
function call located into the libavcodec/qsvdec.c. This opens an easy
way to implement qsv-accelerated mpeg2, hevc and vc1 decoders.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h264.c-SPS-parsing-now-performs-by.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello Hendrik,

Ok, no problem. I will ask. But in general it makes no sense. I have
got enough experience for MXF using and common transcoding developing
to see that current implementation is not good and dangerous.

I should to say that actually I see lot minor issues and quite ugly
code pieces into QSV-related modules.
I have got big doubts that all that was "by specific reason".

For example discussed code piece not able to handle a case when decoded
stream begins from arbitrary place, not from SPS. Decoding fails. It
is common scenario for MPEG TS decoding.
Also current code tries to handle dynamic SPS change at bad place (good
place should be into the qsvdec.c) and by bad way (no fifo flush).
My patch does not solve these issues but at least I have got clear
roadmap in mind how to get qsv decoder more reliable and usable.
It is just question of another patches.
Should we keep this code which obvious bad?

Thursday, July 16, 2015, 11:57:25 PM, you wrote:

HL> There was a specific reason this was done this way.
HL> You should definitely inquire with the original author of this code
HL> for the reason of not using the header parser, IIRC it was broken in
HL> some cases.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello Michael,

Usually I'm use annex-b streams to test. Since this functions calls
after bitstream filter which restore annex-b codes it *should* work for mp4 too.
But I did several tests just now and should to say that *both*
versions, original and patched fails on mp4 files. Looks like
bitstream filter uses by wrong way or does contain own issue. But for
any case this issue not related with patch. The patch touches code
where only annex-b bitstream allowed.

Friday, July 17, 2015, 12:57:58 AM, you wrote:

MN> i dont know the qsv parser code but like hendrik suggested, it
MN> is quite possible that our parser supports more cases.

MN> did you test .mp4  and annex b (.h264) ? do both work ?


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fwd: Re: libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hi guys!

I'm currently working under extension of QSV support in ffmpeg.
Could please anybody say, are there any serious reasons to use external SPS
parser into the qsv_process_data() of libavcodec/qsvdec_h264.c instead
nice MFXVideoDECODE_DecodeHeader() function? Looks like it is just
rudiment of initial implementation but may be it is really important by some 
reason?
Thank!

This is a forwarded message
From: Hendrik Leppkes 
To: FFmpeg development discussions and patches 
CC: 
Date: Thursday, July 16, 2015, 11:57:25 PM
Subject: [FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by 
MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

===8<==Original message text===
On Thu, Jul 16, 2015 at 10:02 PM, Ivan Uskov  wrote:
> Hello All,
>
> Current implementation of libavcodec/qsvdec_h264.c does use external
> SPS parser. It does not optimal since MFX library has own unified way
> to parse headers of all supported formats. This performs by one
> MFXVideoDECODE_DecodeHeader() call.
> The suggested patch does replace stream specific code to one universal
> function call located into the libavcodec/qsvdec.c. This opens an easy
> way to implement qsv-accelerated mpeg2, hevc and vc1 decoders.
> Please review.

There was a specific reason this was done this way.
You should definitely inquire with the original author of this code
for the reason of not using the header parser, IIRC it was broken in
some cases.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

===8<===End of original message text===



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello Michael,

Ok, will do, thanks.

Friday, July 17, 2015, 3:25:20 AM, you wrote:

MN> also maybe you want to send a patch to add yourself to the
MN> MAINTAINERs file for qsv*



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Adding myself as maintainer for qsv*

[Ivan Uskov]

Hello All,

I have added myself as maintainer for qsv* part.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-Adding-myself-as-maintainer-for-qsv.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: missed MFXVideoDECODE_Close() call

[Ivan Uskov]

Hello All,

Current implementation never calls MFXVideoDECODE_Close() at decoding
done that may be a reason of resource leak. The attached patch solves
this issue. Please review.

  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-missed-MFXVideoDECODE_Close-call.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello Michael,

Unfortunately, I do not received any feedback from both persons which
maintain libavcodec/qsvdec_h264.c about details of current
implementation. I still believe this is just defect of initial
design.
As I can see the  libavcodec/qsvdec.c was changed recently by commit
f929081f2e64d979fd8c58b17705e9554f99baf9 so current patch does
conflict now. I will prepare another patch with same task some later.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Ivan Uskov]

Hello All,

The attached patch represents new design for qsv session control and internal
allocation.  All qsv modules now uses instance of AVQSVContext so now session
allocates by external application and session allocates internally by ffmpeg
itself handles by unified way.
For  the  case  of  internal  session  allocation  now one global instance of
AVQSVContext   creates,   I.e. one common session uses for all qsv components
in  processing  chain   (decoder,   vpp,  encoder).   This   opens  a  way to
implement a complex video processing into the GPU without system memory using.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsv.c-Re-design-session-control-and-inter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Ivan Uskov]

Hello Hendrik,

Wednesday, October 7, 2015, 5:58:25 PM, you wrote:

HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov  wrote:

HL> Global static variables are not acceptable, sorry.
HL> You'll have to find another way to solve your problem, but global
HL> state is not the way to go.
Unfortunately   I   do   not   have   ideas  how to provide single and common
memory  block  for  separatemodules   by  another  way.   Memory  mapping
files  looks not too portable and much more bulky solution then one global 
variable.
I  do  not  see  the  way to use appropriate field of AVCodecContext to share
global data.
Has anybody any ideas?
Is  me  missed  something?  There is really the necessary to have a global 
common
structure shared between decoder, vpp and decoder. 

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Ivan Uskov]

Hello wm4,

Wednesday, October 7, 2015, 7:40:45 PM, you wrote:

w> There's no automagic way to get this done.

w> Hardware accelerators like vaapi and vdpau need the same thing. These
w> have special APIs to set an API context on the decoder. Some APIs use
w> hwaccel_context, vdpau uses av_vdpau_bind_context().

w> The hwaccel_context pointer is untyped (just a void*), and what it means
w> is implicit to the hwaccel or the decoder that is used. It could point
w> to some sort of qsv state, which will have to be explicitly allocated
w> and set by the API user (which might be ffmpeg.c).
So  if  I will implement something like ffmpeg_qsv.c (using ffmpeg_vdpau.c as
example)   and   extend  the  hwaccels[]  into  ffmpeg_opt.c  by corresponded
qsv entries it  would  be the acceptable solution, correct?

w> For filters there is no such thing yet. New API would have to be
w> created. For filters in particular, we will have to make sure that the
w> API isn't overly qsv-specific, and that it is extendable to other APIs
w> (like for example vaapi or vdpau).
Ok,   if   VPP  could be the  issue  I  would  like  to  get  working  direct
link qsv_decoder-qsv_encoder first.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: disabling --enable-libmfx and --enable-gpl combination

[Ivan Uskov]

Hello All,

Since libmfx is not under GPL, Intel asked to correct "configure" behavior
for --enable-libmfx option to avoid licenses violation:
./configure --enable-libmfx
- allowed

./configure --enable-libmfx --enable-gpl
-prohibited, error message

./configure --enable-libmfx --enable-gpl --enable-nonfree
-allowed

Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-configure-disabling-enable-libmfx-and-enable-gpl-com.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: disabling --enable-libmfx and --enable-gpl combination

[Ivan Uskov]

Hello Hendrik,

Thursday, October 8, 2015, 7:03:36 PM, you wrote:

HL> That doesn't seem correct to me. The mfx dispatcher library has the BSD
HL> license plastered all over it. BSD is compatible with the GPL.
Dispatcher, yes, but mfx library by itself which loaded by dispatcher is not.

HL> On top of that, it would seriously limit the use of these features, so why
HL> would Intel want that?
Because  mfx  library  is  not  GPL  I  believe. Else anybody may ask mfx 
library
sources since it uses by GPL build of ffmpeg.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: disabling --enable-libmfx and --enable-gpl combination

[Ivan Uskov]

Hello Timothy,

Thursday, October 8, 2015, 8:29:31 PM, you wrote:
>> HL> That doesn't seem correct to me. The mfx dispatcher library has the BSD
>> HL> license plastered all over it. BSD is compatible with the GPL.
>> Dispatcher, yes, but mfx library by itself which loaded by dispatcher is
>> not.
>>

TG> I don't think GPL has any provisions for dynamic loading, only linking.
If I understanding this correct:
http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
GPL does not make difference between static and dynamic linking.

I  believe  it   would  be  too  simple  to  make  any proprietary library is
"opensource" just by writing an opensource proxy/wrapper. :-)


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: disabling --enable-libmfx and --enable-gpl combination

[Ivan Uskov]

Hello Hendrik,

Thursday, October 8, 2015, 11:43:37 PM, you wrote:


HL> We're not talking about dynamic linking here though, but runtime loading.
HL> Can I not use VAAPI because the underlying driver behind it may be closed
HL> source?
I  do  not  know  I'm  not  expert.  But most likely VAAPI treats as "system
library" in GPL terms.
HL> In fact we talked about this exact topic with j-b the other day, and he is
HL> the closest to a lawyer we have around here ;), and he agreed that FFmpeg
HL> built against the mfx dispatcher is no problem - it only becomes a problem
HL> when you start distributing the Intel binary with it, which you shouldn't
HL> do.
Ok, got it.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] QSV support clarifications

[Ivan Uskov]

Hello Stefano,

Monday, October 12, 2015, 9:10:04 PM, you wrote:
SS> 2. The mfx_dispatch library compiles fine on my system, but then I
SS> wonder how it is supposed to reference the Intel Media library:
SS> https://software.intel.com/en-us/intel-media-server-studio

SS> ...

SS> I'm able to compile FFmpeg with --enable-libmfx after installing
SS> the mfx_dispatch library, and run this command:
SS> ffmpeg -i test.mp4 -c:v h264_qsv -y test.out.mp4

SS> but then it fails with:
SS> Error initializing an internal MFX session
As far as I understanding Intel's libraries and patches from Media SDK should
be  present  in a system.
The  open-source mfx dispatch library is just wrapper which loads appropriate
.so by intel.
The official instruction how to setup intel media sdk
on linux is following: 
https://software.intel.com/sites/default/files/media_server_studio_getting_started_guide.pdf

 SS> Running strace on the command it results that it's looking for the
SS> libmfxsw64.so library and failing:
SS> open("/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
SS> open("/usr/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
SS> open("/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
SS> open("/usr/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
SS> munmap(0x7f9a55072000, 155122)  = 0
Intel's library usually locates into the
/opt/intel/mediasdk/lib64
For example for Media SDK 1.16 here following files should be:
-rwxr-xr-x. 1 root root 28826704 Jun 11 08:44 iHD_drv_video.so
-rwxr-xr-x. 1 root root 10646952 Jun 11 08:44 libmfxhw64-p.so.1.16
lrwxrwxrwx. 1 root root   20 Jul 10 16:52 libmfxhw64.so -> 
libmfxhw64-p.so.1.16
-rwxr-xr-x. 1 root root  9364712 Jun 11 08:44 libmfxsw64-p.so.1.16
lrwxrwxrwx. 1 root root   20 Jul 10 16:52 libmfxsw64.so -> 
libmfxsw64-p.so.1.16


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV dynamically linked on linux

[Ivan Uskov]

Hello Julien,

Thursday, October 15, 2015, 7:08:10 PM, you wrote:

JF> Hi all,

JF> I'm using QuickSync and FFmpeg on linux.
JF> It works well for encoding and decoding when I build it with
JF> --enable-static.

JF> But when I build it with --enable-shared, it hangs.
JF> So my question is: is it supposed to work when dynamically linked?
As  far as I understanding, here only libmfx library can be the reason of the
issue. Possible libmfx was compiled without -fPIC flag.
There are two source of libmfx possible, original Intel distributive and
mfx_dispatch project: https://github.com/lu-zero/mfx_dispatch
For  both  cases  libmfx  delivers  in sources so you can double-check how it
compiles, and try to recompile libmfx with forced -fPIC compiler option.
In general linker should to reject libs compiled without position-independent
code option so the  reason may be more deep and complex but -fPIC is first what
necessary to check.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter - second try

[Ivan Uskov]

Hello wm4,

Thursday, November 5, 2015, 3:42:30 PM, you wrote:

w> On Thu, 5 Nov 2015 12:49:50 +0100
w> "Sven Dueking"  wrote:

>> > > +} else if (ret == MFX_WRN_DEVICE_BUSY) {
>> > > +av_usleep(500);  
>> > 
>> > What. Use proper event-based waiting.
It is not possible.
>> 
>> That´s the same behavior as we have in the qsv encoder and decoder.
>> And as far as I know this is how Intel recommends to handle this.

w> That's just ridiculous. Can you send some hate-mail to Intel and tell
w> them what a bad idea this is? Half a millisecond is an eternity for a
w> CPU. What if the device is blocked only for 10 microseconds? Then it
w> will waste time by spending 490 microseconds idly.
1. Please remember we use GPU, not CPU.
2.   500us  means that even we will get MFX_WRN_DEVICE_BUSY at every frame we
willable toachieve~2000fps  performance.  It   looks   enough
performance level for any practical applications.
3.   In   real  life  MFX_WRN_DEVICE_BUSY does appear when GPU really busy by
other  tasks. So nothing bad will appear if one thread/process will sleep for
500us to make another thread complete its work.

w> Software engineers recognized that polling is a bad idea half a century
w> ago. Why can't Intel do this right?
May  be  because  it  is  complex to organize event-polling when calculations
performs in GPU?

w> Or does MFX have some sort of async mode that works without polling?
Does  NOT.  I'm  sorry  but  we  forced  to  use this way, since it is by QSV
design.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter - second try

[Ivan Uskov]

Hello wm4,

Thursday, November 5, 2015, 5:07:08 PM, you wrote:

>>
>> >> > > +} else if (ret == MFX_WRN_DEVICE_BUSY) {
>> >> > > +av_usleep(500);
>> >> > 
>> >> > What. Use proper event-based waiting.  
>> It is not possible.
>> >> 
>> >> That´s the same behavior as we have in the qsv encoder and decoder.
>> >> And as far as I know this is how Intel recommends to handle this.  
>> 
>> w> That's just ridiculous. Can you send some hate-mail to Intel and tell
>> w> them what a bad idea this is? Half a millisecond is an eternity for a
>> w> CPU. What if the device is blocked only for 10 microseconds? Then it
>> w> will waste time by spending 490 microseconds idly.  
>> 1. Please remember we use GPU, not CPU.

w> That makes it even worse, because the CPU could literally be entirely
w> idle.
Not mandatory.
There are following scenarios are possible:
1.  transcoding  completely  executes by QSV components. At this case CPU always
almost  idle and it is not issue at all. It is most probably scenario when we
theoretically can get MFX_WRN_DEVICE_BUSY and CPU loading does not matter.
2.   SW   components  like  encoder  or  decoder  works  together   with  QSV
components.  At this case  possible  a scenario  when GPU is busy but CPU still
executes some thread pool (inside SW encoder for example).

>> 2.   500us  means that even we will get MFX_WRN_DEVICE_BUSY at every frame we
>> willable toachieve~2000fps  performance.  It   looks   enough
>> performance level for any practical applications.

w> Only if all other CPU processing takes 0 microseconds.
Here  can  be  other threads which will very happy if we will slip until GPU
busy. Also we never will get MFX_WRN_DEVICE_BUSY at each frame.
I  just would like to point that delay has not big impact to real performance
which usually much less than 2000fps.

>> 3.   In   real  life  MFX_WRN_DEVICE_BUSY does appear when GPU really busy by
>> other  tasks. So nothing bad will appear if one thread/process will sleep for
>> 500us to make another thread complete its work.
>> 
>> w> Software engineers recognized that polling is a bad idea half a century
>> w> ago. Why can't Intel do this right?  
>> May  be  because  it  is  complex to organize event-polling when calculations
>> performs in GPU?

w> Even just making the call blocking would be 1. easier, 2. more
w> efficient (because it will idle only as long as needed).
I believe Intel had serious reasons do not implement blocking here.
General   processing  in  QSV  is  asynchronous  and  has  nice functions  to
wait completion of encoding/decoding/processing.
If   Intel   made   MFX_WRN_DEVICE_BUSY   as  immediately return code without
event   handling  and  still keep it as is during library 16 releases that it
has the reason.
For  example  here  can be a small penalty during general processing which will
give visible overhead for hundreds frames per second.

For any case do not have an ability to change this API.
-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsvenc: write a53 caption data to SEI

[Ivan Uskov]

Hello Will,

Saturday, November 7, 2015, 5:29:15 PM, you wrote:

WK> ---
WK>  libavcodec/qsvenc.c  | 114
WK> +--
WK>  libavcodec/qsvenc.h  |   2 +-
WK>  libavcodec/qsvenc_h264.c |   2 +-
WK>  3 files changed, 113 insertions(+), 5 deletions(-)

WK> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
WK> index df1f777..0ee45f9 100644
WK> --- a/libavcodec/qsvenc.c
WK> +++ b/libavcodec/qsvenc.c
WK> @@ -30,6 +30,7 @@
WK>  #include "libavutil/log.h"
WK>  #include "libavutil/time.h"
WK>  #include "libavutil/imgutils.h"
WK> +#include "libavcodec/bytestream.h"
WK>  
WK>  #include "avcodec.h"
WK>  #include "internal.h"
WK> @@ -276,7 +277,7 @@ int ff_qsv_enc_init(AVCodecContext *avctx, 
QSVEncContext *q)
WK>  q->param.AsyncDepth = q->async_depth;
WK>  
WK>  q->async_fifo = av_fifo_alloc((1 + q->async_depth) *
WK> -  (sizeof(AVPacket) +
WK> sizeof(mfxSyncPoint) + sizeof(mfxBitstream*)));
WK> +  (sizeof(AVPacket) +
WK> sizeof(mfxSyncPoint) + sizeof(mfxBitstream*) + sizeof(mfxEncodeCtrl*)));
WK>  if (!q->async_fifo)
WK>  return AVERROR(ENOMEM);
WK>  
WK> @@ -494,6 +495,27 @@ static void print_interlace_msg(AVCodecContext *avctx, 
QSVEncContext *q)
WK>  }
WK>  }
WK>  
WK> +static void freep_encoder_ctrl(mfxEncodeCtrl** enc_ptr)
WK> +{
WK> +mfxEncodeCtrl* enc_ctrl;
WK> +
WK> +if (!enc_ptr)
WK> +return;
WK> +
WK> +enc_ctrl = *enc_ptr;
WK> +
WK> +if (enc_ctrl) {
WK> +int i;
WK> +for (i = 0; i < enc_ctrl->NumPayload; i++) {
WK> +av_free(enc_ctrl->Payload[i]->Data);
WK> +av_freep(&enc_ctrl->Payload[i]);
WK> +}
WK> +av_free(enc_ctrl->Payload);
WK> +av_freep(&enc_ctrl);
WK> +}
WK> +*enc_ptr = NULL;
WK> +}
WK> +
WK>  int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
WK>AVPacket *pkt, const AVFrame *frame, int *got_packet)
WK>  {
WK> @@ -504,6 +526,10 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
*q,
WK>  mfxSyncPoint sync  = NULL;
WK>  int ret;
WK>  
WK> +// for A53 CC data
WK> +mfxEncodeCtrl* enc_ctrl = NULL;
WK> +AVFrameSideData *side_data = NULL;
WK> +
WK>  if (frame) {
WK>  ret = submit_frame(q, frame, &surf);
WK>  if (ret < 0) {
WK> @@ -526,8 +552,83 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
*q,
WK>  bs->Data  = new_pkt.data;
WK>  bs->MaxLength = new_pkt.size;
WK>  
+if (q->>a53_cc && frame) {
WK> +side_data = av_frame_get_side_data(frame, AV_FRAME_DATA_A53_CC);
WK> +if (side_data) {
Although   the  code  looks  ok  by itself, I believe it is bad idea to place
H.264-specific   codeto   the   function   which  is  commonfor   all
encoders.  I believe H.264-specific user data insertion should  locates  into
the qsvenc_h264.c 
I.e. there is necessary some kind of 'SetEncodeCtrl' callback which points to
function into the encoder-specific module.
I believe if you will define a callback pointer QSVEncContext::SetEncodeCtrlCB,
setup  it  into  qsv_enc_init()  of the qsvenc_h264.c and call if it non-zero
from   ff_qsv_encode()  we  will  have  good base to extend add user data for
MPEG2 later. Else we will get very bulky and ugly ff_qsv_encode().
I can release something but I hope you will able to catch my idea.
Please let me know if something is unclear.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsvenc: Add adaptive_i and adaptive_b toggles

[Ivan Uskov]

Hello Will,

Tuesday, November 10, 2015, 11:41:19 PM, you wrote:

WK> Signed-off-by: Will Kelleher 
WK> ---
WK>  libavcodec/qsvenc.c  | 2 ++
WK>  libavcodec/qsvenc.h  | 2 ++
WK>  libavcodec/qsvenc_h264.c | 2 ++
WK>  3 files changed, 6 insertions(+)

WK> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
WK> index df1f777..5e6ace1 100644
WK> --- a/libavcodec/qsvenc.c
WK> +++ b/libavcodec/qsvenc.c
WK> @@ -173,6 +173,8 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
WK>  #endif
WK>  #if QSV_VERSION_ATLEAST(1,8)
WK>  q->extco2.LookAheadDS   = q->look_ahead_downsampling;
+q->>extco2.AdaptiveI = q->adaptive_i ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_UNKNOWN;
+q->>extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_UNKNOWN;
WK>  #endif
WK>  
WK>  q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)&q->extco2;
WK> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
WK> index 3dd7afe..a5f9463 100644
WK> --- a/libavcodec/qsvenc.h
WK> +++ b/libavcodec/qsvenc.h
WK> @@ -76,6 +76,8 @@ typedef struct QSVEncContext {
WK>  int look_ahead;
WK>  int look_ahead_depth;
WK>  int look_ahead_downsampling;
WK> +int adaptive_i;
WK> +int adaptive_b;
WK>  
WK>  char *load_plugins;
WK>  } QSVEncContext;
WK> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
WK> index 0e5a26c..507f490 100644
WK> --- a/libavcodec/qsvenc_h264.c
WK> +++ b/libavcodec/qsvenc_h264.c
WK> @@ -97,6 +97,8 @@ static const AVOption options[] = {
WK>  { "slow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
WK> MFX_TARGETUSAGE_3  },INT_MIN, INT_MAX, VE, "preset" },
WK>  { "slower",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
WK> MFX_TARGETUSAGE_2  },INT_MIN, INT_MAX, VE, "preset" },
WK>  { "veryslow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
WK> MFX_TARGETUSAGE_BEST_QUALITY  }, INT_MIN, INT_MAX, VE, "preset" },
WK> +{ "adaptive_i",  "Use AdaptiveI", OFFSET(qsv.adaptive_i),
WK> AV_OPT_TYPE_BOOL,   {.i64 = 0}, 0, 1, VE},
WK> +{ "adaptive_b",  "Use AdaptiveB", OFFSET(qsv.adaptive_b),
WK> AV_OPT_TYPE_BOOL,   {.i64 = 0}, 0, 1, VE},
WK>  
WK>  { NULL },
WK>  };
Looks good to me, thank!

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsvenc: Add adaptive_i and adaptive_b toggles

[Ivan Uskov]

Hello Hendrik,

Wednesday, November 11, 2015, 11:56:49 AM, you wrote:

HL> On Tue, Nov 10, 2015 at 9:41 PM, Will Kelleher  
wrote:
>> Signed-off-by: Will Kelleher 
>> ---
>>  libavcodec/qsvenc.c  | 2 ++
>>  libavcodec/qsvenc.h  | 2 ++
>>  libavcodec/qsvenc_h264.c | 2 ++
>>  3 files changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
>> index df1f777..5e6ace1 100644
>> --- a/libavcodec/qsvenc.c
>> +++ b/libavcodec/qsvenc.c
>> @@ -173,6 +173,8 @@ static int init_video_param(AVCodecContext *avctx, 
>> QSVEncContext *q)
>>  #endif
>>  #if QSV_VERSION_ATLEAST(1,8)
>>  q->extco2.LookAheadDS   = q->look_ahead_downsampling;
>> +q->extco2.AdaptiveI = q->adaptive_i ? MFX_CODINGOPTION_ON : 
>> MFX_CODINGOPTION_UNKNOWN;
>> +q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON : 
>> MFX_CODINGOPTION_UNKNOWN;
>>  #endif
>>
>>  q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
>> *)&q->extco2;
>> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
>> index 3dd7afe..a5f9463 100644
>> --- a/libavcodec/qsvenc.h
>> +++ b/libavcodec/qsvenc.h
>> @@ -76,6 +76,8 @@ typedef struct QSVEncContext {
>>  int look_ahead;
>>  int look_ahead_depth;
>>  int look_ahead_downsampling;
>> +int adaptive_i;
>> +int adaptive_b;
>>
>>  char *load_plugins;
>>  } QSVEncContext;
>> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
>> index 0e5a26c..507f490 100644
>> --- a/libavcodec/qsvenc_h264.c
>> +++ b/libavcodec/qsvenc_h264.c
>> @@ -97,6 +97,8 @@ static const AVOption options[] = {
>>  { "slow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TARGETUSAGE_3 
>>  },INT_MIN, INT_MAX, VE, "preset" },
>>  { "slower",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TARGETUSAGE_2 
>>  },INT_MIN, INT_MAX, VE, "preset" },
>>  { "veryslow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
>> MFX_TARGETUSAGE_BEST_QUALITY  }, INT_MIN, INT_MAX, VE, "preset" },
>> +{ "adaptive_i",  "Use AdaptiveI", OFFSET(qsv.adaptive_i), 
>> AV_OPT_TYPE_BOOL,   {.i64 = 0}, 0, 1, VE},
>> +{ "adaptive_b",  "Use AdaptiveB", OFFSET(qsv.adaptive_b), 
>> AV_OPT_TYPE_BOOL,   {.i64 = 0}, 0, 1, VE},
>>
>>  { NULL },
>>  };

HL> I don't suppose you can give these options a slightly more verbose 
description?
HL> That doesn't really tell me anything at all. ": Use "
HL> is like the worst kind of docs you can have. :)
I   belive  "Insertion I-frames depending by content" and "Insertion B-frames
depending by content" would be an enough short description, what do you think?

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] Added QSV based VPP filter

[Ivan Uskov]

Hello All,

Thursday, November 12, 2015, 1:33:28 PM, you wrote:

SD> Attached an updated version of the VPP filter.

SD>  

SD> Changes to v2 :

SD>  

SD> -Copy input frame if not aligned

SD> -Proper use of AVERROR(ENOMEM)

SD> -Removed unneeded pointer checks

SD> -Cleanup

SD> -Updated Documentation

SD>  

SD> Please review.
I   have  inspected  several  private variants of this patch and believe this
version can be approved. LGTM

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsvenc: write a53 caption data to SEI

[Ivan Uskov]

Hello Will,

Thursday, November 12, 2015, 12:53:46 AM, you wrote:

WK> On 11/07, Ivan Uskov wrote:
>> Although   the  code  looks  ok  by itself, I believe it is bad idea to place
>> H.264-specific   codeto   the   function   which  is  commonfor   all
>> encoders.  I believe H.264-specific user data insertion should  locates  into
>> the qsvenc_h264.c 
>> I.e. there is necessary some kind of 'SetEncodeCtrl' callback which points to
>> function into the encoder-specific module.
>> I believe if you will define a callback pointer 
>> QSVEncContext::SetEncodeCtrlCB,
>> setup  it  into  qsv_enc_init()  of the qsvenc_h264.c and call if it non-zero
>> from   ff_qsv_encode()  we  will  have  good base to extend add user data for
>> MPEG2 later. Else we will get very bulky and ugly ff_qsv_encode().
>> I can release something but I hope you will able to catch my idea.
>> Please let me know if something is unclear.

WK> Hi Ivan,

WK> Here is an updated patch.  Let me know if this is what you were thinking.
I'm like and agree this implementation, no questions from my side. Thank!

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] qsv.c: making qsv session routines common for libavcodec and libavfilter modules.

[Ivan Uskov]

Hello All,

As  it  turned  out, a suggested recently libavfilter/vf_qsv_vpp.c may not use
ff_qsv_init_internal_session() from libavcodec/qsv.c.
The attached patch moves qsv.c and qsv_internal.h to libavutil subdir to make
corresponded routines common for codecs and filters.
First  argument  of  ff_qsv_init_internal_session()has been changed to accept
pointer to any context structure compatible with av_log().

Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-qsv.c-making-qsv-session-routines-common-for-libavco.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines common for libavcodec and libavfilter modules.

[Ivan Uskov]

Hello Hendrik,

Friday, November 13, 2015, 12:55:38 AM, you wrote:

HL> On Thu, Nov 12, 2015 at 10:15 PM, Ivan Uskov  wrote:
>> Hello All,
>>
>> As  it  turned  out, a suggested recently libavfilter/vf_qsv_vpp.c may not 
>> use
>> ff_qsv_init_internal_session() from libavcodec/qsv.c.
>> The attached patch moves qsv.c and qsv_internal.h to libavutil subdir to make
>> corresponded routines common for codecs and filters.
>> First  argument  of  ff_qsv_init_internal_session()has been changed to accept
>> pointer to any context structure compatible with av_log().
>>
>> Please review.

HL> Your patch does not work. Please test it with dynamic linking, and
HL> you'll immediately see it failing (hint: only av* symbols are
HL> exported)
Sorry, really released dynamic linking.
Ok, it can be fixed if it will necessary, thank.

HL> Secondly, I don't think exposing these internals as public API (which
HL> avutil generally is), would be a good idea at all.
HL> Heck the header is even called qsv_internal.h, stuff like this should
HL> never be used across library boundaries. It puts the API/ABI in stone,
HL> and hinders any future expansions or enhancements.
We can rename qsv_internal.h to qsv_common.h it is just question of  
naming.
The  ff_qsv_init_internal_session() can be renamed to av_init_default_session()
etc  and  can  be used in user application. BTW, the current qsvdec.c example
would  to  use  such  API instead direct and non-portable VAAPI-related code
that currently works for linux platforms only.

HL> avutil is not a place we dump stuff that should be shared between
HL> avcodec and avfilter, or similar, avutil should generally be public
HL> useful API.
I believe 3 of 4 functions here can be published as useful API.
If   you   do  not  like  this  way,  could  you  please  advise some another
constructive  way to avoid a duplication of more then 300 code lines? Or copy
paste between codecs and filters is really best solution for this case?
Thank!

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines common for libavcodec and libavfilter modules.

[Ivan Uskov]

Hello wm4,

Friday, November 13, 2015, 11:28:46 AM, you wrote:
>> HL> avutil is not a place we dump stuff that should be shared between
>> HL> avcodec and avfilter, or similar, avutil should generally be public
>> HL> useful API.  
>> I believe 3 of 4 functions here can be published as useful API.
>> If   you   do  not  like  this  way,  could  you  please  advise some another
>> constructive  way to avoid a duplication of more then 300 code lines? Or copy
>> paste between codecs and filters is really best solution for this case?
>> Thank!
>> 

w> Didn't we just write how we don't want this to be public API?
I  saw only mentions based on functions and headers names which were selected
arbitrary  long  time  ago. So I was forced to highlight that this api can be
useful  and  public.  Of  course  you  can  have another opposite opinion, no
problem.
But there are no constructive suggestion from your side how to solve the issue,
but just rejection, correct?


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV

[Ivan Uskov]

Hello Michael,

Thursday, November 26, 2015, 11:13:45 PM, you wrote:

MN> Hi

MN> are there any QSV patches which have been reviewed and have no
MN> objections raised against them ?
MN> that is patches i should apply/push for qsv ...
Excluding two patches by Will Kelleher which were re-checked today only one
small patch still not reviewed.
It is the
[PATCH] "libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame."
at the September 9, please look. I can resend it if necessary.

MN> ivan, also it might make sense if you would be on IRC, so you and
MN> others could discuss any QSV issues or questions or patches or ...
MN> iam asking as it was asked on IRC a few days ago
MN> "Nov 22 18:51:46 *  Daemon404 wonders if "Ivan Uskov" is on irc"
Ok, I will try to connect to channel and be online.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] QSV

[Ivan Uskov]

Hello All,

Friday, November 27, 2015, 11:34:52 AM, you wrote:

IU> Hello Michael,

IU> Thursday, November 26, 2015, 11:13:45 PM, you wrote:

MN>> Hi

MN>> are there any QSV patches which have been reviewed and have no
MN>> objections raised against them ?
MN>> that is patches i should apply/push for qsv ...
IU> Excluding two patches by Will Kelleher which were re-checked today only one
IU> small patch still not reviewed.
IU> It is the
IU> [PATCH] "libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame."
IU> at the September 9, please look. I can resend it if necessary.
*September 16*, sorry.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 12:19:23 PM, you wrote:

HL> On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking  wrote:
>> This patch expose 3 QSV functions as public.
>> This is needed because the VPP needs access to these functions too.
>>
>> Please review.
>>

HL> public API is not allowed to use config.h, it needs to be config and
HL> OS agnostic.
Any qsv_* function can not be public since are all under CONFIG_QSV, correct?

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 1:10:59 PM, you wrote:

 This patch expose 3 QSV functions as public.
 This is needed because the VPP needs access to these functions too.

 Please review.

>>
>> HL> public API is not allowed to use config.h, it needs to be config and
>> HL> OS agnostic.
>> Any qsv_* function can not be public since are all under CONFIG_QSV, correct?
>>

HL> Thats not necessarily true, if its supposed to be public API, it just
HL> has to always be present, so it would have to be changed to just do
HL> nothing and return an error if QSV is not enabled, but the functions
HL> still exist.
But   it  is exactly that Sven did, there are dummies for all public function
into the qsv_api.c for the case if CONFIG_QSV==0
What is wrong then?



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public

[Ivan Uskov]

Hello Hendrik,

Thursday, December 10, 2015, 2:00:51 PM, you wrote:
>> What is wrong then?

HL> The public qsv.h uses config.h, thats not allowed.
ah, got it, thank.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] qsvenc: Use scene-change hints from source frame if available

[Ivan Uskov]

Hello Will,

Friday, December 11, 2015, 6:47:28 PM, you wrote:

WK> Since adaptive_i support is broken, this allows the QSV encoder to use 
scene-
WK> change hints from the input stream if force_key_frames = source is used.  
The
WK> result will be improved transcoding quality at scene change boundaries.

WK> Signed-off-by: Will Kelleher 
WK> ---
WK>  libavcodec/qsvenc.c | 11 +++
WK>  1 file changed, 11 insertions(+)

WK> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
WK> index d00fdff..74e40f7 100644
WK> --- a/libavcodec/qsvenc.c
WK> +++ b/libavcodec/qsvenc.c
WK> @@ -939,6 +939,17 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
*q,
WK>  q->set_encode_ctrl_cb(avctx, frame, &qsv_frame->enc_ctrl);
WK>  }
WK>  
WK> +if (enc_ctrl) {
+if (frame->>pict_type == AV_PICTURE_TYPE_I) {
WK> +enc_ctrl->FrameType = MFX_FRAMETYPE_I | MFX_FRAMETYPE_REF;
WK> +if (frame->key_frame) {
WK> +enc_ctrl->FrameType |= MFX_FRAMETYPE_IDR;
WK> +}
WK> +} else {
WK> +enc_ctrl->FrameType = 0;
WK> +}
WK> +}
WK> +
WK>  do {
WK>  ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf, 
bs, &sync);
WK>  if (ret == MFX_WRN_DEVICE_BUSY) {
Am  I understanding  right  that suggesting feature is non-optional and will
active  always? I believe it should have own option to activate because there
are negative side effects are possible.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/qsv: export session management functionality (variant #3)

[Ivan Uskov]

Hello All,

There is updated patch version initially introduced by Sven Dueking 


This patch expose 3 QSV functions as public.
This is needed because the VPP needs access to these functions too.

Please review.


-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-avcodec-qsv-export-session-management-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Cyrillic devices name support in libavdevice/dshow

[Ivan Uskov]

Hello Derek,

Wednesday, December 16, 2015, 8:24:33 PM, you wrote:

DB> On 12/16/2015 4:29 PM, Roger Pack wrote:
>> Still mulling over why this would be needed...hm

DB> It makes sense that CP_OEMCP is needed for device names, in my mind,
DB> after reading https://support.microsoft.com/en-us/kb/108450 - however,
DB> I don't think changing the generic functions in cmdutils.c is correct
DB> here.
The actual implementation of these functions for Windows platform looks buggy.
Are  will work right only for ASCII characters subset.
It is hard to imagine what the reason was to use CP_UTF8 in windows-related 
code.
Windows   never  use UTF8 in command line and in other places here only 8 bit
OEM  code  pages  or 16 bit unicode are possible.
So using CP_OEMCP looks much more appropriate and correct.

But  suggested patch looks incomplete, it is quite strange when 
dup_wchar_to_utf8()
function   internally  performs   an   action  which  does not match with the
function name. :-)
So dup_wchar_to_utf8() should be also renamed to dup_wchar_to_oem() for example.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Cyrillic devices name support in libavdevice/dshow

[Ivan Uskov]

Hello All,

Wednesday, December 16, 2015, 11:36:17 PM, you wrote:

IU> Hello Derek,

IU> Wednesday, December 16, 2015, 8:24:33 PM, you wrote:

DB>> On 12/16/2015 4:29 PM, Roger Pack wrote:
>>> Still mulling over why this would be needed...hm

DB>> It makes sense that CP_OEMCP is needed for device names, in my mind,
DB>> after reading https://support.microsoft.com/en-us/kb/108450 - however,
DB>> I don't think changing the generic functions in cmdutils.c is correct
DB>> here.
IU> The actual implementation of these functions for Windows platform looks 
buggy.
IU> Are  will work right only for ASCII characters subset.
IU> It is hard to imagine what the reason was to use CP_UTF8 in windows-related 
code.
IU> Windows   never  use UTF8 in command line and in other places here only 8 
bit
IU> OEM  code  pages  or 16 bit unicode are possible.
IU> So using CP_OEMCP looks much more appropriate and correct.

IU> But  suggested patch looks incomplete, it is quite strange when 
dup_wchar_to_utf8()
IU> function   internally  performs   an   action  which  does not match with 
the
IU> function name. :-)
IU> So dup_wchar_to_utf8() should be also renamed to dup_wchar_to_oem() for 
example.
After some more deep thinking I should to take all my words back. :-)
Using OEMCP in suggested patch will break uncode files processing. So it is 
necessary to
resolve the issue  from  an opposite  end: it is necessary to convert device 
name to
UTF8 and do no touch existing functions.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c

[Ivan Uskov]

Hello All,

There is first patch from 4 which makes qsv-based decode
implementation more simple and reliable. This patch replaces external 
frame parse to internal MFXVideoDECODE_DecodeHeader() function which
able to parse any supported stream kind (h.264, hevc, mpeg2, vc-1) by
universal way.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h264.c-SPS-parsing-now-performs-by.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/4] libavcodec/qsvdec_h264.c: refactoring: functional of qsv_process_data() has been moved into qsvdec.c

[Ivan Uskov]

Hello All,

The qsv_process_data() doing nothing h.264-specific, so it has been
moved into qsvdec.c with new name ff_qsv_prepare().
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0002-libavcodec-qsvdec_h264.c-refactoring-functional-of-q.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello all,

Actual implementation of ff_qsv_decode() is not reliable, it may
return without consumption of 1..3 last bytes of packet which
initiates infinitive loop. New implementation guarantees that packet
will consumed, now internal fifo uses to join unconsumed previous packet
tail with new packet.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0003-libavcodec-qsvdec.c-The-ff_qsv_decode-now-guarantees.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] libavcodec/qsvdec_h264.c: packet buffering has been removed since qsvdec.c does maintain own data buffering now.

[Ivan Uskov]

Hello all,

Since after [PATCH 3/4] the ff_qsv_decode() always consume whole packet
payload buffering of packets into qsvdec_h264.c is need not more.
Suggested patch makes qsvdec_h264.c simple as far as it possible.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0004-libavcodec-qsvdec_h264.c-packet-buffering-has-been-r.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavcodec/qsvdec_h264.c: refactoring: functional of qsv_process_data() has been moved into qsvdec.c

[Ivan Uskov]

Hello Michael,

I have replaced 'ready' flag name to 'engine_ready' and added
a corresponded comment.
Regarding ff_qsv_prepare() looks like it is need not at all, I have
modified ff_qsv_decode_init() instead. So patch become even simple,
thank.

Please review.

NOTE
The ff_qsv_decode_init() should be another subject of refactoring, it
should be split at least to 3 parts:
-qsv/mfx session creation (common with qsvenc.c so this part  should be moved
to qsv.c or qsv_internal.c)
-header detection (because it calls several times in common case and
here can be a necessity to re-detect sequence header on a fly)
-encoder creation.
But I plan to take it some later, currently I have got couple critical
bug fixes in my queue of patches.

Thursday, July 23, 2015, 4:18:13 AM, you wrote:


>> +int ready;

MN> I think this should be documented, its not immedeatly clear from
MN> just the name "ready" what exactly it refers to
MN> maybe a more verbose variable name would make it also more immedeatly
MN> obvious what it means

MN> maybe something like
MN> "int prepared" and ff_qsv_prepare() but maybe that is not the
MN> best suggestion i dont know

MN> also ff_qsv_prepare() should be documented what it exactly does/means

MN> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h264.c-refactoring-functional-of-q.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello All ,

There is updated version of patch which should be applied without conflicts.
Also here couple wrong places have been corrected into ff_qsv_decode().

Tuesday, July 21, 2015, 4:08:47 PM, you wrote:

IU> Hello all,

IU> Actual implementation of ff_qsv_decode() is not reliable, it may
IU> return without consumption of 1..3 last bytes of packet which
IU> initiates infinitive loop. New implementation guarantees that packet
IU> will consumed, now internal fifo uses to join unconsumed previous packet
IU> tail with new packet.
IU> Please review.
IU>   




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0002-libavcodec-qsvdec.c-The-ff_qsv_decode-now-guarantees.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,

Thursday, July 23, 2015, 6:29:13 PM, you wrote:

>> +} else {
>> +bs.Data   = avpkt->data;
>> +bs.DataLength = avpkt->size;
>> +}

MN> Does this mean that each packet will be memcpy-ed ?
MN> this would slow things down
Exactly not. Copying uses only for quite rare case when decoder does
not consume several bytes at tail packet tail. Then these bytes copied
into fifo. Next time these bytes usually are totally consumed with new
packet and only reference to packets uses in general decoding.
For several test streams I'm observing that 2-3 bytes copying appear
only at begin of decoding, for first 5-10 frames.
>> -do {
>> +while (1) {
>>  ret = get_surface(avctx, q, &insurf);
>>  if (ret < 0)
>>  return ret;
>> +do {
>> +ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ? 
>> &bs : NULL,
>> +  insurf, &outsurf, &sync);
>> +if (ret != MFX_WRN_DEVICE_BUSY)
>> +break;
>> -ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ? &bs 
>> : NULL,
>> -  insurf, &outsurf, &sync);
>> -if (ret == MFX_WRN_DEVICE_BUSY)

>> -av_usleep(1);
>> +av_usleep(500);

MN> looks like a unrelated change,
MN> should be in a seperate patch with explanation
These lines (new decoding loop) are absolutely necessary to consume all
available data in packets. Else data not consumes and input_fifo uses all
the time with wrong frames sequence output (duplicates and drops).

The reason of replacing of av_usleep(1) to av_usleep(500) is
following: I believe it is bad idea to ask hardware 100 times per
second if it is busy, especially in main decoding loop.
Peak qsv decoding performance is about 2000 fps when destination is GPU memory.
For system memory the performance is less then 1000fps usually. So delay in 
500microseconds (i.e. 0.5 ms)
is much more appropriate.
I can move it to separate patch but since main decoding loop totally
re-designed possible it can be applied as?


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,

Thursday, July 23, 2015, 11:47:28 PM, you wrote:
>> For several test streams I'm observing that 2-3 bytes copying appear
>> only at begin of decoding, for first 5-10 frames.

MN> what are these additional bytes?
MN> why are they not consumed ?

At least for h.264 looks like absolutely arbitrary data at access unit
end. I.e. it is not zero padding or annex-b prefixes.
In general intel QSV decoder are stream-based and does guarantee
complete edit unit consumption by itself.
The quote from Intel's documentation directly says following about
MFXVideoDECODE_DecodeFrameAsync:

<...>
The input bitstream bs can be of any size. If there are not enough
bits to decode a frame, the function returns MFX_ERR_MORE_DATA, and
consumes all input bits except if a partial start code or sequence
header is at the end of the buffer. In this case,
*the_function_leaves_the_last_few_bytes_in_the_bitstream_buffer*.
If there is more incoming bitstream, the_application_should_append the
incoming bitstream to the bitstream buffer.
<...>

I.e. in general case we should be always ready that "few bytes" of
packet can be not consumed by decoder and it is necessary to join this
data with next packet at next time.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,

Friday, July 24, 2015, 2:48:45 AM, you wrote:


>> +/* A decoder's latency depends not only by async_depth
>> +  but by DPB size too. The latency may acheve 16 frames.
>> +  So it is necessary to handle the size of async_fifo 
>> dynamically:
>> +*/
>> +if (av_fifo_space(q->async_fifo) < sizeof(out_frame) + 
>> sizeof(sync))
>> +av_fifo_grow(q->async_fifo, sizeof(out_frame)+sizeof(sync));

MN> the DPB cannot be arbitrary large, so maybe the grow code could be
MN> avoided ?
MN> or maybe i missunderstand

As you can see, the current implementation pre-allocates async_fifo
for async_depth+1 elements where async_depth==4 by default (see
tehff_qsv_decode_init() function).
For h.264 and HEVC max DPB size is 16. So we theoretically  can
hard-code 16+1 size for this fifo.
Also same code will be used for mpeg2, mjpeg, vc1 where 16+1 most
likely too big.
Are you agree to use fixed size for fifo?



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,

Friday, July 24, 2015, 2:50:49 AM, you wrote:
>> The reason of replacing of av_usleep(1) to av_usleep(500) is
>> following: I believe it is bad idea to ask hardware 100 times per
>> second if it is busy, especially in main decoding loop.
>> Peak qsv decoding performance is about 2000 fps when destination is GPU 
>> memory.
>> For system memory the performance is less then 1000fps usually. So delay in 
>> 500microseconds (i.e. 0.5 ms)
>> is much more appropriate.

>> I can move it to separate patch but since main decoding loop totally
>> re-designed possible it can be applied as?

MN> i think it should be split, as it would allow very easy regression
MN> testing with bisect, of the change in the future
Ok, no problem, I will left av_usleep(1) for this patch.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,


Friday, July 24, 2015, 12:26:27 PM, you wrote:

MN> yes, it seems simpler,
MN> and its only structs, not bitmaps so space wise it should not be a
MN> problem
Ok, really makes sense.

There is modified patch attached with following changes:
1. static pre-allocation for 17 elements uses for async_fifo
2. qsv_fifo_relocate() documented
3. argument for av_usleep() left '1' yet.

Please review.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-The-ff_qsv_decode-now-guarantees.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello All,

The current implementation of libavcodec/qsvdec_h264.c does not store
original extradata buffer. At the same time the
\libavcodec\h264_mp4toannexb_bsf filter does modify extradata buffer
inplace and fails to process it next time if decoder reinitializes.
So it is not possible to decode mp4 or mkv container using ffmpeg
command line with h264_qsv decoder.
The attached patch solves this issue. The corresponded code was taken
from \libavcodec\crystalhd.c which also uses the h264_mp4toannexb_bsf
filter.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h264.c-bug-fixed-decoder-fails-aft.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Hendrik,

Friday, July 24, 2015, 2:37:11 PM, you wrote:
>> The attached patch solves this issue. The corresponded code was taken
>> from \libavcodec\crystalhd.c which also uses the h264_mp4toannexb_bsf
>> filter.

HL> I don't think this is safe. avctx->extradata is user-managed and
HL> allocated, so mocking with it from within a decoder seems rather
HL> unsafe.
I totally agree. In general it is issue of old-old h264_mp4toannexb_bsf.c
which kills original extradata and silently replaces it by own
version, with annex-b prefixes. Most fanny fact that this filter
can not handle correctly own extradata changes if it creates second
time for the same context.

I can not patch h264_mp4toannexb_bsf because here can be side effects
in other codecs which can wait replaced extradata (SPS/PPS transformed
to annex-b kind) after this filter work.
Please note that dirty trick with original extradata storing/restoring
does present currently in another codecs which use h264_mp4toannexb_bsf.c.
it is libavcodec\crystalhd.c and libavcodec\libstagefright.cpp,

I can not left libavcodec/qsvdec_h264.c as is because it is not able
to decode mp4 and mkv at all which is definitely bug.

Do you have any constructive idea how bad behavior of the
h264_mp4toannexb_bsf.c can be overcome into the libavcodec/qsvdec_h264.c?
Should I write own "good" mp4toannexb filter?
Any other ideas?
Thank.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Michael,

Friday, July 24, 2015, 11:24:30 PM, you wrote:


MN> it should be possible to add a parameter (passed through args)
MN> which disables extradata mangling to h264_mp4toannexb_bsf

I'm sorry, I do not see this possibility.
The h264_extradata_to_annexb() into h264_mp4toannexb_bsf replaces
extradata unconditionally.

This function calls by h264_mp4toannexb_filter() under simple
condition:
if (!ctx->extradata_parsed) {
ret = h264_extradata_to_annexb(ctx, avctx, 
FF_INPUT_BUFFER_PADDING_SIZE);
<...>
ctx->extradata_parsed = 1;
}

Looks like no any parameters to avoid extradata substitution by 
h264_mp4toannexb_bsf.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Michael,

Saturday, July 25, 2015, 12:51:36 PM, you wrote:
>> Looks like no any parameters to avoid extradata substitution by 
>> h264_mp4toannexb_bsf.

MN> yes, h264_mp4toannexb_bsf needs to be changed to optionally support
MN> not doing that.
MN> One way is to use the args for that and for example check for a
MN> specific keyword like "skip_extradata"
Ok, I will think about it, thank you.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Hendrik,

Saturday, July 25, 2015, 3:13:38 PM, you wrote:

HL> I'm slightly confused by the entire concept here.

HL> - Why does the decoder need to re-init anyway?
Each time when I launch a command line like:
./ffmpeg -c:v h264_qsv -i hd.mp4 -y result.yuv
I can see that:
1. decoder opens,
2. decoding until stream detect performs,
3. decoder closes,
4. decoder opens,
5. normal decoding begins.
I still not big ffmpeg expert but I suspecting this behavior is by design.

HL> - You want the bsf to convert the bitstream to annexb, but not the
HL> extradata? Why not?
qsv* modules does not touch extradata at all.
But at step #5 above the bsf bumped to converted extradata which product of
bsf by itself at step #2. So at step #5 bsf confuses and fails.
So no mkv and mp4 decoding by h264_qsv at all currently.

HL> - Ideally, a decoder should support both bitstream syntax without the
HL> bsf, since the bsf is a hack for re-muxing, and many playback
HL> applications do not use the bsf since practically no decoder otherwise
HL> needs them.
Intel's QSV decoder does require annex-b stream, it is documented in
SDK reference.
I can implement necessary functions to generate annex-b prefixes just into
libavcodec/qsvdec_h264.c if Michael will agree this way.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] QSV MPEG-2 video decoder has been added.

[Ivan Uskov]

Hello all,

The attached patch adding the QSV-based MPEG2 video decoder.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-QSV-MPEG-2-video-decoder-has-been-added.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Michael,

Saturday, July 25, 2015, 6:14:20 PM, you wrote:

>> I can implement necessary functions to generate annex-b prefixes just into
>> libavcodec/qsvdec_h264.c if Michael will agree this way.

MN> would this be faster ?
MN> avoid a copy/malloc ?
If it implemented inside libavcodec/qsvdec_h264.c then it will use
about same code like current bsf implementation uses but with using of
private buffer for sps/pps instead public extradata buf using.

Here can  be the trick to write SPS/PPS directly to
QSVContext::input_fifo which implemented recently into qsvdec.
It will not solve memory copying necessity but it will solve possible twice 
memory
copying issue when packet re-allocation perform into mp4toannexb filter then
data copies again into input_fifo since qsv decoder did not consume
previous packet in full. What do you think?



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] QSV MPEG-2 video decoder has been added.

[Ivan Uskov]

Hello Michael,

Saturday, July 25, 2015, 6:30:14 PM, you wrote:


MN> btw, if qsv_decode_init/qsv_decode_flush arent intended to be used
MN> in the future they can be removed and the function pointers left at
MN> NULL
Ok, thank.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: Add QSV VC-1 video decoder.

[Ivan Uskov]

Hello all,

This patch adds QSV-based VC-1 video decoder.
Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-avcodec-Add-QSV-VC-1-video-decoder.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Ivan Uskov]

Hello Michael,

Saturday, July 25, 2015, 8:21:44 PM, you wrote:
>> MN> would this be faster ?
>> MN> avoid a copy/malloc ?
>> If it implemented inside libavcodec/qsvdec_h264.c then it will use
>> about same code like current bsf implementation uses but with using of
>> private buffer for sps/pps instead public extradata buf using.
>> 
>> Here can  be the trick to write SPS/PPS directly to
>> QSVContext::input_fifo which implemented recently into qsvdec.
>> It will not solve memory copying necessity but it will solve possible twice 
>> memory
>> copying issue when packet re-allocation perform into mp4toannexb filter then
>> data copies again into input_fifo since qsv decoder did not consume
>> previous packet in full. What do you think?

MN> does this affect a large memcpy() on a common path ?

MN> if it avoids just a rare or small case then its not worth it
I believe this trick will no give visible improvement in performance.
Just small win in some rare cases.



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel