[FFmpeg-devel] [PATCH] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header
These will be used by HLS demuxer in case of SAMPLE-AES decryption.
Signed-off-by: Nachiket Tarate
---
libavcodec/adts_header.c | 1 +
libavcodec/adts_header.h | 14 ++
libavcodec/adts_parser.c | 28
3 files changed, 43 insertions(+)
diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
index 0889820f8a..e4454529c4 100644
--- a/libavcodec/adts_header.c
+++ b/libavcodec/adts_header.c
@@ -66,6 +66,7 @@ int ff_adts_header_parse(GetBitContext *gbc,
AACADTSHeaderInfo *hdr)
hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
hdr->samples= (rdb + 1) * 1024;
hdr->bit_rate = size * 8 * hdr->sample_rate / hdr->samples;
+hdr->frame_length = size;
return size;
}
diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
index f615f6a9f9..9ecd67fb5b 100644
--- a/libavcodec/adts_header.h
+++ b/libavcodec/adts_header.h
@@ -34,6 +34,7 @@ typedef struct AACADTSHeaderInfo {
uint8_t sampling_index;
uint8_t chan_config;
uint8_t num_aac_frames;
+uint32_t frame_length;
} AACADTSHeaderInfo;
/**
@@ -47,4 +48,17 @@ typedef struct AACADTSHeaderInfo {
*/
int ff_adts_header_parse(GetBitContext *gbc, AACADTSHeaderInfo *hdr);
+/**
+ * Parse the ADTS frame header contained in the buffer, which is
+ * the first 54 bits.
+ * @param[in] buf Pointer to buffer containing the first 54 bits of the
frame.
+ * @param[in] size Size of buffer containing the first 54 bits of the frame.
+ * @param[out] phdr Pointer to pointer to struct AACADTSHeaderInfo for which
+ * memory is allocated and header info is written into it.
+ * @return Returns 0 on success, -1 if there is a sync word mismatch,
+ * -2 if the version element is invalid, -3 if the sample rate
+ * element is invalid, or -4 if the bit rate element is invalid.
+ */
+int avpriv_adts_header_parse(AACADTSHeaderInfo **phdr, const uint8_t *buf,
size_t size);
+
#endif /* AVCODEC_ADTS_HEADER_H */
diff --git a/libavcodec/adts_parser.c b/libavcodec/adts_parser.c
index 5c9f8ff6f2..7df714e227 100644
--- a/libavcodec/adts_parser.c
+++ b/libavcodec/adts_parser.c
@@ -42,3 +42,31 @@ int av_adts_header_parse(const uint8_t *buf, uint32_t
*samples, uint8_t *frames)
return AVERROR(ENOSYS);
#endif
}
+
+int avpriv_adts_header_parse(AACADTSHeaderInfo **phdr, const uint8_t *buf,
size_t size)
+{
+#if CONFIG_ADTS_HEADER
+int ret = 0;
+GetBitContext gb;
+
+if (size < AV_AAC_ADTS_HEADER_SIZE)
+return AVERROR_INVALIDDATA;
+
+if (!*phdr)
+*phdr = av_mallocz(sizeof(AACADTSHeaderInfo));
+if (!*phdr)
+return AVERROR(ENOMEM);
+
+ret = init_get_bits8(, buf, AV_AAC_ADTS_HEADER_SIZE);
+if (ret < 0)
+return ret;
+
+ret = ff_adts_header_parse(, *phdr);
+if (ret < 0)
+return ret;
+
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
--
2.17.1
___
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/pthread_frame: Fix checks and cleanup during init
On Fri, Feb 12, 2021 at 12:06 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, ff_frame_thread_init had several bugs:
> 1. It did not check whether the condition and mutexes
>could be successfully created.
> 2. In case an error happened when setting up the child threads,
>ff_frame_thread_free is called to clean up all threads set up so far,
>including the current one. But a half-allocated context needs
>special handling which ff_frame_thread_frame_free doesn't provide.
>Notably, if allocating the AVCodecInternal, the codec's private data
>or setting the options fails, the codec's close function will be
>called (if there is one); it will also be called if the codec's init
>function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP
>is set. This is not supported by all codecs; in ticket #9099 (which
>this commit fixes) it led to a crash.
>
> This commit fixes both of these issues. Given that it is not documented
> to be save to destroy mutexes/conditions that have only been zeroed, but
> not initialized (or whose initialization has failed), one either needs to
> duplicate the code to destroy them in ff_frame_thread_init or record
> which mutexes/condition variables need to be destroyed and check for this
> in ff_frame_thread_free. This patch uses the former way for the
> mutexes/condition variables, but lets ff_frame_thread_free take
> over for all threads whose AVCodecContext could be allocated.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> After several unsuccessful attempts to make pthread_cond/mutex_init
> fail, I looked at the source [1] and it seems that the glibc versions of
> these functions can't fail at all (unless one sets nondefault attributes).
> Therefore this part of the code is untested, unfortunately.
>
> (Removing all pthread_mutex/cond_destroy calls does not result in any
> complaints from Valgrind/ASAN either; seems the glibc implementation
> doesn't need allocations.)
>
> [1]: https://github.com/bminor/glibc/blob/master/nptl/pthread_cond_init.c
> https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c
>
> libavcodec/pthread_frame.c | 175 ++---
> 1 file changed, 106 insertions(+), 69 deletions(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 4429a4d59c..a10d8c1266 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -64,6 +64,12 @@ enum {
> STATE_SETUP_FINISHED,
> };
>
> +enum {
> +UNINITIALIZED, ///< Thread has not been created, AVCodec->close
> mustn't be called
> +NEEDS_CLOSE,///< AVCodec->close needs to be called
> +INITIALIZED,///< Thread has been properly set up
> +};
> +
> /**
> * Context used by codec threads and stored in their AVCodecInternal
> thread_ctx.
> */
> @@ -698,27 +704,40 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
> thread_count)
>
> for (i = 0; i < thread_count; i++) {
> PerThreadContext *p = >threads[i];
> +AVCodecContext *ctx = p->avctx;
>
> -pthread_mutex_lock(>mutex);
> -p->die = 1;
> -pthread_cond_signal(>input_cond);
> -pthread_mutex_unlock(>mutex);
> -
> -if (p->thread_init)
> -pthread_join(p->thread, NULL);
> -p->thread_init=0;
> +if (ctx->internal) {
> +if (p->thread_init == INITIALIZED) {
> +pthread_mutex_lock(>mutex);
> +p->die = 1;
> +pthread_cond_signal(>input_cond);
> +pthread_mutex_unlock(>mutex);
>
> -if (codec->close && p->avctx)
> -codec->close(p->avctx);
> +pthread_join(p->thread, NULL);
>
This will signal exit for one thread, then wait for it completely. All
operation are serilized.
How about we split it into two loops. one loop signal all threads for exit.
One loop to join all thread.
When we join a thread, other threads can work on exiting.
> +}
> +if (codec->close && p->thread_init != UNINITIALIZED)
> +codec->close(ctx);
>
> #if FF_API_THREAD_SAFE_CALLBACKS
> -release_delayed_buffers(p);
> +release_delayed_buffers(p);
> +for (int j = 0; j < p->released_buffers_allocated; j++)
> +av_frame_free(>released_buffers[j]);
> +av_freep(>released_buffers);
> #endif
> -av_frame_free(>frame);
> -}
> +if (ctx->priv_data) {
> +if (codec->priv_class)
> +av_opt_free(ctx->priv_data);
> +av_freep(>priv_data);
> +}
>
> -for (i = 0; i < thread_count; i++) {
> -PerThreadContext *p = >threads[i];
> +av_freep(>slice_offset);
> +
> +av_buffer_unref(>internal->pool);
> +av_freep(>internal);
> +av_buffer_unref(>hw_frames_ctx);
> +}
> +
> +av_frame_free(>frame);
>
>
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: check that the local context list exists before dereferencing it
On Fri, Feb 12, 2021 at 12:19 AM James Almer wrote: > > >>> Signed-off-by: James Almer > >>> --- > >>> Maybe ff_frame_thread_free() should not call AVCodec->close() for > thread > >> contexts > >>> where AVCodec->init() failed and FF_CODEC_CAP_INIT_CLEANUP is not set? > >>> > >> > >> Fixing this has been on my to-do list. (The situation is even worse than > >> you describe it: It is possible that AVCodec->close is called on an > >> AVCodecContext whose private_data couldn't be allocated.) > >> > > > > So how should proceed? Apply this patch and fix other issues after it? > > Applied this patch. The other unchecked allocs are handled in another > patch, and the ff_frame_thread_init() issues should be fixed by Andreas' > patch. > , you are so efficient. > ___ > 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/hevcdec: add some missing allocation checks
On Thu, Feb 11, 2021 at 11:49 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/hevcdec.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 898dac8cbb..325c7850e6 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -515,6 +515,9 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps,
> s->sao_pixel_buffer_v[c_idx] =
> av_malloc((h * 2 * sps->ctb_width) <<
>sps->pixel_shift);
> +if (!s->sao_pixel_buffer_h[c_idx] ||
> +!s->sao_pixel_buffer_v[c_idx])
> +goto fail;
> }
> }
>
> @@ -525,6 +528,10 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps,
>
> fail:
> pic_arrays_free(s);
> +for (i = 0; i < 3; i++) {
> +av_freep(>sao_pixel_buffer_h[i]);
> +av_freep(>sao_pixel_buffer_v[i]);
> +}
>
We have the same code after ff_videodsp_init and the same code in
hevc_decode_free.
Could we define a function like free_sao_pixel_buffers for it?
> s->ps.sps = NULL;
> return ret;
> }
> @@ -2624,13 +2631,19 @@ static int hls_slice_data_wpp(HEVCContext *s,
> const H2645NAL *nal)
>
> ff_alloc_entries(s->avctx, s->sh.num_entry_point_offsets + 1);
>
> -if (!s->sList[1]) {
> -for (i = 1; i < s->threads_number; i++) {
> -s->sList[i] = av_malloc(sizeof(HEVCContext));
> -memcpy(s->sList[i], s, sizeof(HEVCContext));
> -s->HEVClcList[i] = av_mallocz(sizeof(HEVCLocalContext));
> -s->sList[i]->HEVClc = s->HEVClcList[i];
> +for (i = 1; i < s->threads_number; i++) {
> +if (s->sList[i] && s->HEVClcList[i])
> +continue;
> +av_freep(>sList[i]);
> +av_freep(>HEVClcList[i]);
> +s->sList[i] = av_malloc(sizeof(HEVCContext));
> +s->HEVClcList[i] = av_mallocz(sizeof(HEVCLocalContext));
> +if (!s->sList[i] || !s->HEVClcList[i]) {
> +res = AVERROR_INVALIDDATA;
>
AVERROR(ENOMEM) ?
> +goto error;
> }
> +memcpy(s->sList[i], s, sizeof(HEVCContext));
> +s->sList[i]->HEVClc = s->HEVClcList[i];
> }
>
> offset = (lc->gb.index >> 3);
> --
> 2.30.0
>
> ___
> 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]lavc/pnm: Support decoding gray float pbm images.
On Fri, Feb 12, 2021 at 12:21 AM Carl Eugen Hoyos wrote: > Am Fr., 12. Feb. 2021 um 00:18 Uhr schrieb Paul B Mahol >: > > > > This is variant of PFM images, PBM image format is only fixed point gray. > > Should I change the commit message or the patch? > commit message > > Thank you, Carl Eugen > ___ > 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]lavc/pnm: Support decoding gray float pbm images.
Am Fr., 12. Feb. 2021 um 00:18 Uhr schrieb Paul B Mahol : > > This is variant of PFM images, PBM image format is only fixed point gray. Should I change the commit message or the patch? Thank you, Carl Eugen ___ 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]lavc/pnm: Support decoding gray float pbm images.
This is variant of PFM images, PBM image format is only fixed point gray. ___ 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]lavc/pnm: Support decoding gray float pbm images.
Hi!
Attached patch allows to decode gray float pbm images, sample by ami_stuff.
Please comment, Carl Eugen
From 71283c6de2eb5ef45382390d695845abb500b316 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 11 Feb 2021 23:37:06 +0100
Subject: [PATCH] lavc/pnm: Allow decoding of gray float pbm images.
---
libavcodec/pnm.c| 5 -
libavcodec/pnmdec.c | 24
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index aad23c7ae2..5af04965e7 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -72,6 +72,7 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
s->bytestream[0] != 'P' ||
(s->bytestream[1] < '1' ||
s->bytestream[1] > '7' &&
+ s->bytestream[1] != 'f' &&
s->bytestream[1] != 'F')) {
s->bytestream += s->bytestream_end > s->bytestream;
s->bytestream += s->bytestream_end > s->bytestream;
@@ -82,6 +83,8 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
if (buf1[1] == 'F') {
avctx->pix_fmt = AV_PIX_FMT_GBRPF32;
+} else if (buf1[1] == 'f') {
+avctx->pix_fmt = AV_PIX_FMT_GRAYF32;
} else if (s->type==1 || s->type==4) {
avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
} else if (s->type==2 || s->type==5) {
@@ -177,7 +180,7 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
if (ret < 0)
return ret;
-if (avctx->pix_fmt == AV_PIX_FMT_GBRPF32) {
+if (avctx->pix_fmt == AV_PIX_FMT_GBRPF32 || avctx->pix_fmt == AV_PIX_FMT_GRAYF32) {
pnm_get(s, buf1, sizeof(buf1));
if (av_sscanf(buf1, "%f", >scale) != 1 || s->scale == 0.0 || !isfinite(s->scale)) {
av_log(avctx, AV_LOG_ERROR, "Invalid scale.\n");
diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index 9add5cfc84..4d5ce0bcb5 100644
--- a/libavcodec/pnmdec.c
+++ b/libavcodec/pnmdec.c
@@ -297,6 +297,30 @@ static int pnm_decode_frame(AVCodecContext *avctx, void *data,
}
}
break;
+case AV_PIX_FMT_GRAYF32:
+if (avctx->width * avctx->height * 4 > s->bytestream_end - s->bytestream)
+return AVERROR_INVALIDDATA;
+scale = 1.f / s->scale;
+if (s->endian) {
+float *g = (float *)p->data[0];
+for (int i = 0; i < avctx->height; i++) {
+for (int j = 0; j < avctx->width; j++) {
+g[j] = av_int2float(AV_RL32(s->bytestream)) * scale;
+s->bytestream += 4;
+}
+g += p->linesize[0] / 4;
+}
+} else {
+float *g = (float *)p->data[0];
+for (int i = 0; i < avctx->height; i++) {
+for (int j = 0; j < avctx->width; j++) {
+g[j] = av_int2float(AV_RB32(s->bytestream)) * scale;
+s->bytestream += 4;
+}
+g += p->linesize[0] / 4;
+}
+}
+break;
}
*got_frame = 1;
--
2.29.2
___
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/dpx: check for possible buffer overreads
Signed-off-by: Paul B Mahol --- libavcodec/dpx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 5372e3d586..68a2762017 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -606,6 +606,9 @@ static int decode_frame(AVCodecContext *avctx, ff_set_sar(avctx, avctx->sample_aspect_ratio); +if (buf_size - offset < (((uint64_t)elements * avctx->width * avctx->height * bits_per_color) >> 3)) +return AVERROR_INVALIDDATA; + if ((ret = ff_get_buffer(avctx, p, 0)) < 0) return ret; -- 2.17.1 ___ 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 3/3] mmaldec with plain yuv420p without copy
On Thu, Feb 11, 2021 at 10:34:11PM +, Mark Thompson wrote:
> On 11/02/2021 21:48, Lluís Batlle i Rossel wrote:
> > From: Lluís Batlle i Rossell
> >
> > +
>
> Random whitespace change?
likely. I can fix that.
>
> > if (!ref)
> > return AVERROR(ENOMEM);
> > @@ -140,8 +141,19 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef
> > *pool,
> > atomic_fetch_add_explicit(>pool->refcount, 1,
> > memory_order_relaxed);
> > mmal_buffer_header_acquire(buffer);
> > -frame->format = AV_PIX_FMT_MMAL;
> > -frame->data[3] = (uint8_t *)ref->buffer;
> > +frame->format = avctx->pix_fmt;
> > +
> > +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P) {
> > +int w = FFALIGN(avctx->width, 32);
> > +int h = FFALIGN(avctx->height, 16);
> > +
> > +av_image_fill_arrays(frame->data, frame->linesize,
> > +buffer->data + buffer->type->video.offset[0],
> > +avctx->pix_fmt, w, h, 1);
> > +} else {
> > +frame->data[3] = (uint8_t *)ref->buffer;
> > +}
> > +
> > return 0;
> > }
> > @@ -633,30 +645,14 @@ static int ffmal_copy_frame(AVCodecContext *avctx,
> > AVFrame *frame,
>
> The function name is very misleading after this change.
Definitely. I can fix that.
> > +if ((ret = ffmmal_set_ref(avctx, frame, ctx->pool_out, buffer)) < 0)
> > +goto done;
> > frame->pts = buffer->pts == MMAL_TIME_UNKNOWN ? AV_NOPTS_VALUE :
> > buffer->pts;
> > #if FF_API_PKT_PTS
> >
>
> What happens if the user holds on to multiple of the output frames, perhaps
> because they are being queued into some other operation? The number of
> buffers appears fixed, so what happens if they run out?
I don't know. I don't know how to trigger that situation. That would
affect also the "mmal" pixfmt, already present.
--
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key 7CBD1DA5 - https://emailselfdefense.fsf.org/
___
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/3] libavcodec/mmaldec: enable MJPEG decoding
On Thu, Feb 11, 2021 at 10:19:01PM +, Mark Thompson wrote: > On 11/02/2021 21:48, Lluís Batlle i Rossel wrote: > > From: Lluís Batlle i Rossell > > > > From: Cosmin Gorgovan > > > > --- > > configure | 1 + > > libavcodec/allcodecs.c | 1 + > > libavcodec/mmaldec.c | 4 > > 3 files changed, 6 insertions(+) > > This seems reasonable. But, what does it do with non-4:2:0 JPEGs? Does it > fail; convert them to 4:2:0 (like downsampling 4:2:2); have a different > non-yuv420p output format? It works fine here in the Pi: ffprobe says for a file I created: Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown/unknown), 640x480, 30 fps, 30 tbr, 1k tbn, 1k tbc (default) And I can decode it fine with mjpeg_mmal. I tried to do the same with "-hwaccel vaapi" in intel, and the mjpeg decoder failed for me. $ ffmpeg -hwaccel vaapi -i mjpeg422.mkv -y -f null - [AVHWFramesContext @ 0x192ec40] Failed to read image from surface 0x405: 20 (the requested function is not implemented). while the command above works with the regular yuvj420p mjpeg input. -- (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) PGP key 7CBD1DA5 - https://emailselfdefense.fsf.org/ ___ 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/3] avformat/electronicarts: Clear partial_packet on error
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".
[FFmpeg-devel] [PATCH 2/3] avformat/jacosubdec: Use 64bit intermediate for start/end timestamp shift
Fixes: signed integer overflow: -1957694447 + -1620425806 cannot be represented in type 'int' Fixes: 30207/clusterfuzz-testcase-minimized-ffmpeg_dem_JACOSUB_fuzzer-5050791771635712 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/jacosubdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c index 14221b166c..e1adbc1735 100644 --- a/libavformat/jacosubdec.c +++ b/libavformat/jacosubdec.c @@ -125,8 +125,8 @@ static const char *read_ts(JACOsubContext *jacosub, const char *buf, return NULL; shift_and_ret: -ts_start64 = (ts_start + jacosub->shift) * 100LL / jacosub->timeres; -ts_end64= (ts_end + jacosub->shift) * 100LL / jacosub->timeres; +ts_start64 = (ts_start + (int64_t)jacosub->shift) * 100LL / jacosub->timeres; +ts_end64= (ts_end + (int64_t)jacosub->shift) * 100LL / jacosub->timeres; *start= ts_start64; *duration = ts_end64 - ts_start64; return buf + len; -- 2.17.1 ___ 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 3/3] avformat/flvdec: Check array entry number
Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type
'int'
Fixes:
30209/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5724831658147840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/flvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 30d1fcf4b7..138a96ec61 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -871,6 +871,8 @@ static int amf_skip_tag(AVIOContext *pb, AMFDataType type,
int depth)
parse_name = 0;
case AMF_DATA_TYPE_MIXEDARRAY:
nb = avio_rb32(pb);
+if (nb < 0)
+return AVERROR_INVALIDDATA;
case AMF_DATA_TYPE_OBJECT:
while(!pb->eof_reached && (nb-- > 0 || type != AMF_DATA_TYPE_ARRAY)) {
if (parse_name) {
--
2.17.1
___
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 1/3] avformat/electronicarts: Clear partial_packet on error
Fixes: Infinite loop
Fixes:
30165/clusterfuzz-testcase-minimized-ffmpeg_dem_EA_fuzzer-6224642371092480
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/electronicarts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index a98a8d604e..7c0d6a2e37 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -728,6 +728,7 @@ get_video_packet:
ret = av_get_packet(pb, pkt, chunk_size);
if (ret < 0) {
packet_read = 1;
+partial_packet = 0;
break;
}
partial_packet = chunk_type == MVIh_TAG;
--
2.17.1
___
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 3/3] mmaldec with plain yuv420p without copy
On 11/02/2021 21:48, Lluís Batlle i Rossel wrote:
From: Lluís Batlle i Rossell
---
libavcodec/mmaldec.c | 48
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 4dfaacbb41..097b990f92 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -119,10 +119,11 @@ static void ffmmal_release_frame(void *opaque, uint8_t
*data)
// Setup frame with a new reference to buffer. The buffer must have been
// allocated from the given pool.
-static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
- MMAL_BUFFER_HEADER_T *buffer)
+static int ffmmal_set_ref(AVCodecContext *avctx, AVFrame *frame,
+FFPoolRef *pool, MMAL_BUFFER_HEADER_T *buffer)
{
FFBufferRef *ref = av_mallocz(sizeof(*ref));
+
Random whitespace change?
if (!ref)
return AVERROR(ENOMEM);
@@ -140,8 +141,19 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
atomic_fetch_add_explicit(>pool->refcount, 1, memory_order_relaxed);
mmal_buffer_header_acquire(buffer);
-frame->format = AV_PIX_FMT_MMAL;
-frame->data[3] = (uint8_t *)ref->buffer;
+frame->format = avctx->pix_fmt;
+
+if (avctx->pix_fmt == AV_PIX_FMT_YUV420P) {
+int w = FFALIGN(avctx->width, 32);
+int h = FFALIGN(avctx->height, 16);
+
+av_image_fill_arrays(frame->data, frame->linesize,
+buffer->data + buffer->type->video.offset[0],
+avctx->pix_fmt, w, h, 1);
+} else {
+frame->data[3] = (uint8_t *)ref->buffer;
+}
+
return 0;
}
@@ -633,30 +645,14 @@ static int ffmal_copy_frame(AVCodecContext *avctx, AVFrame *frame,
The function name is very misleading after this change.
frame->interlaced_frame = ctx->interlaced_frame;
frame->top_field_first = ctx->top_field_first;
-if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
-if (!ctx->pool_out)
-return AVERROR_UNKNOWN; // format change code failed with OOM
previously
-
-if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
-goto done;
-
-if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
-goto done;
-} else {
-int w = FFALIGN(avctx->width, 32);
-int h = FFALIGN(avctx->height, 16);
-uint8_t *src[4];
-int linesize[4];
+if (!ctx->pool_out)
+return AVERROR_UNKNOWN; // format change code failed with OOM
previously
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
-goto done;
+if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
+goto done;
-av_image_fill_arrays(src, linesize,
- buffer->data + buffer->type->video.offset[0],
- avctx->pix_fmt, w, h, 1);
-av_image_copy(frame->data, frame->linesize, src, linesize,
- avctx->pix_fmt, avctx->width, avctx->height);
-}
+if ((ret = ffmmal_set_ref(avctx, frame, ctx->pool_out, buffer)) < 0)
+goto done;
frame->pts = buffer->pts == MMAL_TIME_UNKNOWN ? AV_NOPTS_VALUE : buffer->pts;
#if FF_API_PKT_PTS
What happens if the user holds on to multiple of the output frames, perhaps
because they are being queued into some other operation? The number of buffers
appears fixed, so what happens if they run out?
- Mark
___
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] libsvtav1: Add logical_processors option
On Thu, Feb 11, 2021 at 11:15 PM Mark Thompson wrote: > On 10/02/2021 23:53, Paul B Mahol wrote: > > On Wed, Feb 10, 2021 at 11:08 PM Mark Thompson wrote: > > > >> On 10/02/2021 17:16, Christopher Degawa wrote: > >>> From: Christopher Degawa > >>> > >>> Equivalent to the --lp option for SvtAv1EncApp, and is the only way > >>> to control how much cpu power svt-av1 uses for now > >>> > >>> Not using thread_count as it would be preferable to reserve that until > >>> svt-av1 properly implements a threads option > >> > >> Then what does it actually do? The description below about the number > of > >> logical threads to run sounds pretty much exactly like what the threads > >> option does. > >> > >> > > Threads option is limited to filters that do filtering by calling > > execute(), internal threading code of libavfilter. > > This would be from AVCodecContext.thread_count, not anything in > libavfilter. > > Yes, but it is same .execute thing. But I agree with rest of your views. > - Mark > ___ > 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] libsvtav1: Add logical_processors option
On 10/02/2021 23:49, Christopher Degawa wrote: Based on my limited understanding of the code, it's limiting the usage using pthread_setaffinity_np and CPU_SET on Linux to limit the process to certain CPUs, but it also has a default and max of the return of `sysconf(_SC_NPROCESSORS_ONLN)`. According to Hassene Tmar of SVT-AV1, it is a "target core count that SVT would do a best effort to achieve" and "--lp 8 might still produce 50 threads". It does not actually limit how many threads are deployed. IMO people who want to do things with processor affinity should use the flexible tools that their OS provides to do it (on Linux, that's taskset for the ffmpeg utility and sched_setaffinity() for library users). Having a specific and weird special case option is not obviously useful. (In particular, not warning that it's changing processor affinity in a tricky way is making the option a footgun - if I run two instances of ffmpeg then the intuitive thing to do would be to pass my number of cpus / 2 to each, which would give me a result much worse than passing nothing at all.) That said, if you have a general use-case where this is helpful and the documentation explains what it is doing (and warns about the bad cases) then maybe? Thanks, - Mark ___ 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/3] libavcodec/mmaldec: enable MJPEG decoding
On 11/02/2021 21:48, Lluís Batlle i Rossel wrote:
From: Lluís Batlle i Rossell
From: Cosmin Gorgovan
---
configure | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/mmaldec.c | 4
3 files changed, 6 insertions(+)
diff --git a/configure b/configure
index a76c2ec4ae..048bedb589 100755
--- a/configure
+++ b/configure
@@ -3105,6 +3105,7 @@ hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
mjpeg_cuvid_decoder_deps="cuvid"
+mjpeg_mmal_decoder_deps="mmal"
mjpeg_qsv_decoder_select="qsvdec"
mjpeg_qsv_encoder_deps="libmfx"
mjpeg_qsv_encoder_select="qsvenc"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 16ec182a52..8d1908c6d5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -187,6 +187,7 @@ extern AVCodec ff_mdec_decoder;
extern AVCodec ff_mimic_decoder;
extern AVCodec ff_mjpeg_encoder;
extern AVCodec ff_mjpeg_decoder;
+extern AVCodec ff_mjpeg_mmal_decoder;
extern AVCodec ff_mjpegb_decoder;
extern AVCodec ff_mmvideo_decoder;
extern AVCodec ff_mobiclip_decoder;
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index cb15ac072a..df14b9fc95 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -375,6 +375,9 @@ static av_cold int ffmmal_init_decoder(AVCodecContext
*avctx)
format_in = decoder->input[0]->format;
format_in->type = MMAL_ES_TYPE_VIDEO;
switch (avctx->codec_id) {
+case AV_CODEC_ID_MJPEG:
+format_in->encoding = MMAL_ENCODING_MJPEG;
+break;
case AV_CODEC_ID_MPEG2VIDEO:
format_in->encoding = MMAL_ENCODING_MP2V;
break;
@@ -851,6 +854,7 @@ static const AVOption options[]={
};
FFMMAL_DEC(h264, AV_CODEC_ID_H264)
+FFMMAL_DEC(mjpeg, AV_CODEC_ID_MJPEG)
FFMMAL_DEC(mpeg2, AV_CODEC_ID_MPEG2VIDEO)
FFMMAL_DEC(mpeg4, AV_CODEC_ID_MPEG4)
FFMMAL_DEC(vc1, AV_CODEC_ID_VC1)
This seems reasonable. But, what does it do with non-4:2:0 JPEGs? Does it
fail; convert them to 4:2:0 (like downsampling 4:2:2); have a different
non-yuv420p output format?
- Mark
___
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] libsvtav1: Add logical_processors option
On 10/02/2021 23:53, Paul B Mahol wrote: On Wed, Feb 10, 2021 at 11:08 PM Mark Thompson wrote: On 10/02/2021 17:16, Christopher Degawa wrote: From: Christopher Degawa Equivalent to the --lp option for SvtAv1EncApp, and is the only way to control how much cpu power svt-av1 uses for now Not using thread_count as it would be preferable to reserve that until svt-av1 properly implements a threads option Then what does it actually do? The description below about the number of logical threads to run sounds pretty much exactly like what the threads option does. Threads option is limited to filters that do filtering by calling execute(), internal threading code of libavfilter. This would be from AVCodecContext.thread_count, not anything in libavfilter. - Mark ___ 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/pngdec: fix possible race condition with APNG decoding
Fixes #9017
Signed-off-by: Paul B Mahol
---
libavcodec/pngdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 395b86bbe7..61642b7cbe 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -711,13 +711,13 @@ static int decode_idat_chunk(AVCodecContext *avctx,
PNGDecContext *s,
s->bpp += byte_depth;
}
-if ((ret = ff_thread_get_buffer(avctx, >picture,
AV_GET_BUFFER_FLAG_REF)) < 0)
-return ret;
if (avctx->codec_id == AV_CODEC_ID_APNG && s->last_dispose_op !=
APNG_DISPOSE_OP_PREVIOUS) {
ff_thread_release_buffer(avctx, >previous_picture);
if ((ret = ff_thread_get_buffer(avctx, >previous_picture,
AV_GET_BUFFER_FLAG_REF)) < 0)
return ret;
}
+if ((ret = ff_thread_get_buffer(avctx, >picture,
AV_GET_BUFFER_FLAG_REF)) < 0)
+return ret;
p->pict_type= AV_PICTURE_TYPE_I;
p->key_frame= 1;
p->interlaced_frame = !!s->interlace_type;
--
2.17.1
___
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/4] avcodec/pnm_parser: Check av_image_get_buffer_size() for failure
On Thu, Feb 11, 2021 at 10:27:58PM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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] [PATCH 3/3] mmaldec with plain yuv420p without copy
From: Lluís Batlle i Rossell
---
libavcodec/mmaldec.c | 48
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 4dfaacbb41..097b990f92 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -119,10 +119,11 @@ static void ffmmal_release_frame(void *opaque, uint8_t
*data)
// Setup frame with a new reference to buffer. The buffer must have been
// allocated from the given pool.
-static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
- MMAL_BUFFER_HEADER_T *buffer)
+static int ffmmal_set_ref(AVCodecContext *avctx, AVFrame *frame,
+FFPoolRef *pool, MMAL_BUFFER_HEADER_T *buffer)
{
FFBufferRef *ref = av_mallocz(sizeof(*ref));
+
if (!ref)
return AVERROR(ENOMEM);
@@ -140,8 +141,19 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
atomic_fetch_add_explicit(>pool->refcount, 1, memory_order_relaxed);
mmal_buffer_header_acquire(buffer);
-frame->format = AV_PIX_FMT_MMAL;
-frame->data[3] = (uint8_t *)ref->buffer;
+frame->format = avctx->pix_fmt;
+
+if (avctx->pix_fmt == AV_PIX_FMT_YUV420P) {
+int w = FFALIGN(avctx->width, 32);
+int h = FFALIGN(avctx->height, 16);
+
+av_image_fill_arrays(frame->data, frame->linesize,
+buffer->data + buffer->type->video.offset[0],
+avctx->pix_fmt, w, h, 1);
+} else {
+frame->data[3] = (uint8_t *)ref->buffer;
+}
+
return 0;
}
@@ -633,30 +645,14 @@ static int ffmal_copy_frame(AVCodecContext *avctx,
AVFrame *frame,
frame->interlaced_frame = ctx->interlaced_frame;
frame->top_field_first = ctx->top_field_first;
-if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
-if (!ctx->pool_out)
-return AVERROR_UNKNOWN; // format change code failed with OOM
previously
-
-if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
-goto done;
-
-if ((ret = ffmmal_set_ref(frame, ctx->pool_out, buffer)) < 0)
-goto done;
-} else {
-int w = FFALIGN(avctx->width, 32);
-int h = FFALIGN(avctx->height, 16);
-uint8_t *src[4];
-int linesize[4];
+if (!ctx->pool_out)
+return AVERROR_UNKNOWN; // format change code failed with OOM
previously
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
-goto done;
+if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
+goto done;
-av_image_fill_arrays(src, linesize,
- buffer->data + buffer->type->video.offset[0],
- avctx->pix_fmt, w, h, 1);
-av_image_copy(frame->data, frame->linesize, src, linesize,
- avctx->pix_fmt, avctx->width, avctx->height);
-}
+if ((ret = ffmmal_set_ref(avctx, frame, ctx->pool_out, buffer)) < 0)
+goto done;
frame->pts = buffer->pts == MMAL_TIME_UNKNOWN ? AV_NOPTS_VALUE :
buffer->pts;
#if FF_API_PKT_PTS
--
2.29.2
___
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 2/3] libavcodec/mmaldec: continue after receiving EOS without having sent one
From: Lluís Batlle i Rossell
From: Cosmin Gorgovan
The previous logic in mmaldec was causing the MMAL MJPEG decoder
to stop if it received an invalid frame - which happened to be the
first frame received from a UVC camera via V4L2 in my application
---
libavcodec/mmaldec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index df14b9fc95..4dfaacbb41 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -711,9 +711,13 @@ static int ffmmal_read_frame(AVCodecContext *avctx,
AVFrame *frame, int *got_fra
goto done;
}
-ctx->eos_received |= !!(buffer->flags & MMAL_BUFFER_HEADER_FLAG_EOS);
-if (ctx->eos_received)
+int eos = !!(buffer->flags & MMAL_BUFFER_HEADER_FLAG_EOS);
+if (eos) {
+if (ctx->eos_sent) {
+ ctx->eos_received = 1;
+}
goto done;
+}
if (buffer->cmd == MMAL_EVENT_FORMAT_CHANGED) {
MMAL_COMPONENT_T *decoder = ctx->decoder;
--
2.29.2
___
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 1/3] libavcodec/mmaldec: enable MJPEG decoding
From: Lluís Batlle i Rossell
From: Cosmin Gorgovan
---
configure | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/mmaldec.c | 4
3 files changed, 6 insertions(+)
diff --git a/configure b/configure
index a76c2ec4ae..048bedb589 100755
--- a/configure
+++ b/configure
@@ -3105,6 +3105,7 @@ hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
mjpeg_cuvid_decoder_deps="cuvid"
+mjpeg_mmal_decoder_deps="mmal"
mjpeg_qsv_decoder_select="qsvdec"
mjpeg_qsv_encoder_deps="libmfx"
mjpeg_qsv_encoder_select="qsvenc"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 16ec182a52..8d1908c6d5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -187,6 +187,7 @@ extern AVCodec ff_mdec_decoder;
extern AVCodec ff_mimic_decoder;
extern AVCodec ff_mjpeg_encoder;
extern AVCodec ff_mjpeg_decoder;
+extern AVCodec ff_mjpeg_mmal_decoder;
extern AVCodec ff_mjpegb_decoder;
extern AVCodec ff_mmvideo_decoder;
extern AVCodec ff_mobiclip_decoder;
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index cb15ac072a..df14b9fc95 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -375,6 +375,9 @@ static av_cold int ffmmal_init_decoder(AVCodecContext
*avctx)
format_in = decoder->input[0]->format;
format_in->type = MMAL_ES_TYPE_VIDEO;
switch (avctx->codec_id) {
+case AV_CODEC_ID_MJPEG:
+format_in->encoding = MMAL_ENCODING_MJPEG;
+break;
case AV_CODEC_ID_MPEG2VIDEO:
format_in->encoding = MMAL_ENCODING_MP2V;
break;
@@ -851,6 +854,7 @@ static const AVOption options[]={
};
FFMMAL_DEC(h264, AV_CODEC_ID_H264)
+FFMMAL_DEC(mjpeg, AV_CODEC_ID_MJPEG)
FFMMAL_DEC(mpeg2, AV_CODEC_ID_MPEG2VIDEO)
FFMMAL_DEC(mpeg4, AV_CODEC_ID_MPEG4)
FFMMAL_DEC(vc1, AV_CODEC_ID_VC1)
--
2.29.2
___
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 0/3] mjpeg_mmal and avoid a frame copy in mmaldec
From: Lluís Batlle i Rossell I needed to acquire mjpeg from a v4l2 uvc webcam in a Raspberry pi, and I saw mmaldec lacked mjpeg and also was doing an unnecessary copy. I used two patches I found in the mailing list archives to enable mjpeg mmaldec and then wrote one that avoids the copy. It works fine for me but I have not run 'fate' yet. I'm in a cross-building situation and I have yet to learn how that works. In a Raspberry Pi 1 Model B now it can 640x480 30fps mjpeg->h264_omx with 25% of cpu (as "top" shows). Before these three patches, 640x480 YUY2->h264_omx could do only 20fps and "top" showed 50% of cpu. A Raspberry Pi 2 can do easily 30fps 1280x720 mjpeg->h264_omx as well. It'd be a lot easier for me if these patches were upstream so I'm interested in the code getting in. I'm new in ffmpeg so I may have missed customary details. I also thank the help #ffmpeg-devel that made my patch (3rd) simpler than I originally thought. Cosmin Gorgovan (2): libavcodec/mmaldec: enable MJPEG decoding libavcodec/mmaldec: continue after receiving EOS without having sent one Lluís Batlle i Rossell (1): mmaldec with plain yuv420p without copy configure | 1 + libavcodec/allcodecs.c | 1 + libavcodec/mmaldec.c | 60 ++ 3 files changed, 34 insertions(+), 28 deletions(-) -- 2.29.2 ___ 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 2/4] avcodec/mv30: Check available space in decode_intra() more completly
this is hack ___ 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 4/4] avformat/r3d: Check samples before computing duration
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".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/pnm_parser: Check av_image_get_buffer_size() for failure
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".
[FFmpeg-devel] [PATCH 2/4] avcodec/mv30: Check available space in decode_intra() more completly
Fixes: Timeout (>10sec -> instantaneous) Fixes: 30147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5549246684200960 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mv30.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/mv30.c b/libavcodec/mv30.c index 7ae264e0f0..c92048a179 100644 --- a/libavcodec/mv30.c +++ b/libavcodec/mv30.c @@ -411,6 +411,8 @@ static int decode_intra(AVCodecContext *avctx, GetBitContext *gb, AVFrame *frame mgb = *gb; if (get_bits_left(gb) < s->mode_size * 8) return AVERROR_INVALIDDATA; +if (get_bits_left() < (avctx->height + 15)/16 * ((avctx->width + 15)/16) * 12) +return AVERROR_INVALIDDATA; skip_bits_long(gb, s->mode_size * 8); -- 2.17.1 ___ 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 1/4] avcodec/pnm_parser: Check av_image_get_buffer_size() for failure
Fixes: out of array access
Fixes:
30135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PBM_fuzzer-4997145650397184
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm_parser.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
index d19dbfe98c..f3be6d640c 100644
--- a/libavcodec/pnm_parser.c
+++ b/libavcodec/pnm_parser.c
@@ -109,8 +109,10 @@ retry:
if (next == END_NOT_FOUND)
pnmpc->ascii_scan = sync - pnmctx.bytestream + skip;
} else {
-next = pnmctx.bytestream - pnmctx.bytestream_start + skip
- + av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
avctx->height, 1);
+int ret = av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
avctx->height, 1);
+next = pnmctx.bytestream - pnmctx.bytestream_start + skip;
+if (ret >= 0)
+next += ret;
}
if (next != END_NOT_FOUND && pnmctx.bytestream_start != buf + skip)
next -= pc->index;
--
2.17.1
___
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 4/4] avformat/r3d: Check samples before computing duration
Fixes: signed integer overflow: -4611686024827895807 + -4611686016279904256 cannot be represented in type 'long' Fixes: 30161/clusterfuzz-testcase-minimized-ffmpeg_dem_R3D_fuzzer-5694406713802752 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/r3d.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/r3d.c b/libavformat/r3d.c index 606ed010d6..9de0fb52c7 100644 --- a/libavformat/r3d.c +++ b/libavformat/r3d.c @@ -325,7 +325,8 @@ static int r3d_read_reda(AVFormatContext *s, AVPacket *pkt, Atom *atom) pkt->stream_index = 1; pkt->dts = dts; -if (st->codecpar->sample_rate) + +if (st->codecpar->sample_rate && samples > 0) pkt->duration = av_rescale(samples, st->time_base.den, st->codecpar->sample_rate); av_log(s, AV_LOG_TRACE, "pkt dts %"PRId64" duration %"PRId64" samples %d sample rate %d\n", pkt->dts, pkt->duration, samples, st->codecpar->sample_rate); -- 2.17.1 ___ 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 3/4] avcodec/sonic: Use unsigned temporary in predictor_calc_error()
Fixes: signed integer overflow: -2147471366 - 18638 cannot be represented in
type 'int'
Fixes:
30157/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5171199746506752
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/sonic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 32e94d24f6..c049f6aedc 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -475,13 +475,13 @@ static int predictor_calc_error(int *k, int *state, int
order, int error)
for (i = order-2; i >= 0; i--, k_ptr--, state_ptr--)
{
int k_value = *k_ptr, state_value = *state_ptr;
-x -= shift_down(k_value * (unsigned)state_value, LATTICE_SHIFT);
+x -= (unsigned)shift_down(k_value * (unsigned)state_value,
LATTICE_SHIFT);
state_ptr[1] = state_value + shift_down(k_value * (unsigned)x,
LATTICE_SHIFT);
}
#else
for (i = order-2; i >= 0; i--)
{
-x -= shift_down(k[i] * state[i], LATTICE_SHIFT);
+x -= (unsigned)shift_down(k[i] * state[i], LATTICE_SHIFT);
state[i+1] = state[i] + shift_down(k[i] * x, LATTICE_SHIFT);
}
#endif
--
2.17.1
___
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] Avoid a decoded frame copy in mmaldec for raspberrypi
Hello,
I needed to acquire mjpeg from a v4l2 uvc webcam in a Raspberry pi,
and I saw mmaldec lacked mjpeg and also was doing an unnecessary copy.
I used two patches I found in the mailing list archives to enable mjpeg
mmaldec and then wrote one that avoids the copy. It works fine for me but
I have not run 'fate' yet. I'm in a cross-building situation and I have
yet to learn how that works.
In a Raspberry Pi 1 Model B now it can 640x480 30fps mjpeg->h264_omx with
25% of cpu (as "top" shows).
Before these three patches, 640x480 YUY2->h264_omx could do only 20fps and
"top" showed 50% of cpu.
A Raspberry Pi 2 can do easily 30fps 1280x720 mjpeg->h264_omx as well.
It'd be a lot easier for me if these patches were upstream so I'm
interested in the code getting in. I'm new in ffmpeg so I may have missed
customary details. I also thank the help #ffmpeg-devel that made my patch
(3rd) simpler than I originally thought.
Regards,
Lluís.
--
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key 7CBD1DA5 - https://emailselfdefense.fsf.org/
>From ac005288e1b8493dcf7457171820dcf1a2fa03ca Mon Sep 17 00:00:00 2001
From: Cosmin Gorgovan
Date: Thu, 20 Aug 2020 21:05:23 +0100
Subject: [PATCH 1/3] libavcodec/mmaldec: enable MJPEG decoding
---
configure | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/mmaldec.c | 4
3 files changed, 6 insertions(+)
diff --git a/configure b/configure
index a76c2ec4ae..048bedb589 100755
--- a/configure
+++ b/configure
@@ -3105,6 +3105,7 @@ hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
mjpeg_cuvid_decoder_deps="cuvid"
+mjpeg_mmal_decoder_deps="mmal"
mjpeg_qsv_decoder_select="qsvdec"
mjpeg_qsv_encoder_deps="libmfx"
mjpeg_qsv_encoder_select="qsvenc"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 16ec182a52..8d1908c6d5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -187,6 +187,7 @@ extern AVCodec ff_mdec_decoder;
extern AVCodec ff_mimic_decoder;
extern AVCodec ff_mjpeg_encoder;
extern AVCodec ff_mjpeg_decoder;
+extern AVCodec ff_mjpeg_mmal_decoder;
extern AVCodec ff_mjpegb_decoder;
extern AVCodec ff_mmvideo_decoder;
extern AVCodec ff_mobiclip_decoder;
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index cb15ac072a..df14b9fc95 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -375,6 +375,9 @@ static av_cold int ffmmal_init_decoder(AVCodecContext
*avctx)
format_in = decoder->input[0]->format;
format_in->type = MMAL_ES_TYPE_VIDEO;
switch (avctx->codec_id) {
+case AV_CODEC_ID_MJPEG:
+format_in->encoding = MMAL_ENCODING_MJPEG;
+break;
case AV_CODEC_ID_MPEG2VIDEO:
format_in->encoding = MMAL_ENCODING_MP2V;
break;
@@ -851,6 +854,7 @@ static const AVOption options[]={
};
FFMMAL_DEC(h264, AV_CODEC_ID_H264)
+FFMMAL_DEC(mjpeg, AV_CODEC_ID_MJPEG)
FFMMAL_DEC(mpeg2, AV_CODEC_ID_MPEG2VIDEO)
FFMMAL_DEC(mpeg4, AV_CODEC_ID_MPEG4)
FFMMAL_DEC(vc1, AV_CODEC_ID_VC1)
--
2.29.2
>From 62a2f1e7194405e004de9c2f0386b33c4b07446e Mon Sep 17 00:00:00 2001
From: Cosmin Gorgovan
Date: Thu, 20 Aug 2020 21:11:49 +0100
Subject: [PATCH 2/3] libavcodec/mmaldec: continue after receiving EOS without
having sent one
The previous logic in mmaldec was causing the MMAL MJPEG decoder
to stop if it received an invalid frame - which happened to be the
first frame received from a UVC camera via V4L2 in my application
---
libavcodec/mmaldec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index df14b9fc95..4dfaacbb41 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -711,9 +711,13 @@ static int ffmmal_read_frame(AVCodecContext *avctx,
AVFrame *frame, int *got_fra
goto done;
}
-ctx->eos_received |= !!(buffer->flags & MMAL_BUFFER_HEADER_FLAG_EOS);
-if (ctx->eos_received)
+int eos = !!(buffer->flags & MMAL_BUFFER_HEADER_FLAG_EOS);
+if (eos) {
+if (ctx->eos_sent) {
+ ctx->eos_received = 1;
+}
goto done;
+}
if (buffer->cmd == MMAL_EVENT_FORMAT_CHANGED) {
MMAL_COMPONENT_T *decoder = ctx->decoder;
--
2.29.2
>From 6ae87ea2012444ff52dcff36718d27fb9262b14f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?=
Date: Wed, 10 Feb 2021 22:58:17 +0100
Subject: [PATCH 3/3] mmaldec with plain yuv420p without copy
---
libavcodec/mmaldec.c | 48
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 4dfaacbb41..097b990f92 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -119,10 +119,11 @@ static void ffmmal_release_frame(void *opaque, uint8_t
*data)
// Setup frame with a new reference to
Re: [FFmpeg-devel] [PATCH] avdevice/avdevice: Deprecate AVDevice Capabilities API
Andreas Rheinhardt: > Anton Khirnov: >> Quoting Andreas Rheinhardt (2021-02-09 09:04:23) >>> Can I get an update on how to proceed with this patch? >> >> It doesn't seem that anyone actually objected to this patch, so go ahead >> and push IMO. >> >>> >>> - Andreas >>> >>> PS: I could already remove all the av_device_capabilities options >>> (except the sentinel) at the next major bump, couldn't I? >> >> Doxy says should not be used by a user, so I guess yes. >> > Then I could actually remove these options now. > > - Andreas > Will apply with that change the day after tomorrow unless there are objections. - 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] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
Hi Martin! > On 10 Feb 2021, at 22:53, Martin Storsjö wrote: > > +.macro idct_16x16 bitdepth > +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1 > +//r0 - coeffs > +mov x15, lr > + Binutils doesn't recognize "lr" as alias for x30 >>> It didn’t have an issue in the Debian unstable VM? >>> That seems like the kind of workaround where it would be >>> better to leave a comment with more info, if you know >>> what exactly is affected. >> >> Binutils 2.28 doesn't recognize "lr" while 2.30 does, it seems. >> >> FWIW, all the existing aarch64 assembly just uses "x30" to refer to this >> register, none of it uses "lr". > > Do you want to follow up on this patch? IIRC changing it to use "x30" instead > of "lr" was the only blocker from my point of view (and the add_residual > patch that goes on top of it was mostly fine as well)? Sorry, I forgot about that comment when I sent the last revision. Josh has been doing some polishing of these patches, so unless I hear otherwise I’ll assume he’s volunteering to do these minor fixes (thanks in advance), otherwise we just end up stepping on each other’s toes. But I am around in principle and will if necessary help out getting it merged. Best regards, Reimar ___ 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 v2] avfilter/vf_zscale: add support for setting scaling filter parameters
On Thu, Feb 11, 2021 at 8:31 PM Paul B Mahol wrote: > > lgtm Thanks, applied as 58e59396f5fe93f0606dc458d84c609b5d23ea1c . Jan ___ 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 v2] avfilter/vf_zscale: add support for setting scaling filter parameters
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".
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: add some missing allocation checks
On 2/11/2021 12:57 PM, Paul B Mahol wrote: probably ok Applied. Thanks. ___ 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 v2] avfilter/vf_zscale: add support for setting scaling filter parameters
param_a/b are utilized for this.
---
Changes from v1:
* Documentation was added.
* The author of the zimg library noted that the bicubic parameters technically
can go negative. Thus the range is -DBL_MAX to DBL_MAX.
---
doc/filters.texi| 7 +++
libavfilter/vf_zscale.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 50aa0eb305..152e806fdd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22393,6 +22393,13 @@ Possible values are:
@item npl
Set the nominal peak luminance.
+
+@item param_a
+Parameter A for scaling filters. Parameter "b" for bicubic, and the number of
+filter taps for lanczos.
+
+@item param_b
+Parameter B for scaling filters. Parameter "c" for bicubic.
@end table
The values of the @option{w} and @option{h} options are expressions
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 57199a0878..c18a161ab4 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -101,6 +101,8 @@ typedef struct ZScaleContext {
char *size_str;
double nominal_peak_luminance;
int approximate_gamma;
+double param_a;
+double param_b;
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
@@ -601,6 +603,8 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
s->params.resample_filter_uv = s->filter;
s->params.nominal_peak_luminance = s->nominal_peak_luminance;
s->params.allow_approximate_gamma = s->approximate_gamma;
+s->params.filter_param_a = s->params.filter_param_a_uv = s->param_a;
+s->params.filter_param_b = s->params.filter_param_b_uv = s->param_b;
format_init(>src_format, in, desc, s->colorspace_in,
s->primaries_in, s->trc_in, s->range_in, s->chromal_in);
@@ -897,6 +901,9 @@ static const AVOption zscale_options[] = {
{ "cin","set input chroma location", OFFSET(chromal_in),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_CHROMA_BOTTOM, FLAGS, "chroma" },
{ "npl", "set nominal peak luminance",
OFFSET(nominal_peak_luminance), AV_OPT_TYPE_DOUBLE, {.dbl = NAN}, 0, DBL_MAX,
FLAGS },
{ "agamma", "allow approximate gamma", OFFSET(approximate_gamma),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+{ "param_a", "parameter A, which is parameter \"b\" for bicubic, "
+ "and the number of filter taps for lanczos", OFFSET(param_a),
AV_OPT_TYPE_DOUBLE, {.dbl = NAN}, -DBL_MAX, DBL_MAX, FLAGS },
+{ "param_b", "parameter B, which is parameter \"c\" for bicubic",
OFFSET(param_b), AV_OPT_TYPE_DOUBLE, {.dbl = NAN}, -DBL_MAX, DBL_MAX, FLAGS },
{ NULL }
};
--
2.29.2
___
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 1/2] avcodec/dpx: add float support for single components and rgb(a)
Signed-off-by: Paul B Mahol
---
libavcodec/dpx.c | 71 +---
1 file changed, 67 insertions(+), 4 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 12bc165415..702caa385e 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -159,8 +159,8 @@ static int decode_frame(AVCodecContext *avctx,
AVFrame *const p = data;
uint8_t *ptr[AV_NUM_DATA_POINTERS];
uint32_t header_version, version = 0;
-char creator[101];
-char input_device[33];
+char creator[101] = { 0 };
+char input_device[33] = { 0 };
unsigned int offset;
int magic_num, endian;
@@ -327,6 +327,10 @@ static int decode_frame(AVCodecContext *avctx,
}
switch (descriptor) {
+case 1: // R
+case 2: // G
+case 3: // B
+case 4: // A
case 6: // Y
elements = 1;
yuv = 1;
@@ -385,8 +389,10 @@ static int decode_frame(AVCodecContext *avctx,
case 16:
stride = 2 * avctx->width * elements;
break;
-case 1:
case 32:
+stride = 4 * avctx->width * elements;
+break;
+case 1:
case 64:
avpriv_report_missing_feature(avctx, "Depth %d", bits_per_color);
return AVERROR_PATCHWELCOME;
@@ -499,6 +505,20 @@ static int decode_frame(AVCodecContext *avctx,
case 6120:
avctx->pix_fmt = AV_PIX_FMT_GRAY12;
break;
+case 1320:
+case 2320:
+case 3320:
+case 4320:
+case 6320:
+avctx->pix_fmt = AV_PIX_FMT_GRAYF32LE;
+break;
+case 1321:
+case 2321:
+case 3321:
+case 4321:
+case 6321:
+avctx->pix_fmt = AV_PIX_FMT_GRAYF32BE;
+break;
case 50081:
case 50080:
avctx->pix_fmt = AV_PIX_FMT_RGB24;
@@ -549,6 +569,18 @@ static int decode_frame(AVCodecContext *avctx,
case 51160:
avctx->pix_fmt = AV_PIX_FMT_RGBA64LE;
break;
+case 50320:
+avctx->pix_fmt = AV_PIX_FMT_GBRPF32LE;
+break;
+case 50321:
+avctx->pix_fmt = AV_PIX_FMT_GBRPF32BE;
+break;
+case 51320:
+avctx->pix_fmt = AV_PIX_FMT_GBRAPF32LE;
+break;
+case 51321:
+avctx->pix_fmt = AV_PIX_FMT_GBRAPF32BE;
+break;
case 100081:
avctx->pix_fmt = AV_PIX_FMT_UYVY422;
break;
@@ -559,7 +591,8 @@ static int decode_frame(AVCodecContext *avctx,
avctx->pix_fmt = AV_PIX_FMT_YUVA444P;
break;
default:
-av_log(avctx, AV_LOG_ERROR, "Unsupported format\n");
+av_log(avctx, AV_LOG_ERROR, "Unsupported format %d\n",
+ 1000 * descriptor + 10 * bits_per_color + endian);
return AVERROR_PATCHWELCOME;
}
@@ -657,6 +690,36 @@ static int decode_frame(AVCodecContext *avctx,
buf += need_align;
}
break;
+case 32:
+if (elements == 1) {
+av_image_copy_plane(ptr[0], p->linesize[0],
+buf, stride,
+elements * avctx->width * 4, avctx->height);
+} else {
+for (y = 0; y < avctx->height; y++) {
+ptr[0] = p->data[0] + y * p->linesize[0];
+ptr[1] = p->data[1] + y * p->linesize[1];
+ptr[2] = p->data[2] + y * p->linesize[2];
+ptr[3] = p->data[3] + y * p->linesize[3];
+for (x = 0; x < avctx->width; x++) {
+AV_WN32(ptr[2], AV_RN32(buf));
+AV_WN32(ptr[0], AV_RN32(buf + 4));
+AV_WN32(ptr[1], AV_RN32(buf + 8));
+if (avctx->pix_fmt == AV_PIX_FMT_GBRAPF32BE ||
+avctx->pix_fmt == AV_PIX_FMT_GBRAPF32LE) {
+AV_WN32(ptr[3], AV_RN32(buf + 12));
+buf += 4;
+ptr[3] += 4;
+}
+
+buf += 12;
+ptr[2] += 4;
+ptr[0] += 4;
+ptr[1] += 4;
+}
+}
+}
+break;
case 16:
elements *= 2;
case 8:
--
2.17.1
___
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 2/2] avcodec/dpx: add support for other single component 8bit files
Signed-off-by: Paul B Mahol
---
libavcodec/dpx.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 702caa385e..5372e3d586 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -497,6 +497,14 @@ static int decode_frame(AVCodecContext *avctx,
}
switch (1000 * descriptor + 10 * bits_per_color + endian) {
+case 1081:
+case 1080:
+case 2081:
+case 2080:
+case 3081:
+case 3080:
+case 4081:
+case 4080:
case 6081:
case 6080:
avctx->pix_fmt = AV_PIX_FMT_GRAY8;
--
2.17.1
___
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/hevcdec: check that the local context list exists before dereferencing it
On 2/10/2021 8:59 PM, Paul B Mahol wrote: On Wed, Feb 10, 2021 at 6:57 PM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: James Almer: Since the decoder is not flagged as init cleanup capable, hevc_decode_free() is being called manually if the hevc_decode_extradata() call fails at the end of hevc_decode_init(). In a frame threading scenario, however, if AVCodec->init() returns an error, ff_frame_thread_free() will be called regardless of the above flag being set or not, resulting in hevc_decode_free() being called a second time for the same context. Solve this by ensuring pointers are not dereferenced if they are NULL, and setting the decoder as init cleanup capable. Fixes ticket #9099. Signed-off-by: James Almer --- Maybe ff_frame_thread_free() should not call AVCodec->close() for thread contexts where AVCodec->init() failed and FF_CODEC_CAP_INIT_CLEANUP is not set? Fixing this has been on my to-do list. (The situation is even worse than you describe it: It is possible that AVCodec->close is called on an AVCodecContext whose private_data couldn't be allocated.) So how should proceed? Apply this patch and fix other issues after it? Applied this patch. The other unchecked allocs are handled in another patch, and the ff_frame_thread_init() issues should be fixed by Andreas' patch. ___ 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/pthread_frame: Fix checks and cleanup during init
Up until now, ff_frame_thread_init had several bugs:
1. It did not check whether the condition and mutexes
could be successfully created.
2. In case an error happened when setting up the child threads,
ff_frame_thread_free is called to clean up all threads set up so far,
including the current one. But a half-allocated context needs
special handling which ff_frame_thread_frame_free doesn't provide.
Notably, if allocating the AVCodecInternal, the codec's private data
or setting the options fails, the codec's close function will be
called (if there is one); it will also be called if the codec's init
function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP
is set. This is not supported by all codecs; in ticket #9099 (which
this commit fixes) it led to a crash.
This commit fixes both of these issues. Given that it is not documented
to be save to destroy mutexes/conditions that have only been zeroed, but
not initialized (or whose initialization has failed), one either needs to
duplicate the code to destroy them in ff_frame_thread_init or record
which mutexes/condition variables need to be destroyed and check for this
in ff_frame_thread_free. This patch uses the former way for the
mutexes/condition variables, but lets ff_frame_thread_free take
over for all threads whose AVCodecContext could be allocated.
Signed-off-by: Andreas Rheinhardt
---
After several unsuccessful attempts to make pthread_cond/mutex_init
fail, I looked at the source [1] and it seems that the glibc versions of
these functions can't fail at all (unless one sets nondefault attributes).
Therefore this part of the code is untested, unfortunately.
(Removing all pthread_mutex/cond_destroy calls does not result in any
complaints from Valgrind/ASAN either; seems the glibc implementation
doesn't need allocations.)
[1]: https://github.com/bminor/glibc/blob/master/nptl/pthread_cond_init.c
https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c
libavcodec/pthread_frame.c | 175 ++---
1 file changed, 106 insertions(+), 69 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 4429a4d59c..a10d8c1266 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -64,6 +64,12 @@ enum {
STATE_SETUP_FINISHED,
};
+enum {
+UNINITIALIZED, ///< Thread has not been created, AVCodec->close mustn't
be called
+NEEDS_CLOSE,///< AVCodec->close needs to be called
+INITIALIZED,///< Thread has been properly set up
+};
+
/**
* Context used by codec threads and stored in their AVCodecInternal
thread_ctx.
*/
@@ -698,27 +704,40 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
thread_count)
for (i = 0; i < thread_count; i++) {
PerThreadContext *p = >threads[i];
+AVCodecContext *ctx = p->avctx;
-pthread_mutex_lock(>mutex);
-p->die = 1;
-pthread_cond_signal(>input_cond);
-pthread_mutex_unlock(>mutex);
-
-if (p->thread_init)
-pthread_join(p->thread, NULL);
-p->thread_init=0;
+if (ctx->internal) {
+if (p->thread_init == INITIALIZED) {
+pthread_mutex_lock(>mutex);
+p->die = 1;
+pthread_cond_signal(>input_cond);
+pthread_mutex_unlock(>mutex);
-if (codec->close && p->avctx)
-codec->close(p->avctx);
+pthread_join(p->thread, NULL);
+}
+if (codec->close && p->thread_init != UNINITIALIZED)
+codec->close(ctx);
#if FF_API_THREAD_SAFE_CALLBACKS
-release_delayed_buffers(p);
+release_delayed_buffers(p);
+for (int j = 0; j < p->released_buffers_allocated; j++)
+av_frame_free(>released_buffers[j]);
+av_freep(>released_buffers);
#endif
-av_frame_free(>frame);
-}
+if (ctx->priv_data) {
+if (codec->priv_class)
+av_opt_free(ctx->priv_data);
+av_freep(>priv_data);
+}
-for (i = 0; i < thread_count; i++) {
-PerThreadContext *p = >threads[i];
+av_freep(>slice_offset);
+
+av_buffer_unref(>internal->pool);
+av_freep(>internal);
+av_buffer_unref(>hw_frames_ctx);
+}
+
+av_frame_free(>frame);
pthread_mutex_destroy(>mutex);
pthread_mutex_destroy(>progress_mutex);
@@ -727,26 +746,6 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
thread_count)
pthread_cond_destroy(>output_cond);
av_packet_unref(>avpkt);
-#if FF_API_THREAD_SAFE_CALLBACKS
-for (int j = 0; j < p->released_buffers_allocated; j++)
-av_frame_free(>released_buffers[j]);
-av_freep(>released_buffers);
-#endif
-
-if (p->avctx) {
-if (codec->priv_class)
-av_opt_free(p->avctx->priv_data);
-
Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: Fix checks and cleanup during init
Andreas Rheinhardt:
> Up until now, ff_frame_thread_init had several bugs:
> 1. It did not check whether the condition and mutexes
>could be successfully created.
> 2. In case an error happened when setting up the child threads,
>ff_frame_thread_free is called to clean up all threads set up so far,
>including the current one. But a half-allocated context needs
>special handling which ff_frame_thread_frame_free doesn't provide.
>Notably, if allocating the AVCodecInternal, the codec's private data
>or setting the options fails, the codec's close function will be
>called (if there is one); it will also be called if the codec's init
>function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP
>is set. This is not supported by all codecs; in ticket #9099 (which
>this commit fixes) it led to a crash.
>
> This commit fixes both of these issues. Given that it is not documented
> to be save to destroy mutexes/conditions that have only been zeroed, but
> not initialized (or whose initialization has failed), one either needs to
> duplicate the code to destroy them in ff_frame_thread_init or record
> which mutexes/condition variables need to be destroyed and check for this
> in ff_frame_thread_free. This patch uses the former way for the
> mutexes/condition variables, but lets ff_frame_thread_free take
> over for all threads whose AVCodecContext could be allocated.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> After several unsuccessful attempts to make pthread_cond/mutex_init
> fail, I looked at the source [1] and it seems that the glibc versions of
> these functions can't fail at all (unless one sets nondefault attributes).
> Therefore this part of the code is untested, unfortunately.
>
> (Removing all pthread_mutex/cond_destroy calls does not result in any
> complaints from Valgrind/ASAN either; seems the glibc implementation
> doesn't need allocations.)
>
> [1]: https://github.com/bminor/glibc/blob/master/nptl/pthread_cond_init.c
> https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c
>
> libavcodec/pthread_frame.c | 175 ++---
> 1 file changed, 106 insertions(+), 69 deletions(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 4429a4d59c..a10d8c1266 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -64,6 +64,12 @@ enum {
> STATE_SETUP_FINISHED,
> };
>
> +enum {
> +UNINITIALIZED, ///< Thread has not been created, AVCodec->close mustn't
> be called
> +NEEDS_CLOSE,///< AVCodec->close needs to be called
> +INITIALIZED,///< Thread has been properly set up
> +};
> +
> /**
> * Context used by codec threads and stored in their AVCodecInternal
> thread_ctx.
> */
> @@ -698,27 +704,40 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
> thread_count)
>
> for (i = 0; i < thread_count; i++) {
> PerThreadContext *p = >threads[i];
> +AVCodecContext *ctx = p->avctx;
>
> -pthread_mutex_lock(>mutex);
> -p->die = 1;
> -pthread_cond_signal(>input_cond);
> -pthread_mutex_unlock(>mutex);
> -
> -if (p->thread_init)
> -pthread_join(p->thread, NULL);
> -p->thread_init=0;
> +if (ctx->internal) {
> +if (p->thread_init == INITIALIZED) {
> +pthread_mutex_lock(>mutex);
> +p->die = 1;
> +pthread_cond_signal(>input_cond);
> +pthread_mutex_unlock(>mutex);
>
> -if (codec->close && p->avctx)
> -codec->close(p->avctx);
> +pthread_join(p->thread, NULL);
> +}
> +if (codec->close && p->thread_init != UNINITIALIZED)
> +codec->close(ctx);
>
> #if FF_API_THREAD_SAFE_CALLBACKS
> -release_delayed_buffers(p);
> +release_delayed_buffers(p);
> +for (int j = 0; j < p->released_buffers_allocated; j++)
> +av_frame_free(>released_buffers[j]);
> +av_freep(>released_buffers);
> #endif
> -av_frame_free(>frame);
> -}
> +if (ctx->priv_data) {
> +if (codec->priv_class)
> +av_opt_free(ctx->priv_data);
> +av_freep(>priv_data);
> +}
>
> -for (i = 0; i < thread_count; i++) {
> -PerThreadContext *p = >threads[i];
> +av_freep(>slice_offset);
> +
> +av_buffer_unref(>internal->pool);
> +av_freep(>internal);
> +av_buffer_unref(>hw_frames_ctx);
> +}
> +
> +av_frame_free(>frame);
>
> pthread_mutex_destroy(>mutex);
> pthread_mutex_destroy(>progress_mutex);
> @@ -727,26 +746,6 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
> thread_count)
> pthread_cond_destroy(>output_cond);
> av_packet_unref(>avpkt);
>
> -#if FF_API_THREAD_SAFE_CALLBACKS
> -for
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: add some missing allocation checks
probably ok ___ 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/hevcdec: add some missing allocation checks
Signed-off-by: James Almer
---
libavcodec/hevcdec.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 898dac8cbb..325c7850e6 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -515,6 +515,9 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps,
s->sao_pixel_buffer_v[c_idx] =
av_malloc((h * 2 * sps->ctb_width) <<
sps->pixel_shift);
+if (!s->sao_pixel_buffer_h[c_idx] ||
+!s->sao_pixel_buffer_v[c_idx])
+goto fail;
}
}
@@ -525,6 +528,10 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps,
fail:
pic_arrays_free(s);
+for (i = 0; i < 3; i++) {
+av_freep(>sao_pixel_buffer_h[i]);
+av_freep(>sao_pixel_buffer_v[i]);
+}
s->ps.sps = NULL;
return ret;
}
@@ -2624,13 +2631,19 @@ static int hls_slice_data_wpp(HEVCContext *s, const
H2645NAL *nal)
ff_alloc_entries(s->avctx, s->sh.num_entry_point_offsets + 1);
-if (!s->sList[1]) {
-for (i = 1; i < s->threads_number; i++) {
-s->sList[i] = av_malloc(sizeof(HEVCContext));
-memcpy(s->sList[i], s, sizeof(HEVCContext));
-s->HEVClcList[i] = av_mallocz(sizeof(HEVCLocalContext));
-s->sList[i]->HEVClc = s->HEVClcList[i];
+for (i = 1; i < s->threads_number; i++) {
+if (s->sList[i] && s->HEVClcList[i])
+continue;
+av_freep(>sList[i]);
+av_freep(>HEVClcList[i]);
+s->sList[i] = av_malloc(sizeof(HEVCContext));
+s->HEVClcList[i] = av_mallocz(sizeof(HEVCLocalContext));
+if (!s->sList[i] || !s->HEVClcList[i]) {
+res = AVERROR_INVALIDDATA;
+goto error;
}
+memcpy(s->sList[i], s, sizeof(HEVCContext));
+s->sList[i]->HEVClc = s->HEVClcList[i];
}
offset = (lc->gb.index >> 3);
--
2.30.0
___
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 v5 03/10] avformat: add vvc raw demux
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vvcdec.c | 61
3 files changed, 63 insertions(+)
create mode 100644 libavformat/vvcdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 10fee749c8..2b9d0eee7f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -564,6 +564,7 @@ OBJS-$(CONFIG_VOC_MUXER) += vocenc.o voc.o
OBJS-$(CONFIG_VPK_DEMUXER) += vpk.o
OBJS-$(CONFIG_VPLAYER_DEMUXER) += vplayerdec.o subtitles.o
OBJS-$(CONFIG_VQF_DEMUXER) += vqf.o
+OBJS-$(CONFIG_VVC_DEMUXER) += vvcdec.o rawdec.o
OBJS-$(CONFIG_W64_DEMUXER) += wavdec.o w64.o pcm.o
OBJS-$(CONFIG_W64_MUXER) += wavenc.o w64.o
OBJS-$(CONFIG_WAV_DEMUXER) += wavdec.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index f837ddabc8..fb06723fb9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -463,6 +463,7 @@ extern AVOutputFormat ff_voc_muxer;
extern AVInputFormat ff_vpk_demuxer;
extern AVInputFormat ff_vplayer_demuxer;
extern AVInputFormat ff_vqf_demuxer;
+extern AVInputFormat ff_vvc_demuxer;
extern AVInputFormat ff_w64_demuxer;
extern AVOutputFormat ff_w64_muxer;
extern AVInputFormat ff_wav_demuxer;
diff --git a/libavformat/vvcdec.c b/libavformat/vvcdec.c
new file mode 100644
index 00..149f39f28e
--- /dev/null
+++ b/libavformat/vvcdec.c
@@ -0,0 +1,61 @@
+/*
+ * RAW VVC video demuxer
+ * Copyright (c) 2020 Nuo Mi
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/vvc.h"
+
+#include "avformat.h"
+#include "rawdec.h"
+
+static int vvc_probe(const AVProbeData *p)
+{
+uint32_t code = -1;
+int sps = 0, pps = 0, irap = 0;
+int i;
+
+for (i = 0; i < p->buf_size - 1; i++) {
+code = (code << 8) + p->buf[i];
+if ((code & 0xff00) == 0x100) {
+uint8_t nal2 = p->buf[i + 1];
+int type = (nal2 & 0xF8) >> 3;
+
+if (code & 0xc0) // forbidden_zero_bit and nuh_reserved_zero_bit
+return 0;
+
+if ((nal2 & 0x7) == 0) // nuh_temporal_id_plus1
+return 0;
+
+switch (type) {
+case VVC_SPS_NUT: sps++; break;
+case VVC_PPS_NUT: pps++; break;
+case VVC_IDR_N_LP:
+case VVC_IDR_W_RADL:
+case VVC_CRA_NUT:
+case VVC_GDR_NUT: irap++; break;
+}
+}
+}
+
+if (sps && pps && irap)
+return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER(vvc, "raw VVC video", vvc_probe, "h266,266,vvc",
AV_CODEC_ID_VVC)
--
2.25.1
___
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/hevcdec: check that the local context list exists before dereferencing it
hevcdec and pthread_slice has some memory manage issues. 1. hls_slice_data_wpp did not check the return value of ff_alloc_entries and av_malloc. 2. ff_alloc_entries did not check the return value of pthread_cond_init and pthread_mutex_init 2. Even hls_slice_data_wpp return some error for memory allocation failed, decode_nal_unit may ignore the return value at the end, We need carefully handle the half created arrays/memory. ___ 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 v5 04/10] cbs_h2645: refact, allow INVALID_OFFSET for id_offset and active_offset
---
libavcodec/cbs_h2645.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 36212d1da6..fdc527f8e8 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -664,6 +664,7 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext
*ctx,
static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit)
{
+static const size_t INVALID_OFFSET = (size_t)-1;
typedef struct {
int nal_unit_type;
int max_count;
@@ -728,8 +729,8 @@ static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
const PSType *ps_type;
AVBufferRef **ref_array;
void **ptr_array;
-void **active;
-int err, id, i, nb_ps_types;
+void **active = NULL;
+int err, id = 0, i, nb_ps_types;
switch (ctx->codec->codec_id) {
case AV_CODEC_ID_H264:
@@ -751,12 +752,14 @@ static int cbs_h2645_replace_ps(CodedBitstreamContext
*ctx,
}
av_assert0(i < nb_ps_types);
-id = *((uint8_t*)unit->content + ps_type->id_offset);
+if (ps_type->id_offset != INVALID_OFFSET) {
+id = *((uint8_t*)unit->content + ps_type->id_offset);
-if (id >= ps_type->max_count) {
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid %s id: %d.\n",
- ps_type->name, id);
-return AVERROR_INVALIDDATA;
+if (id >= ps_type->max_count) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid %s id: %d.\n",
+ps_type->name, id);
+return AVERROR_INVALIDDATA;
+}
}
err = ff_cbs_make_unit_refcounted(ctx, unit);
@@ -766,9 +769,10 @@ static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
ref_array =
(AVBufferRef**)((uint8_t*)ctx->priv_data + ps_type->ref_array_offset);
ptr_array = (void**)((uint8_t*)ctx->priv_data + ps_type->ptr_array_offset);
-active= (void**)((uint8_t*)ctx->priv_data + ps_type->active_offset);
+if (ps_type->active_offset != INVALID_OFFSET)
+active = (void**)((uint8_t*)ctx->priv_data + ps_type->active_offset);
-if (ptr_array[id] == *active) {
+if (active && ptr_array[id] == *active) {
// The old active parameter set is being overwritten, so it can't
// be active after this point.
*active = NULL;
--
2.25.1
___
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 v5 02/10] avcodec/vvc: add shared header for vvc
---
libavcodec/vvc.h | 142 +++
1 file changed, 142 insertions(+)
create mode 100644 libavcodec/vvc.h
diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
new file mode 100644
index 00..ca15297d7a
--- /dev/null
+++ b/libavcodec/vvc.h
@@ -0,0 +1,142 @@
+/*
+ * VVC shared code
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_VVC_H
+#define AVCODEC_VVC_H
+
+/**
+ * Table 5 – NAL unit type codes and NAL unit type classes
+ * in T-REC-H.266-202008
+ */
+enum VVCNALUnitType {
+VVC_TRAIL_NUT = 0,
+VVC_STSA_NUT = 1,
+VVC_RADL_NUT = 2,
+VVC_RASL_NUT = 3,
+VVC_RSV_VCL_4 = 4,
+VVC_RSV_VCL_5 = 5,
+VVC_RSV_VCL_6 = 6,
+VVC_IDR_W_RADL = 7,
+VVC_IDR_N_LP = 8,
+VVC_CRA_NUT= 9,
+VVC_GDR_NUT= 10,
+VVC_RSV_IRAP_11= 11,
+VVC_OPI_NUT= 12,
+VVC_DCI_NUT= 13,
+VVC_VPS_NUT= 14,
+VVC_SPS_NUT= 15,
+VVC_PPS_NUT= 16,
+VVC_PREFIX_APS_NUT = 17,
+VVC_SUFFIX_APS_NUT = 18,
+VVC_PH_NUT = 19,
+VVC_AUD_NUT= 20,
+VVC_EOS_NUT= 21,
+VVC_EOB_NUT= 22,
+VVC_PREFIX_SEI_NUT = 23,
+VVC_SUFFIX_SEI_NUT = 24,
+VVC_FD_NUT = 25,
+VVC_RSV_NVCL_26= 26,
+VVC_RSV_NVCL_27= 27,
+VVC_UNSPEC_28 = 28,
+VVC_UNSPEC_29 = 29,
+VVC_UNSPEC_30 = 30,
+VVC_UNSPEC_31 = 31,
+};
+
+enum VVCSliceType {
+VVC_SLICE_TYPE_B = 0,
+VVC_SLICE_TYPE_P = 1,
+VVC_SLICE_TYPE_I = 2,
+};
+
+enum {
+//6.2 we can have 3 sample arrays
+MAX_SAMPLE_ARRAYS = 3,
+
+//7.4.3.3 vps_max_layers_minus1 is u(6)
+VVC_MAX_LAYERS = 64,
+
+//7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the range of 0
to 6, inclusive
+VVC_MAX_SUBLAYERS = 7,
+
+//7.4.3.3 vps_num_ptls_minus1 is u(8)
+VVC_MAX_PTLS = 256,
+
+//7.4.3.3 vps_num_output_layer_sets_minus2 is u(8)
+VVC_MAX_TOTAL_NUM_OLSS = 257,
+
+// 7.3.2.3: vps_video_parameter_set_id is u(4).
+VVC_MAX_VPS_COUNT = 16,
+// 7.3.2.4: sps_seq_parameter_set_id is u(4)
+VVC_MAX_SPS_COUNT = 16,
+// 7.3.2.5: pps_pic_parameter_set_id is u(6)
+VVC_MAX_PPS_COUNT = 64,
+
+// 7.4.4.1: ptl_num_sub_profiles is u(8)
+VVC_MAX_SUB_PROFILES = 256,
+
+// A.4.2: according to (1577), MaxDpbSize is bounded above by 2 *
maxDpbPicBuf(8)
+VVC_MAX_DPB_SIZE = 16,
+
+//7.4.3.4 sps_num_ref_pic_lists in range [0, 64]
+VVC_MAX_REF_PIC_LISTS = 64,
+
+//7.4.11 num_ref_entries in range [0, MaxDpbSize + 13]
+VVC_MAX_REF_ENTRIES = VVC_MAX_DPB_SIZE + 13,
+
+//7.4.3.3 sps_num_points_in_qp_table_minus1[i] in range [0, 36 −
sps_qp_table_start_minus26[i]],
+//sps_qp_table_start_minus26[i] in range [sps_qp_table_start_minus26[i]
−26 − QpBdOffset, 36]
+//for 10 bitsQpBdOffset is 12, so sps_num_points_in_qp_table_minus1[i] in
range [0, 74]
+VVC_MAX_POINTS_IN_QP_TABLE = 75,
+
+// 7.4.6.1: hrd_cpb_cnt_minus1 is in [0, 31].
+VVC_MAX_CPB_CNT = 32,
+
+// A.4.1: the highest level allows a MaxLumaPs of 35 651 584.
+VVC_MAX_LUMA_PS = 35651584,
+
+// A.4.1: pic_width_in_luma_samples and pic_height_in_luma_samples are
+// constrained to be not greater than sqrt(MaxLumaPs * 8). Hence height/
+// width are bounded above by sqrt(8 * 35651584) = 16888.2 samples.
+VVC_MAX_WIDTH = 16888,
+VVC_MAX_HEIGHT = 16888,
+
+// A.4.1: table A.1 allows at most 440 tiles per au for any level.
+VVC_MAX_TILES_PER_AU = 440,
+// A.4.1: table A.1 did not define max tile rows.
+// in worest a case, we can have 1x440 tiles picture.
+VVC_MAX_TILE_ROWS= VVC_MAX_TILES_PER_AU,
+// A.4.1: table A.1 allows at most 20 tile columns for any level.
+VVC_MAX_TILE_COLUMNS = 20,
+
+// A.4.1 table A.1 allows at most 600 slice for any level.
+VVC_MAX_SLICES = 600,
+
+// 7.4.8: in the worst case (tiles_enabled_flag and
+// entropy_coding_sync_enabled_flag are both set), entry points can be
+// placed at the beginning of every Ctb row in every tile, giving an
+// upper bound of (num_tile_columns_minus1 + 1) * PicHeightInCtbsY - 1.
+// Only a
[FFmpeg-devel] [PATCH v5 08/10] avformat: add h266/vvc muxer
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rawenc.c | 25 +
3 files changed, 27 insertions(+)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2b9d0eee7f..d3a755a47a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -565,6 +565,7 @@ OBJS-$(CONFIG_VPK_DEMUXER) += vpk.o
OBJS-$(CONFIG_VPLAYER_DEMUXER) += vplayerdec.o subtitles.o
OBJS-$(CONFIG_VQF_DEMUXER) += vqf.o
OBJS-$(CONFIG_VVC_DEMUXER) += vvcdec.o rawdec.o
+OBJS-$(CONFIG_VVC_MUXER) += rawenc.o
OBJS-$(CONFIG_W64_DEMUXER) += wavdec.o w64.o pcm.o
OBJS-$(CONFIG_W64_MUXER) += wavenc.o w64.o
OBJS-$(CONFIG_WAV_DEMUXER) += wavdec.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index fb06723fb9..481541bf8c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -464,6 +464,7 @@ extern AVInputFormat ff_vpk_demuxer;
extern AVInputFormat ff_vplayer_demuxer;
extern AVInputFormat ff_vqf_demuxer;
extern AVInputFormat ff_vvc_demuxer;
+extern AVOutputFormat ff_vvc_muxer;
extern AVInputFormat ff_w64_demuxer;
extern AVOutputFormat ff_w64_muxer;
extern AVInputFormat ff_wav_demuxer;
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 32704f9bfd..b4e24c3e26 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -372,6 +372,31 @@ AVOutputFormat ff_hevc_muxer = {
};
#endif
+#if CONFIG_VVC_MUXER
+static int vvc_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
+{
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ AV_RB24(pkt->data) != 0x01) {
+//TODO: fixed this after vvc codec defined in http://mp4ra.org/#/codecs
+av_log(s, AV_LOG_ERROR, "vvc: mp4 to annexb is not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+return 1;
+}
+
+AVOutputFormat ff_vvc_muxer = {
+.name = "vvc",
+.long_name = NULL_IF_CONFIG_SMALL("raw VVC video"),
+.extensions= "vvc,h266,266",
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_VVC,
+.write_header = force_one_stream,
+.write_packet = ff_raw_write_packet,
+.check_bitstream = vvc_check_bitstream,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
#if CONFIG_M4V_MUXER
AVOutputFormat ff_m4v_muxer = {
.name = "m4v",
--
2.25.1
___
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 v5 01/10] cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps
From: Mark Thompson
---
libavcodec/cbs_h2645.c | 171 +++--
1 file changed, 130 insertions(+), 41 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 6005d46e0d..36212d1da6 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -661,38 +661,127 @@ static int
cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
return 0;
}
-#define cbs_h2645_replace_ps(h26n, ps_name, ps_var, id_element) \
-static int cbs_h26 ## h26n ## _replace_ ## ps_var(CodedBitstreamContext *ctx, \
- CodedBitstreamUnit *unit) \
-{ \
-CodedBitstreamH26 ## h26n ## Context *priv = ctx->priv_data; \
-H26 ## h26n ## Raw ## ps_name *ps_var = unit->content; \
-unsigned int id = ps_var->id_element; \
-int err; \
-if (id >= FF_ARRAY_ELEMS(priv->ps_var)) { \
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid " #ps_name \
- " id : %d.\n", id); \
-return AVERROR_INVALIDDATA; \
-} \
-err = ff_cbs_make_unit_refcounted(ctx, unit); \
-if (err < 0) \
-return err; \
-if (priv->ps_var[id] == priv->active_ ## ps_var) \
-priv->active_ ## ps_var = NULL ; \
-av_buffer_unref(>ps_var ## _ref[id]); \
-av_assert0(unit->content_ref); \
-priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
-if (!priv->ps_var ## _ref[id]) \
-return AVERROR(ENOMEM); \
-priv->ps_var[id] = (H26 ## h26n ## Raw ## ps_name *)priv->ps_var ##
_ref[id]->data; \
-return 0; \
-}
+static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
+CodedBitstreamUnit *unit)
+{
+typedef struct {
+int nal_unit_type;
+int max_count;
+const char *name;
+size_t id_offset;
+size_t ref_array_offset;
+size_t ptr_array_offset;
+size_t active_offset;
+} PSType;
+
+static const PSType h264_ps_types[] = {
+{
+H264_NAL_SPS,
+H264_MAX_SPS_COUNT,
+"SPS",
+offsetof(H264RawSPS, seq_parameter_set_id),
+offsetof(CodedBitstreamH264Context, sps_ref),
+offsetof(CodedBitstreamH264Context, sps),
+offsetof(CodedBitstreamH264Context, active_sps),
+},
+{
+H264_NAL_PPS,
+H264_MAX_PPS_COUNT,
+"PPS",
+offsetof(H264RawPPS, pic_parameter_set_id),
+offsetof(CodedBitstreamH264Context, pps_ref),
+offsetof(CodedBitstreamH264Context, pps),
+offsetof(CodedBitstreamH264Context, active_pps),
+},
+};
+
+static const PSType h265_ps_types[] = {
+{
+HEVC_NAL_VPS,
+HEVC_MAX_VPS_COUNT,
+"VPS",
+offsetof(H265RawVPS, vps_video_parameter_set_id),
+offsetof(CodedBitstreamH265Context, vps_ref),
+offsetof(CodedBitstreamH265Context, vps),
+offsetof(CodedBitstreamH265Context, active_vps),
+},
+{
+HEVC_NAL_SPS,
+HEVC_MAX_SPS_COUNT,
+"SPS",
+offsetof(H265RawSPS, sps_seq_parameter_set_id),
+offsetof(CodedBitstreamH265Context, sps_ref),
+offsetof(CodedBitstreamH265Context, sps),
+offsetof(CodedBitstreamH265Context, active_sps),
+},
+{
+HEVC_NAL_PPS,
+HEVC_MAX_PPS_COUNT,
+"PPS",
+offsetof(H265RawPPS, pps_pic_parameter_set_id),
+offsetof(CodedBitstreamH265Context, pps_ref),
+offsetof(CodedBitstreamH265Context, pps),
+offsetof(CodedBitstreamH265Context, active_pps),
+},
+};
-cbs_h2645_replace_ps(4, SPS, sps, seq_parameter_set_id)
-cbs_h2645_replace_ps(4, PPS, pps, pic_parameter_set_id)
-cbs_h2645_replace_ps(5, VPS, vps, vps_video_parameter_set_id)
-cbs_h2645_replace_ps(5, SPS, sps, sps_seq_parameter_set_id)
-cbs_h2645_replace_ps(5, PPS, pps, pps_pic_parameter_set_id)
+const PSType *ps_type;
+AVBufferRef **ref_array;
+void **ptr_array;
+void **active;
+int err, id, i, nb_ps_types;
+
+switch (ctx->codec->codec_id) {
+case AV_CODEC_ID_H264:
+ps_type = h264_ps_types;
+nb_ps_types = FF_ARRAY_ELEMS(h264_ps_types);
+break;
+case AV_CODEC_ID_H265:
+ps_type = h265_ps_types;
+nb_ps_types = FF_ARRAY_ELEMS(h265_ps_types);
+break;
+default:
+av_assert0(0);
+}
+
+for (i = 0; i < nb_ps_types; i++) {
+if (ps_type->nal_unit_type == unit->type)
+break;
+++ps_type;
+}
+av_assert0(i < nb_ps_types);
+
+id = *((uint8_t*)unit->content + ps_type->id_offset);
+
+if (id >= ps_type->max_count) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid %s id: %d.\n",
+ ps_type->name, id);
+return AVERROR_INVALIDDATA;
+}
+
+err =
[FFmpeg-devel] [PATCH v5 09/10] avcodec/cbs_h2645: vvc, do not skip nals for nuh_layer_id > 0
--- libavcodec/cbs_h2645.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c index 81177c1096..6dc4f79930 100644 --- a/libavcodec/cbs_h2645.c +++ b/libavcodec/cbs_h2645.c @@ -604,8 +604,9 @@ static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx, const H2645NAL *nal = >nals[i]; AVBufferRef *ref; size_t size = nal->size; +enum AVCodecID codec_id = ctx->codec->codec_id; -if (nal->nuh_layer_id > 0) +if (codec_id != AV_CODEC_ID_VVC && nal->nuh_layer_id > 0) continue; // Remove trailing zeroes. -- 2.25.1 ___ 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 v5 00/10] add vvc raw demuxer, muxer, parser, metadata bsf
Major changes since v4: * Remove active_xps in CodedBitstreamH266Context * Add H266AuDetector in CodedBitstreamH266Context. It's needed by h266_metadata_update_fragment and cbs_h2645_unit_requires_zero_byte Misc: * Correct raw muxer extesion from .hevc to .vvc. * Fixed missed cbs_sei_h266_types in ff_cbs_sei_find_type * Remove sei emulation since we can use generic sei.h Mark Thompson (1): cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps Nuo Mi (9): avcodec/vvc: add shared header for vvc avformat: add vvc raw demux cbs_h2645: refact, allow INVALID_OFFSET for id_offset and active_offset avcodec: add cbs for h266/vvc avcodec/h2645_parse: add nal header parser for h266/vvc avcodec: add vvc parser avformat: add h266/vvc muxer avcodec/cbs_h2645: vvc, do not skip nals for nuh_layer_id > 0 avcodec: add vvc metadata bsf configure |4 + libavcodec/Makefile |3 + libavcodec/bitstream_filters.c|1 + libavcodec/cbs.c |6 + libavcodec/cbs_h2645.c| 752 ++- libavcodec/cbs_h266.h | 817 +++ libavcodec/cbs_h266_syntax_template.c | 3006 + libavcodec/cbs_internal.h |3 +- libavcodec/cbs_sei.c | 29 + libavcodec/h2645_parse.c | 74 +- libavcodec/h266_metadata_bsf.c| 129 ++ libavcodec/parsers.c |1 + libavcodec/vvc.h | 142 ++ libavcodec/vvc_parser.c | 310 +++ libavformat/Makefile |2 + libavformat/allformats.c |2 + libavformat/rawenc.c | 25 + libavformat/vvcdec.c | 61 + 18 files changed, 5314 insertions(+), 53 deletions(-) create mode 100644 libavcodec/cbs_h266.h create mode 100644 libavcodec/cbs_h266_syntax_template.c create mode 100644 libavcodec/h266_metadata_bsf.c create mode 100644 libavcodec/vvc.h create mode 100644 libavcodec/vvc_parser.c create mode 100644 libavformat/vvcdec.c -- 2.25.1 ___ 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 v5 10/10] avcodec: add vvc metadata bsf
We run following command with all 265 VTM-11.0 clips:
ffmpeg -i in.bit -c:v copy -bsf vvc_metadata -f vvc out.bit
The output bitstream can get same yuv as the origin.
---
configure | 1 +
libavcodec/Makefile| 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/h266_metadata_bsf.c | 129 +
4 files changed, 132 insertions(+)
create mode 100644 libavcodec/h266_metadata_bsf.c
diff --git a/configure b/configure
index 24463595d2..c3121fe25f 100755
--- a/configure
+++ b/configure
@@ -3184,6 +3184,7 @@ mjpeg2jpeg_bsf_select="jpegtables"
mpeg2_metadata_bsf_select="cbs_mpeg2"
trace_headers_bsf_select="cbs"
vp9_metadata_bsf_select="cbs_vp9"
+vvc_metadata_bsf_select="cbs_h266"
# external libraries
aac_at_decoder_deps="audiotoolbox"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 65f81f5b68..6764a8f73c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1172,6 +1172,7 @@ OBJS-$(CONFIG_VP9_METADATA_BSF) +=
vp9_metadata_bsf.o
OBJS-$(CONFIG_VP9_RAW_REORDER_BSF)+= vp9_raw_reorder_bsf.o
OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF) += vp9_superframe_split_bsf.o
+OBJS-$(CONFIG_VVC_METADATA_BSF) += h266_metadata_bsf.o
# thread libraries
OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index b26d6a910e..001a7bb3a4 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -60,6 +60,7 @@ extern const AVBitStreamFilter ff_vp9_metadata_bsf;
extern const AVBitStreamFilter ff_vp9_raw_reorder_bsf;
extern const AVBitStreamFilter ff_vp9_superframe_bsf;
extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
+extern const AVBitStreamFilter ff_vvc_metadata_bsf;
#include "libavcodec/bsf_list.c"
diff --git a/libavcodec/h266_metadata_bsf.c b/libavcodec/h266_metadata_bsf.c
new file mode 100644
index 00..50d618205f
--- /dev/null
+++ b/libavcodec/h266_metadata_bsf.c
@@ -0,0 +1,129 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "cbs.h"
+#include "cbs_bsf.h"
+#include "cbs_h266.h"
+#include "vvc.h"
+
+typedef struct VVCMetadataContext {
+CBSBSFContext common;
+
+H266RawAUD aud_nal;
+
+int aud;
+} VVCMetadataContext;
+
+static int h266_metadata_update_fragment(AVBSFContext *bsf, AVPacket *pkt,
+ CodedBitstreamFragment *pu)
+{
+VVCMetadataContext *ctx = bsf->priv_data;
+int err, i;
+
+// If an AUD is present, it must be the first NAL unit.
+if (pu->units[0].type == VVC_AUD_NUT) {
+if (ctx->aud == BSF_ELEMENT_REMOVE)
+ff_cbs_delete_unit(pu, 0);
+} else {
+CodedBitstreamH266Context *h266 = ctx->common.input->priv_data;
+if (ctx->aud == BSF_ELEMENT_INSERT && h266_is_au_start(h266, pu, bsf)
> 0) {
+H266RawAUD *aud = >aud_nal;
+int pic_type = 0, temporal_id = 8, layer_id = 0;
+for (i = 0; i < pu->nb_units; i++) {
+const H266RawNALUnitHeader *nal = pu->units[i].content;
+if (!nal)
+continue;
+if (nal->nuh_temporal_id_plus1 < temporal_id + 1)
+temporal_id = nal->nuh_temporal_id_plus1 - 1;
+
+if (pu->units[i].type <= VVC_RSV_IRAP_11) {
+const H266RawSlice *slice = pu->units[i].content;
+layer_id = nal->nuh_layer_id;
+if (slice->header.sh_slice_type == VVC_SLICE_TYPE_B &&
+pic_type < 2)
+pic_type = 2;
+if (slice->header.sh_slice_type == VVC_SLICE_TYPE_P &&
+pic_type < 1)
+pic_type = 1;
+}
+}
+
+aud->nal_unit_header = (H266RawNALUnitHeader) {
+.nal_unit_type = VVC_AUD_NUT,
+.nuh_layer_id = layer_id,
+.nuh_temporal_id_plus1 = temporal_id + 1,
+};
+
[FFmpeg-devel] [PATCH v5 06/10] avcodec/h2645_parse: add nal header parser for h266/vvc
---
libavcodec/h2645_parse.c | 74 ++--
1 file changed, 71 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index a36ef4f5a0..35f9d035a9 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -1,5 +1,5 @@
/*
- * H.264/HEVC common parsing code
+ * H.264/HEVC/VVC common parsing code
*
* This file is part of FFmpeg.
*
@@ -27,6 +27,7 @@
#include "libavutil/mem.h"
#include "bytestream.h"
+#include "vvc.h"
#include "hevc.h"
#include "h264.h"
#include "h2645_parse.h"
@@ -146,6 +147,47 @@ nsc:
return si;
}
+static const char *const vvc_nal_type_name[32] = {
+"TRAIL_NUT", // VVC_TRAIL_NUT
+"STSA_NUT", // VVC_STSA_NUT
+"RADL_NUT", // VVC_RADL_NUT
+"RASL_NUT", // VVC_RASL_NUT
+"RSV_VCL_4", // VVC_RSV_VCL_4
+"RSV_VCL_5", // VVC_RSV_VCL_5
+"RSV_VCL_6", // VVC_RSV_VCL_6
+"IDR_W_RADL", // VVC_IDR_W_RADL
+"IDR_N_LP", // VVC_IDR_N_LP
+"CRA_NUT", // VVC_CRA_NUT
+"GDR_NUT", // VVC_GDR_NUT
+"RSV_IRAP_11", // VVC_RSV_IRAP_11
+"OPI_NUT", // VVC_OPI_NUT
+"DCI_NUT", // VVC_DCI_NUT
+"VPS_NUT", // VVC_VPS_NUT
+"SPS_NUT", // VVC_SPS_NUT
+"PPS_NUT", // VVC_PPS_NUT
+"PREFIX_APS_NUT",// VVC_PREFIX_APS_NUT
+"SUFFIX_APS_NUT",// VVC_SUFFIX_APS_NUT
+"PH_NUT", // VVC_PH_NUT
+"AUD_NUT", // VVC_AUD_NUT
+"EOS_NUT", // VVC_EOS_NUT
+"EOB_NUT", // VVC_EOB_NUT
+"PREFIX_SEI_NUT",// VVC_PREFIX_SEI_NUT
+"SUFFIX_SEI_NUT",// VVC_SUFFIX_SEI_NUT
+"FD_NUT", // VVC_FD_NUT
+"RSV_NVCL_26", // VVC_RSV_NVCL_26
+"RSV_NVCL_27", // VVC_RSV_NVCL_27
+"UNSPEC_28", // VVC_UNSPEC_28
+"UNSPEC_29", // VVC_UNSPEC_29
+"UNSPEC_30", // VVC_UNSPEC_30
+"UNSPEC_31", // VVC_UNSPEC_31
+};
+
+static const char *vvc_nal_unit_name(int nal_type)
+{
+av_assert0(nal_type >= 0 && nal_type < 32);
+return vvc_nal_type_name[nal_type];
+}
+
static const char *const hevc_nal_type_name[64] = {
"TRAIL_N", // HEVC_NAL_TRAIL_N
"TRAIL_R", // HEVC_NAL_TRAIL_R
@@ -289,6 +331,31 @@ static int get_bit_length(H2645NAL *nal, int
skip_trailing_zeros)
* @return AVERROR_INVALIDDATA if the packet is not a valid NAL unit,
* 0 otherwise
*/
+static int vvc_parse_nal_header(H2645NAL *nal, void *logctx)
+{
+GetBitContext *gb = >gb;
+
+if (get_bits1(gb) != 0) //forbidden_zero_bit
+return AVERROR_INVALIDDATA;
+
+skip_bits1(gb); //nuh_reserved_zero_bit
+
+nal->nuh_layer_id = get_bits(gb, 6);
+nal->type = get_bits(gb, 5);
+nal->temporal_id = get_bits(gb, 3) - 1;
+if (nal->temporal_id < 0)
+return AVERROR_INVALIDDATA;
+
+if ((nal->type >= VVC_IDR_W_RADL && nal->type <= VVC_RSV_IRAP_11) &&
nal->temporal_id)
+return AVERROR_INVALIDDATA;
+
+av_log(logctx, AV_LOG_DEBUG,
+ "nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
+ nal->type, vvc_nal_unit_name(nal->type), nal->nuh_layer_id,
nal->temporal_id);
+
+return 0;
+}
+
static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
{
GetBitContext *gb = >gb;
@@ -503,8 +570,9 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
/* Reset type in case it contains a stale value from a previously
parsed NAL */
nal->type = 0;
-
-if (codec_id == AV_CODEC_ID_HEVC)
+if (codec_id == AV_CODEC_ID_VVC)
+ret = vvc_parse_nal_header(nal, logctx);
+else if (codec_id == AV_CODEC_ID_HEVC)
ret = hevc_parse_nal_header(nal, logctx);
else
ret = h264_parse_nal_header(nal, logctx);
--
2.25.1
___
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 v5 07/10] avcodec: add vvc parser
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/parsers.c| 1 +
libavcodec/vvc_parser.c | 310
4 files changed, 313 insertions(+)
create mode 100644 libavcodec/vvc_parser.c
diff --git a/configure b/configure
index 11df59a229..24463595d2 100755
--- a/configure
+++ b/configure
@@ -3167,6 +3167,7 @@ mpegaudio_parser_select="mpegaudioheader"
mpegvideo_parser_select="mpegvideo"
mpeg4video_parser_select="h263dsp mpegvideo qpeldsp"
vc1_parser_select="vc1dsp"
+vcc_parser_select="cbs_h266"
# bitstream_filters
aac_adtstoasc_bsf_select="adts_header"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15250fd36f..65f81f5b68 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1128,6 +1128,7 @@ OBJS-$(CONFIG_VC1_PARSER) += vc1_parser.o
vc1.o vc1data.o \
OBJS-$(CONFIG_VP3_PARSER) += vp3_parser.o
OBJS-$(CONFIG_VP8_PARSER) += vp8_parser.o
OBJS-$(CONFIG_VP9_PARSER) += vp9_parser.o
+OBJS-$(CONFIG_VVC_PARSER) += vvc_parser.o
OBJS-$(CONFIG_WEBP_PARSER) += webp_parser.o
OBJS-$(CONFIG_XBM_PARSER) += xbm_parser.o
OBJS-$(CONFIG_XMA_PARSER) += xma_parser.o
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index f8cfa1cde9..61d753d680 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -72,6 +72,7 @@ extern AVCodecParser ff_vorbis_parser;
extern AVCodecParser ff_vp3_parser;
extern AVCodecParser ff_vp8_parser;
extern AVCodecParser ff_vp9_parser;
+extern AVCodecParser ff_vvc_parser;
extern AVCodecParser ff_webp_parser;
extern AVCodecParser ff_xbm_parser;
extern AVCodecParser ff_xma_parser;
diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
new file mode 100644
index 00..4b4aa4b625
--- /dev/null
+++ b/libavcodec/vvc_parser.c
@@ -0,0 +1,310 @@
+/*
+ * VVC parser
+ *
+ * Copyright (C) 2029 Nuo Mi
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "cbs.h"
+#include "cbs_h266.h"
+#include "internal.h"
+#include "parser.h"
+
+#define START_CODE 0x01 ///< start_code_prefix_one_3bytes
+
+#define IS_SLICE(nut) (nut <= VVC_RASL_NUT || (nut >= VVC_IDR_W_RADL && nut <=
VVC_GDR_NUT))
+
+typedef struct VVCParserContext {
+ParseContext pc;
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment picture_unit;
+int parsed_extradata;
+} VVCParserContext;
+
+static const enum AVPixelFormat pix_fmts_8bit[] = {
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P
+};
+
+static const enum AVPixelFormat pix_fmts_10bit[] = {
+AV_PIX_FMT_GRAY10, AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10
+};
+
+static int get_format(const H266RawSPS* sps)
+{
+switch (sps->sps_bitdepth_minus8) {
+case 0:
+return pix_fmts_8bit[sps->sps_chroma_format_idc];
+case 2:
+return pix_fmts_10bit[sps->sps_chroma_format_idc];
+}
+return AV_PIX_FMT_NONE;
+}
+
+/**
+ * Find the end of the current frame in the bitstream.
+ * @return the position of the first byte of the next frame, or END_NOT_FOUND
+ */
+static int find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
+ int buf_size)
+{
+VVCParserContext *ctx = s->priv_data;
+ParseContext *pc = >pc;
+int i;
+
+for (i = 0; i < buf_size; i++) {
+int nut;
+
+pc->state64 = (pc->state64 << 8) | buf[i];
+
+if (((pc->state64 >> 3 * 8) & 0xFF) != START_CODE)
+continue;
+
+nut = (pc->state64 >> (8 + 3)) & 0x1F;
+// 7.4.2.4.3 and 7.4.2.4.4
+if ((nut >= VVC_OPI_NUT && nut <= VVC_PREFIX_APS_NUT && nut !=
VVC_PH_NUT) ||
+nut == VVC_AUD_NUT || nut == VVC_PREFIX_SEI_NUT || nut ==
VVC_RSV_NVCL_26 ||
+nut == VVC_UNSPEC_28 || nut == VVC_UNSPEC_29) {
+if (pc->frame_start_found) {
+pc->frame_start_found = 0;
+return i - 5;
+}
+} else if (nut == VVC_PH_NUT || IS_SLICE(nut)) {
+int sh_picture_header_in_slice_header_flag = buf[i] >> 7;
+
+if (nut == VVC_PH_NUT || sh_picture_header_in_slice_header_flag) {
+
[FFmpeg-devel] [PATCH] [RFC][v4] Tech Resolution Process
--- doc/dev_community/resolution_process.md | 91 + 1 file changed, 91 insertions(+) create mode 100644 doc/dev_community/resolution_process.md diff --git a/doc/dev_community/resolution_process.md b/doc/dev_community/resolution_process.md new file mode 100644 index 00..4ed0b63c43 --- /dev/null +++ b/doc/dev_community/resolution_process.md @@ -0,0 +1,91 @@ +# Technical Committee + +_This document only makes sense with the rules from [the community document](community)_. + +The Technical Committee (**TC**) is here to arbitrate and make decisions when +technical conflicts occur in the project. + +The TC main role is to resolve technical conflicts. +It is therefore not a technical steering committee, but it is understood that +some decisions might impact the future of the project. + +# Process + +## Seizing + +The TC can take possession of any technical matter that it sees fit. + +To involve the TC in a matter, email tc@ or CC them on an ongoing discussion. + +As members of TC are developers, they also can email tc@ to raise an issue. + +## Announcement + +The TC, once seized, must announce itself on the main mailing list, with a _[TC]_ tag. + +The TC has 2 modes of operation: a RFC one and an internal one. + +If the TC thinks it needs the input from the larger community, the TC can call +for a RFC. Else, it can decide by itself. + +If the disagreement involves a member of the TC, that member should recuse +themselves from the decision. + +The decision to use a RFC process or an internal discussion is a discretionary +decision of the TC. + +The TC can also reject a seizure for a few reasons such as: +the matter was not discussed enough previously; it lacks expertise to reach a +beneficial decision on the matter; or the matter is too trivial. + +### RFC call + +In the RFC mode, one person from the TC posts on the mailing list the +technical question and will request input from the community. + +The mail will have the following specification: +* a precise title +* a specific tag [TC RFC] +* a top-level email +* contain a precise question that does not exceed 100 words and that is answerable by developers +* may have an extra description, or a link to a previous discussion, if deemed necessary, +* contain a precise end date for the answers. + +The answers from the community must be on the main mailing list and must have +the following specification: +* keep the tag and the title unchanged +* limited to 400 words +* a first-level, answering directly to the main email +* answering to the question. + +Further replies to answers are permitted, as long as they conform to the +community standards of politeness, they are limited to 100 words, and are not +nested more than once. (max-depth=2) + +After the end-date, mails on the thread will be ignored. + +Violations of those rules will be escalated through the Community Committee. + +After all the emails are in, the TC has 96 hours to give its final decision. +Exceptionally, the TC can request an extra delay, that will be notified on the +mailing list. + +### Within TC + +In the internal case, the TC has 96 hours to give its final decision. +Exceptionally, the TC can request an extra delay. + + +## Decisions + +The decisions from the TC will be sent on the mailing list, with the _[TC]_ tag. + +Internally, the TC should take decisions with a majority, or using +ranked-choice voting. + +The decision from the TC should be published with a summary of the reasons that +lead to this decision. + +The decisions from the TC are final, until the matters are reopened after +no less than one year. + -- 2.30.0 ___ 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] avfilter: add monochrome video filter
Will apply soon. ___ 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 v2 4/4] avcodec/aarch64/hevcdsp: add sao_band NEON
On Thu, 4 Feb 2021, Josh Dekker wrote:
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 7 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_sao_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 2ea1d74a38..954461f81d 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -62,4 +62,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) +=
aarch64/vp9itxfm_16bpp_neon.o \
aarch64/vp9mc_16bpp_neon.o \
aarch64/vp9mc_neon.o
NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \
- aarch64/hevcdsp_init_aarch64.o
+ aarch64/hevcdsp_init_aarch64.o
\
+ aarch64/hevcdsp_sao_neon.o
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index fe111bd1ac..c785e46f79 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -53,6 +53,12 @@ void ff_hevc_idct_4x4_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_8x8_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_16x16_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_32x32_dc_10_neon(int16_t *coeffs);
+void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, uint8_t *_src,
+ ptrdiff_t stride_dst, ptrdiff_t stride_src,
+ int16_t *sao_offset_val, int sao_left_class,
+ int width, int height);
+
+
av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
{
@@ -69,6 +75,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->idct_dc[1] = ff_hevc_idct_8x8_dc_8_neon;
c->idct_dc[2] = ff_hevc_idct_16x16_dc_8_neon;
c->idct_dc[3] = ff_hevc_idct_32x32_dc_8_neon;
+c->sao_band_filter[0] = ff_hevc_sao_band_filter_8x8_8_neon;
}
if (bit_depth == 10) {
c->add_residual[0] = ff_hevc_add_residual_4x4_10_neon;
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
new file mode 100644
index 00..f142c1e8c2
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -0,0 +1,87 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * AArch64 NEON optimised SAO functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+// void sao_band_filter(uint8_t *_dst, uint8_t *_src,
+// ptrdiff_t stride_dst, ptrdiff_t stride_src,
+// int16_t *sao_offset_val, int sao_left_class,
+// int width, int height)
+function ff_hevc_sao_band_filter_8x8_8_neon, export=1
+sub sp, sp, #64
+stp xzr, xzr, [sp]
+stp xzr, xzr, [sp, #16]
+stp xzr, xzr, [sp, #32]
+stp xzr, xzr, [sp, #48]
+mov w8, #4
+0:
+ldrsh x9, [x4, x8, lsl #1] // x9 = sao_offset_val[k+1]
+subs w8, w8, #1
+add w10, w8, w5 // x10 = k + sao_left_class
+and w10, w10, #0x1F
+strh w9, [sp, x10, lsl #1]
+bne 0b
+ld1 {v16.16b-v19.16b}, [sp], #64
+movi v20.8h, #1
+1: // beginning of line
No technical objections, it seems to build fine in all environments, and
gives a consistent speedup over C, so that's good even if things maybe
could be even faster. Didn't look closer at the algorithm so far. But the
indentation is way different than all other asm, so please fix that.
// Martin
___
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 2/3] libavformat/hls: add support for SAMPLE-AES decryption in HLS demuxer
> 在 2021年2月3日，09:11，Steven Liu 写道：
>
>
>
>> 2021年2月2日 下午10:51，Nachiket Tarate 写道：
>>
>> Hello Steven,
>>
>> Was this test passing earlier (without my patch) ?
> Hi Nachiket,
> no, and it to support sample aes without your patch
>>
>> Because SAMPLE-AES encryption method is for MPEG-TS format and not for
>> Fragmented MP4. So, my patch should not affect anything related to
>> Fragmented MP4.
> I think sample ads should support not only mpegts, but also support fmp4 too.
> Reference rfc context:
> An encryption method of SAMPLE-AES means that the Media Segments
> contain media samples, such as audio or video, that are encrypted
> using the Advanced Encryption Standard [AES_128]. How these media
> streams are encrypted and encapsulated in a segment depends on the
> media encoding and the media format of the segment. fMP4 Media
> Segments are encrypted using the 'cbcs' scheme of Common
> Encryption [COMMON_ENC]. Encryption of other Media Segment
> formats containing H.264 [H_264], AAC [ISO_14496], AC-3 [AC_3],
> and Enhanced AC-3 [AC_3] media streams is described in the HTTP
> Live Streaming (HLS) Sample Encryption specification [SampleEnc].
> The IV attribute MAY be present; see Section 5.2.
>
> And I saw the m3u8 context, the METHOD is SAMPLE-AES.
>
> (base) liuqi05:ufbuild liuqi$ head -n10 prog_index.m3u8
> #EXTM3U
> #EXT-X-TARGETDURATION:10
> #EXT-X-VERSION:7
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXT-X-INDEPENDENT-SEGMENTS
>
> Focus on this line.
> #EXT-X-KEY:METHOD=SAMPLE-AES,URI="http://127.0.0.1/keyOnly.bin",IV=0xcece273e2737a58ca785e257eb080482
>
>
> #EXT-X-MAP:URI="fileSequence0.mp4"
> #EXTINF:8.31667,
> #EXT-X-BITRATE:7064
>
>
> You can point me the part if I misunderstood SAMPLE-AES.
>
>>
>> Can you please confirm ?
>>
>> Best Regards,
>> Nachiket Tarate
>>
>> On Mon, Feb 1, 2021 at 12:48 PM Steven Liu wrote:
>>
>>
>>> 2021年1月28日 下午11:11，Nachiket Tarate 写道：
>>>
>>> Apple HTTP Live Streaming Sample Encryption:
>>>
>>> https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
>>>
>>> Signed-off-by: Nachiket Tarate
>>> ---
>>> libavformat/Makefile | 2 +-
>>> libavformat/hls.c| 101 +++--
>>> libavformat/hls_sample_aes.c | 403 +++
>>> libavformat/hls_sample_aes.h | 66 ++
>>> libavformat/mpegts.c | 12 ++
>>> 5 files changed, 568 insertions(+), 16 deletions(-)
>>> create mode 100644 libavformat/hls_sample_aes.c
>>> create mode 100644 libavformat/hls_sample_aes.h
>>>
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index 3a8fbcbe5f..c97930d98b 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -237,7 +237,7 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o pcm.o
>>> OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
>>> OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
>>> OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
>>> -OBJS-$(CONFIG_HLS_DEMUXER) += hls.o
>>> +OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_aes.o
>>> OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
>>> OBJS-$(CONFIG_HNM_DEMUXER) += hnm.o
>>> OBJS-$(CONFIG_ICO_DEMUXER) += icodec.o
>>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>>> index af2468ad9b..850068736e 100644
>>> --- a/libavformat/hls.c
>>> +++ b/libavformat/hls.c
>>> @@ -2,6 +2,7 @@
>>> * Apple HTTP Live Streaming demuxer
>>> * Copyright (c) 2010 Martin Storsjo
>>> * Copyright (c) 2013 Anssi Hannula
>>> + * Copyright (c) 2021 Nachiket Tarate
>>> *
>>> * This file is part of FFmpeg.
>>> *
>>> @@ -39,6 +40,8 @@
>>> #include "avio_internal.h"
>>> #include "id3v2.h"
>>>
>>> +#include "hls_sample_aes.h"
>>> +
>>> #define INITIAL_BUFFER_SIZE 32768
>>>
>>> #define MAX_FIELD_LEN 64
>>> @@ -145,6 +148,10 @@ struct playlist {
>>>int id3_changed; /* ID3 tag data has changed at some point */
>>>ID3v2ExtraMeta *id3_deferred_extra; /* stored here until subdemuxer is
>>> opened */
>>>
>>> +/* Used in case of SAMPLE-AES encryption method */
>>> +HLSAudioSetupInfo audio_setup_info;
>>> +HLSCryptoContext crypto_ctx;
>>> +
>>>int64_t seek_timestamp;
>>>int seek_flags;
>>>int seek_stream_index; /* into subdemuxer stream array */
>>> @@ -266,6 +273,8 @@ static void free_playlist_list(HLSContext *c)
>>>pls->ctx->pb = NULL;
>>>avformat_close_input(>ctx);
>>>}
>>> +if (pls->crypto_ctx.aes_ctx)
>>> + av_free(pls->crypto_ctx.aes_ctx);
>>>av_free(pls);
>>>}
>>>av_freep(>playlists);
>>> @@ -994,7 +1003,10 @@ fail:
>>>
>>> static struct segment *current_segment(struct playlist *pls)
>>> {
>>> -return pls->segments[pls->cur_seq_no - pls->start_seq_no];
>>> +int64_t n = pls->cur_seq_no - pls->start_seq_no;
>>> +if (n >=
Re: [FFmpeg-devel] [PATCH v2 3/4] avcodec/aarch64/hevcdsp: add idct_dc NEON
On Thu, 4 Feb 2021, Josh Dekker wrote:
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 54 +++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 16 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index 329038a958..d3902a9e0f 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -5,6 +5,7 @@
*
* Ported from arm/hevcdsp_idct_neon.S by
* Copyright (c) 2020 Reimar Döffinger
+ * Copyright (c) 2020 Josh Dekker
*
* This file is part of FFmpeg.
*
@@ -568,3 +569,56 @@ tr_16x4 secondpass_10, 20 - 10, 512, 1
idct_16x16 8
idct_16x16 10
+
+// void ff_hevc_idct_NxN_dc_DEPTH_neon(int16_t *coeffs)
+.macro idct_dc size bitdepth
This needs a comma between size and bitdepth. Normally, commas are
optional, but when targeting darwin, commas between macro arguments (both
in the declaration like this, and when invoking macros) are mandatory (due
to backwards compatibility with a different macro syntax in legacy gas on
darwin platforms, I think).
+function ff_hevc_idct_\size\()x\size\()_dc_\bitdepth\()_neon, export=1
+ldrsh w1, [x0]
The indentation of your new code differs from the rest of the existing
code in the file
+mov w2, #(1 << (13 - \bitdepth))
+add w1, w1, #1
+asr w1, w1, #1
+add w1, w1, w2
+asr w1, w1, #(14 - \bitdepth)
The function is a bit slower than expected in some cases; on Cortex A72
and A73, it's actually slower than what GCC produces for small block
sizes:
Cortex A53 A72 A73
hevc_idct_4x4_dc_8_c: 25.511.7 14.7
hevc_idct_4x4_dc_8_neon:15.512.5 15.5
However these 5 instructions above can be replaced with just these three:
mov w2, #((1 << (14 - \bitdepth))+1)
add w1, w1, w2
asr w1, w1, #(15 - \bitdepth)
With that change, I get it down to this:
hevc_idct_4x4_dc_8_neon:12.710.2 13.5
So then it's universally faster than the C code at least.
A different alternative is this:
moviv1.8h, #((1 << (14 - \bitdepth))+1)
ld1r{v4.8h}, [x0]
add v4.8h, v4.8h, v1.8h
sshrv0.8h, v4.8h, #(15 - \bitdepth)
sshrv1.8h, v4.8h, #(15 - \bitdepth)
.if \size > 4
sshrv2.8h, v4.8h, #(15 - \bitdepth)
sshrv3.8h, v4.8h, #(15 - \bitdepth)
(The reason for doing 4 sshr instructions, instead of just doing 1
followed by 3 dups, is that this allows all of them to start possibly in
parallel, as soon as the result of the add is available, instead of having
a second dup instruction waiting for the result from the sshr.)
That produces the following numbers:
hevc_idct_4x4_dc_8_neon:12.711.5 9.2
I.e. a tiny bit slower than the previous on A72, and faster on A73, but
also a viable alternative.
One could also consider this prologue:
ld1r{v4.8h}, [x0]
srshr v4.8h, v4.8h, #1
srshr v0.8h, v4.8h, #(14 - \bitdepth)
srshr v1.8h, v4.8h, #(14 - \bitdepth)
.if \size > 4
srshr v2.8h, v4.8h, #(14 - \bitdepth)
srshr v3.8h, v4.8h, #(14 - \bitdepth)
But that's a worse combination overall:
hevc_idct_4x4_dc_8_neon:13.512.5 10.2
+dup v0.8h, w1
+dup v1.8h, w1
+.if \size > 4
+dup v2.8h, w1
+dup v3.8h, w1
+.if \size > 16 /* dc 32x32 */
+mov x2, #4
+1:
+subsx2, x2, #1
+.endif
+addx12, x0, #64
+movx13, #128
+.if \size > 8 /* dc 16x16 */
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+.endif /* dc 8x8 */
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+.if \size > 16 /* dc 32x32 */
+bne 1b
+.endif
+.else /* dc 4x4 */
+st1 {v0.8h-v1.8h}, [x0]
+.endif
+ret
+endfunc
+.endm
+
+idct_dc 4 8
+idct_dc 4 10
+
+idct_dc 8 8
+idct_dc 8 10
+
+idct_dc 16 8
+idct_dc 16 10
+
+idct_dc 32 8
+idct_dc 32 10
Missing commas between the macro arguments.
// Martin
___
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 v2 2/4] avcodec/aarch64/hevcdsp: port add_residual functions
On Thu, 4 Feb 2021, Josh Dekker wrote:
From: Reimar Döffinger
Speedup is fairly small, around 1.5%, but these are fairly simple.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 190 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 24 +++
2 files changed, 214 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index c70d6a906d..329038a958 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -36,6 +36,196 @@ const trans, align=4
.short 31, 22, 13, 4
endconst
+.macro clip10 in1, in2, c1, c2
+smax\in1, \in1, \c1
+smax\in2, \in2, \c1
+smin\in1, \in1, \c2
+smin\in2, \in2, \c2
+.endm
+
+function ff_hevc_add_residual_4x4_8_neon, export=1
+ld1 {v0.8h-v1.8h}, [x1]
+ld1 {v2.s}[0], [x0], x2
+ld1 {v2.s}[1], [x0], x2
+ld1 {v2.s}[2], [x0], x2
+ld1 {v2.s}[3], [x0], x2
+sub x0, x0, x2, lsl #2
+uxtlv6.8h, v2.8B
+uxtl2 v7.8h, v2.16B
Personal preference: I prefer the non-shouty forms like v2.16b instead of
v2.16B.
+sqadd v0.8h, v0.8h, v6.8h
+sqadd v1.8h, v1.8h, v7.8h
Nit: Incosistent alignment between columns 1-2 and 2-3. (And if one would
want to make space for full sized operands like v16.16b, they'd all need
another space.)
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+st1 {v0.s}[0], [x0], x2
+st1 {v0.s}[1], [x0], x2
+st1 {v0.s}[2], [x0], x2
+st1 {v0.s}[3], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_4x4_10_neon, export=1
+mov x12, x0
+ld1 {v0.8h-v1.8h}, [x1]
+ld1 {v2.d}[0], [x12], x2
+ld1 {v2.d}[1], [x12], x2
+ld1 {v3.d}[0], [x12], x2
+sqadd v0.8h, v0.8h, v2.8h
+ld1 {V3.d}[1], [x12], x2
+moviv4.8h, #0
+sqadd v1.8h, v1.8h, v3.8h
+mvniv5.8h, #0xFC, LSL #8 // movi #0x3FF
+clip10 v0.8h, v1.8h, v4.8h, v5.8h
+st1 {v0.d}[0], [x0], x2
+st1 {v0.d}[1], [x0], x2
+st1 {v1.d}[0], [x0], x2
+st1 {v1.d}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_8_neon, export=1
+add x12, x0, x2
+add x2, x2, x2
+mov x3, #8
+1: subsx3, x3, #2
Nit: Odd vertical alignment here?
+ld1 {v2.d}[0], [x0]
+ld1 {v2.d}[1], [x12]
+uxtlv3.8h, v2.8B
+ld1 {v0.8h-v1.8h}, [x1], #32
+uxtl2 v2.8h, v2.16B
+sqadd v0.8h, v0.8h, v3.8h
+sqadd v1.8h, v1.8h, v2.8h
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+st1 {v0.d}[0], [x0], x2
+st1 {v0.d}[1], [x12], x2
+bne 1b
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_10_neon, export=1
+add x12, x0, x2
+add x2, x2, x2
+mov x3, #8
+moviv4.8h, #0
+mvniv5.8h, #0xFC, LSL #8 // movi #0x3FF
+1: subsx3, x3, #2
+ld1 {v0.8h-v1.8h}, [x1], #32
+ld1 {v2.8h},[x0]
+sqadd v0.8h, v0.8h, v2.8h
+ld1 {v3.8h},[x12]
+sqadd v1.8h, v1.8h, v3.8h
+clip10 v0.8h, v1.8h, v4.8h, v5.8h
+st1 {v0.8h}, [x0], x2
+st1 {v1.8h}, [x12], x2
+bne 1b
+ret
+endfunc
+
+function ff_hevc_add_residual_16x16_8_neon, export=1
+mov x3, #16
+add x12, x0, x2
+add x2, x2, x2
+1: subsx3, x3, #2
+ld1 {v16.16B}, [x0]
+ld1 {v0.8h-v3.8h}, [x1], #64
+ld1 {v19.16B},[x12]
+uxtlv17.8h, v16.8B
+uxtl2 v18.8h, v16.16B
+uxtlv20.8h, v19.8B
+uxtl2 v21.8h, v19.16B
+sqadd v0.8h, v0.8h, v17.8h
+sqadd v1.8h, v1.8h, v18.8h
+sqadd v2.8h, v2.8h, v20.8h
+sqadd v3.8h, v3.8h, v21.8h
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+sqxtun v1.8B, v2.8h
+sqxtun2 v1.16B, v3.8h
+st1 {v0.16B}, [x0], x2
+st1
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/aarch64/hevcdsp: port SIMD idct functions
On Thu, 4 Feb 2021, Josh Dekker wrote: From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. Signed-off-by: Josh Dekker --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 380 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 430 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e40da..2ea1d74a38 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 00..c70d6a906d --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,380 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8h +sqrshrn2\d\dt, \n\().4s, \m + .else +sqrshrn \n\().4h, \n\().4s, \m +mov \d\().d[0], \n\().d[0] + .endif +.endm Just mentioning it again even though it was brought up in the previous review; this looks pretty clumsy, and causes stalls on in-order cores. I understand that this comes from trying to port the existing arm assembly with as little modification as possible. It would be good to look into restructuring things so we don't need contraptions like this - but as the patch itself gives good speedup as is (3.9-9x speedup over unvectorized code from GCC 7), I guess one could file that under "future work", not a requirement per se. + +// uses and clobbers v28-v31 as temp registers +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, p1, p2 + sshll\p1 v28.4s, \in0, #6 + movv29.16b, v28.16b + smull\p1 v30.4s, \in1, v0.h[1] + smull\p1 v31.4s, \in1, v0.h[3] Nit: Vertical alignment could be a bit more consistent, but it's hard to keep it sensible in macro-heavy code anyway. + smlal\p2 v28.4s, \in2, v0.h[0] //e0 + smlsl\p2 v29.4s, \in2, v0.h[0] //e1 + smlal\p2 v30.4s, \in3, v0.h[3] //o0 + smlsl\p2 v31.4s, \in3, v0.h[1] //o1 + + add\out0, v28.4s, v30.4s + add\out1, v29.4s, v31.4s + sub\out2, v29.4s, v31.4s + sub\out3, v28.4s, v30.4s +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8h, \r0\().8h, \r1\().8h +trn2v3.8h, \r0\().8h, \r1\().8h +trn1v4.8h,
Re: [FFmpeg-devel] [PATCH V2 08/10] libavutil: add side data AVDnnBoundingBox for dnn based detect/classify filters
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: 2021年2月11日 6:19
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 08/10] libavutil: add side data
> AVDnnBoundingBox for dnn based detect/classify filters
>
> On 10/02/2021 09:34, Guo, Yejun wrote:
> > Signed-off-by: Guo, Yejun
> > ---
> > doc/APIchanges | 2 ++
> > libavutil/Makefile | 1 +
> > libavutil/dnn_bbox.h | 68
>
> > libavutil/frame.c| 1 +
> > libavutil/frame.h| 7 +
> > libavutil/version.h | 2 +-
> > 6 files changed, 80 insertions(+), 1 deletion(-)
> > create mode 100644 libavutil/dnn_bbox.h
>
> What is the intended consumer of this box information? (Is there some other
> filter which will read these are do something with them, or some sort of user
> program?)
>
> If there is no use in ffmpeg outside libavfilter then the header should
> probably
> be in libavfilter.
Thanks for the feedback.
For most case, other filters will use this box information,
for example, a classify filter will recognize the car number after the car
plate is detected,
another filter can apply 'beauty' if a face is detected, and updated drawbox
filter (in plan)
can draw the box for visualization, and a new filter such as bbox_to_roi can be
added
to apply roi encoding for the detected result.
It is possible that some others will use it,
for example, the new codec is adding AI labels and so libavcodec might need it
in the future,
and a user program might do something special such as:
1. use libavcodec to decode
2. use filter detect
3. write his own code to handle the detect result
As the first step, how about to put it in the libavfilter (so do not expose it
at API level and we are free to change it when needed)? And we can move
it to libavutil once it is required.
>
> How tied is this to the DNN implementation, and hence the DNN name? If
> someone made a standalone filter doing object detection by some other
> method, would it make sense for them to reuse this structure?
Yes, this structure is general, I add dnn prefix because of two reasons:
1. There's already bounding box in libavfilter/bbox.h, see below, it's simple
and we could
not reuse it, so we need a new name.
typedef struct FFBoundingBox {
int x1, x2, y1, y2;
} FFBoundingBox;
2. DNN is currently the dominate method for object detection.
How about to use 'struct BoudingBox' when it is under libavfilter (added into
current file bbox.h),
and rename to 'AVBoudingBox' when it is needed to move to libavutil?
>
> > diff --git a/libavutil/dnn_bbox.h b/libavutil/dnn_bbox.h new file mode
> > 100644 index 00..50899c4486
> > --- /dev/null
> > +++ b/libavutil/dnn_bbox.h
> > +
> > +/**
> > + * Object detection is usually applied to a smaller image that
> > + * is scaled down from the original frame.
> > + * width and height are attributes of the scaled image, in pixel.
> > + */
> > +int model_input_width;
> > +int model_input_height;
>
> Other than to interpret the distances below, what will the user do with this
> information? (Alternatively: why not map the distances back onto the
> original frame size?)
My idea was: if the original frame is scaled sometime later, the side data
(bbox)
keeps correct without any modification.
If we use the distance on the original frame size, shall we say the behavior
is undefined when it is scaled sometime later?
>
> > +
> > +/**
> > + * Distance in pixels from the top edge of the scaled image to top
> > + * and bottom, and from the left edge of the scaled image to left and
> > + * right, defining the bounding box.
> > + */
> > +int top;
> > +int left;
> > +int bottom;
> > +int right;
> > +
> > +/**
> > + * Detect result
> > + */
> > +int detect_label;
>
> How does a user interpret this label? Is it from some known enum?
The mappings between label_id (int) and label_name (string) are not part of
the model file, it is usually another file provided together with the model
file.
The mappings are specific with the model file.
My idea was to provide the mapping file only when it is needed, for example,
when draw the box and text with filter drawbox/drawtext to visualize the
bounding box.
If we don't care the size in side_data, we can add label name into this struct,
for example.
#define BBOX_LABEL_NAME_MAX_LENGTH 32
int detect_label_id;
char detect_label_name[BBOX_LABEL_NAME_MAX_LENGTH+1];
int classify_label_ids[AV_NUM_BBOX_CLASSIFY];
char classify_label_names[AV_NUM_BBOX_CLASSIFY][ BBOX_LABEL_NAME_MAX_LENGTH+1]
>
> > +AVRational detect_conf;
>
> "conf"... idence? A longer name and a descriptive comment might help.
sure, will change to detect_confidence and classify_confidences[]
>
> > +
> > +/**
> > + * At most 4 classifications based on the detected bounding box.
> > + * For example, we can get max 4
