Re: [FFmpeg-devel] [PATCH 2/3] libavformat/hls: add support for decryption of HLS streams in MPEG-TS format protected using SAMPLE-AES encryption
On Wed, Mar 3, 2021 at 11:15 AM Nachiket Tarate wrote: > > On Mon, Mar 1, 2021 at 1:05 PM Steven Liu wrote: > > > > > > > > > 2021年3月1日 下午3:22，Nachiket Tarate 写道： > > > > > > On Mon, Mar 1, 2021 at 11:30 AM Steven Liu wrote: > > >> > > >> > > >> > > >>> 2021年3月1日 下午12:55，Nachiket Tarate 写道： > > >>> > > >>> This is an updated version of the patch in which I have added the > > >>> check. If > > >>> the segments are in Fragmented MP4 format, HLS demuxer quits by giving > > >>> an > > >>> error message: > > >>> > > >>> "SAMPLE-AES encryption is not supported for fragmented MP4 format yet” > > >> I don’t think is a good resolution for SAMPLE-AES encryption and > > >> decryption. > > >> You should support that if you want support SAMPLE-AES in hls, > > >> because SAMPLE-AES not only support in MPEG-TS, but also support > > >> fragment mp4. > > >> Whatever, if you only support mpegts en[de]cryption, it should be a half > > >> part patch. > > > > > > Two completely different technologies/specifications have been used > > > for SAMPLE-AES encryption of HLS streams in MPEG-TS and fragmented MP4 > > > formats. > > > > > > Fragmented MP4 media segments are encrypted using the 'cbcs' scheme of > > > Common Encryption [CENC]: > > > > > > https://www.iso.org/standard/68042.html > > > > > > Encryption of other media segment formats such as MPEG-TS or external > > > audio tracks containing H.264, AAC, AC-3 and Enhanced AC-3 media > > > streams is described in the Apple's HTTP Live Streaming (HLS) Sample > > > Encryption specifications: > > > > > > https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption > > > > > > This patch implements the later specifications and enables decryption > > > of media segments in MPEG-TS, AAC, AC-3 and Enhanced AC-3 formats. So > > > I think we should merge this patch right now. > > > > I think sample ads should support not only mpegts, but also support fmp4 > > too. > > Reference rfc8216 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. > > Your understanding of SAMPLE-AES is absolutely correct. > > I am insisting that let us add support for it in 2 phases as > completely 2 different specifications have been used. > > Phase 1 : Media segments in MPEG-TS, AAC, AC-3 and Enhanced AC-3 > formats (Apple's specifications) > > Phase 2 : Media segments in fragmented MP4 format (CENC specifications) > > Kindly let me know your opinion. Hello Steven, I am looking forward to hearing from you. Best Regards, Nachiket > > > > > > > In future, we will add support for CENC or see how can we use existing > > > things from MOV demuxer. > > > > > > Best Regards, > > > Nachiket Tarate > > > > > >>> > > >>> Best Regards, > > >>> Nachiket Tarate > > >>> > > >>> On Mon, Mar 1, 2021 at 10:13 AM Steven Liu wrote: > > >>> > > > > > > > 2021年3月1日 下午12:35，Nachiket Tarate 写道： > > > > > > @Steven Liu > > > > > > Can we merge this patch ? > > I’m waiting update patch for fragment mp4 encryption. > > After new version of the patchset I will test and review. > > > > > > Best Regards, > > > Nachiket Tarate > > > > > > On Wed, Feb 24, 2021 at 4:44 PM Nachiket Tarate < > > > nachiket.program...@gmail.com> wrote: > > > > > >> 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| 105 -- > > >> libavformat/hl
Re: [FFmpeg-devel] [PATCH]lavf/sga: Fix several format specifiers
Quoting Carl Eugen Hoyos (2021-03-04 22:47:57) > Am Do., 4. März 2021 um 22:23 Uhr schrieb Moritz Barsnick : > > > > On Thu, Mar 04, 2021 at 20:37:26 +0100, Carl Eugen Hoyos wrote: > > > attached patch fixes a few warnings when compiling for 32bit. > > > > > av_log(s, AV_LOG_DEBUG, "START %s\n", where); > > > -av_log(s, AV_LOG_DEBUG, "pos: %lX\n", avio_tell(s->pb)); > > > +av_log(s, AV_LOG_DEBUG, "pos: %"PRIX64"\n", avio_tell(s->pb)); > > > > #include > > It is included through common.h - do we add it to every C file > that would need it if common.h were not included? Yes, every file should explicitly include all the headers it directly uses. There was a recent discussion about this. -- Anton Khirnov ___ 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 decryption of HLS streams in MPEG-TS format protected using SAMPLE-AES encryption
> 2021年3月8日 下午3:15，Nachiket Tarate 写道： >> >> Your understanding of SAMPLE-AES is absolutely correct. >> >> I am insisting that let us add support for it in 2 phases as >> completely 2 different specifications have been used. >> >> Phase 1 : Media segments in MPEG-TS, AAC, AC-3 and Enhanced AC-3 >> formats (Apple's specifications) >> >> Phase 2 : Media segments in fragmented MP4 format (CENC specifications) >> >> Kindly let me know your opinion. > > Hello Steven, > > I am looking forward to hearing from you. You could make 4 or 5 patch merge two phase to one patchset. > > Best Regards, > Nachiket Thanks Steven Liu ___ 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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Quoting Guo, Yejun (2021-03-08 06:05:20)
> Signed-off-by: Guo, Yejun
> ---
> doc/APIchanges| 2 ++
> libavutil/frame.c | 1 +
> libavutil/frame.h | 5 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4027d599e7..b83409a412 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,8 @@ libavutil: 2017-10-21
>
>
> API changes, most recent first:
> +2021-03-xx - xx - lavu 56.xx.100 - frame.h
> + Add AV_FRAME_DATA_BOUNDING_BOXES
>
> 2021-03-04 - xx - lavc 58.128.101 - avcodec.h
>Enable err_recognition to be set for encoders.
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index eab51b6a32..53868a2410 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -852,6 +852,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> case AV_FRAME_DATA_VIDEO_ENC_PARAMS:return "Video encoding
> parameters";
> case AV_FRAME_DATA_SEI_UNREGISTERED:return "H.26[45] User
> Data Unregistered SEI message";
> case AV_FRAME_DATA_FILM_GRAIN_PARAMS: return "Film grain
> parameters";
> +case AV_FRAME_DATA_BOUNDING_BOXES: return "Bounding boxes";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 1aeafef6de..3fbe15c47e 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -198,6 +198,11 @@ enum AVFrameSideDataType {
> * Must be present for every frame which should have film grain applied.
> */
> AV_FRAME_DATA_FILM_GRAIN_PARAMS,
> +
> +/**
> + * The data is for internal use by libavfilter.
I do not like this. We should not have internal side data unless there
is a strong reason for it. There is nothing about this side data that
makes it inherently lavfi-specific.
--
Anton Khirnov
___
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] cmdutils: replace strncpy() with equivalent memcpy()
Fixes truncation warnings, such as
warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from
a string of the same length [-Wstringop-truncation]
in gcc 10.2.0
---
fftools/cmdutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 8cfca22564..505006cd8b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1163,13 +1163,13 @@ static void print_buildconf(int flags, int level)
// Change all the ' --' strings to '~--' so that
// they can be identified as tokens.
while ((conflist = strstr(str, " --")) != NULL) {
-strncpy(conflist, "~--", 3);
+memcpy(conflist, "~--", 3);
}
// Compensate for the weirdness this would cause
// when passing 'pkg-config --static'.
while ((remove_tilde = strstr(str, "pkg-config~")) != NULL) {
-strncpy(remove_tilde, "pkg-config ", 11);
+memcpy(remove_tilde, "pkg-config ", 11);
}
splitconf = strtok(str, "~");
--
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 2/2] avcodec/mediacodec_wrapper: use MediaCodecInfo.isSoftwareOnly() when available
On Wed, Feb 17, 2021 at 04:51:09PM +0100, sfan5 wrote:
>
> From 22ebde779f61fb030633a881ef320264ea446b6b Mon Sep 17 00:00:00 2001
> From: sfan5
> Date: Thu, 11 Feb 2021 20:48:54 +0100
> Subject: [PATCH 2/2] avcodec/mediacodec_wrapper: use
> MediaCodecInfo.isSoftwareOnly() when available
>
> Added in Android 10 it provides a reliable way of filtering out
> software decoders, unlike existing string-based checks.
> ---
> libavcodec/mediacodec_wrapper.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index f1945bcfc0..c829941d6b 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -45,6 +45,7 @@ struct JNIAMediaCodecListFields {
> jmethodID get_codec_capabilities_id;
> jmethodID get_supported_types_id;
> jmethodID is_encoder_id;
> +jmethodID is_software_only_id;
>
> jclass codec_capabilities_class;
> jfieldID color_formats_id;
> @@ -81,6 +82,7 @@ static const struct FFJniField
> jni_amediacodeclist_mapping[] = {
> { "android/media/MediaCodecInfo", "getCapabilitiesForType",
> "(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;",
> FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields,
> get_codec_capabilities_id), 1 },
> { "android/media/MediaCodecInfo", "getSupportedTypes",
> "()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct
> JNIAMediaCodecListFields, get_supported_types_id), 1 },
> { "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD,
> offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
> +{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z",
> FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields,
> is_software_only_id), 0 },
>
> { "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL,
> FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields,
> codec_capabilities_class), 1 },
> { "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats",
> "[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields,
> color_formats_id), 1 },
> @@ -441,6 +443,17 @@ char *ff_AMediaCodecList_getCodecNameByType(const char
> *mime, int profile, int e
> goto done_with_info;
> }
>
> +if (jfields.is_software_only_id) {
> +int is_software_only = (*env)->CallBooleanMethod(env, info,
> jfields.is_software_only_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
> +
> +if (is_software_only) {
> +goto done_with_info;
> +}
> +}
> +
> codec_name = (*env)->CallObjectMethod(env, info,
> jfields.get_name_id);
> if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> goto done;
> --
> 2.30.1
>
LGTM, I'll push the patch in two days if there is no objection.
Thanks,
--
Matthieu B.
___
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 v4 2/2] avformat/gopher: Add support for Gopher over TLS.
Bump for review. ___ 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]lavf/sga: Fix several format specifiers
On Mon, Mar 8, 2021 at 9:22 AM Anton Khirnov wrote: > Quoting Carl Eugen Hoyos (2021-03-04 22:47:57) > > Am Do., 4. März 2021 um 22:23 Uhr schrieb Moritz Barsnick < > barsn...@gmx.net>: > > > > > > On Thu, Mar 04, 2021 at 20:37:26 +0100, Carl Eugen Hoyos wrote: > > > > attached patch fixes a few warnings when compiling for 32bit. > > > > > > > av_log(s, AV_LOG_DEBUG, "START %s\n", where); > > > > -av_log(s, AV_LOG_DEBUG, "pos: %lX\n", avio_tell(s->pb)); > > > > +av_log(s, AV_LOG_DEBUG, "pos: %"PRIX64"\n", avio_tell(s->pb)); > > > > > > #include > > > > It is included through common.h - do we add it to every C file > > that would need it if common.h were not included? > > Yes, every file should explicitly include all the headers it directly > uses. There was a recent discussion about this. > That would make bunch of headers needed to be added to every single file. I do not remember such discussion ever take place. > -- > Anton Khirnov > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Re: [PATCH 4/7] avcodec/h261dec: Remove parse_context cruft
Quoting Andreas Rheinhardt (2020-12-25 16:47:21) > The H.261 decoder doesn't use the ParseContext of its > MpegEncContext since e7316976650b429345da619c3acff38004aaf6b8. > > Signed-off-by: Andreas Rheinhardt > --- Looks good, please push. > Does actually anybody use the AV_CODEC_FLAG_TRUNCATED (MpegEncContext > contains a ParseContext because of this flag)? I will send a patch to deprecate it shortly. -- Anton Khirnov ___ 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] mobiclip: fix copyright headers
0001-mobiclip-fix-copyright-headers.patch Description: Binary data ___ 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] lavc: deprecate AV_CODEC_FLAG_TRUNCATED
It is supported only by two decoders and is entirely redundant with
parsers.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 4
libavcodec/decode.c| 6 +-
libavcodec/h263dec.c | 10 --
libavcodec/mpeg12dec.c | 12 +++-
libavcodec/mpegvideo.c | 6 ++
libavcodec/mpegvideo.h | 2 ++
libavcodec/options_table.h | 2 ++
libavcodec/pthread.c | 2 ++
libavcodec/version.h | 3 +++
10 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4027d599e7..344f484a8b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-03-xx - xx - avcodec.h
+ Deprecate AV_CODEC_FLAG_TRUNCATED, as it is redundant with parsers.
+
2021-03-04 - xx - lavc 58.128.101 - avcodec.h
Enable err_recognition to be set for encoders.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 46d31b34ad..45929d6b05 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -310,11 +310,15 @@ typedef struct RcOverride{
* error[?] variables will be set during encoding.
*/
#define AV_CODEC_FLAG_PSNR(1 << 15)
+#if FF_API_FLAG_TRUNCATED
/**
* Input bitstream might be truncated at a random location
* instead of only at frame boundaries.
+ *
+ * @deprecated use codec parsers for packetizing input
*/
#define AV_CODEC_FLAG_TRUNCATED (1 << 16)
+#endif
/**
* Use interlaced DCT.
*/
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index c976795311..c00069b8d4 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -462,7 +462,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!got_frame)
av_frame_unref(frame);
-if (ret >= 0 && avctx->codec->type == AVMEDIA_TYPE_VIDEO && !(avctx->flags
& AV_CODEC_FLAG_TRUNCATED))
+if (ret >= 0 && avctx->codec->type == AVMEDIA_TYPE_VIDEO
+#if FF_API_FLAG_TRUNCATED
+&& !(avctx->flags & AV_CODEC_FLAG_TRUNCATED)
+#endif
+)
ret = pkt->size;
#if FF_API_AVCTX_TIMEBASE
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index dafa54d8d4..57d4a0d4e7 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -172,13 +172,17 @@ static int get_consumed_bytes(MpegEncContext *s, int
buf_size)
/* We would have to scan through the whole buf to handle the weird
* reordering ... */
return buf_size;
-} else if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
+}
+#if FF_API_FLAG_TRUNCATED
+else if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
pos -= s->parse_context.last_index;
// padding is not really read so this might be -1
if (pos < 0)
pos = 0;
return pos;
-} else {
+}
+#endif
+else {
// avoid infinite loops (maybe not needed...)
if (pos == 0)
pos = 1;
@@ -443,6 +447,7 @@ int ff_h263_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
return 0;
}
+#if FF_API_FLAG_TRUNCATED
if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
int next;
@@ -462,6 +467,7 @@ int ff_h263_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
&buf_size) < 0)
return buf_size;
}
+#endif
retry:
if (s->divx_packed && s->bitstream_buffer_size) {
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 92dd6a0b24..9e1f9c4b79 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1267,10 +1267,14 @@ static int mpeg_decode_postinit(AVCodecContext *avctx)
(s1->save_progressive_seq != s->progressive_sequence &&
FFALIGN(s->height, 16) != FFALIGN(s->height, 32)) ||
0) {
if (s1->mpeg_enc_ctx_allocated) {
+#if FF_API_FLAG_TRUNCATED
ParseContext pc = s->parse_context;
s->parse_context.buffer = 0;
ff_mpv_common_end(s);
s->parse_context = pc;
+#else
+ff_mpv_common_end(s);
+#endif
s1->mpeg_enc_ctx_allocated = 0;
}
@@ -2506,7 +2510,11 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame
*picture,
if (avctx->err_recognition & AV_EF_EXPLODE && s2->er.error_count)
return AVERROR_INVALIDDATA;
-return FFMAX(0, buf_ptr - buf - s2->parse_context.last_index);
+return FFMAX(0, buf_ptr - buf
+#if FF_API_FLAG_TRUNCATED
+ - s2->parse_context.last_index
+#endif
+);
}
input_size = buf_end - buf_ptr;
@@ -2812,6 +2820,7 @@ static int mpeg_decode_frame(AVCodecContext *avctx, void
*data,
return buf_size;
}
+#if FF_API_FLAG_TRUNCATED
if (s2->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
int next = ff_mpeg1_find_frame_end(&s2->parse_context, buf,
buf_size, NULL);
@@ -2820,6 +2829,7 @@ static
[FFmpeg-devel] [PATCH 2/2] Revert "fate: Add test for ticket 6024, truncated decoding mode"
This reverts commit 47cd8effea343e71c4010929ed3fb10dd3dca4b1. AV_CODEC_FLAG_TRUNCATED is now deprecated. --- tests/fate/video.mak| 3 --- tests/ref/fate/mpeg2-ticket6024 | 27 --- 2 files changed, 30 deletions(-) delete mode 100644 tests/ref/fate/mpeg2-ticket6024 diff --git a/tests/fate/video.mak b/tests/fate/video.mak index d6b5770aba..dff1f13e88 100644 --- a/tests/fate/video.mak +++ b/tests/fate/video.mak @@ -251,9 +251,6 @@ FATE_VIDEO-$(call DEMDEC, MPEGTS, MPEG2VIDEO) += fate-mpeg2-field-enc fate-mpeg2 fate-mpeg2-field-enc: CMD = framecrc -flags +bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -an -frames:v 30 fate-mpeg2-ticket186: CMD = framecrc -flags +bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/t.mpg -an -FATE_VIDEO-$(call DEMDEC, MPEGPS, MPEG2VIDEO) += fate-mpeg2-ticket6024 -fate-mpeg2-ticket6024: CMD = framecrc -flags +bitexact -idct simple -flags +truncated -i $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg -an - FATE_VIDEO-$(call DEMDEC, MPEGVIDEO, MPEG2VIDEO) += fate-mpeg2-ticket6677 fate-mpeg2-ticket6677: CMD = framecrc -flags +bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/sony-ct3.bs diff --git a/tests/ref/fate/mpeg2-ticket6024 b/tests/ref/fate/mpeg2-ticket6024 deleted file mode 100644 index bd416240f3..00 --- a/tests/ref/fate/mpeg2-ticket6024 +++ /dev/null @@ -1,27 +0,0 @@ -#tb 0: 1/25 -#media_type 0: video -#codec_id 0: rawvideo -#dimensions 0: 716x236 -#sar 0: 1/1 -0, 2, 2,1, 253464, 0xc51a46f9 -0, 4, 4,1, 253464, 0xd0661651 -0, 5, 5,1, 253464, 0x38a213b3 -0, 6, 6,1, 253464, 0x038a5118 -0, 7, 7,1, 253464, 0xebd8de64 -0, 8, 8,1, 253464, 0x0b319ee0 -0, 9, 9,1, 253464, 0x37b03a45 -0, 10, 10,1, 253464, 0x5f9c89ae -0, 11, 11,1, 253464, 0x88ad9c08 -0, 12, 12,1, 253464, 0x387198bc -0, 13, 13,1, 253464, 0xf3933eb6 -0, 14, 14,1, 253464, 0x9bd27b98 -0, 15, 15,1, 253464, 0x9442c538 -0, 16, 16,1, 253464, 0x330be2a4 -0, 17, 17,1, 253464, 0xb4b8c1df -0, 18, 18,1, 253464, 0xc97ded34 -0, 19, 19,1, 253464, 0xcad936e0 -0, 20, 20,1, 253464, 0x11a2850d -0, 21, 21,1, 253464, 0x2545ad23 -0, 22, 22,1, 253464, 0xa5e17c47 -0, 23, 23,1, 253464, 0x39452689 -0, 24, 24,1, 253464, 0x1daefd72 -- 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] avutil/hwcontext_d3d11va: Support DXGI_FORMAT_B8G8R8A8_UNORM encoding
From: you74674
Support using DXGI_FORMAT_B8G8R8A8_UNORM format ID3D11Texture2D
texture as AVCodecContext->hw_frames_ctx for encoding.
AV_PIX_FMT_0RGB32 is used here because in libavcodec/nvenc.c, it is
mapped to NV_ENC_BUFFER_FORMAT_ARGB, which is mapped to
DXGI_FORMAT_B8G8R8A8_UNORM in sample code from NvCodec.
---
libavutil/hwcontext_d3d11va.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index c8ae58f908..14c2fe562e 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -88,6 +88,7 @@ static const struct {
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
+{ DXGI_FORMAT_B8G8R8A8_UNORM, AV_PIX_FMT_0RGB32 }
};
static void d3d11va_default_lock(void *ctx)
--
2.28.0.windows.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] mobiclip: fix copyright headers
The Mobiclip related code was based on Mobius (https://github.com/adibsurani/Mobius), which was based on my original reverse engineering efforts (https://github.com/Gericom/MobiclipDecoder). This commit adds the appropriate copyright headers on the related files. Signed-off-by: Florian Nouwt --- libavcodec/fastaudio.c | 2 ++ libavcodec/mobiclip.c | 1 + libavformat/mods.c | 2 ++ libavformat/moflex.c | 2 ++ 4 files changed, 7 insertions(+) diff --git a/libavcodec/fastaudio.c b/libavcodec/fastaudio.c index e50678cd3d..9de42d2134 100644 --- a/libavcodec/fastaudio.c +++ b/libavcodec/fastaudio.c @@ -1,5 +1,7 @@ /* * MOFLEX Fast Audio decoder + * Copyright (c) 2015-2016 Florian Nouwt + * Copyright (c) 2017 Adib Surani * Copyright (c) 2020 Paul B Mahol * * This file is part of FFmpeg. diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c index 9392ab947e..bf47a5bc41 100644 --- a/libavcodec/mobiclip.c +++ b/libavcodec/mobiclip.c @@ -1,5 +1,6 @@ /* * MobiClip Video decoder + * Copyright (c) 2015-2016 Florian Nouwt * Copyright (c) 2017 Adib Surani * Copyright (c) 2020 Paul B Mahol * diff --git a/libavformat/mods.c b/libavformat/mods.c index 4f093cdf0c..a26db87e6c 100644 --- a/libavformat/mods.c +++ b/libavformat/mods.c @@ -1,5 +1,7 @@ /* * MODS demuxer + * Copyright (c) 2015-2016 Florian Nouwt + * Copyright (c) 2017 Adib Surani * Copyright (c) 2020 Paul B Mahol * * This file is part of FFmpeg. diff --git a/libavformat/moflex.c b/libavformat/moflex.c index 8142925adc..41335ada78 100644 --- a/libavformat/moflex.c +++ b/libavformat/moflex.c @@ -1,5 +1,7 @@ /* * MOFLEX demuxer + * Copyright (c) 2015-2016 Florian Nouwt + * Copyright (c) 2017 Adib Surani * Copyright (c) 2020 Paul B Mahol * * This file is part of FFmpeg. -- 2.18.0.windows.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/2] avcodec/mediacodec_wrapper: clean up ff_AMediaCodecList_getCodecNameByType a bit
On Wed, Feb 17, 2021 at 04:50:00PM +0100, sfan5 wrote:
> Hi,
>
> while looking into mediacodec for unrelated reasons I saw some room for
> improvement.
>
> Therefore, here's a series with two small patches.
>
> From cadd2b2d4a5ffbb4dcc34faf2d3e139e1d4d608b Mon Sep 17 00:00:00 2001
> From: sfan5
> Date: Thu, 11 Feb 2021 19:23:26 +0100
> Subject: [PATCH 1/2] avcodec/mediacodec_wrapper: clean up
> ff_AMediaCodecList_getCodecNameByType a bit
>
> We can skip software decoders before even looking at the mime types.
> ---
> libavcodec/mediacodec_wrapper.c | 113
> 1 file changed, 57 insertions(+), 56 deletions(-)
>
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 79abc8b6aa..f1945bcfc0 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -441,6 +441,30 @@ char *ff_AMediaCodecList_getCodecNameByType(const char
> *mime, int profile, int e
> goto done_with_info;
> }
>
> +codec_name = (*env)->CallObjectMethod(env, info,
> jfields.get_name_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
> +
> +name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
> +if (!name) {
> +goto done;
> +}
> +
> +if (codec_name) {
> +(*env)->DeleteLocalRef(env, codec_name);
> +codec_name = NULL;
> +}
> +
> +/* Skip software decoders */
> +if (
> +strstr(name, "OMX.google") ||
> +strstr(name, "OMX.ffmpeg") ||
> +(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> +!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> +goto done_with_info;
> +}
> +
> type_count = (*env)->GetArrayLength(env, types);
> for (j = 0; j < type_count; j++) {
> int k;
> @@ -456,74 +480,51 @@ char *ff_AMediaCodecList_getCodecNameByType(const char
> *mime, int profile, int e
> goto done;
> }
>
> -if (!av_strcasecmp(supported_type, mime)) {
> -codec_name = (*env)->CallObjectMethod(env, info,
> jfields.get_name_id);
> -if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> -}
> +if (av_strcasecmp(supported_type, mime)) {
> +goto done_with_type;
> +}
>
> -name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
> -if (!name) {
> -goto done;
> -}
> +capabilities = (*env)->CallObjectMethod(env, info,
> jfields.get_codec_capabilities_id, type);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
>
> -if (codec_name) {
> -(*env)->DeleteLocalRef(env, codec_name);
> -codec_name = NULL;
> -}
> +profile_levels = (*env)->GetObjectField(env, capabilities,
> jfields.profile_levels_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
>
> -/* Skip software decoders */
> -if (
> -strstr(name, "OMX.google") ||
> -strstr(name, "OMX.ffmpeg") ||
> -(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> -!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> -av_freep(&name);
> -goto done_with_type;
> +profile_count = (*env)->GetArrayLength(env, profile_levels);
> +if (!profile_count) {
> +found_codec = 1;
> +}
> +for (k = 0; k < profile_count; k++) {
> +int supported_profile = 0;
> +
> +if (profile < 0) {
> +found_codec = 1;
> +break;
> }
>
> -capabilities = (*env)->CallObjectMethod(env, info,
> jfields.get_codec_capabilities_id, type);
> +profile_level = (*env)->GetObjectArrayElement(env,
> profile_levels, k);
> if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> goto done;
> }
>
> -profile_levels = (*env)->GetObjectField(env, capabilities,
> jfields.profile_levels_id);
> +supported_profile = (*env)->GetIntField(env, profile_level,
> jfields.profile_id);
> if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> goto done;
> }
>
> -profile_count = (*env)->GetArrayLength(env, profile_levels);
> -if (!profile_count) {
> -found_codec = 1;
> +found_codec = profile == supported_profi
Re: [FFmpeg-devel] [PATCH 1/2] lavc: deprecate AV_CODEC_FLAG_TRUNCATED
Anton Khirnov:
> It is supported only by two decoders and is entirely redundant with
> parsers.
Just because it is only used in two files doesn't mean it is only used
by two decoders: Six decoders have the AV_CODEC_CAP_TRUNCATED (which you
forgot to deprecate) set.
(fftools/cmdutils.c checks for AV_CODEC_CAP_TRUNCATED and informs the
user about whether it is supported by a codec or not. It should probably
be wrapped in #if LIBAVCODEC_VERSION_MAJOR < 60 checks.)
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 4
> libavcodec/decode.c| 6 +-
> libavcodec/h263dec.c | 10 --
> libavcodec/mpeg12dec.c | 12 +++-
> libavcodec/mpegvideo.c | 6 ++
> libavcodec/mpegvideo.h | 2 ++
> libavcodec/options_table.h | 2 ++
> libavcodec/pthread.c | 2 ++
> libavcodec/version.h | 3 +++
> 10 files changed, 46 insertions(+), 4 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4027d599e7..344f484a8b 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2021-03-xx - xx - avcodec.h
Missing version
> + Deprecate AV_CODEC_FLAG_TRUNCATED, as it is redundant with parsers.
> +
> 2021-03-04 - xx - lavc 58.128.101 - avcodec.h
>Enable err_recognition to be set for encoders.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 46d31b34ad..45929d6b05 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -310,11 +310,15 @@ typedef struct RcOverride{
> * error[?] variables will be set during encoding.
> */
> #define AV_CODEC_FLAG_PSNR(1 << 15)
> +#if FF_API_FLAG_TRUNCATED
> /**
> * Input bitstream might be truncated at a random location
> * instead of only at frame boundaries.
> + *
> + * @deprecated use codec parsers for packetizing input
> */
> #define AV_CODEC_FLAG_TRUNCATED (1 << 16)
> +#endif
> /**
> * Use interlaced DCT.
> */
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c976795311..c00069b8d4 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -462,7 +462,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (!got_frame)
> av_frame_unref(frame);
>
> -if (ret >= 0 && avctx->codec->type == AVMEDIA_TYPE_VIDEO &&
> !(avctx->flags & AV_CODEC_FLAG_TRUNCATED))
> +if (ret >= 0 && avctx->codec->type == AVMEDIA_TYPE_VIDEO
> +#if FF_API_FLAG_TRUNCATED
> +&& !(avctx->flags & AV_CODEC_FLAG_TRUNCATED)
> +#endif
> +)
> ret = pkt->size;
>
> #if FF_API_AVCTX_TIMEBASE
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index dafa54d8d4..57d4a0d4e7 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -172,13 +172,17 @@ static int get_consumed_bytes(MpegEncContext *s, int
> buf_size)
> /* We would have to scan through the whole buf to handle the weird
> * reordering ... */
> return buf_size;
> -} else if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
> +}
> +#if FF_API_FLAG_TRUNCATED
> +else if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
> pos -= s->parse_context.last_index;
> // padding is not really read so this might be -1
> if (pos < 0)
> pos = 0;
> return pos;
> -} else {
> +}
> +#endif
> +else {
> // avoid infinite loops (maybe not needed...)
> if (pos == 0)
> pos = 1;
> @@ -443,6 +447,7 @@ int ff_h263_decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> return 0;
> }
>
> +#if FF_API_FLAG_TRUNCATED
> if (s->avctx->flags & AV_CODEC_FLAG_TRUNCATED) {
> int next;
>
> @@ -462,6 +467,7 @@ int ff_h263_decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> &buf_size) < 0)
> return buf_size;
> }
> +#endif
>
> retry:
> if (s->divx_packed && s->bitstream_buffer_size) {
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 92dd6a0b24..9e1f9c4b79 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -1267,10 +1267,14 @@ static int mpeg_decode_postinit(AVCodecContext *avctx)
> (s1->save_progressive_seq != s->progressive_sequence &&
> FFALIGN(s->height, 16) != FFALIGN(s->height, 32)) ||
> 0) {
> if (s1->mpeg_enc_ctx_allocated) {
> +#if FF_API_FLAG_TRUNCATED
> ParseContext pc = s->parse_context;
> s->parse_context.buffer = 0;
> ff_mpv_common_end(s);
> s->parse_context = pc;
> +#else
> +ff_mpv_common_end(s);
> +#endif
> s1->mpeg_enc_ctx_allocated = 0;
> }
>
> @@ -2506,7 +2510,11 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
> if (avctx->err_recognition & AV_EF_EXPLODE && s2->er.error_count)
> return AVER
Re: [FFmpeg-devel] [PATCH] cmdutils: replace strncpy() with equivalent memcpy()
Anton Khirnov:
> Fixes truncation warnings, such as
> warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes
> from a string of the same length [-Wstringop-truncation]
> in gcc 10.2.0
> ---
> fftools/cmdutils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 8cfca22564..505006cd8b 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -1163,13 +1163,13 @@ static void print_buildconf(int flags, int level)
> // Change all the ' --' strings to '~--' so that
> // they can be identified as tokens.
> while ((conflist = strstr(str, " --")) != NULL) {
> -strncpy(conflist, "~--", 3);
> +memcpy(conflist, "~--", 3);
> }
>
> // Compensate for the weirdness this would cause
> // when passing 'pkg-config --static'.
> while ((remove_tilde = strstr(str, "pkg-config~")) != NULL) {
> -strncpy(remove_tilde, "pkg-config ", 11);
> +memcpy(remove_tilde, "pkg-config ", 11);
> }
>
> splitconf = strtok(str, "~");
>
Wouldn't it be more natural to just use "conflist[0] = '~'" when
changing only one character?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavc: deprecate AV_CODEC_FLAG_TRUNCATED
On 3/8/2021 9:24 AM, Andreas Rheinhardt wrote: Anton Khirnov: It is supported only by two decoders and is entirely redundant with parsers. Just because it is only used in two files doesn't mean it is only used by two decoders: Six decoders have the AV_CODEC_CAP_TRUNCATED (which you forgot to deprecate) set. (fftools/cmdutils.c checks for AV_CODEC_CAP_TRUNCATED and informs the user about whether it is supported by a codec or not. It should probably be wrapped in #if LIBAVCODEC_VERSION_MAJOR < 60 checks.) --- doc/APIchanges | 3 +++ libavcodec/avcodec.h | 4 libavcodec/decode.c| 6 +- libavcodec/h263dec.c | 10 -- libavcodec/mpeg12dec.c | 12 +++- libavcodec/mpegvideo.c | 6 ++ libavcodec/mpegvideo.h | 2 ++ libavcodec/options_table.h | 2 ++ libavcodec/pthread.c | 2 ++ libavcodec/version.h | 3 +++ 10 files changed, 46 insertions(+), 4 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 4027d599e7..344f484a8b 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2021-03-xx - xx - avcodec.h Missing version [...] diff --git a/libavcodec/version.h b/libavcodec/version.h index 169c763e8a..d3e813428b 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -162,5 +162,8 @@ Missing minor version bump. Entries in APIChanges, Changelog, and version bumps are many times skipped in patches to simplify rebasing and people applying for testing purposes since they will almost always end up conflicting with other changes pushed during the review phase, and are either added before pushing or in the last iteration of the 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".
Re: [FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Mar 8, 2021, 09:33 by an...@khirnov.net:
> Quoting Guo, Yejun (2021-03-08 06:05:20)
>
>> Signed-off-by: Guo, Yejun <>> yejun@intel.com>> >
>> ---
>> doc/APIchanges| 2 ++
>> libavutil/frame.c | 1 +
>> libavutil/frame.h | 5 +
>> 3 files changed, 8 insertions(+)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 4027d599e7..b83409a412 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -14,6 +14,8 @@ libavutil: 2017-10-21
>>
>>
>> API changes, most recent first:
>> +2021-03-xx - xx - lavu 56.xx.100 - frame.h
>> + Add AV_FRAME_DATA_BOUNDING_BOXES
>>
>> 2021-03-04 - xx - lavc 58.128.101 - avcodec.h
>> Enable err_recognition to be set for encoders.
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index eab51b6a32..53868a2410 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -852,6 +852,7 @@ const char *av_frame_side_data_name(enum
>> AVFrameSideDataType type)
>> case AV_FRAME_DATA_VIDEO_ENC_PARAMS:return "Video encoding
>> parameters";
>> case AV_FRAME_DATA_SEI_UNREGISTERED:return "H.26[45] User Data
>> Unregistered SEI message";
>> case AV_FRAME_DATA_FILM_GRAIN_PARAMS: return "Film grain
>> parameters";
>> +case AV_FRAME_DATA_BOUNDING_BOXES: return "Bounding boxes";
>> }
>> return NULL;
>> }
>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>> index 1aeafef6de..3fbe15c47e 100644
>> --- a/libavutil/frame.h
>> +++ b/libavutil/frame.h
>> @@ -198,6 +198,11 @@ enum AVFrameSideDataType {
>> * Must be present for every frame which should have film grain applied.
>> */
>> AV_FRAME_DATA_FILM_GRAIN_PARAMS,
>> +
>> +/**
>> + * The data is for internal use by libavfilter.
>>
>
> I do not like this. We should not have internal side data unless there
> is a strong reason for it. There is nothing about this side data that
> makes it inherently lavfi-specific.
>
I object to making this public. This is not something we want to be
stuck with. That's why I suggested internal_ref was used instead,
but unfortunately someone just noticed it exists, of course though
"but what if we need it for something else later, even though we've
done just fine without it until now!?!".
I still want to have internal_ref be used for this until the format
is stable enough and/or codecs which make use of this appear.
Or at least keep this patch as-is.
___
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] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions
Am 24.02.21 um 17:53 schrieb Thilo Borgmann: > Am 24.02.21 um 05:06 schrieb Zane van Iperen: >> As per discussion at [1]. Patches attached. >> >> Patch 1/3 adds /node_modules/ to .gitignore >> >> Patch 2/3 adds the actual key and verification instructions >> >> Patch 3/3 adds a prominent download link for the public key. >> This might be bit obnoxious, but it was suggested in the original discussion. >> >> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276752.html > > As in [1] above I like that idea. However, I can't really comment on the > technical side of keys and signatures. So proper someones opinion with actual > knowledge would be appreciated. If there are no complains, I'll push that soon (tm). -Thilo ___ 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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Quoting Lynne (2021-03-08 14:18:15)
> Mar 8, 2021, 09:33 by an...@khirnov.net:
>
> > Quoting Guo, Yejun (2021-03-08 06:05:20)
> >
> >> Signed-off-by: Guo, Yejun <>> yejun@intel.com>> >
> >> ---
> >> doc/APIchanges| 2 ++
> >> libavutil/frame.c | 1 +
> >> libavutil/frame.h | 5 +
> >> 3 files changed, 8 insertions(+)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index 4027d599e7..b83409a412 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -14,6 +14,8 @@ libavutil: 2017-10-21
> >>
> >>
> >> API changes, most recent first:
> >> +2021-03-xx - xx - lavu 56.xx.100 - frame.h
> >> + Add AV_FRAME_DATA_BOUNDING_BOXES
> >>
> >> 2021-03-04 - xx - lavc 58.128.101 - avcodec.h
> >> Enable err_recognition to be set for encoders.
> >> diff --git a/libavutil/frame.c b/libavutil/frame.c
> >> index eab51b6a32..53868a2410 100644
> >> --- a/libavutil/frame.c
> >> +++ b/libavutil/frame.c
> >> @@ -852,6 +852,7 @@ const char *av_frame_side_data_name(enum
> >> AVFrameSideDataType type)
> >> case AV_FRAME_DATA_VIDEO_ENC_PARAMS:return "Video encoding
> >> parameters";
> >> case AV_FRAME_DATA_SEI_UNREGISTERED:return "H.26[45] User
> >> Data Unregistered SEI message";
> >> case AV_FRAME_DATA_FILM_GRAIN_PARAMS: return "Film grain
> >> parameters";
> >> +case AV_FRAME_DATA_BOUNDING_BOXES: return "Bounding
> >> boxes";
> >> }
> >> return NULL;
> >> }
> >> diff --git a/libavutil/frame.h b/libavutil/frame.h
> >> index 1aeafef6de..3fbe15c47e 100644
> >> --- a/libavutil/frame.h
> >> +++ b/libavutil/frame.h
> >> @@ -198,6 +198,11 @@ enum AVFrameSideDataType {
> >> * Must be present for every frame which should have film grain applied.
> >> */
> >> AV_FRAME_DATA_FILM_GRAIN_PARAMS,
> >> +
> >> +/**
> >> + * The data is for internal use by libavfilter.
> >>
> >
> > I do not like this. We should not have internal side data unless there
> > is a strong reason for it. There is nothing about this side data that
> > makes it inherently lavfi-specific.
> >
>
> I object to making this public. This is not something we want to be
> stuck with.
Why not? What about this API should be changed and why not make this
change now?
> That's why I suggested internal_ref was used instead,
> but unfortunately someone just noticed it exists, of course though
> "but what if we need it for something else later, even though we've
> done just fine without it until now!?!".
> I still want to have internal_ref be used for this until the format
> is stable enough and/or codecs which make use of this appear.
> Or at least keep this patch as-is.
I see no reason to believe the format will become more public-worthy
with time.
--
Anton Khirnov
___
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] FFmpeg dev meeting
Hello, As discussed on the framadate poll, the next developer meeting for FFmpeg is next Saturday: Saturday 13 March 16:00 UTC (17:00 Berlin Time) Will be probably on jitsi and on IRC like last time. Agenda will probably be related to TC/CC and about next major release. Please send other agenda topic, if you want/can. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [RFC][v4] Tech Resolution Process
Hello, This is a reminder about the vote. This is closing soon, and most of you have not voted yet! Best, On Mon, 1 Mar 2021, at 15:29, Jean-Baptiste Kempf wrote: > Hello, > > If you are a voter part of the FFmpeg General Assembly, you should have > received an email to allow you to vote on this. > > Best, > > On Thu, 11 Feb 2021, at 11:46, Jean-Baptiste Kempf wrote: > > --- > > 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 > > > > > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing li
[FFmpeg-devel] Re: [PATCH 1/2] lavc: deprecate AV_CODEC_FLAG_TRUNCATED
Quoting Andreas Rheinhardt (2021-03-08 13:24:32) > Anton Khirnov: > > It is supported only by two decoders and is entirely redundant with > > parsers. > > Just because it is only used in two files doesn't mean it is only used > by two decoders: Six decoders have the AV_CODEC_CAP_TRUNCATED (which you > forgot to deprecate) set. > > (fftools/cmdutils.c checks for AV_CODEC_CAP_TRUNCATED and informs the > user about whether it is supported by a codec or not. It should probably > be wrapped in #if LIBAVCODEC_VERSION_MAJOR < 60 checks.) > > > --- > > doc/APIchanges | 3 +++ > > libavcodec/avcodec.h | 4 > > libavcodec/decode.c| 6 +- > > libavcodec/h263dec.c | 10 -- > > libavcodec/mpeg12dec.c | 12 +++- > > libavcodec/mpegvideo.c | 6 ++ > > libavcodec/mpegvideo.h | 2 ++ > > libavcodec/options_table.h | 2 ++ > > libavcodec/pthread.c | 2 ++ > > libavcodec/version.h | 3 +++ > > 10 files changed, 46 insertions(+), 4 deletions(-) > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 4027d599e7..344f484a8b 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > > > API changes, most recent first: > > > > +2021-03-xx - xx - avcodec.h > > Missing version [...] > > diff --git a/libavcodec/version.h b/libavcodec/version.h > > index 169c763e8a..d3e813428b 100644 > > --- a/libavcodec/version.h > > +++ b/libavcodec/version.h > > @@ -162,5 +162,8 @@ > > Missing minor version bump. That is intentional. I see no reason to bump version, because nothing in the API or ABI changes with this patch. We bump the version when new APIs are added to allow users to test whether that API is present. But it makes no sense for the users to check whether this flag (or anything else) is deprecated, since deprecation is merely a declaration of intent to change something in the future. -- Anton Khirnov ___ 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/h264_slice: properly handle missing reference frames with hwaccels
Unlike av_image_copy(), av_frame_copy() supports hardware pixel formats. Based on a patch by Hendrik Leppkes. Signed-off-by: James Almer --- libavcodec/h264_slice.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index fa7a639053..0916de6cd2 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -1599,13 +1599,9 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl, ff_thread_await_progress(&prev->tf, INT_MAX, 0); if (prev->field_picture) ff_thread_await_progress(&prev->tf, INT_MAX, 1); -av_image_copy(h->short_ref[0]->f->data, - h->short_ref[0]->f->linesize, - (const uint8_t **)prev->f->data, - prev->f->linesize, - prev->f->format, - prev->f->width, - prev->f->height); +ret = av_frame_copy(h->short_ref[0]->f, prev->f); +if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE)) +return ret; h->short_ref[0]->poc = prev->poc + 2U; } else if (!h->frame_recovered && !h->avctx->hwaccel) ff_color_frame(h->short_ref[0]->f, c); -- 2.30.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 v7 2/9] 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..586934a7bf
--- /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
+VVC_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 (!pps_no_pic_partition_flag and
+// sps_entropy_coding_sync_enabled_flag are both true), 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.
+
[FFmpeg-devel] [PATCH v7 9/9] avcodec: add vvc metadata bsf
You can download vtm 12 clips at
https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-12.0/
We run following command with all 267 VTM-12.0 clips:
ffmpeg -i in.bit -c:v copy -bsf vvc_metadata -f vvc out.bit
The output bitstream can get same yuv as original.
---
configure | 1 +
libavcodec/Makefile| 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/h266_metadata_bsf.c | 145 +
4 files changed, 148 insertions(+)
create mode 100644 libavcodec/h266_metadata_bsf.c
diff --git a/configure b/configure
index 01cf3a88c7..a7668a8bd3 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 3ab5582d3b..0292d635be 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1175,6 +1175,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 02d33abb18..e642bffa47 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -61,6 +61,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..ff9462994f
--- /dev/null
+++ b/libavcodec/h266_metadata_bsf.c
@@ -0,0 +1,145 @@
+/*
+ * 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"
+
+#define IS_SLICE(nut) (nut <= VVC_RASL_NUT || (nut >= VVC_IDR_W_RADL && nut <=
VVC_GDR_NUT))
+#define IS_PH(nut) (nut == VVC_PH_NUT)
+
+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 {
+if (ctx->aud == BSF_ELEMENT_INSERT) {
+const H266RawSlice *first_slice = NULL;
+const H266RawPH*ph = NULL;
+H266RawAUD *aud = &ctx->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 (IS_PH(nal->nal_unit_type)) {
+ph = pu->units[i].content;
+} else if(IS_SLICE(nal->nal_unit_type)) {
+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_ty
[FFmpeg-devel] [PATCH v7 6/9] avcodec: add vvc parser
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/parsers.c| 1 +
libavcodec/vvc_parser.c | 571
4 files changed, 574 insertions(+)
create mode 100644 libavcodec/vvc_parser.c
diff --git a/configure b/configure
index f1bc9d383e..01cf3a88c7 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"
+vvc_parser_select="cbs_h266"
# bitstream_filters
aac_adtstoasc_bsf_select="adts_header"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1ba9c08d62..3ab5582d3b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1130,6 +1130,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 3d944f5222..7b2b127be4 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..ab8937f709
--- /dev/null
+++ b/libavcodec/vvc_parser.c
@@ -0,0 +1,571 @@
+/*
+ * VVC parser
+ *
+ * Copyright (C) 2021 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))
+#define IS_PH(nut) (nut == VVC_PH_NUT)
+#define IS_IDR(nut) (nut == VVC_IDR_W_RADL || nut == VVC_IDR_N_LP)
+
+
+typedef struct PuInfo {
+AVBufferRef *sps_ref;
+AVBufferRef *pps_ref;
+AVBufferRef *slice_ref;
+AVBufferRef *ph_ref;
+
+const H266RawPPS *pps;
+const H266RawSPS *sps;
+const H266RawPH *ph;
+const H266RawSlice *slice;
+int pic_type;
+} PuInfo;
+
+typedef struct AuDetector {
+uint8_t prev_layer_id;
+int prev_tid0_poc;
+int prev_poc;
+} AuDetector;
+
+typedef struct VVCParserContext {
+ParseContext pc;
+CodedBitstreamContext *cbc;
+
+CodedBitstreamFragment picture_unit;
+
+PuInfo au_info;
+AVPacket au;
+AVPacket last_au;
+
+AuDetector au_detector;
+
+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 = &ctx->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;
+//
[FFmpeg-devel] [PATCH v7 3/9] 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 0504f47f88..af6428541d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -567,6 +567,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 a38fd1f583..1543d0d7ca 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -466,6 +466,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..304f900966
--- /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 & 0x80) // forbidden_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".
[FFmpeg-devel] [PATCH v7 5/9] 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 6fbe97ad4a..7712ee9b1a 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 = &nal->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 = &nal->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 v7 0/9] add vvc raw demuxer, muxer, parser, metadata bsf
Changes since v6: Major changes: vvcparser: combine to AU instead of PU cbs_h266: Hide picture header in CodedBitstreamH266Context, user should not touch it. cbs_h266: When sh_picture_header_in_slice_header_flag is true, do not copy picture header from slice header to CodedBitstreamH266Context Update testset to vtm12.0, all clips passed. Misc: Fix typo vcc_parser_select. Remove nuh_reserved_zero_bit check in vvc raw demuxer. Other typos suggested by Mark. Mark Thompson (1): cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps Nuo Mi (8): avcodec/vvc: add shared header for vvc avformat: add vvc raw demux 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| 573 - libavcodec/cbs_h266.h | 784 +++ libavcodec/cbs_h266_syntax_template.c | 3003 + libavcodec/cbs_internal.h |3 +- libavcodec/cbs_sei.c | 29 + libavcodec/h2645_parse.c | 74 +- libavcodec/h266_metadata_bsf.c| 145 ++ libavcodec/parsers.c |1 + libavcodec/vvc.h | 142 ++ libavcodec/vvc_parser.c | 571 + libavformat/Makefile |2 + libavformat/allformats.c |2 + libavformat/rawenc.c | 25 + libavformat/vvcdec.c | 61 + 18 files changed, 5383 insertions(+), 46 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 v7 8/9] 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 6e3b706813..c08a76e734 100644 --- a/libavcodec/cbs_h2645.c +++ b/libavcodec/cbs_h2645.c @@ -493,8 +493,9 @@ static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx, const H2645NAL *nal = &packet->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".
Re: [FFmpeg-devel] [PATCH v6 1/9] cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps
Nuo Mi:
> From: Mark Thompson
>
> ---
> libavcodec/cbs_h2645.c | 167 +++--
> 1 file changed, 126 insertions(+), 41 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 6005d46e0d..57c419aa05 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -661,38 +661,123 @@ 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(&priv->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 {
> +// Codec this parameter set exists in.
> +enum AVCodecID codec_id;
> +// The NAL unit type corresponding to this parameter set type.
> +intnal_unit_type;
> +// Name of the parameter set. This field is large enough to
> +// contain a string of the form "XPS".
> +char name[4];
> +// The maximum number of this type of parameter set which might
> +// be stored. The greatest valid id is also one less than this.
> +intid_count;
> +// Offset of the ID field (uint8_t) in the decomposed raw
> +// parameter set structure.
> +size_t id_offset;
> +// Offset of the reference array (AVBufferRef*[]) in the codec
> +// private context.
> +size_t ref_array_offset;
> +// Offset of the pointer array (CodecRawXPS*[]) in the codec
> +// private context.
> +size_t ptr_array_offset;
> +// Offset of the active field (const CodecRawXPS*) in the codec
> +// private context, or zero if this codec does not have active
> +// parameter sets.
> +size_t active_offset;
> +} PSType;
> +
> +#define H26456_PS_TYPE(codec, nal, cname, uname, count, id_off, active_off)
> { \
> +.codec_id = AV_CODEC_ID_ ## codec, \
> +.nal_unit_type= nal, \
> +.name = #cname, \
> +.id_count = count, \
> +.id_offset= id_off, \
> +.ref_array_offset = offsetof(CodedBitstream ## codec ## Context, \
> + uname ## _ref), \
> +.ptr_array_offset = offsetof(CodedBitstream ## codec ## Context, \
> + uname), \
> +.active_offset= active_off, \
> +}
> +
> +#define H2645_PS_TYPE(codec, nal, cname, uname, count, id_name,
> active_field) \
> +H26456_PS_TYPE(codec, nal, cname, uname, count, \
> +offsetof(codec ## Raw ## cname, id_name ## _parameter_set_id), \
> +offsetof(CodedBitstream ## codec ## Context, active_field))
> +
> +#define H264_PS_TYPE(cname, uname, id_name) \
> +H2645_PS_TYPE(H264, H264_NAL_ ## cname, cname, uname, \
> + H264_MAX_ ## cname ## _COUNT, \
> + id_name, active_ ## uname)
> +#define H265_PS_TYPE(cname, uname, id_name) \
> +H2645_PS_TYPE(H265, HEVC_NAL_ ## cname, cname, uname, \
> + HEVC_MAX_ ## cname ## _COUNT, \
> + uname ## _ ## id_name, active_ ## uname)
> +
> +static const PSType ps_types[] = {
> +H264_PS_TYPE(SPS, sps, seq),
> +H264_PS_TYPE(PPS, pps, pic),
> +H265_PS_TYPE(VPS, vps, video),
> +H265_PS_TYPE(SPS, sps, seq),
> +H265_PS_TYPE(PPS, pps, pic),
> +};
> +
> +const PSType *ps_type;
> +AVBufferRef **ref_array;
> +void **ptr_array;
> +int err, id = 0, i;
> +
> +ps_type = NULL;
> +for (i = 0; i < FF_ARRAY_ELEMS(ps_types); i++) {
> +if (ps_types[i].codec_id == ctx->codec->codec_id &&
> +ps_types[i].nal_unit_type == unit->type) {
> +ps_type = &ps_types[i];
> +
[FFmpeg-devel] [PATCH v7 1/9] cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps
From: Mark Thompson
---
libavcodec/cbs_h2645.c | 162 ++---
1 file changed, 121 insertions(+), 41 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 6005d46e0d..9e4a12c421 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -661,38 +661,118 @@ 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(&priv->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 {
+// Codec this parameter set exists in.
+enum AVCodecID codec_id;
+// The NAL unit type corresponding to this parameter set type.
+intnal_unit_type;
+// Name of the parameter set. This field is large enough to
+// contain a string of the form "XPS".
+char name[4];
+// The maximum number of this type of parameter set which might
+// be stored. The greatest valid id is also one less than this.
+intid_count;
+// Offset of the ID field (uint8_t) in the decomposed raw
+// parameter set structure.
+size_t id_offset;
+// Offset of the reference array (AVBufferRef*[]) in the codec
+// private context.
+size_t ref_array_offset;
+// Offset of the pointer array (CodecRawXPS*[]) in the codec
+// private context.
+size_t ptr_array_offset;
+// Offset of the active field (const CodecRawXPS*) in the codec
+// private context, or zero if this codec does not have active
+// parameter sets.
+size_t active_offset;
+} PSType;
+
+#define H2645_PS_TYPE(codec, nal, cname, uname, count, id_name, active_field)
{ \
+.codec_id = AV_CODEC_ID_ ## codec, \
+.nal_unit_type= nal, \
+.name = #cname, \
+.id_count = count, \
+.id_offset= offsetof(codec ## Raw ## cname, \
+ id_name ## _parameter_set_id), \
+.ref_array_offset = offsetof(CodedBitstream ## codec ## Context, \
+ uname ## _ref), \
+.ptr_array_offset = offsetof(CodedBitstream ## codec ## Context, \
+ uname), \
+.active_offset= offsetof(CodedBitstream ## codec ## Context, \
+ active_field), \
+}
+#define H264_PS_TYPE(cname, uname, id_name) \
+H2645_PS_TYPE(H264, H264_NAL_ ## cname, cname, uname, \
+ H264_MAX_ ## cname ## _COUNT, \
+ id_name, active_ ## uname)
+#define H265_PS_TYPE(cname, uname, id_name) \
+H2645_PS_TYPE(H265, HEVC_NAL_ ## cname, cname, uname, \
+ HEVC_MAX_ ## cname ## _COUNT, \
+ uname ## _ ## id_name, active_ ## uname)
+
+static const PSType ps_types[] = {
+H264_PS_TYPE(SPS, sps, seq),
+H264_PS_TYPE(PPS, pps, pic),
+H265_PS_TYPE(VPS, vps, video),
+H265_PS_TYPE(SPS, sps, seq),
+H265_PS_TYPE(PPS, pps, pic),
+};
+
+const PSType *ps_type;
+AVBufferRef **ref_array;
+void **ptr_array;
+int err, id, i;
+
+ps_type = NULL;
+for (i = 0; i < FF_ARRAY_ELEMS(ps_types); i++) {
+if (ps_types[i].codec_id == ctx->codec->codec_id &&
+ps_types[i].nal_unit_type == unit->type) {
+ps_type = &ps_types[i];
+break;
+}
+}
+av_assert0(ps_type);
-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)
+
+id =
Re: [FFmpeg-devel] [PATCH v6 1/9] cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps
On Mon, Mar 8, 2021 at 10:28 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Nuo Mi:
> > From: Mark Thompson
> >
> > ---
> > libavcodec/cbs_h2645.c | 167 +++--
> > 1 file changed, 126 insertions(+), 41 deletions(-)
> >
> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > index 6005d46e0d..57c419aa05 100644
> > --- a/libavcodec/cbs_h2645.c
> > +++ b/libavcodec/cbs_h2645.c
> > @@ -661,38 +661,123 @@ 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(&priv->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 {
> > +// Codec this parameter set exists in.
> > +enum AVCodecID codec_id;
> > +// The NAL unit type corresponding to this parameter set type.
> > +intnal_unit_type;
> > +// Name of the parameter set. This field is large enough to
> > +// contain a string of the form "XPS".
> > +char name[4];
> > +// The maximum number of this type of parameter set which might
> > +// be stored. The greatest valid id is also one less than this.
> > +intid_count;
> > +// Offset of the ID field (uint8_t) in the decomposed raw
> > +// parameter set structure.
> > +size_t id_offset;
> > +// Offset of the reference array (AVBufferRef*[]) in the codec
> > +// private context.
> > +size_t ref_array_offset;
> > +// Offset of the pointer array (CodecRawXPS*[]) in the codec
> > +// private context.
> > +size_t ptr_array_offset;
> > +// Offset of the active field (const CodecRawXPS*) in the codec
> > +// private context, or zero if this codec does not have active
> > +// parameter sets.
> > +size_t active_offset;
> > +} PSType;
> > +
> > +#define H26456_PS_TYPE(codec, nal, cname, uname, count, id_off,
> active_off) { \
> > +.codec_id = AV_CODEC_ID_ ## codec, \
> > +.nal_unit_type= nal, \
> > +.name = #cname, \
> > +.id_count = count, \
> > +.id_offset= id_off, \
> > +.ref_array_offset = offsetof(CodedBitstream ## codec ##
> Context, \
> > + uname ## _ref), \
> > +.ptr_array_offset = offsetof(CodedBitstream ## codec ##
> Context, \
> > + uname), \
> > +.active_offset= active_off, \
> > +}
> > +
> > +#define H2645_PS_TYPE(codec, nal, cname, uname, count, id_name,
> active_field) \
> > +H26456_PS_TYPE(codec, nal, cname, uname, count, \
> > +offsetof(codec ## Raw ## cname, id_name ##
> _parameter_set_id), \
> > +offsetof(CodedBitstream ## codec ## Context, active_field))
> > +
> > +#define H264_PS_TYPE(cname, uname, id_name) \
> > +H2645_PS_TYPE(H264, H264_NAL_ ## cname, cname, uname, \
> > + H264_MAX_ ## cname ## _COUNT, \
> > + id_name, active_ ## uname)
> > +#define H265_PS_TYPE(cname, uname, id_name) \
> > +H2645_PS_TYPE(H265, HEVC_NAL_ ## cname, cname, uname, \
> > + HEVC_MAX_ ## cname ## _COUNT, \
> > + uname ## _ ## id_name, active_ ## uname)
> > +
> > +static const PSType ps_types[] = {
> > +H264_PS_TYPE(SPS, sps, seq),
> > +H264_PS_TYPE(PPS, pps, pic),
> > +H265_PS_TYPE(VPS, vps, video),
> > +H265_PS_TYPE(SPS, sps, seq),
> > +H265_PS_TYPE(PPS, pps, pic),
> > +};
> > +
> > +const PSType *ps_type;
> > +AVBufferRef **ref_array;
> > +
[FFmpeg-devel] [PATCH v7 7/9] 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 af6428541d..d5aa0cc843 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -568,6 +568,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 1543d0d7ca..00b7c60dad 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -467,6 +467,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 1/5] avcodec/ylc: Remove write-only variable
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ylc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/ylc.c b/libavcodec/ylc.c
index f68fcf0bba..a200d04acd 100644
--- a/libavcodec/ylc.c
+++ b/libavcodec/ylc.c
@@ -58,7 +58,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
typedef struct Node {
int16_t sym;
-int16_t n0;
uint32_t count;
int16_t l, r;
} Node;
@@ -99,7 +98,6 @@ static int build_vlc(AVCodecContext *avctx, VLC *vlc, const
uint32_t *table)
for (i = 0; i < 256; i++) {
nodes[i].count = table[i];
nodes[i].sym = i;
-nodes[i].n0= -2;
nodes[i].l = i;
nodes[i].r = i;
}
@@ -141,7 +139,6 @@ static int build_vlc(AVCodecContext *avctx, VLC *vlc, const
uint32_t *table)
}
nodes[cur_node].count = nd + st;
nodes[cur_node].sym = -1;
-nodes[cur_node].n0 = cur_node;
nodes[cur_node].l = first_node;
nodes[cur_node].r = second_node;
cur_node++;
--
2.27.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 2/5] avcodec/ylc: Only use one temporary buffer
The effective lifetime of the buffer used to build the VLCs and
the buffer containing the bitstream is disjoint, so that one can use
a common buffer for both.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ylc.c | 44 ++--
1 file changed, 18 insertions(+), 26 deletions(-)
diff --git a/libavcodec/ylc.c b/libavcodec/ylc.c
index a200d04acd..6dc3e60fec 100644
--- a/libavcodec/ylc.c
+++ b/libavcodec/ylc.c
@@ -39,10 +39,8 @@
typedef struct YLCContext {
VLC vlc[4];
uint32_t table[1024];
-uint8_t *table_bits;
-uint8_t *bitstream_bits;
-int table_bits_size;
-int bitstream_bits_size;
+uint8_t *buffer;
+int buffer_size;
BswapDSPContext bdsp;
} YLCContext;
@@ -312,17 +310,18 @@ static int decode_frame(AVCodecContext *avctx,
if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
return ret;
-av_fast_malloc(&s->table_bits, &s->table_bits_size,
- boffset - toffset + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!s->table_bits)
+av_fast_malloc(&s->buffer, &s->buffer_size,
+ FFMAX(boffset - toffset, avpkt->size - boffset)
+ + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!s->buffer)
return AVERROR(ENOMEM);
-memcpy(s->table_bits, avpkt->data + toffset, boffset - toffset);
-memset(s->table_bits + boffset - toffset, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-s->bdsp.bswap_buf((uint32_t *) s->table_bits,
- (uint32_t *) s->table_bits,
+memcpy(s->buffer, avpkt->data + toffset, boffset - toffset);
+memset(s->buffer + boffset - toffset, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+s->bdsp.bswap_buf((uint32_t *) s->buffer,
+ (uint32_t *) s->buffer,
(boffset - toffset + 3) >> 2);
-if ((ret = init_get_bits8(&gb, s->table_bits, boffset - toffset)) < 0)
+if ((ret = init_get_bits8(&gb, s->buffer, boffset - toffset)) < 0)
return ret;
for (x = 0; x < 1024; x++) {
@@ -345,17 +344,12 @@ static int decode_frame(AVCodecContext *avctx,
if (ret < 0)
return ret;
-av_fast_malloc(&s->bitstream_bits, &s->bitstream_bits_size,
- avpkt->size - boffset + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!s->bitstream_bits)
-return AVERROR(ENOMEM);
-
-memcpy(s->bitstream_bits, avpkt->data + boffset, avpkt->size - boffset);
-memset(s->bitstream_bits + avpkt->size - boffset, 0,
AV_INPUT_BUFFER_PADDING_SIZE);
-s->bdsp.bswap_buf((uint32_t *) s->bitstream_bits,
- (uint32_t *) s->bitstream_bits,
+memcpy(s->buffer, avpkt->data + boffset, avpkt->size - boffset);
+memset(s->buffer + avpkt->size - boffset, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+s->bdsp.bswap_buf((uint32_t *) s->buffer,
+ (uint32_t *) s->buffer,
(avpkt->size - boffset) >> 2);
-if ((ret = init_get_bits8(&gb, s->bitstream_bits, avpkt->size - boffset))
< 0)
+if ((ret = init_get_bits8(&gb, s->buffer, avpkt->size - boffset)) < 0)
return ret;
dst = p->data[0];
@@ -461,10 +455,8 @@ static av_cold int decode_end(AVCodecContext *avctx)
ff_free_vlc(&s->vlc[1]);
ff_free_vlc(&s->vlc[2]);
ff_free_vlc(&s->vlc[3]);
-av_freep(&s->table_bits);
-s->table_bits_size = 0;
-av_freep(&s->bitstream_bits);
-s->bitstream_bits_size = 0;
+av_freep(&s->buffer);
+s->buffer_size = 0;
return 0;
}
--
2.27.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 3/5] avcodec/ylc: Avoid code duplication when creating and freeing VLCs
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ylc.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/libavcodec/ylc.c b/libavcodec/ylc.c
index 6dc3e60fec..793d8846b5 100644
--- a/libavcodec/ylc.c
+++ b/libavcodec/ylc.c
@@ -38,7 +38,7 @@
typedef struct YLCContext {
VLC vlc[4];
-uint32_t table[1024];
+uint32_t table[256];
uint8_t *buffer;
int buffer_size;
BswapDSPContext bdsp;
@@ -324,25 +324,18 @@ static int decode_frame(AVCodecContext *avctx,
if ((ret = init_get_bits8(&gb, s->buffer, boffset - toffset)) < 0)
return ret;
-for (x = 0; x < 1024; x++) {
+for (int i = 0; i < 4; i++) {
+for (x = 0; x < 256; x++) {
unsigned len = get_unary(&gb, 1, 31);
uint32_t val = ((1U << len) - 1) + get_bits_long(&gb, len);
s->table[x] = val;
}
-ret = build_vlc(avctx, &s->vlc[0], &s->table[0 ]);
-if (ret < 0)
-return ret;
-ret = build_vlc(avctx, &s->vlc[1], &s->table[256]);
-if (ret < 0)
-return ret;
-ret = build_vlc(avctx, &s->vlc[2], &s->table[512]);
-if (ret < 0)
-return ret;
-ret = build_vlc(avctx, &s->vlc[3], &s->table[768]);
+ret = build_vlc(avctx, &s->vlc[i], s->table);
if (ret < 0)
return ret;
+}
memcpy(s->buffer, avpkt->data + boffset, avpkt->size - boffset);
memset(s->buffer + avpkt->size - boffset, 0, AV_INPUT_BUFFER_PADDING_SIZE);
@@ -451,10 +444,8 @@ static av_cold int decode_end(AVCodecContext *avctx)
{
YLCContext *s = avctx->priv_data;
-ff_free_vlc(&s->vlc[0]);
-ff_free_vlc(&s->vlc[1]);
-ff_free_vlc(&s->vlc[2]);
-ff_free_vlc(&s->vlc[3]);
+for (int i = 0; i < FF_ARRAY_ELEMS(s->vlc); i++)
+ff_free_vlc(&s->vlc[i]);
av_freep(&s->buffer);
s->buffer_size = 0;
--
2.27.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 4/5] avcodec/ylc: Reindent after previous commit
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ylc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/ylc.c b/libavcodec/ylc.c
index 793d8846b5..ab1f8958f3 100644
--- a/libavcodec/ylc.c
+++ b/libavcodec/ylc.c
@@ -326,15 +326,15 @@ static int decode_frame(AVCodecContext *avctx,
for (int i = 0; i < 4; i++) {
for (x = 0; x < 256; x++) {
-unsigned len = get_unary(&gb, 1, 31);
-uint32_t val = ((1U << len) - 1) + get_bits_long(&gb, len);
+unsigned len = get_unary(&gb, 1, 31);
+uint32_t val = ((1U << len) - 1) + get_bits_long(&gb, len);
-s->table[x] = val;
-}
+s->table[x] = val;
+}
ret = build_vlc(avctx, &s->vlc[i], s->table);
-if (ret < 0)
-return ret;
+if (ret < 0)
+return ret;
}
memcpy(s->buffer, avpkt->data + boffset, avpkt->size - boffset);
--
2.27.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 5/5] avformat/rawenc: Use init instead of write_header function
force_one_stream() does not write anything.
Signed-off-by: Andreas Rheinhardt
---
Is it it actually intended that the mp2 muxer does not use
force_one_stream at all? And is it intended that force_one_stream
does only check codec_type and not the actual codec?
And wouldn't it be better to inform the caller about the fact that
the format supports only one stream by adding a new
AVOutputFormat.flags?
libavformat/rawenc.c | 60 ++--
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 32704f9bfd..caec297f4a 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -64,7 +64,7 @@ AVOutputFormat ff_ac3_muxer = {
.extensions= "ac3",
.audio_codec = AV_CODEC_ID_AC3,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -96,7 +96,7 @@ AVOutputFormat ff_adx_muxer = {
.extensions= "adx",
.audio_codec = AV_CODEC_ID_ADPCM_ADX,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.write_trailer = adx_write_trailer,
.flags = AVFMT_NOTIMESTAMPS,
@@ -110,7 +110,7 @@ AVOutputFormat ff_aptx_muxer = {
.extensions= "aptx",
.audio_codec = AV_CODEC_ID_APTX,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -123,7 +123,7 @@ AVOutputFormat ff_aptx_hd_muxer = {
.extensions= "aptxhd",
.audio_codec = AV_CODEC_ID_APTX_HD,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -136,7 +136,7 @@ AVOutputFormat ff_avs2_muxer = {
.extensions= "avs,avs2",
.audio_codec = AV_CODEC_ID_NONE,
.video_codec = AV_CODEC_ID_AVS2,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -149,7 +149,7 @@ AVOutputFormat ff_cavsvideo_muxer = {
.extensions= "cavs",
.audio_codec = AV_CODEC_ID_NONE,
.video_codec = AV_CODEC_ID_CAVS,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -161,7 +161,7 @@ AVOutputFormat ff_codec2raw_muxer = {
.long_name = NULL_IF_CONFIG_SMALL("raw codec2 muxer"),
.audio_codec = AV_CODEC_ID_CODEC2,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -172,7 +172,7 @@ AVOutputFormat ff_codec2raw_muxer = {
AVOutputFormat ff_data_muxer = {
.name = "data",
.long_name = NULL_IF_CONFIG_SMALL("raw data"),
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -185,7 +185,7 @@ AVOutputFormat ff_dirac_muxer = {
.extensions= "drc,vc2",
.audio_codec = AV_CODEC_ID_NONE,
.video_codec = AV_CODEC_ID_DIRAC,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -198,7 +198,7 @@ AVOutputFormat ff_dnxhd_muxer = {
.extensions= "dnxhd,dnxhr",
.audio_codec = AV_CODEC_ID_NONE,
.video_codec = AV_CODEC_ID_DNXHD,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -212,7 +212,7 @@ AVOutputFormat ff_dts_muxer = {
.extensions= "dts",
.audio_codec = AV_CODEC_ID_DTS,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = force_one_stream,
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
@@ -226,7 +226,7 @@ AVOutputFormat ff_eac3_muxer = {
.extensions= "eac3",
.audio_codec = AV_CODEC_ID_EAC3,
.video_codec = AV_CODEC_ID_NONE,
-.write_header = force_one_stream,
+.init = fo
Re: [FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Anton Khirnov (12021-03-08): > I see no reason to believe the format will become more public-worthy > with time. Just the fact that as months pass, the likelihood we notice something that requires a deep change decreases. Do you have any actual argument against internal side data, beyond "I do not like it"? Regards, -- Nicolas George 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] mailmap: add entry for myself
Signed-off-by: Linjie Fu --- .mailmap | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index 3bd1a85c3c..ba072f38c8 100644 --- a/.mailmap +++ b/.mailmap @@ -10,7 +10,8 @@ - + + -- 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] mailmap: add entry for myself
Hi, Am 08.03.21 um 16:12 schrieb Linjie Fu: > Signed-off-by: Linjie Fu > --- > .mailmap | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index 3bd1a85c3c..ba072f38c8 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -10,7 +10,8 @@ > > > > - > + > + > > > LGTM, you are listed as one of the libopenh264enc maintainers, please push. -Thilo ___ 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/5] avcodec/ylc: Avoid code duplication when creating and freeing VLCs
all ylc patches lgtm.
On Mon, Mar 8, 2021 at 4:30 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ylc.c | 23 +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/ylc.c b/libavcodec/ylc.c
> index 6dc3e60fec..793d8846b5 100644
> --- a/libavcodec/ylc.c
> +++ b/libavcodec/ylc.c
> @@ -38,7 +38,7 @@
>
> typedef struct YLCContext {
> VLC vlc[4];
> -uint32_t table[1024];
> +uint32_t table[256];
> uint8_t *buffer;
> int buffer_size;
> BswapDSPContext bdsp;
> @@ -324,25 +324,18 @@ static int decode_frame(AVCodecContext *avctx,
> if ((ret = init_get_bits8(&gb, s->buffer, boffset - toffset)) < 0)
> return ret;
>
> -for (x = 0; x < 1024; x++) {
> +for (int i = 0; i < 4; i++) {
> +for (x = 0; x < 256; x++) {
> unsigned len = get_unary(&gb, 1, 31);
> uint32_t val = ((1U << len) - 1) + get_bits_long(&gb, len);
>
> s->table[x] = val;
> }
>
> -ret = build_vlc(avctx, &s->vlc[0], &s->table[0 ]);
> -if (ret < 0)
> -return ret;
> -ret = build_vlc(avctx, &s->vlc[1], &s->table[256]);
> -if (ret < 0)
> -return ret;
> -ret = build_vlc(avctx, &s->vlc[2], &s->table[512]);
> -if (ret < 0)
> -return ret;
> -ret = build_vlc(avctx, &s->vlc[3], &s->table[768]);
> +ret = build_vlc(avctx, &s->vlc[i], s->table);
> if (ret < 0)
> return ret;
> +}
>
> memcpy(s->buffer, avpkt->data + boffset, avpkt->size - boffset);
> memset(s->buffer + avpkt->size - boffset, 0,
> AV_INPUT_BUFFER_PADDING_SIZE);
> @@ -451,10 +444,8 @@ static av_cold int decode_end(AVCodecContext *avctx)
> {
> YLCContext *s = avctx->priv_data;
>
> -ff_free_vlc(&s->vlc[0]);
> -ff_free_vlc(&s->vlc[1]);
> -ff_free_vlc(&s->vlc[2]);
> -ff_free_vlc(&s->vlc[3]);
> +for (int i = 0; i < FF_ARRAY_ELEMS(s->vlc); i++)
> +ff_free_vlc(&s->vlc[i]);
> av_freep(&s->buffer);
> s->buffer_size = 0;
>
> --
> 2.27.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".
[FFmpeg-devel] [PATCH][RFC - DO NOT MERGE] Revert "mov: Discard invalid CTTS."
This reverts commit 4093220029a4d77f272c491e9299680480a08c00. Signed-off-by: Derek Buitenhuis --- I have CC'd Michael here, as he is the original author here and the "soltuion" is nor clear. To explain this RFC: We (Vimeo) have started seeing an uptick in broken MP4 files (what creates them is under investigation; we have reached out to some users in hopes that we can identify the broken muxer and contact its authors). They are broken in a very specific way: The CTTS box starts off normal, but then at some point, the duration field of the CTTS entries starts to increment on each entry, and this continues until the end of the file, resulting in incorrect and insane PTS/DTS differences (like PTS/DTS differing by 15 minutes / 10,000 frames). I have linked both a text dump of the boxes and a trimmed moov box as an example in [1] and [2]. I can only provide a full file (~12 GiB) privately. Thes files *happen* to decode linearly just fine, of course, because FFmpeg doesn't care about the CTTS info in that case, but if you seek, everything will explode, as you would expect. So, anyway, in the meanwhile, I was writing a simple detection filter for these sorts of files, and I noticed it only detected some of them, and this lead me to 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa. What happens is that if the file is long enough, the incrementing CTTS entry durations eventually trigger this, as far as I can tell, totally arbitrary check for 1<<28, and that results in the entire CTTS being thrown away, and libavformat setting PTS==DTS for all packets, which both makes detection impossible, and breaks seeking in a completely different way. So the options are: * Revert 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa and detect them as I was already. * Change the check to something else or some other value, which would still be totally arbitrary - but maybe something like >16 frames. This would still leave seeking totally broken, of course, since it will still set PTS==DTS for all packets. This is still maybe detectable for API users by checking b_frames and has_b_frames of video_delay, but PTS==DTS? Seems kind gross, but... eh. * (Possibly in addition to other changes) Make the check an error, or make seeking return an error when this sort of file is detected. * Something I haven't listed here. So, basically, all options suck, and I thought some people may have opinions on the least bad option, here - specifically Michael, as the author of the original patch. People: Please comment if you feel strongly about one solution or another. [1] http://chromashift.org/ctts_sadness/broken_cut.mp4.xz [2] http://chromashift.org/ctts_sadness/broken.boxes.txt.xz --- libavformat/mov.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 1c07cff6b5..256e7d376f 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -3079,13 +3079,6 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom) av_log(c->fc, AV_LOG_TRACE, "count=%d, duration=%d\n", count, duration); -if (FFNABS(duration) < -(1<<28) && i+2fc, AV_LOG_WARNING, "CTTS invalid\n"); -av_freep(&sc->ctts_data); -sc->ctts_count = 0; -return 0; -} - if (i+2fc); } -- 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] mobiclip: fix copyright headers
OK, assuming you are really that person. On Mon, Mar 8, 2021 at 12:02 PM Florian Nouwt wrote: > The Mobiclip related code was based on Mobius ( > https://github.com/adibsurani/Mobius), which was based on my original > reverse engineering efforts (https://github.com/Gericom/MobiclipDecoder). > This commit adds the appropriate copyright headers on the related files. > > Signed-off-by: Florian Nouwt > --- > libavcodec/fastaudio.c | 2 ++ > libavcodec/mobiclip.c | 1 + > libavformat/mods.c | 2 ++ > libavformat/moflex.c | 2 ++ > 4 files changed, 7 insertions(+) > > diff --git a/libavcodec/fastaudio.c b/libavcodec/fastaudio.c > index e50678cd3d..9de42d2134 100644 > --- a/libavcodec/fastaudio.c > +++ b/libavcodec/fastaudio.c > @@ -1,5 +1,7 @@ > /* > * MOFLEX Fast Audio decoder > + * Copyright (c) 2015-2016 Florian Nouwt > + * Copyright (c) 2017 Adib Surani > * Copyright (c) 2020 Paul B Mahol > * > * This file is part of FFmpeg. > diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c > index 9392ab947e..bf47a5bc41 100644 > --- a/libavcodec/mobiclip.c > +++ b/libavcodec/mobiclip.c > @@ -1,5 +1,6 @@ > /* > * MobiClip Video decoder > + * Copyright (c) 2015-2016 Florian Nouwt > * Copyright (c) 2017 Adib Surani > * Copyright (c) 2020 Paul B Mahol > * > diff --git a/libavformat/mods.c b/libavformat/mods.c > index 4f093cdf0c..a26db87e6c 100644 > --- a/libavformat/mods.c > +++ b/libavformat/mods.c > @@ -1,5 +1,7 @@ > /* > * MODS demuxer > + * Copyright (c) 2015-2016 Florian Nouwt > + * Copyright (c) 2017 Adib Surani > * Copyright (c) 2020 Paul B Mahol > * > * This file is part of FFmpeg. > diff --git a/libavformat/moflex.c b/libavformat/moflex.c > index 8142925adc..41335ada78 100644 > --- a/libavformat/moflex.c > +++ b/libavformat/moflex.c > @@ -1,5 +1,7 @@ > /* > * MOFLEX demuxer > + * Copyright (c) 2015-2016 Florian Nouwt > + * Copyright (c) 2017 Adib Surani > * Copyright (c) 2020 Paul B Mahol > * > * This file is part of FFmpeg. > -- > 2.18.0.windows.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 mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH][RFC - DO NOT MERGE] Revert "mov: Discard invalid CTTS."
On 08/03/2021 15:55, Derek Buitenhuis wrote: > So the options are: > * Revert 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa and detect them as I > was already. Copy-paste fail. This should say 4093220029a4d77f272c491e9299680480a08c00. - Derek ___ 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] mobiclip: fix copyright headers
If you need some confirmation, you can see on this commit that I used the same email address at least: https://github.com/Gericom/MobiclipDecoder/commit/32eb908f134f9140782e0585e2871ef2569ae23c.patch The author of Mobius can also confirm, I discussed it with him yesterday. Op ma 8 mrt. 2021 17:08 schreef Paul B Mahol : > OK, assuming you are really that person. > > On Mon, Mar 8, 2021 at 12:02 PM Florian Nouwt wrote: > >> The Mobiclip related code was based on Mobius ( >> https://github.com/adibsurani/Mobius), which was based on my original >> reverse engineering efforts (https://github.com/Gericom/MobiclipDecoder). >> This commit adds the appropriate copyright headers on the related files. >> >> Signed-off-by: Florian Nouwt >> --- >> libavcodec/fastaudio.c | 2 ++ >> libavcodec/mobiclip.c | 1 + >> libavformat/mods.c | 2 ++ >> libavformat/moflex.c | 2 ++ >> 4 files changed, 7 insertions(+) >> >> diff --git a/libavcodec/fastaudio.c b/libavcodec/fastaudio.c >> index e50678cd3d..9de42d2134 100644 >> --- a/libavcodec/fastaudio.c >> +++ b/libavcodec/fastaudio.c >> @@ -1,5 +1,7 @@ >> /* >> * MOFLEX Fast Audio decoder >> + * Copyright (c) 2015-2016 Florian Nouwt >> + * Copyright (c) 2017 Adib Surani >> * Copyright (c) 2020 Paul B Mahol >> * >> * This file is part of FFmpeg. >> diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c >> index 9392ab947e..bf47a5bc41 100644 >> --- a/libavcodec/mobiclip.c >> +++ b/libavcodec/mobiclip.c >> @@ -1,5 +1,6 @@ >> /* >> * MobiClip Video decoder >> + * Copyright (c) 2015-2016 Florian Nouwt >> * Copyright (c) 2017 Adib Surani >> * Copyright (c) 2020 Paul B Mahol >> * >> diff --git a/libavformat/mods.c b/libavformat/mods.c >> index 4f093cdf0c..a26db87e6c 100644 >> --- a/libavformat/mods.c >> +++ b/libavformat/mods.c >> @@ -1,5 +1,7 @@ >> /* >> * MODS demuxer >> + * Copyright (c) 2015-2016 Florian Nouwt >> + * Copyright (c) 2017 Adib Surani >> * Copyright (c) 2020 Paul B Mahol >> * >> * This file is part of FFmpeg. >> diff --git a/libavformat/moflex.c b/libavformat/moflex.c >> index 8142925adc..41335ada78 100644 >> --- a/libavformat/moflex.c >> +++ b/libavformat/moflex.c >> @@ -1,5 +1,7 @@ >> /* >> * MOFLEX demuxer >> + * Copyright (c) 2015-2016 Florian Nouwt >> + * Copyright (c) 2017 Adib Surani >> * Copyright (c) 2020 Paul B Mahol >> * >> * This file is part of FFmpeg. >> -- >> 2.18.0.windows.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 mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH][RFC - DO NOT MERGE] Revert "mov: Discard invalid CTTS."
On Mon, Mar 08, 2021 at 03:55:19PM +, Derek Buitenhuis wrote: > This reverts commit 4093220029a4d77f272c491e9299680480a08c00. > > Signed-off-by: Derek Buitenhuis > --- > I have CC'd Michael here, as he is the original author here and the > "soltuion" is nor clear. > > To explain this RFC: > > We (Vimeo) have started seeing an uptick in broken MP4 files (what creates > them is under > investigation; we have reached out to some users in hopes that we can > identify the broken > muxer and contact its authors). They are broken in a very specific way: The > CTTS box starts > off normal, but then at some point, the duration field of the CTTS entries > starts to increment > on each entry, and this continues until the end of the file, resulting in > incorrect and insane > PTS/DTS differences (like PTS/DTS differing by 15 minutes / 10,000 frames). I > have linked both > a text dump of the boxes and a trimmed moov box as an example in [1] and [2]. > I can only provide > a full file (~12 GiB) privately. > > Thes files *happen* to decode linearly just fine, of course, because FFmpeg > doesn't care about the > CTTS info in that case, but if you seek, everything will explode, as you > would expect. > > So, anyway, in the meanwhile, I was writing a simple detection filter for > these sorts of files, > and I noticed it only detected some of them, and this lead me to > 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa. > What happens is that if the file is long enough, the incrementing CTTS entry > durations eventually > trigger this, as far as I can tell, totally arbitrary check for 1<<28, and > that results in the > entire CTTS being thrown away, and libavformat setting PTS==DTS for all > packets, which both > makes detection impossible, and breaks seeking in a completely different way. > > So the options are: > * Revert 1fb9efbda0149c3491529ea5fa92cfdcb8cebfaa and detect them as I > was already. > * Change the check to something else or some other value, which would > still be totally > arbitrary - but maybe something like >16 frames. This would still leave > seeking totally > broken, of course, since it will still set PTS==DTS for all packets. > This is still maybe > detectable for API users by checking b_frames and has_b_frames of > video_delay, but > PTS==DTS? Seems kind gross, but... eh. > * (Possibly in addition to other changes) Make the check an error, or > make seeking return an > error when this sort of file is detected. > * Something I haven't listed here. > > So, basically, all options suck, and I thought some people may have opinions > on the least bad > option, here - specifically Michael, as the author of the original patch. I would try to detect the specific abberant muxer based on the input. Then have custom code in the demuxer which is based on reverse engnenering the issue to do a best effort to recover as much as is possible. And also print a big warning about the broken input / muxer so the user doesnt stay unaware. You can see this also in 2 ways 1. It sucks its not our job to workaround someone elses bugs 2. It cool, it gives FFmpegs demuxer a unique advantage over competing demuxers Implementing this will be more enjoyable to whoever does, if (s)he sees it as in "2." Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutils/opt: fix discarded-qualifiers compiler warning
On 2/14/2021 10:12 AM, Nuo Mi wrote:
On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
Nuo Mi:
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 590146b5fb..c554e9c063 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1735,7 +1735,7 @@ const AVClass *av_opt_child_class_iterate(const
AVClass *parent, void **iter)
#if FF_API_CHILD_CLASS_NEXT
FF_DISABLE_DEPRECATION_WARNINGS
if (parent->child_class_next) {
-*iter = parent->child_class_next(*iter);
+*iter = (void*)parent->child_class_next(*iter);
return *iter;
}
FF_ENABLE_DEPRECATION_WARNINGS
This doesn't look like a fix; you just silenced a warning.
Yes, but this the only way if we do not change the function signature.
Since a major release is "coming up", now could be the time to fix the
signature to '(..., const void **iter)' and eliminate the non-const cast
kludge across the board for these cases.
-Chad
___
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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Quoting Nicolas George (2021-03-08 16:32:08) > Anton Khirnov (12021-03-08): > > I see no reason to believe the format will become more public-worthy > > with time. > > Just the fact that as months pass, the likelihood we notice something > that requires a deep change decreases. > As does the likelihood that anybody will actually do any work to polish this. > Do you have any actual argument against internal side data, beyond "I do > not like it"? The argument for internal side data is literally that it's not good enough to be made public. So the option of making it private is used as an excuse to avoid designing the format properly. Lavfi is enough of a black box as it is, no need to make it even more so with internal side data formats. -- Anton Khirnov ___ 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] avcodec: add a get_encoder_buffer() callback to AVCodecContext
On 2/22/2021 7:27 PM, James Almer wrote:
On 2/21/2021 6:04 PM, James Almer wrote:
On 2/21/2021 5:29 PM, Mark Thompson wrote:
On 21/02/2021 20:00, James Almer wrote:
On 2/21/2021 4:13 PM, Mark Thompson wrote:
On 21/02/2021 17:35, James Almer wrote:
This callback is functionally the same as get_buffer2() is for
decoders, and
implements for the new encode API the functionality of the old
encode API had
where the user could provide their own buffers.
Signed-off-by: James Almer
---
Used the names Lynne suggested this time, plus a line about how
the callback
must be thread safe.
libavcodec/avcodec.h | 45
libavcodec/codec.h | 8 ---
libavcodec/encode.c | 54
+++-
libavcodec/encode.h | 8 +++
libavcodec/options.c | 1 +
5 files changed, 112 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7dbf083a24..e60eb16ce1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -513,6 +513,11 @@ typedef struct AVProducerReferenceTime {
*/
#define AV_GET_BUFFER_FLAG_REF (1 << 0)
+/**
+ * The encoder will keep a reference to the packet and may reuse
it later.
+ */
+#define AV_GET_ENCODER_BUFFER_FLAG_REF (1 << 0)
+
struct AVCodecInternal;
/**
@@ -2346,6 +2351,39 @@ typedef struct AVCodecContext {
* - encoding: set by user
*/
int export_side_data;
+
+ /**
+ * This callback is called at the beginning of each packet to
get a data
+ * buffer for it.
+ *
+ * The following field will be set in the packet before this
callback is
+ * called:
+ * - size
+ * This callback must use the above value to calculate the
required buffer size,
+ * which must padded by at least AV_INPUT_BUFFER_PADDING_SIZE
bytes.
+ *
+ * This callback must fill the following fields in the packet:
+ * - data
Is the data pointer allowed to be in write-only memory?
I'm not sure what the use case for this would be, so probably no?
The two use-cases I see for this API are:
* You want to avoid a copy when combining the output with something
else. E.g. you pass a pointer to the block of memory following where
you are going to put your header data (for something you are going to
send over the network, say).
* You want to avoid a copy when passing the output directly to
something external. E.g. you pass a pointer to a memory-mapped
device buffer (such as a V4L2 buffer, say).
In the second case, write-only memory on an external device seems
possible, as does memory which is, say, readable but uncached, so
reading it is a really bad idea.
Allowing the second case would depend on how encoders behave. Some may
attempt to read data already written to the output packet. It's not
like all of them allocate the packet, do a memcpy from an internal
buffer, then return.
There is also the flag meant to signal that the encoder will keep a
reference to the packet around, which more or less implies it will be
read later in the encoding process.
The doxy for avcodec_encode_video2(), which allowed the user to
provide their own buffers in the output packet, does not mention any
kind of requirement for the data pointer, so I don't think we can say
it's an allowed scenario here either.
Does it have any alignment requirements?
No, just padding. AVPacket doesn't require alignment for the payload.
I think say that explicitly. avcodec_default_get_encoder_buffer()
does give you aligned memory, even though it isn't needed.
Would saying "There's no alignment requirement for the data pointer"
add anything of value to the doxy? If i don't mention any kind of
alignment requirement, it's because there isn't any, and it's implicit.
I listed the requirements the user needs to keep in mind, like the
padding and the need for an AVBufferRef. But if you think it's worth
adding, then sure.
+ * - buf must contain a pointer to an AVBufferRef structure.
The packet's
+ * data pointer must be contained in it.
+ * See: av_buffer_create(), av_buffer_alloc(), and
av_buffer_ref().
+ *
+ * If AV_CODEC_CAP_DR1 is not set then get_encoder_buffer()
must call
+ * avcodec_default_get_encoder_buffer() instead of providing
a buffer allocated by
+ * some other means.
+ *
+ * If AV_GET_ENCODER_BUFFER_FLAG_REF is set in flags then the
packet may be reused
+ * (read and/or written to if it is writable) later by
libavcodec.
+ *
+ * This callback must be thread-safe, as when frame
multithreading is used, it may
+ * be called from multiple threads simultaneously.
Allowing simulatenous calls feels unexpectedly tricky. Is it
really necessary?
This was a suggestion by Lynne, i personally don't know. We support
frame threading encoding (For intra-only codecs), but currently
ff_alloc_packet2() does not seem to be thread safe, seeing it calls
av_fast_padded_malloc
Re: [FFmpeg-devel] [PATCH 2/2] avformat/swfdec: Check outlen before allocation
On Sun, Jan 24, 2021 at 02:05:17PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-01-23 23:34:19)
> > On Sat, Jan 23, 2021 at 03:29:38PM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2021-01-22 15:09:47)
> > > > Fixes: Timeout (too long -> 241ms)
> > > > Fixes:
> > > > 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
> > > >
> > > > Found-by: continuous fuzzing process
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavformat/swfdec.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> > > > index 1463f0ad4d..aa4be88f91 100644
> > > > --- a/libavformat/swfdec.c
> > > > +++ b/libavformat/swfdec.c
> > > > @@ -367,6 +367,9 @@ static int swf_read_packet(AVFormatContext *s,
> > > > AVPacket *pkt)
> > > > ff_dlog(s, "bitmap: ch=%d fmt=%d %dx%d (linesize=%d)
> > > > len=%d->%ld pal=%d\n",
> > > > ch_id, bmp_fmt, width, height, linesize, len,
> > > > out_len, colormapsize);
> > > >
> > > > +if (len * 17373LL < out_len)
> > >
> > > Where does the magic number come from?
> >
> > A very quick simulation of the best case compression for "compress"
> > below is not nice written code as i did not expect I or anyone else
> > would ever see it again
> >
> > I would have preferred some nicer expression or course, but thats
> > what it seems to be asymptotically. For smaller amounts of data a
> > tighter bound is possible but i saw no nice way to consider that
> > and it seems also overkill to try to do it more fine grained for
> > just this
> >
> > main(){
> > int64_t bits = 0;
> > int bank = 256;
> > int bitbank = 8;
> > for(unsigned i = 0; i<1024*1024*1024*4U-10;) {
> > int word_size = bank-255;
> > i += word_size;
> > bits += bitbank;
> >
> > if (!(bank & (bank-1)))
> > bitbank ++;
> > bank++;
> > if (bitbank > 16) {
> > printf("BEST %f \n", 8.0 * i / bits );
> > bank = 256;
> > bitbank = 8;
> > }
> > }
> > }
> >
> > above assumes i remembered correctly how the algorithm works but the
> > value was close to what actual compession of zeros gave
>
> People who read this code in the future will be interested in all this.
> So the content of your reply should be added to the commit message
> and/or the code itself.
will apply with the message in the commit message
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: add a get_encoder_buffer() callback to AVCodecContext
Mar 8, 2021, 21:31 by jamr...@gmail.com: > On 2/22/2021 7:27 PM, James Almer wrote: > >> >> Looked at bit into this. AVCodec->encode2() based encoders don't support >> returning EAGAIN at all, as it completely breaks the frame threading logic. >> It would require a considerable rewrite in order to re-add a task that >> didn't fail but also didn't succeed. >> >> Non frame threading encoders could probably support it with some minimal >> changes, but i don't think suddenly letting an scenario that was until now >> guaranteed to never happen start happening (avcodec_send_frame() and >> avcodec_receive_packet() both returning EAGAIN) is a good idea. It's an API >> break. >> Letting the user's custom get_encode_buffer() callback suspend the thread is >> IMO acceptable. In frame threading scenarios, the other threads are still >> working on their own packets (afaics none depends on the others, since it's >> intra only encoders only). >> > > Ping. I'd like to get this in. > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276679.html ___ 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/5] avcodec/aacdec_template: Avoid undefined negation in imdct_and_windowing_eld()
On Thu, Jan 21, 2021 at 01:03:43AM +0100, Michael Niedermayer wrote: > Fixes: negation of -2147483648 cannot be represented in type 'INTFLOAT' (aka > 'int'); cast to an unsigned type to negate this value to itself > Fixes: > 29057/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5642758933053440 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/aacdec_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] tools/target_dec_fuzzer: Adjust flv1 threshold
On Thu, Jan 21, 2021 at 01:03:46AM +0100, Michael Niedermayer wrote: > Fixes: Timeout (long -> 95ms) > Fixes: > 29068/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLV_fuzzer-6509662832820224 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/paf: Check for EOF before allocation in read_header()
On Wed, Jan 20, 2021 at 12:32:23AM +0100, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 26584/clusterfuzz-testcase-minimized-ffmpeg_dem_PAF_fuzzer-5172661183053824 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/paf.c | 4 > 1 file changed, 4 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: add a get_encoder_buffer() callback to AVCodecContext
On 3/8/2021 5:48 PM, Lynne wrote: Mar 8, 2021, 21:31 by jamr...@gmail.com: On 2/22/2021 7:27 PM, James Almer wrote: Looked at bit into this. AVCodec->encode2() based encoders don't support returning EAGAIN at all, as it completely breaks the frame threading logic. It would require a considerable rewrite in order to re-add a task that didn't fail but also didn't succeed. Non frame threading encoders could probably support it with some minimal changes, but i don't think suddenly letting an scenario that was until now guaranteed to never happen start happening (avcodec_send_frame() and avcodec_receive_packet() both returning EAGAIN) is a good idea. It's an API break. Letting the user's custom get_encode_buffer() callback suspend the thread is IMO acceptable. In frame threading scenarios, the other threads are still working on their own packets (afaics none depends on the others, since it's intra only encoders only). Ping. I'd like to get this in. https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276679.html You agreed with me, so i didn't think i needed to reply to that email. It's Mark who hasn't yet said if he's ok with it. And regarding to the AVPacket data alignment, that's a separate discussion for an API change unrelated to this. ___ 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] avformat/flvdec: Check double before cast in parse_keyframes_index()
On Tue, Jan 26, 2021 at 05:08:39PM +0100, Michael Niedermayer wrote: > Fixes: -2.21166e+304 is outside the range of representable values of type > 'long' > Fixes: > 29169/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5725452796821504 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/flvdec.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: do not write out of rdft visualization texture
On Sun, 7 Mar 2021, Michael Niedermayer wrote:
On Wed, Mar 03, 2021 at 11:27:22PM +0100, Marton Balint wrote:
If the window is resized it was possible that xpos pointed outside the
visualization texture. By rearranging the overflow check we make sure this (and
a crash) does not happen.
We also don't have to use xleft for start position, as that is 0 anyways, and
if we ever want to take into account xleft then the texture should be
positioned accordingly when rendering.
reading this, i wonder if a assertion with xleft == 0 would make sense
I don't really see the point. I'd rather add the xleft/ytop to the render
if you prefer, but overall I don't think it matters.
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1193,7 +1193,8 @@ static void video_audio_display(VideoState *s)
}
SDL_UnlockTexture(s->vis_texture);
}
-SDL_RenderCopy(renderer, s->vis_texture, NULL, NULL);
+rect = (SDL_Rect){s->xleft, s->ytop, s->width, s->height};
+SDL_RenderCopy(renderer, s->vis_texture, NULL, &rect);
}
if (!s->paused)
s->xpos++;
Regards,
Marton
___
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] fftools/ffplay: do not write out of rdft visualization texture
On Mon, Mar 08, 2021 at 09:56:38PM +0100, Marton Balint wrote: > > > On Sun, 7 Mar 2021, Michael Niedermayer wrote: > > > On Wed, Mar 03, 2021 at 11:27:22PM +0100, Marton Balint wrote: > > > If the window is resized it was possible that xpos pointed outside the > > > visualization texture. By rearranging the overflow check we make sure > > > this (and > > > a crash) does not happen. > > > > > > > > We also don't have to use xleft for start position, as that is 0 anyways, > > > and > > > if we ever want to take into account xleft then the texture should be > > > positioned accordingly when rendering. > > > > reading this, i wonder if a assertion with xleft == 0 would make sense > > I don't really see the point. It was just an idea that came to my mind without any deep thoughts > I'd rather add the xleft/ytop to the render if > you prefer, but overall I don't think it matters. please do what you prefer! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/dcadsp: Fix integer overflow in dmix_add_c()
On Sat, Jan 30, 2021 at 08:28:24PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 1515225320 + 759416059 cannot be represented > in type 'int' > Fixes: > 29256/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DCA_fuzzer-5719088561258496 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/dcadsp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/movenc: Support encryption of H265 stream in AnnexB format
Ping.
This change is quite simple and should be quick to review. Feel free to ask
any questions
On Mon, 1 Mar 2021, 14:54 Vadym Bezdushnyi, wrote:
> Add an ability to accept H265 AnnexB stream at encryption
> similar to how its done for H264 AnnexB stream.
>
> Steps to test:
>
> 1. Create h265 test files - mp4 and h265 AnnexB streams:
> ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v hevc
> input_h265.mp4
> ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v hevc
> -bsf:v hevc_mp4toannexb input_h265.h265
>
> 2. Encrypt and decrypt files. Put appropriate input file name here:
> input_h265.mp4 or input_h265.h265
> ffmpeg -i input_h265.h265 -vcodec copy -acodec copy -encryption_scheme
> cenc-aes-ctr \
> -encryption_key -encryption_kid
> \
> encrypted_h265.mp4
> ffplay -i encrypted_h265.mp4 -decryption_key
>
>
> Signed-off-by: Vadym Bezdushnyi
> ---
> libavformat/movenc.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 545b0885ae..0433968cd2 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5685,7 +5685,15 @@ int ff_mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> return ret;
> avio_write(pb, reformatted_data, size);
> } else {
> -size = ff_hevc_annexb2mp4(pb, pkt->data, pkt->size, 0, NULL);
> +if (trk->cenc.aes_ctr) {
> +size = ff_mov_cenc_avc_parse_nal_units(&trk->cenc, pb,
> pkt->data, size);
> +if (size < 0) {
> +ret = size;
> +goto err;
> +}
> +} else {
> +size = ff_hevc_annexb2mp4(pb, pkt->data, pkt->size, 0,
> NULL);
> +}
> }
> } else if (par->codec_id == AV_CODEC_ID_AV1) {
> if (trk->hint_track >= 0 && trk->hint_track < mov->nb_streams) {
> @@ -5727,6 +5735,9 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
> *pkt)
> if (par->codec_id == AV_CODEC_ID_H264 && par->extradata_size
> > 4) {
> int nal_size_length = (par->extradata[4] & 0x3) + 1;
> ret = ff_mov_cenc_avc_write_nal_units(s, &trk->cenc,
> nal_size_length, pb, pkt->data, size);
> +} else if(par->codec_id == AV_CODEC_ID_HEVC &&
> par->extradata_size > 21) {
> +int nal_size_length = (par->extradata[21] & 0x3) + 1;
> +ret = ff_mov_cenc_avc_write_nal_units(s, &trk->cenc,
> nal_size_length, pb, pkt->data, size);
> } else {
> ret = ff_mov_cenc_write_packet(&trk->cenc, pb, pkt->data,
> size);
> }
> @@ -6711,7 +6722,8 @@ static int mov_init(AVFormatContext *s)
>
> if (mov->encryption_scheme == MOV_ENC_CENC_AES_CTR) {
> ret = ff_mov_cenc_init(&track->cenc, mov->encryption_key,
> -track->par->codec_id == AV_CODEC_ID_H264, s->flags &
> AVFMT_FLAG_BITEXACT);
> +(track->par->codec_id == AV_CODEC_ID_H264 ||
> track->par->codec_id == AV_CODEC_ID_HEVC),
> +s->flags & AVFMT_FLAG_BITEXACT);
> if (ret)
> return ret;
> }
> --
> 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] mailmap: add entry for myself
On Mon, Mar 8, 2021 at 11:58 PM Thilo Borgmann wrote: > > Hi, > > Am 08.03.21 um 16:12 schrieb Linjie Fu: > > Signed-off-by: Linjie Fu > > --- > > .mailmap | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/.mailmap b/.mailmap > > index 3bd1a85c3c..ba072f38c8 100644 > > --- a/.mailmap > > +++ b/.mailmap > > @@ -10,7 +10,8 @@ > > > > > > > > - > > + > > + > > > > > > > > LGTM, you are listed as one of the libopenh264enc maintainers, please push. > Applied, thx. - linjie ___ 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/h264_slice: don't copy frame data during error concealment
In addition to the fact that av_image_copy() cannot handle hardware pixel formats, h->short_ref[0]->f may not even be writable at this point. Based on a patch by Hendrik Leppkes. Signed-off-by: James Almer --- This is an alternative to "avcodec/h264_slice: properly handle missing reference frames with hwaccel", given that I noticed that the target frame is not writable for example when running fate-h264-missing-frame. To keep the current behavior of copying the frame data instead of making a reference, I also tried to do ff_thread_release_buffer() -> ff_thread_get_buffer() -> av_frame_copy(), which worked with software decoding, but when using the d3d11va hwaccel the av_frame_copy() call would fail. There is a warning above this code that makes it sound like making references is not ideal, but considering h->short_ref[0] is not writable here it feels like it could be an outdated comment that someone forgot to remove. libavcodec/h264_slice.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index fa7a639053..a2f4ffa6d6 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -1599,13 +1599,11 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl, ff_thread_await_progress(&prev->tf, INT_MAX, 0); if (prev->field_picture) ff_thread_await_progress(&prev->tf, INT_MAX, 1); -av_image_copy(h->short_ref[0]->f->data, - h->short_ref[0]->f->linesize, - (const uint8_t **)prev->f->data, - prev->f->linesize, - prev->f->format, - prev->f->width, - prev->f->height); +ff_thread_release_buffer(h->avctx, &h->short_ref[0]->tf); +h->short_ref[0]->tf.f = h->short_ref[0]->f; +ret = ff_thread_ref_frame(&h->short_ref[0]->tf, &prev->tf); +if (ret < 0) +return ret; h->short_ref[0]->poc = prev->poc + 2U; } else if (!h->frame_recovered && !h->avctx->hwaccel) ff_color_frame(h->short_ref[0]->f, c); -- 2.30.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 v1] avformat/rtsp: RTP support buffer_size&pkt_size option
From: Jiangjie Gao And forward it to udp. issue: https://trac.ffmpeg.org/ticket/7517 Signed-off-by: Jiangjie Gao --- libavformat/rtsp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index 9a2933346e..25bdf475b3 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -2506,12 +2506,15 @@ static int rtp_read_header(AVFormatContext *s) RTSPState *rt = s->priv_data; const char *p; AVBPrint sdp; +AVDictionary *opts = NULL; if (!ff_network_init()) return AVERROR(EIO); +opts = map_to_opts(rt); ret = ffurl_open_whitelist(&in, s->url, AVIO_FLAG_READ, - &s->interrupt_callback, NULL, s->protocol_whitelist, s->protocol_blacklist, NULL); + &s->interrupt_callback, &opts, s->protocol_whitelist, s->protocol_blacklist, NULL); +av_dict_free(&opts); if (ret) goto fail; -- 2.27.0.windows.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/h264_slice: don't copy frame data during error concealment
On Tue, Mar 9, 2021 at 3:39 AM James Almer wrote: > > In addition to the fact that av_image_copy() cannot handle hardware pixel > formats, h->short_ref[0]->f may not even be writable at this point. > > Based on a patch by Hendrik Leppkes. > > Signed-off-by: James Almer > --- > This is an alternative to "avcodec/h264_slice: properly handle missing > reference frames with hwaccel", given that I noticed that the target frame is > not writable for example when running fate-h264-missing-frame. > > To keep the current behavior of copying the frame data instead of making a > reference, I also tried to do ff_thread_release_buffer() -> > ff_thread_get_buffer() -> av_frame_copy(), which worked with software > decoding, > but when using the d3d11va hwaccel the av_frame_copy() call would fail. > > There is a warning above this code that makes it sound like making references > is not ideal, but considering h->short_ref[0] is not writable here it feels > like it could be an outdated comment that someone forgot to remove. > Looks more thorough then my original change. I was worried about the comment also, but I think it may have been from before the days of ref-counting, frame threading, and all that (the comment appeared with the original code in e2983d6eac7b0bb563886c6f97c4ce0385b2018d, 2010) Perhaps the comment should be removed if we are going to reference now anyway? - Hendrik ___ 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".
