From: Wenbin Chen
When process yuv420 frames, FFmpeg use same alignment on Y/U/V
planes. VPL and MSDK use Y plane's pitch / 2 as U/V planes's
pitch, which make U/V planes 16-bytes aligned. We need to set
a separate alignment to meet runtime's behaviour.
Now the commandline works fine:
ffmpeg -f
Quoting Leo Izen (2022-11-16 12:43:06)
> PFM (aka Portable FloatMap) encodes its scanlines from bottom-to-top,
> not from top-to-bottom, unlike other NetPBM formats. Without this
> patch, FFmpeg ignores this exception and decodes/encodes PFM images
> mirrored vertically from their proper orientatio
Quoting Brian Norris (2022-11-23 22:54:44)
> There can be more than one available render node, and it's not
> guaranteed the first node we come across is the correct one. In
> particular, 'vgem' devices are common, and are
> never VAAPI-enabled and thus not valid here.
>
> We have a 'kernel_driver
On 11/29/2022 5:07 AM, wenbin.chen-at-intel@ffmpeg.org wrote:
From: Wenbin Chen
When process yuv420 frames, FFmpeg use same alignment on Y/U/V
planes. VPL and MSDK use Y plane's pitch / 2 as U/V planes's
pitch, which make U/V planes 16-bytes aligned. We need to set
a separate alignment to m
Just to add that this fix, once approved, should be cherry-picked to all the
release branches where d7f4ad88a0df3c1339e142957bf2c40cd056b8ce has been
cherry-picked.
Basically, 4.4, 5.0, and 5.1.
Thanks
On 27 Nov 2022, 19:34 +0200, Alessandro Di Nepi ,
wrote:
> The commit d7f4ad88a0df3c1339e1429
Hi Anton,
On Tue, Nov 29, 2022 at 12:25:11PM +0100, Anton Khirnov wrote:
> I'm not the maintainer for this, but I wonder if it wouldn't be cleaner
> to instead add something like a 'kernel_driver_blacklist' option that
> would contain a comma-separated list of ignored drivers, and default to
> 'vg
Stick to the library's default value instead.
Should address AOMediaCodec/SVT-AV1 issue #2011.
Signed-off-by: James Almer
---
libavcodec/libsvtav1.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
in
On 11/28/2022 10:25 PM, Marton Balint wrote:
> This looks like a demuxer bug, which should be fixed in the demuxer, and
> not in the muxer.
+1.
I had to re-read the commit message twice because I coulndn't figure out why
the muxer would care about lavf specific demuxer probing.
- Derek
On Mon, 2022-11-21 at 10:31 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> The SDK may provides HDR metadata for HDR streams via mfxExtBuffer
> attached on output mfxFrameSurface1
>
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/qsv_internal.h | 6
> libavcodec/qsvdec.c | 7
On Thu, 2022-11-24 at 10:47 +0800, wenbin.chen-at-intel@ffmpeg.org wrote:
> From: Wenbin Chen
>
> adaptive_i and adaptive_b cannot work with MFX_GOP_STRICT,
> so only enable MFX_GOP_STRICT when these features are disabled.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/qsvenc.c | 9
On Mon, 2022-11-28 at 10:48 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> The SDK will return error if feeding h264_qsv encoder p010 input.
>
> $ ffmpeg -f lavfi -i testsrc -vf "format=p010" -c:v h264_qsv -f null -
> [...]
> [h264_qsv @ 0x55584888b080] Current pixel format is unsupported
On Mon, 2022-11-28 at 12:43 +0800, Xiang, Haihao wrote:
> From: "Chen,Wenbin"
>
> Make sure the size of the output frame always matches the agreed upon
> image size.
>
> Signed-off-by: Wenbin Chen
> ---
> libavfilter/qsvvpp.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> di
> On 11/29/2022 5:07 AM, wenbin.chen-at-intel@ffmpeg.org wrote:
> > From: Wenbin Chen
> >
> > When process yuv420 frames, FFmpeg use same alignment on Y/U/V
> > planes. VPL and MSDK use Y plane's pitch / 2 as U/V planes's
> > pitch, which make U/V planes 16-bytes aligned. We need to set
> > a
13 matches
Mail list logo
