Leo Izen 于2023年4月10日周一 21:14写道：
>
> On 4/8/23 23:07, Steven Liu wrote:
> > When enable lcms2, the fate-png-icc-parse will get error bellow.
> > TESTpng-icc-parse
>
> I believe this change happened when I updated how PNG handles colors (no
> longer using mastering display metadata for that). G
On Thu, Apr 20, 2023 at 12:54:59PM -0400, Leo Izen wrote:
> The change introduced in b18a9c29713abc3a1b081de3f320ab53a47120c6
> created a regression for non-subsampled progressive RGB jpegs. This
> should fix that.
>
> Additionally, this should fix other RGB JPEGs broken before the recent
> patche
Hi all,
the break after the pandemic has stopped for the LinuxDays in Prague this year
as well.
Thus, FFmpeg will be at the Linux Days 2023 in Prague, Czech Republic from
October 7th to 8th!
Find more information on their homepage. The 2023 english version linked here
is still outdated but sho
As with the earlier bswap change, all versions of GCC and Clang that
support RISC-V support the popcount built-ins, so we can just use them
instead of inline assembler.
---
libavutil/riscv/intmath.h | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a
av_bswapXX() are used in context that expect exact size types, notably
variable arguments to av_log(). On Linux RV64, uint_fast32_t is an
unsigned long, so the current inline assembler does not work properly.
Since GCC and Clang gained their byte-swap built-ins before they
supported RISC-V, we can
Added framecrc tests for RGB JPEGs to verify future changes to the
decoder.
---
tests/fate/image.mak | 9 +
tests/ref/fate/jpg-rgb-221 | 6 ++
tests/ref/fate/jpg-rgb-baseline| 6 ++
tests/ref/fate/jpg-rgb-progressive | 6 ++
4 files changed, 27 inserti
The change introduced in b18a9c29713abc3a1b081de3f320ab53a47120c6
created a regression for non-subsampled progressive RGB jpegs. This
should fix that.
Additionally, this should fix other RGB JPEGs broken before the recent
patches, such as those in Trac issue #10190.
---
libavcodec/mjpegdec.c | 9
Changes from v3:
- Wrapped two previous commits into one.
- Removed case logic with regard to s->progressive and !s->progressive, now all
should be treated the same way, at michaelni's recommendation.
- All RGB jpegs are now decoded in RGB order and then the buffers are pivoted
into
GBR-order
On 4/20/23 05:50, Michael Niedermayer wrote:
On Wed, Apr 19, 2023 at 05:15:00PM -0400, Leo Izen wrote:
On 4/19/23 16:37, Michael Niedermayer wrote:
On Wed, Apr 19, 2023 at 03:23:41PM -0400, Leo Izen wrote:
On 4/19/23 14:58, Michael Niedermayer wrote:
On Wed, Apr 19, 2023 at 02:11:24PM -0400,
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
The decoder is tagged as being FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM, so might as
well make use of it.
Signed-off-by: James Almer
---
libavcodec/pdvdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/pdvdec.c b/libavcodec/pdvdec.c
index d1a3d1d3f9..b1fc19b1c9 100644
--- a/liba
This was a bug/mistake in dae3679a9bfa421829ef9049ae2167089a2fdef7.
use_mfra_for by defintion only has an effect on fragmented MP4 files,
making the check not only redundant, but also broken if a user used
the option globally (i.e. set on non-fragmented MP4s).
Signed-off-by: Derek Buitenhuis
---
num_ref_idx_l0_active_minus1, num_ref_idx_l1_active_minus1,
num_ref_idx_l0_default_active,
and num_ref_idx_l1_default_active are all in the range 1 to 15, inclusive.
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 10 --
libavcodec/hevcdec.c | 6 +++---
2 files changed, 11 insert
On Thu, Apr 20, 2023 at 7:27 PM "zhilizhao(赵志立)" wrote:
>
>
>
> > On Apr 18, 2023, at 23:33, Jun Zhao wrote:
> >
> > Support full range videos when transcoding, enabled the
> > YUVJ420P to avoid auto scale from YUVJ420P to YUV420P
>
>
> According to "Towards YUVJ removal"
> http://ffmpeg.org/pipe
> On Apr 18, 2023, at 23:33, Jun Zhao wrote:
>
> Support full range videos when transcoding, enabled the
> YUVJ420P to avoid auto scale from YUVJ420P to YUV420P
According to "Towards YUVJ removal"
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304718.html
> So, as was discussed at t
On Wed, Apr 19, 2023 at 05:15:00PM -0400, Leo Izen wrote:
> On 4/19/23 16:37, Michael Niedermayer wrote:
> > On Wed, Apr 19, 2023 at 03:23:41PM -0400, Leo Izen wrote:
> > > On 4/19/23 14:58, Michael Niedermayer wrote:
> > > > On Wed, Apr 19, 2023 at 02:11:24PM -0400, Leo Izen wrote:
> > > > > The c
On Tue, Apr 18, 2023 at 11:07 PM Michael Niedermayer
wrote:
> On Mon, Apr 17, 2023 at 08:46:15PM +0200, Paul B Mahol wrote:
> > Patches attached.
>
> > Makefile |1
> > allformats.c |1
> > pdvdec.c | 172
> +++
> > 3 files
17 matches
Mail list logo
