> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Friday, 24 September 2021 19:03
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
>
>
>
> > -Original Message-
> > From:
On Thu, Sep 23, 2021 at 09:45:48AM -0400, Christopher Degawa wrote:
> On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa
> wrote:
>
> >
> >
> > On Fri, Sep 17, 2021 at 9:28 PM wrote:
> >
> >> From: Limin Wang
> >>
> >> Signed-off-by: Limin Wang
> >>
> > As a note, I personally favor this
Signed-off-by: Manuel Stoeckl
---
This is the same as PATCH v3 3/3 of the same name, except with the
filter-pixdesc-x2bgr10le test reference value fixed. (My local ffmpeg
copy sometimes fails to set up and run the filter-pixdesc-* tests, so I
missed this.)
libswscale/input.c
On Fri, Sep 24, 2021 at 06:37:11PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tests/avcodec.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
This and also the other patches adding checks LGTM
thx
[...]
--
Michael GnuPG
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: Friday, 24 September 2021 17:40
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
>
> On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tomas
> Härdin
> Sent: Friday, 24 September 2021 17:34
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
>
> fre 2021-09-24 klockan 10:30 + skrev Soft Works:
> > Hi,
On Thu, Sep 23, 2021 at 11:22:29PM -0400, Manuel Stoeckl wrote:
> This resolves a problem where conversions from YUV to X2RGB10LE
> would produce color values a factor 4 too small, because an 8-bit
> value was placed in a 10-bit channel.
>
> Signed-off-by: Manuel Stoeckl
> ---
>
Forgotten in 1f4cf92cfbd3accbae582ac63126ed5570ddfd37.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/internal.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index dc60e4bf08..2111f2b9ae 100644
---
Just check for the existence of the bsf. This is equivalent to
the old criterion of the AVCodecContext being a decoder.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
It is now checked by FATE that no encoder capable of flushing
uses frame threads, so this now redundant runtime check can
be removed.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 5512ae99f7..e26315c368 100644
--- a/libavcodec/tests/avcodec.c
+++
If an AVCodec has a private class, its priv_data_size must be > 0
and at the end of a successful call to avcodec_open2()
the AVCodecContext's priv_data must exist and its first element must
be a pointer to said AVClass. This should not be conditioned
on priv_data_size being > 0 (which is tested by
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 3eb4372019..5512ae99f7 100644
--- a/libavcodec/tests/avcodec.c
+++
They are supposed to be zero.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/j2kenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 7ebd6856e0..71010509ec 100644
--- a/libavcodec/j2kenc.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 64940cfdb1..3eb4372019 100644
--- a/libavcodec/tests/avcodec.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 22f308fafa..64940cfdb1 100644
--- a/libavcodec/tests/avcodec.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 36
1 file changed, 36 insertions(+)
diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 9232647ff0..22f308fafa 100644
--- a/libavcodec/tests/avcodec.c
+++
On Thu, Sep 23, 2021 at 11:22:33PM -0400, Manuel Stoeckl wrote:
> Signed-off-by: Manuel Stoeckl
> ---
> libswscale/input.c | 15 +--
> libswscale/output.c | 9 -
> libswscale/utils.c | 1 +
>
The current name comes from a time in which libavcodec/utils.c
contained the whole core of libavcodec.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 4 ++--
libavcodec/tests/{utils.c => avcodec.c} | 0
tests/fate/libavcodec.mak | 8
3
ping.
在 2021年9月21日 +0800 20:08，Sun Zhenliang ，写道：
>
> ping. Anyone could review this ？
>
> > On Sep 18, 2021, at 20:40, Sun Zhenliang wrote:
> >
> > Ping.
> > 在 2021年9月17日 +0800 15:28，Sun Zhenliang ，写道：
> > > 在 2021年9月17日 +0800 14:49，Paul B Mahol ，写道：
> > > > Are stereo files available somewhere?
On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> Hi,
>
> for a new filter, I want to rescale PAL8 subtitle bitmaps where the palette
> includes
> colors with alpha.
>
> From what I’ve seen, swscale doesn’t support PAL8-to-PAL8, only PAL8-to-BGR8
> which doesn’t support alpha and
fre 2021-09-24 klockan 10:30 + skrev Soft Works:
> Hi,
>
> for a new filter, I want to rescale PAL8 subtitle bitmaps where the
> palette includes
> colors with alpha.
Isn't this typically done at the player level? What's your use case?
>
> From what I’ve seen, swscale doesn’t support
On Fri, Sep 24, 2021 at 5:30 PM Jan Ekström wrote:
>
> On Fri, Sep 24, 2021 at 12:06 PM Ho Ming Shun wrote:
> >
> > MMAL is an fundamentally an asynchronous decoder, which was a bad fit
> > for the legacy dataflow API. Often multiple packets are enqueued before
> > a flood of frames are returned
Hi,
for a new filter, I want to rescale PAL8 subtitle bitmaps where the palette
includes
colors with alpha.
From what I’ve seen, swscale doesn’t support PAL8-to-PAL8, only PAL8-to-BGR8
which doesn’t support alpha and the palette is fixed with 256 entries defined by
convention, while I would
From: Niklas Haas
Similar in spirit and design to 66845cffc3bbb, but slightly simpler due
to the lack of interlaced frames in HEVC. See that commit for more
details.
For the seed value, since no specification for this appears to exist, I
semi-arbitrarily decided to base it off the POC id alone,
On Fri, Sep 24, 2021 at 12:06 PM Ho Ming Shun wrote:
>
> MMAL is an fundamentally an asynchronous decoder, which was a bad fit
> for the legacy dataflow API. Often multiple packets are enqueued before
> a flood of frames are returned from MMAL.
>
> The previous lockstep dataflow meant that any
Signed-off-by: Ho Ming Shun
---
libavcodec/mmaldec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 6dbb991ae1..ff8772b0a6 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -660,7 +660,7 @@ static int
extra_data and normal packets (from ff_decode_get_packet) processing do
not overlap, thus we can re-use the spare AVPacket to send to
ffmmal_add_packet.
Furthermore, this removes allocation of AVPacket on the stack and stops
using deprecated av_init_packet.
Signed-off-by: Ho Ming Shun
---
Use spare packet allocated in DecodeSimpleContext to handle packet
submission into ffmmal_add_packet.
Signed-off-by: Ho Ming Shun
---
libavcodec/mmaldec.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index
MMAL is an fundamentally an asynchronous decoder, which was a bad fit
for the legacy dataflow API. Often multiple packets are enqueued before
a flood of frames are returned from MMAL.
The previous lockstep dataflow meant that any delay in returning packets
from the VPU would cause
v2:
Signed-off and rebased
This series switches mmaldec to use the decoupled dataflow API to reduce
excessive buffering in the driver.
At the same time, remove dependency on sizeof(AVPacket) which is
deprecated. Also fix all compile warnings.
Ho Ming Shun (4):
avcodec/mmaldec: use decoupled
Signed-off-by: Ho Ming Shun
---
libavcodec/mmaldec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 0aad7d0bb1..8ec0fe 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -660,7 +660,7 @@ static int
extra_data and normal packets (from ff_decode_get_packet) processing do
not overlap, thus we can re-use the spare AVPacket to send to
ffmmal_add_packet.
Furthermore, this removes allocation of AVPacket on the stack and stops
using deprecated av_init_packet.
---
libavcodec/mmaldec.c | 8 +++-
Use spare packet allocated in DecodeSimpleContext to handle packet
submission into ffmmal_add_packet.
---
libavcodec/mmaldec.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index b97cc6ff5e..aab107d325 100644
---
MMAL is an fundamentally an asynchronous decoder, which was a bad fit
for the legacy dataflow API. Often multiple packets are enqueued before
a flood of frames are returned from MMAL.
The previous lockstep dataflow meant that any delay in returning packets
from the VPU would cause
This series switches mmaldec to use the decoupled dataflow API to reduce
excessive buffering in the driver.
At the same time, remove dependency on sizeof(AVPacket) which is
deprecated. Also fix all compile warnings.
Ho Ming Shun (4):
avcodec/mmaldec: use decoupled dataflow
avcodec/mmaldec:
On Fri, Sep 24, 2021 at 3:40 AM Andreas Rheinhardt
wrote:
>
> Ho Ming Shun:
> > MMAL is an fundamentally an asynchronous decoder, which was a bad fit
> > for the legacy dataflow API. Often multiple packets are enqueued before
> > a flood of frames are returned from MMAL.
> >
> > The previous
37 matches
Mail list logo
