From: Haihao Xiang
This allows a downstream element stores more frames from qsv decoders
and fixes error in get_buffer()
$ ffmpeg -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 -vf
reverse -f null -
[vist#0:0/h264 @ 0x562248f12c50] Decoding error: Cannot allocate memory
[h264_qsv @
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavfilter/vaapi_vpp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index cf2592e068..818bc7d58a 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
From: Haihao Xiang
This allows a downstream element stores more frames from VAAPI
decoders and fixes error in get_buffer()
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input_100frames.mp4 \
-vf reverse -an -f null -
...
[h264 @ 0x557a075a1400] get_buffer() failed
[h264 @
From: Haihao Xiang
With libva2, the argument for render target list to vaCreateContext() is
a hint, so we may use a dynamic frame pool.
Signed-off-by: Haihao Xiang
---
doc/APIchanges | 4
libavutil/hwcontext_vaapi.c | 2 +-
libavutil/hwcontext_vaapi.h | 5 +++--
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavfilter/qsvvpp.c | 52
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index d09140d89b..2c8e73e87d 100644
--- a/libavfilter/qsvvpp.c
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavfilter/qsvvpp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 5cdba7d54a..d09140d89b 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -307,7 +307,7 @@
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a0144b0760..0f7e7eb85a 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -718,8
From: Haihao Xiang
Lock()/Unlock() aren't called to map/unmap data to system memory, so the
array of QSVMid is not needed.
Signed-off-by: Haihao Xiang
---
libavcodec/qsv.c | 70 +++-
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavutil/hwcontext_qsv.c | 131 +-
1 file changed, 129 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 3259cd38ba..2e75f5ca0b 100644
---
From: Haihao Xiang
Allow the source is a dynamic frame pool
Signed-off-by: Haihao Xiang
---
libavutil/hwcontext_qsv.c | 61 ++-
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index
From: Haihao Xiang
When AVHWFramesContext.initial_pool_size is 0, a dynamic frame pool is
required. We may support this under certain conditions, e.g. oneVPL 2.9+
support dynamic frame allocation, we needn't provide a fixed frame pool
in the mfxFrameAllocator.Alloc callback.
Signed-off-by:
From: Haihao Xiang
Add AVQSVFramesContext.info and update the description
Signed-off-by: Haihao Xiang
---
Rebased https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639
against the latest master with a few changes.
doc/APIchanges| 3 +++
libavutil/hwcontext_qsv.c | 4
Otherwise the function will not iterate through valid group types.
Signed-off-by: James Almer
---
libavformat/options.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/options.c b/libavformat/options.c
index bf6113ca95..73e220bb7d 100644
--- a/libavformat/options.c
+++
On 12/19/2023 9:10 AM, Anton Khirnov wrote:
Quoting James Almer (2023-12-19 13:09:05)
On 12/19/2023 7:41 AM, Anton Khirnov wrote:
Quoting James Almer (2023-12-18 20:30:47)
On 12/18/2023 4:19 PM, Anton Khirnov wrote:
---
libavformat/options.c | 10 ++
1 file changed, 10
From: Zhao Zhili
In close_output(), a dummy frame is created with format NONE passed
to enc_open(), which isn't prepared for it. The NULL pointer
dereference happened at
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
When fgt.graph is NULL, skip fg_output_frame() since there is
nothing
On Tue, Dec 19, 2023 at 8:12 AM Nicolas George wrote:
> Rémi Denis-Courmont (12023-12-07):
> > You have had heated arguments against Paul in recent times too. You have
> also
> > argued a lot of exercising your review privileges, which sounds like a
> very
> > libavish notion to me
>
> Only
Signed-off-by: Ondřej Fiala
---
Simplified per Zhao Zhili's suggestion.
doc/ffplay.texi | 5 -
fftools/ffplay.c | 11 ---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 93f77eeece..91d138a974 100644
--- a/doc/ffplay.texi
+++
On Tue, Dec 19, 2023 at 08:48:39PM +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 19. joulukuuta 2023, 18.58.40 EET Michael Niedermayer a écrit :
> > so the idea is that we cannot access any GUI in any code from anything in
> > libavformat and probably all other libs, ever
>
> No. The idea is
Rémi Denis-Courmont (12023-12-19):
> No. The idea is that a command line program cannot use the GUI, and a library
> can only use the GUI if the main program is a GUI program.
This is braindead design at a level way beyond anything we might have in
FFmpeg.
> Lastly, it has been made clear by
Le tiistaina 19. joulukuuta 2023, 18.58.40 EET Michael Niedermayer a écrit :
> so the idea is that we cannot access any GUI in any code from anything in
> libavformat and probably all other libs, ever
No. The idea is that a command line program cannot use the GUI, and a library
can only use the
On Tue, Dec 19, 2023 at 09:23:29AM +0200, Rémi Denis-Courmont wrote:
>
>
> Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer
> a écrit :
> >On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
> >> Quoting Stefano Sabatini (2023-12-16 16:18:07)
> >> > On date Thursday
On Friday, December 15th, 2023 at 11:18 PM, Leo Izen wrote:
> On 12/15/23 16:31, Zsolt Vadász via ffmpeg-devel wrote:
>
> > On Friday, December 15th, 2023 at 10:12 PM, Leo Izen leo.i...@gmail.com
> > wrote:
> >
> > > On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:
> > >
> > > > On
Niklas Haas (12023-12-14):
> From: Niklas Haas
>
> Currently, the logic inside the FF_FILTER_FORMATS_QUERY_FUNC branch
> prevents this code from running in the event that we have a filter with
> a single video input and a single audio output, as the resulting audio
> output link will not have
Le 19 décembre 2023 14:51:21 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-19):
>> Anton's objections are against the horrible hacks necessary to support
>> Mac and Windows, as far as I understand him.
>
>I have not read that. If that is true, maybe he could start with
From: Zhao Zhili
In close_output(), a dummy frame is created with format NONE passed
to enc_open(), which doesn't prepare for it. The NULL pointer
dereference happened at
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
When fgt.graph is NULL, skip fg_output_frame() since there is
nothing
On 2023/12/19 18:42, Matthieu Bouron wrote:
On Sun, Dec 17, 2023 at 1:51 PM Zhao Zhili wrote:
From: Zhao Zhili
From AOSP doc, these values are device and codec specific, but lower
values generally result in more efficient (smaller-sized) encoding.
For example, global_quality 50 on Pixel 6
Tomas Härdin (12023-12-19):
> Technical debt concerns everyone
There is no technical debt. There is never a technical debt from
something that can be removed at an instant notice and that some are
considering removing now.
Learn from the Dread Pirate Roberts: always put off stupid things until
tis 2023-12-05 klockan 08:44 +0100 skrev Nicolas George:
> Vittorio Giovara (12023-12-04):
> > It's almost 2024, when will you be able to drop it?
>
> Never. When will YOU be able to drop bickering about parts of the
> code
> that do no harm and do not bother you?
Technical debt concerns
Long is 32 bits signed on Windows, and nb_stream{s,_groups} are both unsigned
int. In a realistic scenario this wont make a difference, but it's still
proper.
Also ensure the parsed string is an integer while at it.
Signed-off-by: James Almer
---
fftools/ffmpeg_mux_init.c | 15 +--
> +for ( comp = 0; comp < component_count; comp++ ) {
> +avio_write(pb, >j2k_info.j2k_comp_desc[3*comp] , 3);
> +}
Looks like this could be simplified to just
avio_write(pb, sc->j2k_info.j2k_comp_desc, 3*component_count);
> +if (j2k_ncomponents != component_count) {
> +
Rémi Denis-Courmont (12023-12-07):
> You have had heated arguments against Paul in recent times too. You have also
> argued a lot of exercising your review privileges, which sounds like a very
> libavish notion to me
Only because you were not there at the time to get a first-hand
impression.
Rémi Denis-Courmont (12023-12-19):
> Anton's objections are against the horrible hacks necessary to support
> Mac and Windows, as far as I understand him.
I have not read that. If that is true, maybe he could start with
refraining from using expressions like “horrible hacks”.
> Of course it's
Quoting James Almer (2023-12-19 13:09:05)
> On 12/19/2023 7:41 AM, Anton Khirnov wrote:
> > Quoting James Almer (2023-12-18 20:30:47)
> >> On 12/18/2023 4:19 PM, Anton Khirnov wrote:
> >>> ---
> >>>libavformat/options.c | 10 ++
> >>>1 file changed, 10 insertions(+)
> >>>
> >>> diff
On 12/19/2023 7:41 AM, Anton Khirnov wrote:
Quoting James Almer (2023-12-18 20:30:47)
On 12/18/2023 4:19 PM, Anton Khirnov wrote:
---
libavformat/options.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/options.c b/libavformat/options.c
index
This replaces the riscv specific handling from
7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
with a different implementation of the same (plus a bit more), based
on the corresponding feature in dav1d's checkasm,
> 在 2023年12月19日，下午7:40，Anton Khirnov 写道：
>
> Quoting Zhao Zhili (2023-12-19 12:31:53)
>>
>>
On Dec 19, 2023, at 18:32, Anton Khirnov wrote:
>>>
>>> Quoting Zhao Zhili (2023-12-19 16:37:01)
From: Zhao Zhili
In close_output(), a dummy frame is created with format NONE
Quoting Zhao Zhili (2023-12-19 12:31:53)
>
>
> > On Dec 19, 2023, at 18:32, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2023-12-19 16:37:01)
> >> From: Zhao Zhili
> >>
> >> In close_output(), a dummy frame is created with format NONE passed
> >> to enc_open(), which doesn't prepare for
On Mon, 18 Dec 2023, Martin Storsjö wrote:
This can be used to run tests multple times, with e.g. differing
QEMU settings, by adding something like this to the FATE configuration
file:
target_exec="qemu-aarch64-static"
fate_targets="fate-checkasm fate-cpu"
fate_environments="sve128
> On Dec 19, 2023, at 18:32, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2023-12-19 16:37:01)
>> From: Zhao Zhili
>>
>> In close_output(), a dummy frame is created with format NONE passed
>> to enc_open(), which doesn't prepare for it. The NULL pointer
>> dereference happened at
>>
Le 19 décembre 2023 11:29:04 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-19):
>> As others noted earlier, that won't work for Mac and Windows.
>
>If it works on Linux and other real Unixes, it is a lot better than if
>it does not work on any platform. And we should still
On Sun, Dec 17, 2023 at 1:51 PM Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> From AOSP doc, these values are device and codec specific, but lower
> values generally result in more efficient (smaller-sized) encoding.
>
> For example, global_quality 50 on Pixel 6 results a 1080P 30 FPS
> HEVC with
Quoting James Almer (2023-12-18 20:30:47)
> On 12/18/2023 4:19 PM, Anton Khirnov wrote:
> > ---
> > libavformat/options.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/libavformat/options.c b/libavformat/options.c
> > index bf6113ca95..cc89dd6c72 100644
> > ---
Quoting Zhao Zhili (2023-12-19 16:37:03)
> From: Zhao Zhili
>
> ---
> fftools/ffmpeg_enc.c | 6 ++
> 1 file changed, 6 insertions(+)
Ok.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Quoting Zhao Zhili (2023-12-19 16:37:02)
> From: Zhao Zhili
>
> ---
> fftools/ffmpeg_filter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 69a49a071e..7cc7abba64 100644
> --- a/fftools/ffmpeg_filter.c
> +++
Quoting Zhao Zhili (2023-12-19 16:37:01)
> From: Zhao Zhili
>
> In close_output(), a dummy frame is created with format NONE passed
> to enc_open(), which doesn't prepare for it. The NULL pointer
> dereference happened at
> av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
>
> When
Rémi Denis-Courmont (12023-12-19):
> As others noted earlier, that won't work for Mac and Windows.
If it works on Linux and other real Unixes, it is a lot better than if
it does not work on any platform. And we should still blame whoever
broke it rather than whoever is trying to fix it.
>
The added start delay cannot be considered in the EOF pts.
Previous tpad only forwards in-link's EOF pts to out-link.
Signed-off-by: Mingyeong Kim
---
libavfilter/vf_tpad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_tpad.c b/libavfilter/vf_tpad.c
index
47 matches
Mail list logo
