On Wed, 27 Jul 2022 at 20:51, Emil Velikov wrote:
>
> On Thu, 21 Jul 2022 at 21:47, Mark Thompson wrote:
> >
> > On 20/07/2022 17:41, Emil Velikov wrote:
> > > On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote:
> > >>
> > >> Emil Velikov (1202
Greetings Timo,
On Wed, 27 Jul 2022 at 21:00, Timo Rothenpieler wrote:
> That sounds incredibly broken and will of course cause stuff to break.
> I see the issue lies with that magic script, not with ffmpeg.
>
Apologies, never meant to imply that ffmpeg is broken - far from it.
Simply put libva
On Thu, 28 Jul 2022 at 15:04, Anton Khirnov wrote:
>
> Quoting Emil Velikov (2022-07-22 15:27:26)
> >
> > Assuming I'm reading the code correctly, currently when both are
> > undefined vaapi_device_create() will be basically a dummy, doing some
> > basic mal
On Thu, 21 Jul 2022 at 21:47, Mark Thompson wrote:
>
> On 20/07/2022 17:41, Emil Velikov wrote:
> > On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote:
> >>
> >> Emil Velikov (12022-07-19):
> >>> As you may know the libva* set of libraries share an in
On Thu, 21 Jul 2022 at 22:06, Mark Thompson wrote:
>
> On 20/07/2022 11:56, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind a
> > compiler guard.
> >
> > Signed-off-by: Emil Velikov
On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote:
>
> Emil Velikov (12022-07-19):
> > As you may know the libva* set of libraries share an internal ABI
> > between them. In a resent libva commit, the va_fool API was removed.
> >
> > Thus if one is to mix different
On Wed, 20 Jul 2022 at 11:56, Emil Velikov wrote:
>
> From: Emil Velikov
>
> There is an internal ABI between libva.so the libva-XXX.so libraries.
>
> With a recent change, the internal va_fool API was removed breaking the
> ABI. So if libva.so and libva-x11.so are from d
From: Emil Velikov
Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind a
compiler guard.
Signed-off-by: Emil Velikov
---
libavutil/hwcontext_vaapi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index
From: Emil Velikov
There is an internal ABI between libva.so and libva-drm.so. So having
mismatched versions can cause all sorts of issues.
We had the breakage between libva.so and libva-x11.so addressed with
earlier commit. There's no point in waiting for things to break wrt
libva-drm.
From: Emil Velikov
There is an internal ABI between libva.so the libva-XXX.so libraries.
With a recent change, the internal va_fool API was removed breaking the
ABI. So if libva.so and libva-x11.so are from different version, the
whole stack will crash.
Instead we can dlopen() the libva-x11
tion" API entrypoint.
---
Changes in v2:
- Add libdl dependency, to address underlinking with older glibc
Emil Velikov (3):
hwcontext_vaapi: do not link against libva-x11.so
hwcontext_vaapi: do not link against libva-drm.so
hwcontext_vaapi: #if guard VAAPI_DRM specifics
configu
d drivers, to a single extra "registration" API entrypoint.
Emil Velikov (3):
hwcontext_vaapi: do not link against libva-x11.so
hwcontext_vaapi: do not link against libva-drm.so
hwcontext_vaapi: #if guard VAAPI_DRM specifics
configure | 2 +-
libavut
On Tue, 19 Jul 2022 at 17:56, Emil Velikov wrote:
>
> Greetings everyone,
>
Sincere apologies for accidentally sending this out multiple times. I
may have found a bug where `git send-email --dry-run` does not work
correctly.
Thanks
Emil
_
From: Emil Velikov
Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind an
disabled.
Cc: Mark Thompson
Signed-off-by: Emil Velikov
---
libavutil/hwcontext_vaapi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil
From: Emil Velikov
There is an internal ABI between libva.so and libva-drm.so. So having
mismatched versions can cause all sorts of issues.
We had the breakage between libva.so and libva-x11.so addressed with
earlier commit. There's no point in waiting for things to break wrt
libva-drm.
From: Emil Velikov
There is an internal ABI between libva.so the libva-XXX.so libraries.
With a recent change, the internal va_fool API was removed breaking the
ABI. So if libva.so and libva-x11.so are from different version, the
whole stack will crash.
Instead we can dlopen() the libva-x11
sider backporting it to the stable branches in due time.
- My TODO includes to reducing the massive ABI between libva* and
backend drivers, which is likely to involve adding a "registration" API.
Emil Velikov (3):
hwcontext_vaapi: do not link against libva-x11.so
hwcontext_vaapi: do not lin
From: Emil Velikov
Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind an
disabled.
Cc: Mark Thompson
Signed-off-by: Emil Velikov
---
libavutil/hwcontext_vaapi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil
From: Emil Velikov
There is an internal ABI between libva.so and libva-drm.so. So having
mismatched versions can cause all sorts of issues.
We had the breakage between libva.so and libva-x11.so addressed with
earlier commit. There's no point in waiting for things to break wrt
libva-drm.
From: Emil Velikov
There is an internal ABI between libva.so the libva-XXX.so libraries.
With a recent change, the internal va_fool API was removed breaking the
ABI. So if libva.so and libva-x11.so are from different version, the
whole stack will crash.
Instead we can dlopen() the libva-x11
20 matches
Mail list logo
