Re: [FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?
On Tue, 25 Oct 2022, 21:32 Peter B., wrote: > Hi everyone :) > > Would it possibly have a significant impact on coding speed of FFV1's > slicecrc option (Where a CRC is calculated for each frame slice), to use > a faster algorithm instead (if one exists)? > I'm wondering if, for example something like "xxHash" may warrant a try? > (Haven't found CRC vs xxHash benchmarks yet, but I'm still looking) > > Anyhow, > Thanks for any of your time :D I haven't benchmarked the overhead of the CRC in FFv1 vs the encode or decode process. But FFmpeg's CRC could be optimised using multiple unrolled tables or SIMD or other approaches. Regards, Kieran Kunhya ___ 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".
Re: [FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?
On 10/26/22, Kieran Kunhya wrote: > On Tue, 25 Oct 2022, 21:32 Peter B., wrote: > >> Hi everyone :) >> >> Would it possibly have a significant impact on coding speed of FFV1's >> slicecrc option (Where a CRC is calculated for each frame slice), to use >> a faster algorithm instead (if one exists)? >> I'm wondering if, for example something like "xxHash" may warrant a try? >> (Haven't found CRC vs xxHash benchmarks yet, but I'm still looking) >> >> Anyhow, >> Thanks for any of your time :D > > > I haven't benchmarked the overhead of the CRC in FFv1 vs the encode or > decode process. > But FFmpeg's CRC could be optimised using multiple unrolled tables or SIMD > or other approaches. It is already using multiple tables. > > Regards, > Kieran Kunhya > ___ > 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". > ___ 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".
[FFmpeg-devel] [PATCH] avcodec/eatgq: prevent out of bounds memory access and endless loop
---
libavcodec/eatgq.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
index 89e9f20880..fdda8286ef 100644
--- a/libavcodec/eatgq.c
+++ b/libavcodec/eatgq.c
@@ -56,7 +56,7 @@ static av_cold int tgq_decode_init(AVCodecContext *avctx)
return 0;
}
-static void tgq_decode_block(TgqContext *s, int16_t block[64], GetBitContext
*gb)
+static int tgq_decode_block(TgqContext *s, int16_t block[64], GetBitContext
*gb)
{
const uint8_t *scantable = ff_zigzag_direct;
int i, j, value;
@@ -73,7 +73,9 @@ static void tgq_decode_block(TgqContext *s, int16_t
block[64], GetBitContext *gb
case 1:
skip_bits(gb, 2);
value = get_bits(gb, 6);
-for (j = 0; j < value; j++)
+if (!value)
+return AVERROR_INVALIDDATA;
+for (j = 0; j < value && i < 64; j++)
block[scantable[i++]] = 0;
break;
case 6:
@@ -100,6 +102,7 @@ static void tgq_decode_block(TgqContext *s, int16_t
block[64], GetBitContext *gb
}
}
block[0] += 128 << 4;
+return 0;
}
static void tgq_idct_put_mb(TgqContext *s, int16_t (*block)[64], AVFrame
*frame,
@@ -161,7 +164,8 @@ static int tgq_decode_mb(TgqContext *s, GetByteContext
*gbyte,
return ret;
for (i = 0; i < 6; i++)
-tgq_decode_block(s, s->block[i], &gb);
+if ((ret = tgq_decode_block(s, s->block[i], &gb)) < 0)
+return ret;
tgq_idct_put_mb(s, s->block, frame, mb_x, mb_y);
bytestream2_skip(gbyte, mode);
} else {
--
2.35.1
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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".
[FFmpeg-devel] [PATCHv2] fate/microsoft: add mss2 region test case
--- test file: https://trac.ffmpeg.org/attachment/ticket/3255/mss2_2.wmv (30 KiB) tests/fate/microsoft.mak | 3 ++- tests/ref/fate/mss2-region | 7 +++ 2 files changed, 9 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/mss2-region diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak index ee1a062425..e98ab30aae 100644 --- a/tests/fate/microsoft.mak +++ b/tests/fate/microsoft.mak @@ -14,8 +14,9 @@ FATE_MSS2-$(call FRAMECRC, ASF, MSS2, SCALE_FILTER) += fate-mss2-rgb555 fate-mss fate-mss2-rgb555: CMD = framecrc -i $(TARGET_SAMPLES)/mss2/rle555.wmv -pix_fmt rgb555le -vf scale fate-mss2-rgb555s: CMD = framecrc -i $(TARGET_SAMPLES)/mss2/rle555s.wmv -pix_fmt rgb555le -vf scale -FATE_MSS2 += fate-mss2-wmv +FATE_MSS2 += fate-mss2-wmv fate-mss2-region fate-mss2-wmv: CMD = framecrc -i $(TARGET_SAMPLES)/mss2/msscreencodec.wmv -an -frames 100 +fate-mss2-region: CMD = framecrc -i $(TARGET_SAMPLES)/mss2/mss2_2.wmv -an FATE_MSS2-$(call FRAMECRC, ASF, MSS2) += $(FATE_MSS2) diff --git a/tests/ref/fate/mss2-region b/tests/ref/fate/mss2-region new file mode 100644 index 00..c0a99f3e1f --- /dev/null +++ b/tests/ref/fate/mss2-region @@ -0,0 +1,7 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 160x120 +#sar 0: 0/1 +0, 0, 0,1,57600, 0x51bc82a3 +0, 3000, 3000,1,57600, 0x51bc82a3 -- 2.35.1 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/eatgq: prevent out of bounds memory access and endless loop
Peter Ross:
> ---
> libavcodec/eatgq.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
> index 89e9f20880..fdda8286ef 100644
> --- a/libavcodec/eatgq.c
> +++ b/libavcodec/eatgq.c
> @@ -56,7 +56,7 @@ static av_cold int tgq_decode_init(AVCodecContext *avctx)
> return 0;
> }
>
> -static void tgq_decode_block(TgqContext *s, int16_t block[64], GetBitContext
> *gb)
> +static int tgq_decode_block(TgqContext *s, int16_t block[64], GetBitContext
> *gb)
> {
> const uint8_t *scantable = ff_zigzag_direct;
> int i, j, value;
> @@ -73,7 +73,9 @@ static void tgq_decode_block(TgqContext *s, int16_t
> block[64], GetBitContext *gb
> case 1:
> skip_bits(gb, 2);
> value = get_bits(gb, 6);
> -for (j = 0; j < value; j++)
> +if (!value)
> +return AVERROR_INVALIDDATA;
> +for (j = 0; j < value && i < 64; j++)
> block[scantable[i++]] = 0;
> break;
> case 6:
> @@ -100,6 +102,7 @@ static void tgq_decode_block(TgqContext *s, int16_t
> block[64], GetBitContext *gb
> }
> }
> block[0] += 128 << 4;
> +return 0;
> }
>
> static void tgq_idct_put_mb(TgqContext *s, int16_t (*block)[64], AVFrame
> *frame,
> @@ -161,7 +164,8 @@ static int tgq_decode_mb(TgqContext *s, GetByteContext
> *gbyte,
> return ret;
>
> for (i = 0; i < 6; i++)
> -tgq_decode_block(s, s->block[i], &gb);
> +if ((ret = tgq_decode_block(s, s->block[i], &gb)) < 0)
> +return ret;
> tgq_idct_put_mb(s, s->block, frame, mb_x, mb_y);
> bytestream2_skip(gbyte, mode);
> } else {
>
>
The '4' case can also overread. But actually I don't like the idea of
adding further checks into the main loop; mind if I send an alternative
solution?
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 1/5 v2] avcodec/ac3dec: split off code discarding garbage at the beginning of a packet
On 10/22/2022 6:02 PM, James Almer wrote:
Signed-off-by: James Almer
---
No changes since v1.
libavcodec/ac3_parser.c | 19 +++
libavcodec/ac3_parser_internal.h | 2 ++
libavcodec/ac3dec.c | 15 ++-
3 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 4f154bb7c4..425e1b4742 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -53,6 +53,25 @@ static const uint8_t center_levels[4] = { 4, 5, 6, 5 };
*/
static const uint8_t surround_levels[4] = { 4, 6, 7, 6 };
+int ff_ac3_find_syncword(const uint8_t *buf, int buf_size)
+{
+int i;
+
+for (i = 1; i < buf_size; i += 2) {
+if (buf[i] == 0x77 || buf[i] == 0x0B) {
+if ((buf[i] ^ buf[i-1]) == (0x77 ^ 0x0B)) {
+i--;
+break;
+} else if ((buf[i] ^ buf[i+1]) == (0x77 ^ 0x0B)) {
+break;
+}
+}
+}
+if (i >= buf_size)
+return AVERROR_INVALIDDATA;
+
+return i;
+}
int ff_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo *hdr)
{
diff --git a/libavcodec/ac3_parser_internal.h b/libavcodec/ac3_parser_internal.h
index bd4e1bbffb..2ac0e67ec2 100644
--- a/libavcodec/ac3_parser_internal.h
+++ b/libavcodec/ac3_parser_internal.h
@@ -79,4 +79,6 @@ int ff_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo
*hdr);
int avpriv_ac3_parse_header(AC3HeaderInfo **hdr, const uint8_t *buf,
size_t size);
+int ff_ac3_find_syncword(const uint8_t *buf, int buf_size);
+
#endif /* AVCODEC_AC3_PARSER_INTERNAL_H */
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 340f6e1e37..8e40587ff1 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1508,19 +1508,8 @@ static int ac3_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
s->superframe_size = 0;
buf_size = full_buf_size;
-for (i = 1; i < buf_size; i += 2) {
-if (buf[i] == 0x77 || buf[i] == 0x0B) {
-if ((buf[i] ^ buf[i-1]) == (0x77 ^ 0x0B)) {
-i--;
-break;
-} else if ((buf[i] ^ buf[i+1]) == (0x77 ^ 0x0B)) {
-break;
-}
-}
-}
-if (i >= buf_size)
-return AVERROR_INVALIDDATA;
-if (i > 10)
+i = ff_ac3_find_syncword(buf, buf_size);
+if (i < 0 || i > 10)
return i;
buf += i;
buf_size -= i;
Will apply set.
___
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".
Re: [FFmpeg-devel] [PATCH] RFC: v210enc optimisations and initial AVX-512
I guess it could also be scaled to ymm if you're a big Skylake fan :P (in which case you'd probably want to reorder the shuffle indices so that chroma comes first, i.e. movq [u] + movhps [v] + vinserti32x4[y]) What shuffle or permute did you have in mind when you suggested this for Skylake? Without the permute I'm not sure how the change in ordering helps. Aren't we stuck with data in separate lanes? I'm probably missing something though. ___ 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".
[FFmpeg-devel] [PATCH] Avoid possible integer overflow in yuv420 to rgba64 templates by saturating.
---
libswscale/output.c | 96 ++---
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 0e1c1225a0..8c8f62682a 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1109,20 +1109,20 @@ yuv2rgba64_X_c_template(SwsContext *c, const int16_t
*lumFilter,
B =U * c->yuv2rgb_u2b_coeff;
// 8 bits: 30 - 22 = 8 bits, 16 bits: 30 bits - 14 = 16 bits
-output_pixel(&dest[0], av_clip_uintp2(R_B + Y1, 30) >> 14);
-output_pixel(&dest[1], av_clip_uintp2( G + Y1, 30) >> 14);
-output_pixel(&dest[2], av_clip_uintp2(B_R + Y1, 30) >> 14);
+output_pixel(&dest[0], av_clip_uintp2(av_sat_add32(R_B, Y1), 30) >>
14);
+output_pixel(&dest[1], av_clip_uintp2(av_sat_add32( G, Y1), 30) >>
14);
+output_pixel(&dest[2], av_clip_uintp2(av_sat_add32(B_R, Y1), 30) >>
14);
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(R_B + Y2, 30) >> 14);
-output_pixel(&dest[5], av_clip_uintp2( G + Y2, 30) >> 14);
-output_pixel(&dest[6], av_clip_uintp2(B_R + Y2, 30) >> 14);
+output_pixel(&dest[4], av_clip_uintp2(av_sat_add32(R_B, Y2), 30)
>> 14);
+output_pixel(&dest[5], av_clip_uintp2(av_sat_add32( G, Y2), 30)
>> 14);
+output_pixel(&dest[6], av_clip_uintp2(av_sat_add32(B_R, Y2), 30)
>> 14);
output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
dest += 8;
} else {
-output_pixel(&dest[3], av_clip_uintp2(R_B + Y2, 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2( G + Y2, 30) >> 14);
-output_pixel(&dest[5], av_clip_uintp2(B_R + Y2, 30) >> 14);
+output_pixel(&dest[3], av_clip_uintp2(av_sat_add32(R_B, Y2), 30)
>> 14);
+output_pixel(&dest[4], av_clip_uintp2(av_sat_add32( G, Y2), 30)
>> 14);
+output_pixel(&dest[5], av_clip_uintp2(av_sat_add32(B_R, Y2), 30)
>> 14);
dest += 6;
}
}
@@ -1175,20 +1175,20 @@ yuv2rgba64_2_c_template(SwsContext *c, const int32_t
*buf[2],
A2 += 1 << 13;
}
-output_pixel(&dest[0], av_clip_uintp2(R_B + Y1, 30) >> 14);
-output_pixel(&dest[1], av_clip_uintp2( G + Y1, 30) >> 14);
-output_pixel(&dest[2], av_clip_uintp2(B_R + Y1, 30) >> 14);
+output_pixel(&dest[0], av_clip_uintp2(av_sat_add32(R_B, Y1), 30) >>
14);
+output_pixel(&dest[1], av_clip_uintp2(av_sat_add32( G, Y1), 30) >>
14);
+output_pixel(&dest[2], av_clip_uintp2(av_sat_add32(B_R, Y1), 30) >>
14);
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(R_B + Y2, 30) >> 14);
-output_pixel(&dest[5], av_clip_uintp2( G + Y2, 30) >> 14);
-output_pixel(&dest[6], av_clip_uintp2(B_R + Y2, 30) >> 14);
+output_pixel(&dest[4], av_clip_uintp2(av_sat_add32(R_B, Y2), 30)
>> 14);
+output_pixel(&dest[5], av_clip_uintp2(av_sat_add32( G, Y2), 30)
>> 14);
+output_pixel(&dest[6], av_clip_uintp2(av_sat_add32(B_R, Y2), 30)
>> 14);
output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
dest += 8;
} else {
-output_pixel(&dest[3], av_clip_uintp2(R_B + Y2, 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2( G + Y2, 30) >> 14);
-output_pixel(&dest[5], av_clip_uintp2(B_R + Y2, 30) >> 14);
+output_pixel(&dest[3], av_clip_uintp2(av_sat_add32(R_B, Y2), 30)
>> 14);
+output_pixel(&dest[4], av_clip_uintp2(av_sat_add32( G, Y2), 30)
>> 14);
+output_pixel(&dest[5], av_clip_uintp2(av_sat_add32(B_R, Y2), 30)
>> 14);
dest += 6;
}
}
@@ -1232,20 +1232,20 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t
*buf0,
G = V * c->yuv2rgb_v2g_coeff + U * c->yuv2rgb_u2g_coeff;
B =U * c->yuv2rgb_u2b_coeff;
-output_pixel(&dest[0], av_clip_uintp2(R_B + Y1, 30) >> 14);
-output_pixel(&dest[1], av_clip_uintp2( G + Y1, 30) >> 14);
-output_pixel(&dest[2], av_clip_uintp2(B_R + Y1, 30) >> 14);
+output_pixel(&dest[0], av_clip_uintp2(av_sat_add32(R_B, Y1), 30)
>> 14);
+output_pixel(&dest[1], av_clip_uintp2(av_sat_add32( G, Y1), 30)
>> 14);
+output_pixel(&dest[2], av_clip_uintp2(av_sat_add32(B_R, Y1), 30)
>> 14);
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(R_B + Y2, 30) >> 14);
-output_pixel(&dest[5], av_clip_uintp2( G + Y2, 30) >> 14);
-output_pixel(&dest[6], av_clip_uintp2(B_
Re: [FFmpeg-devel] [PATCH 10/12] avcodec: add MediaCodec encoder
mån 2022-10-24 klockan 11:16 +0800 skrev Zhao Zhili:
>
> +typedef struct MediaCodecEncContext {
> + AVClass *avclass;
> + FFAMediaCodec *codec;
> + int use_ndk_codec;
> + FFANativeWindow *window;
> +
> + int fps;
> + int width;
> + int height;
> +
> + uint8_t *extradata;
> + int extradata_size;
Why not extradata in AVCodecContext?
Some tests would be nice
/Tomas
___
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo: Don't initialize H264Chroma ctx unnecessarily
Andreas Rheinhardt:
> It is only used by the decoders' lowres code, so only initialize
> it for decoders.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> configure | 4 ++--
> libavcodec/mpegvideo.c | 1 -
> libavcodec/mpegvideo_dec.c | 3 +++
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index eefd103414..dd207769a2 100755
> --- a/configure
> +++ b/configure
> @@ -2754,8 +2754,8 @@ me_cmp_select="idctdsp"
> mpeg_er_select="error_resilience"
> mpegaudio_select="mpegaudiodsp mpegaudioheader"
> mpegaudiodsp_select="dct"
> -mpegvideo_select="blockdsp h264chroma hpeldsp idctdsp videodsp"
> -mpegvideodec_select="mpegvideo mpeg_er"
> +mpegvideo_select="blockdsp hpeldsp idctdsp videodsp"
> +mpegvideodec_select="h264chroma mpegvideo mpeg_er"
> mpegvideoenc_select="aandcttables fdctdsp me_cmp mpegvideo pixblockdsp
> qpeldsp"
> msmpeg4dec_select="h263_decoder"
> msmpeg4enc_select="h263_encoder"
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index c436dc8001..697438fa6f 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -275,7 +275,6 @@ static void gray8(uint8_t *dst, const uint8_t *src,
> ptrdiff_t linesize, int h)
> static av_cold int dct_init(MpegEncContext *s)
> {
> ff_blockdsp_init(&s->bdsp);
> -ff_h264chroma_init(&s->h264chroma, 8); //for lowres
> ff_hpeldsp_init(&s->hdsp, s->avctx->flags);
> ff_videodsp_init(&s->vdsp, s->avctx->bits_per_raw_sample);
>
> diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
> index c2d6d8bdd7..12c7144ffb 100644
> --- a/libavcodec/mpegvideo_dec.c
> +++ b/libavcodec/mpegvideo_dec.c
> @@ -51,6 +51,8 @@ void ff_mpv_decode_init(MpegEncContext *s, AVCodecContext
> *avctx)
>
> /* convert fourcc to upper case */
> s->codec_tag = ff_toupper4(avctx->codec_tag);
> +
> +ff_h264chroma_init(&s->h264chroma, 8); //for lowres
> }
>
> int ff_mpeg_update_thread_context(AVCodecContext *dst,
> @@ -83,6 +85,7 @@ int ff_mpeg_update_thread_context(AVCodecContext *dst,
> memset(s, 0, sizeof(*s));
> s->avctx = dst;
> s->private_ctx = private_ctx;
> +memcpy(&s->h264chroma, &s1->h264chroma,
> sizeof(s->h264chroma));
> return err;
> }
> }
Will apply the first two patches of this patchset tonight.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 10/12] avcodec: add MediaCodec encoder
> On Oct 27, 2022, at 05:17, Tomas Härdin wrote:
>
> mån 2022-10-24 klockan 11:16 +0800 skrev Zhao Zhili:
>>
>> +typedef struct MediaCodecEncContext {
>> +AVClass *avclass;
>> +FFAMediaCodec *codec;
>> +int use_ndk_codec;
>> +FFANativeWindow *window;
>> +
>> +int fps;
>> +int width;
>> +int height;
>> +
>> +uint8_t *extradata;
>> +int extradata_size;
>
> Why not extradata in AVCodecContext?
The extradata (BUFFER_FLAG_CODEC_CONFIG) is popped after codec
init, I’m not sure if it’s OK to touch AVCodecContext->extradata
after code init.
Secondly, it isn’t specified in Android doc, but better be safe
to handle the case of BUFFER_FLAG_CODEC_CONFIG show up multiple
times.
So BUFFER_FLAG_CODEC_CONFIG is handled as in-band data, without
touch AVCodecContext->extradata too late or multiple times. Did
I overthinking or misunderstood something?
>
> Some tests would be nice
Did you mean fate test or manual test?
It’s an external codec wrapper, so maybe not in fate.
For NDK MediaCodec wrapper, good news is we can test it with ffmpeg
cmd now. For Java wrapper, it was tested by changing fftool/ffmepg
into a lib: ugly but simple.
https://github.com/quink-black/ffmpeg-ci/tree/master/android
Any suggestion is welcome.
>
> /Tomas
>
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/eatgq: prevent out of bounds memory access and endless loop
On Wed, Oct 26, 2022 at 01:41:57PM +0200, Andreas Rheinhardt wrote:
> Peter Ross:
> > ---
> > libavcodec/eatgq.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
> > index 89e9f20880..fdda8286ef 100644
> > --- a/libavcodec/eatgq.c
> > +++ b/libavcodec/eatgq.c
> > @@ -56,7 +56,7 @@ static av_cold int tgq_decode_init(AVCodecContext *avctx)
> > return 0;
> > }
> >
> > -static void tgq_decode_block(TgqContext *s, int16_t block[64],
> > GetBitContext *gb)
> > +static int tgq_decode_block(TgqContext *s, int16_t block[64],
> > GetBitContext *gb)
> > {
> > const uint8_t *scantable = ff_zigzag_direct;
> > int i, j, value;
> > @@ -73,7 +73,9 @@ static void tgq_decode_block(TgqContext *s, int16_t
> > block[64], GetBitContext *gb
> > case 1:
> > skip_bits(gb, 2);
> > value = get_bits(gb, 6);
> > -for (j = 0; j < value; j++)
> > +if (!value)
> > +return AVERROR_INVALIDDATA;
> > +for (j = 0; j < value && i < 64; j++)
> > block[scantable[i++]] = 0;
> > break;
> > case 6:
> > @@ -100,6 +102,7 @@ static void tgq_decode_block(TgqContext *s, int16_t
> > block[64], GetBitContext *gb
> > }
> > }
> > block[0] += 128 << 4;
> > +return 0;
> > }
> >
> > static void tgq_idct_put_mb(TgqContext *s, int16_t (*block)[64], AVFrame
> > *frame,
> > @@ -161,7 +164,8 @@ static int tgq_decode_mb(TgqContext *s, GetByteContext
> > *gbyte,
> > return ret;
> >
> > for (i = 0; i < 6; i++)
> > -tgq_decode_block(s, s->block[i], &gb);
> > +if ((ret = tgq_decode_block(s, s->block[i], &gb)) < 0)
> > +return ret;
> > tgq_idct_put_mb(s, s->block, frame, mb_x, mb_y);
> > bytestream2_skip(gbyte, mode);
> > } else {
> >
> >
>
> The '4' case can also overread. But actually I don't like the idea of
> adding further checks into the main loop; mind if I send an alternative
> solution?
please go for it.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
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".
