On Sun, 2018-09-30 at 17:15 +0800, Zhong Li wrote:
> Variable 'ret' hasn't been initialized，thus introducing a random
> hwupload failure regression due to qsv session uninitialized.
>
> Signed-off-by: Zhong Li
> ---
> libavutil/hwcontext_qsv.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Tue, 2018-10-23 at 23:46 +0100, Mark Thompson wrote:
> On 23/10/18 08:49, Li, Zhong wrote:
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > Of Mark Thompson
> > > Sent: Sunday, October 14, 2018 12:36 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re:
On Thu, 2018-10-25 at 20:36 +0800, Zhong Li wrote:
> This option can be used to repect original input I/IDR frame type.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 7 +++
> libavcodec/qsvenc.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c
On Fri, 2018-10-26 at 13:46 +0200, Moritz Barsnick wrote:
> On Thu, Oct 25, 2018 at 20:36:07 +0800, Zhong Li wrote:
> > +{ "forced_idr", "Forcing I frames as IDR
> > frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_INT, {
> > .i64 = -1 }, -1, 1, VE }, \
On Mon, 2018-10-29 at 20:54 +, Derek Buitenhuis wrote:
> On 29/10/2018 20:51, Rogozhkin, Dmitry V wrote:
> > Should not the option be named 'force_idr' as well? It makes better
> > sense to me in that way...
>
> That would be inconsistent with the rest of the options f
On Mon, 2018-10-29 at 21:06 +, Mark Thompson wrote:
> On 25/10/18 13:36, Zhong Li wrote:
> > This option can be used to repect original input I/IDR frame type.
> >
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/qsvenc.c | 7 +++
> > libavcodec/qsvenc.h | 2 ++
> > 2 files changed, 9
On Mon, 2018-10-29 at 21:34 +, Mark Thompson wrote:
> On 29/10/18 21:29, Rogozhkin, Dmitry V wrote:
> > On Mon, 2018-10-29 at 21:06 +, Mark Thompson wrote:
> > > On 25/10/18 13:36, Zhong Li wrote:
> > > > This option can be used to repect original
On Fri, 2018-10-26 at 09:34 +, Li, Zhong wrote:
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > Of Rogozhkin, Dmitry V
> > Sent: Friday, October 26, 2018 8:37 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-d
On Tue, 2018-10-30 at 18:05 +0800, Li, Zhong wrote:
> > > +} else
> > > +enc_ctrl->FrameType = MFX_FRAMETYPE_UNKNOWN;
> >
> > "else" block don't make much sense to me. You eventually already
> > had
> > enc_ctrl structure passed to the encoder. Thus, it should be
> >
On Tue, 2018-10-30 at 09:49 +, Li, Zhong wrote:
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > Of Mark Thompson
> > Sent: Tuesday, October 30, 2018 5:06 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 1/5] lavc/qsvenc: add forced_idr
On Tue, 2018-11-13 at 19:58 +0800, Zhong Li wrote:
> This option can be used to repect original input I/IDR frame type.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 7 +++
> libavcodec/qsvenc.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsv.c | 18 ++
> libavcodec/qsv_internal.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index bb0d795..224bc00 100644
>
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c| 1 +
> libavcodec/qsvdec_other.c | 28 +++-
> 5
On Thu, 2019-01-24 at 21:43 +, Rogozhkin, Dmitry V wrote:
> On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> > Using MSDK parser can improve qsv decoder pass rate in some cases
> > (E.g:
> > sps declares a wrong level_idc, smaller than it should be).
> > And it
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Using MSDK parser can improve qsv decoder pass rate in some cases
> (E.g:
> sps declares a wrong level_idc, smaller than it should be).
> And it is necessary for adding new qsv decoders such as MJPEG and VP9
> since current parser can't provide
On Wed, 2019-02-20 at 10:58 +0800, Zhong Li wrote:
> Using MSDK parser can improve qsv decoder pass rate in some cases
> (E.g:
> sps declares a wrong level_idc, smaller than it should be).
> And it is necessary for adding new qsv decoders such as MJPEG and VP9
> since current parser can't provide
On Wed, 2019-02-20 at 10:58 +0800, Zhong Li wrote:
> VP9 decoder is supported on Intel kabyLake+ platforms with MSDK
> Version 1.19+
>
> Signed-off-by: Zhong Li
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/allcodecs.c| 1 +
> libavcodec/qsv.c
On Wed, 2019-02-20 at 10:58 +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c| 1 +
> libavcodec/qsvdec_other.c | 28 +++-
> 5
On Thu, 2019-02-21 at 14:01 +0800, Li, Zhong wrote:
> > > @@ -90,6 +90,17 @@ static av_cold int
> > > qsv_decode_init(AVCodecContext
> > > *avctx)
> > > }
> > > #endif
> > >
> > > +#if CONFIG_VP9_QSV_DECODER
> > > +if (avctx->codec_id == AV_CODEC_ID_VP9) {
> > > +static const
On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> Using MSDK parser can improve qsv decoder pass rate in some cases
> (E.g:
> sps declares a wrong level_idc, smaller than it should be).
> And it is necessary for adding new qsv decoders such as MJPEG and VP9
> since current parser can't provide
On Thu, 2019-03-14 at 19:16 +0800, Li, Zhong wrote:
> > From: Rogozhkin, Dmitry V
> > Sent: Tuesday, March 12, 2019 8:04 AM
> > To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > par
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qs
On Thu, 2019-03-14 at 19:03 +0800, Li, Zhong wrote:
> > From: Rogozhkin, Dmitry V
> > Sent: Tuesday, March 12, 2019 7:37 AM
> > To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > par
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qs
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qs
?
If so, could we try to define the array exactly in this function and
avoid passing the whole array around? See comments below for
suggestions...
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday,
; any 3rd_party implementation can use it by requesting AV_PIX_FMT_QSV
>
> regards
> Max
>
> On Thu, Oct 24, 2019 at 12:47 AM Rogozhkin, Dmitry V <
> dmitry.v.rogozh...@intel.com> wrote:
>
> > Hi,
> >
> > I was looking into the ffmpeg qsv (mediasdk
Hi,
I was looking into the ffmpeg qsv (mediasdk hw acceleration) path
implementation and wonder whether opaque memory allocation path is
actually used and exercised?
I failed to come across any code in ffmpeg sources which use it. Do I
miss something?
Are there any other usages possible? For
On Fri, 2019-10-25 at 02:17 +, Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Rogozhkin, Dmitry V
> > Sent: Friday, October 25, 2019 05:17
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] ffmpeg-qsv:
On Wed, 2019-10-09 at 06:28 -0700, Dmitry Rogozhkin wrote:
> From: Andrey Orlov
>
> synchronization by sync point after DEVICE_BUSY
>
> Fixes: CPU usage on AVC decode cases (18% -> 9%)
I would expect a link or reference to the bug following "Fixes:". If
you don't have it - just a text what is
On Wed, 2020-09-02 at 04:28 +, Xiang, Haihao wrote:
> On Wed, 2020-09-02 at 04:20 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Haihao Xiang
> > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc:
On Wed, 2020-09-02 at 04:32 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Soft Works
> > Sent: Wednesday, September 2, 2020 6:13 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH]
On Wed, 2020-09-02 at 07:31 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Rogozhkin, Dmitry V
> > Sent: Wednesday, September 2, 2020 9:00 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PA
On Wed, 2020-09-02 at 14:21 +, Rogozhkin, Dmitry V wrote:
> On Wed, 2020-09-02 at 08:41 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Rogozhkin, Dmitry V
> > > Sent: Wednesday, September 2, 2020 8:
On Wed, 2020-09-02 at 08:41 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Rogozhkin, Dmitry V
> > Sent: Wednesday, September 2, 2020 8:45 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PA
On Sun, 2020-09-06 at 15:25 +0100, Mark Thompson wrote:
> On 04/09/2020 19:24, Rogozhkin, Dmitry V wrote:
> > On Thu, 2020-09-03 at 01:02 +, Rogozhkin, Dmitry V wrote:
> > > >
> > > > (If you do implement it then you can delete all of the ad-hoc
> > >
On Wed, 2020-09-02 at 20:37 +0100, Mark Thompson wrote:
> > > I still don't see the full picture. What I am looking for at the
> > > first
> > > place is how maintainers and architects envision hwaccel to work
> > > in
> > > general. Basically, there are few ways to specify the device (-
> > >
On Wed, 2020-09-02 at 20:37 +0100, Mark Thompson wrote:
> > In general, per my taste, I would try to use the following device
> > specification working with QSV on Linux across all command lines:
> >
> > -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device
> > qsv=hw@va
> >
Hi,
Can someone, please, help to clarify:
1. Where CONFIG_QSV and CONFIG_LIBMFX gets defined (I don't see that in
the grep output - attached below)?
2. What's relationship between these 2? Which one should actually be
used? /from the first glance they are about the same.../
$ fgrep -rsn
On Thu, 2020-09-03 at 12:59 +0800, myp...@gmail.com wrote:
> On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao
> wrote:
> >
> > On Wed, 2020-09-02 at 14:04 +, Soft Works wrote:
> > > > -Original Message-
> > > > From: ffmpeg-devel On Beh
On Thu, 2020-09-03 at 01:02 +, Rogozhkin, Dmitry V wrote:
> >
> > (If you do implement it then you can delete all of the ad-hoc
> > treatment in ffmpeg, like has been done for the other hardware
> > codecs.)
>
> I like deleting code:). Ok, this sounds good.
On Fri, 2021-06-11 at 10:19 +0800, Haihao Xiang wrote:
> Since commit 89ffcd1, the status pts of the output link is set to a
> value in the input link time base, not in the output link time base
> when
> EOF is reached. Usually this pst value is larger than the required
> one
> because the output
On Wed, 2021-06-09 at 12:18 +0800, Haihao Xiang wrote:
> Since commit 89ffcd1, the pts on output pad is in the time base of
> the
> input link, not the time base of the output link when EOF is reached,
> so
> a filter after vpp_qsv might output some unexpected frames. In order
> to
> avoid this
On Mon, 2022-07-25 at 01:21 +, Xiang, Haihao wrote:
> On Fri, 2022-07-22 at 11:06 -0700, Dmitry Rogozhkin wrote:
> > GPU hang is one of the most typical errors on Intel GPUs in
> > case something goes wrong. It's important to recognize it
> > explicitly for easier bugs triage. Also, this error
Hi,
Can someone, please, help to clarify ffmpeg behavior after one of the
recent changes [1]. This commit turns warning into error to prevent
usage of conflicting options. Error printed out is:
“One of -r/-fpsmax was specified together a non-CFR -vsync/-fps_mode.
This is contradictory.”
In our
On Tue, 2023-11-14 at 19:32 +0100, Hendrik Leppkes wrote:
> On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
> wrote:
> >
> > Gurd against segfault running VLC decoding under msys2 [1]:
> >
> > Thread 33 received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 37728.0xadd0]
> >
On Tue, 2023-11-14 at 11:14 -0800, Dmitry Rogozhkin wrote:
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
>
On Sun, 2023-11-19 at 16:29 +0100, Hendrik Leppkes wrote:
> On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
> wrote:
> >
> > Guard against segfault running VLC decoding under msys2 [1]:
> >
> > Thread 33 received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 37728.0xadd0]
> >
On Tue, 2023-11-21 at 06:17 +0100, Lynne wrote:
> Nov 21, 2023, 05:38 by dmitry.v.rogozhkin-at-intel@ffmpeg.org:
>
> > Validate that a hw_frames_ctx is available before using it for
> > the AVHWAccel.free_frame_priv callback, and don't require it to
> > be present when the callback is not in
49 matches
Mail list logo
