Magic number 124 and ^= are not listed on the spec.
Strictly following the spec will make a reader's life much easier. See (9-6)
for details
---
libavcodec/hevc_cabac.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
passed h264,hevc decoder fate test.
On Sun, Mar 21, 2021 at 1:06 PM Nuo Mi wrote:
> Magic number 124 and ^= are not listed on the spec.
> Strictly following the spec will make a reader's life much easier. See
> (9-6) for details
> ---
> libavcodec/hevc_cabac.c | 10 --
> 1 file changed,
The type of ff_h264_cabac_tables in unit8, it's not signed.
Also,H.264 Table 9-44 and H.265 Table 9-52 never used a signed value
---
libavcodec/cabac.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
index 6649feebe
On Sun, Mar 21, 2021 at 12:10 PM Nuo Mi wrote:
> The type of ff_h264_cabac_tables in unit8, it's not signed.
> Also,H.264 Table 9-44 and H.265 Table 9-52 never used a signed value
> ---
> libavcodec/cabac.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff -
On 3/20/2021 3:30 PM, Carl Eugen Hoyos wrote:
Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer :
On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes lossless aom encoding in some cases for me, it is
still possible to force lossy encoding with crf == 0 and qmax > 0.
P
Hi!
Attached patch fixes ticket #8930 for me.
Please comment, Carl Eugen
From f032f8963d3da6a074f626e6c97c2c95d3918194 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 21 Mar 2021 01:36:32 +0100
Subject: [PATCH] lavc/mjpegdec: Decode format 211121 as YUV 4:4:4
Fixes ticket #8930.
---
Am Di., 16. März 2021 um 21:16 Uhr schrieb Carl Eugen Hoyos
:
> apart from the existing code and the sample files in ticket #9153,
> Nellymoser in swf is apparently supported by Flash binaries if I read
> the existing exploit correctly.
Patch applied, Carl Eugen
__
The SVQ3 decoder modifies the input bitstream at two places.
One of them is only reached when the file is watermarked.
Therefore commit 2264c1108135380c49fdf0aef97520bf77a6ed37
made a copy of all the frame data in this case.
But there is a second possibility for modifying the frame and
therefore L
It takes care of zeroing padding (which has been forgotten here).
Also rename the size variable to indicate that this is not the size
of the current slice.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/s
sharpbai:
> Some encoder set pic_order_cnt_type=0 when not using bframe,
> such as h264_videotoolbox. It may cause that some hardware decoder
> delays output frames (buffer up to 18frames), such as MediaCodec
> decoder before Android 11.
>
> Setting pic_order_cnt_type=2 indicates that the picture
Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer :
>
> On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes lossless aom encoding in some cases for me, it is
> > still possible to force lossy encoding with crf == 0 and qmax > 0.
> >
> > Please comment, Carl Eugen
On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes lossless aom encoding in some cases for me, it is
still possible to force lossy encoding with crf == 0 and qmax > 0.
Please comment, Carl Eugen
From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001
From:
Hi!
Attached patch fixes lossless aom encoding in some cases for me, it is
still possible to force lossy encoding with crf == 0 and qmax > 0.
Please comment, Carl Eugen
From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 20 Mar 2021 18:47:52 +
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-03-16 21:30:58)
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> I actually wonder why this flag is not used for encoders. Several of
>> them explicitly check for invalid channel values.
>
> How would it work? How can the channel count _not_ be prov
Quoting Andreas Rheinhardt (2021-03-16 21:30:58)
> Signed-off-by: Andreas Rheinhardt
> ---
> I actually wonder why this flag is not used for encoders. Several of
> them explicitly check for invalid channel values.
How would it work? How can the channel count _not_ be provided to an
encoder?
--
From: He Yang <1160386...@qq.com>
Signed-off-by: He Yang <1160386...@qq.com>
---
libavdevice/gdigrab.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 9b2c55fe90..c2842975ec 100644
--- a/libavdevice/gdigrab.c
+++
Will apply tomorrow.
On 2021-03-18 17:56, Gyan Doshi wrote:
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index f0ac719d2d..be9c5b4b1c 100755
--- a/configure
+++ b/configure
@@ -3363,6 +3363,7 @@ opus_muxer_select="ogg_muxer"
psp_muxer_select="mov_m
Will apply tomorrow.
On 2021-03-18 18:04, Gyan Doshi wrote:
---
libavformat/rtpenc_mpegts.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 50cebf68a3..28522f8913 100644
--- a/libavformat/rtpenc_m
Some encoder set pic_order_cnt_type=0 when not using bframe,
such as h264_videotoolbox. It may cause that some hardware decoder
delays output frames (buffer up to 18frames), such as MediaCodec
decoder before Android 11.
Setting pic_order_cnt_type=2 indicates that the picture order could not
be rev
Commit 6973df112275c8ea4af0bf3cb1338baecc1d06b3 added support
for music tracks by outputting its two containing tracks
together in one packet. But the actual data is not contiguous
in the file and therefore one can't simply use av_get_packet()
(which has been used before) for it. Therefore the pack
20 matches
Mail list logo
