Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp8: Move end check into MB loop in vp78_decode_mv_mb_modes()
On Mon, Feb 15, 2021 at 09:23:11PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (long -> 5sec)
> Fixes:
> 30269/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5430325004075008
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp8.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index 5fa7971f8f..89c48e6cb1 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -2293,10 +2293,10 @@ int vp78_decode_mv_mb_modes(AVCodecContext *avctx,
> VP8Frame *curframe,
> s->mv_bounds.mv_min.x = -MARGIN;
> s->mv_bounds.mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
>
> -if (vpX_rac_is_end(>c)) {
> -return AVERROR_INVALIDDATA;
> -}
> for (mb_x = 0; mb_x < s->mb_width; mb_x++, mb_xy++, mb++) {
> +if (vpX_rac_is_end(>c)) {
> +return AVERROR_INVALIDDATA;
> +}
> if (mb_y == 0)
> AV_WN32A((mb - s->mb_width - 1)->intra4x4_pred_mode_top,
> DC_PRED * 0x01010101);
ok
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1] avcodec/libvpxenc: fix potential memory leak.
While parsing ref_frame_config, AVdictionary needs to be manually
deallocated.
---
libavcodec/libvpxenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 284cb9a108..941c3fdd88 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1595,6 +1595,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
if (en) {
if (avctx->codec_id == AV_CODEC_ID_VP9) {
AVDictionaryEntry* en2 = NULL;
+ctx->vpx_ref_frame_config = NULL;
av_dict_parse_string(>vpx_ref_frame_config,
en->value, "=", ":", 0);
while ((en2 = av_dict_get(ctx->vpx_ref_frame_config, "",
en2, AV_DICT_IGNORE_SUFFIX))) {
@@ -1604,6 +1605,8 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
en2->key, en2->value);
}
+if (ctx->vpx_ref_frame_config)
+av_dict_free(>vpx_ref_frame_config);
codecctl_intp(avctx, VP9E_SET_SVC_REF_FRAME_CONFIG, (int
*)>ref_frame_config);
} else {
av_log(avctx, AV_LOG_WARNING,
--
2.30.0.478.g8a0d178c01-goog
___
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 08/10] libavutil: add side data AVDnnBoundingBox for dnn based detect/classify filters
On 11/02/2021 08:15, Guo, Yejun wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Mark
Thompson
Sent: 2021年2月11日 6:19
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V2 08/10] libavutil: add side data
AVDnnBoundingBox for dnn based detect/classify filters
On 10/02/2021 09:34, Guo, Yejun wrote:
Signed-off-by: Guo, Yejun
---
doc/APIchanges | 2 ++
libavutil/Makefile | 1 +
libavutil/dnn_bbox.h | 68
libavutil/frame.c| 1 +
libavutil/frame.h| 7 +
libavutil/version.h | 2 +-
6 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644 libavutil/dnn_bbox.h
What is the intended consumer of this box information? (Is there some other
filter which will read these are do something with them, or some sort of user
program?)
If there is no use in ffmpeg outside libavfilter then the header should probably
be in libavfilter.
Thanks for the feedback.
For most case, other filters will use this box information,
for example, a classify filter will recognize the car number after the car
plate is detected,
another filter can apply 'beauty' if a face is detected, and updated drawbox
filter (in plan)
can draw the box for visualization, and a new filter such as bbox_to_roi can be
added
to apply roi encoding for the detected result.
It is possible that some others will use it,
for example, the new codec is adding AI labels and so libavcodec might need it
in the future,
and a user program might do something special such as:
1. use libavcodec to decode
2. use filter detect
3. write his own code to handle the detect result
As the first step, how about to put it in the libavfilter (so do not expose it
at API level and we are free to change it when needed)? And we can move
it to libavutil once it is required.
Sure.
How tied is this to the DNN implementation, and hence the DNN name? If
someone made a standalone filter doing object detection by some other
method, would it make sense for them to reuse this structure?
Yes, this structure is general, I add dnn prefix because of two reasons:
1. There's already bounding box in libavfilter/bbox.h, see below, it's simple
and we could
not reuse it, so we need a new name.
typedef struct FFBoundingBox {
int x1, x2, y1, y2;
} FFBoundingBox;
Right, really this is just the return type for the internal
ff_calculate_bounding_box() function - if you want to reuse the name externally
then it would be fine to rename the existing stuff to get it out of the way.
2. DNN is currently the dominate method for object detection.
Unless your ID values or something else about the output are DNN-specific then
I'm not really seeing the attraction of associating them with the DNN name for
external use. If a user wants to detect some objects in an image and then do
something with the result then maybe they know they are using DNN for first
step, but they won't care about where the result came from after that.
How about to use 'struct BoudingBox' when it is under libavfilter (added into
current file bbox.h),
and rename to 'AVBoudingBox' when it is needed to move to libavutil?
Hmm. What are we actually representing here? It's not just a bounding box
because the structure is also attaching a specific meaning to it - that we
think the bounding box corresponds to the location of some particular object in
the image data.
Given that, maybe we would be better with something like "ObjectLocation"?
(Just an idea, feel free to ignore me and suggest something else.)
diff --git a/libavutil/dnn_bbox.h b/libavutil/dnn_bbox.h new file mode
100644 index 00..50899c4486
--- /dev/null
+++ b/libavutil/dnn_bbox.h
+
+/**
+ * Object detection is usually applied to a smaller image that
+ * is scaled down from the original frame.
+ * width and height are attributes of the scaled image, in pixel.
+ */
+int model_input_width;
+int model_input_height;
Other than to interpret the distances below, what will the user do with this
information? (Alternatively: why not map the distances back onto the
original frame size?)
My idea was: if the original frame is scaled sometime later, the side data
(bbox)
keeps correct without any modification.
If we use the distance on the original frame size, shall we say the behavior
is undefined when it is scaled sometime later?
This probably shouldn't be a specific concern - many other existing side-data
types are invalidated by scaling (or other non-scaling filtering
transformations, for that matter).
Unless there is an independent reason to keep the model size (which there might
well be, I don't know) then I think it would be better to use the actual frame
size.
+
+/**
+ * Distance in pixels from the top edge of the scaled image to top
+ * and bottom, and from the left edge of the scaled image to left and
+ * right, defining the bounding box.
+ */
+int
Re: [FFmpeg-devel] [PATCH]lavc/pnm_parser: Add a pfm parser
Carl Eugen Hoyos: > Hi! > > Attached patch is necessary for a new pfm demuxer. > > Please comment, Carl Eugen > Can't we just wait and increment the number of codec_ids a parser can support at the next bump? - 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".
[FFmpeg-devel] [PATCH v2] cbs_h2645: Implement replace-PS with a table rather than many functions
While this is mode source code, it generates less binary code and can be
more cleanly extended to H.266.
---
On 14/02/2021 19:45, Andreas Rheinhardt wrote:
Nuo Mi:
From: Mark Thompson
---
libavcodec/cbs_h2645.c | 171 +++--
1 file changed, 130 insertions(+), 41 deletions(-)
...
+static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
+CodedBitstreamUnit *unit)
+{
+typedef struct {
+int nal_unit_type;
+int max_count;
+const char *name;
If this were a char name[4], these structs could be put in .rodata
instead of .data (or .data.rel.ro) when using position-independent code.
True, that would be nicer.
New patch enclosing, which also uses some macros to simplify the arrays (and
adds some explanatory comments).
This includes the no-active case, so extension to H.266 requires no additional
logic:
#define H266_PS_TYPE(cname, uname, id_name) \
H2645_PS_TYPE(H266, VVC_NUT_ ## cname, cname, uname, \
VVC_MAX_ ## cname ## _COUNT, \
uname ## _ ## id_name, common)
Then, "H266_PS_TYPE(APS, aps, adaptation)", etc.
Thanks,
- Mark
libavcodec/cbs_h2645.c | 161 ++---
1 file changed, 120 insertions(+), 41 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 6005d46e0d..6c44e781fa 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -661,38 +661,117 @@ static int
cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
return 0;
}
-#define cbs_h2645_replace_ps(h26n, ps_name, ps_var, id_element) \
-static int cbs_h26 ## h26n ## _replace_ ## ps_var(CodedBitstreamContext *ctx, \
- CodedBitstreamUnit *unit) \
-{ \
-CodedBitstreamH26 ## h26n ## Context *priv = ctx->priv_data; \
-H26 ## h26n ## Raw ## ps_name *ps_var = unit->content; \
-unsigned int id = ps_var->id_element; \
-int err; \
-if (id >= FF_ARRAY_ELEMS(priv->ps_var)) { \
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid " #ps_name \
- " id : %d.\n", id); \
-return AVERROR_INVALIDDATA; \
-} \
-err = ff_cbs_make_unit_refcounted(ctx, unit); \
-if (err < 0) \
-return err; \
-if (priv->ps_var[id] == priv->active_ ## ps_var) \
-priv->active_ ## ps_var = NULL ; \
-av_buffer_unref(>ps_var ## _ref[id]); \
-av_assert0(unit->content_ref); \
-priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
-if (!priv->ps_var ## _ref[id]) \
-return AVERROR(ENOMEM); \
-priv->ps_var[id] = (H26 ## h26n ## Raw ## ps_name *)priv->ps_var ##
_ref[id]->data; \
-return 0; \
-}
+static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
+CodedBitstreamUnit *unit)
+{
+typedef struct {
+// 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
[FFmpeg-devel] [PATCH]lavc/pnm_parser: Add a pfm parser
Hi!
Attached patch is necessary for a new pfm demuxer.
Please comment, Carl Eugen
From bd8d192651b3778c2cda387dbdce58eb377ca077 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 15 Feb 2021 23:22:35 +0100
Subject: [PATCH] lavc/pnm_parser: Add a pfm parser.
A parser cannot support more than five codec_ids.
---
libavcodec/parsers.c| 1 +
libavcodec/pnm_parser.c | 7 +++
libavcodec/version.h| 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index f8cfa1cde9..0c48cb67e1 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -62,6 +62,7 @@ extern AVCodecParser ff_mpegvideo_parser;
extern AVCodecParser ff_opus_parser;
extern AVCodecParser ff_png_parser;
extern AVCodecParser ff_pnm_parser;
+extern AVCodecParser ff_pfm_parser;
extern AVCodecParser ff_rv30_parser;
extern AVCodecParser ff_rv40_parser;
extern AVCodecParser ff_sbc_parser;
diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
index f3be6d640c..45d77e69be 100644
--- a/libavcodec/pnm_parser.c
+++ b/libavcodec/pnm_parser.c
@@ -138,3 +138,10 @@ AVCodecParser ff_pnm_parser = {
.parser_parse = pnm_parse,
.parser_close = ff_parse_close,
};
+
+AVCodecParser ff_pfm_parser = {
+.codec_ids = { AV_CODEC_ID_PFM },
+.priv_data_size = sizeof(PNMParseContext),
+.parser_parse = pnm_parse,
+.parser_close = ff_parse_close,
+};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 83dbd1ad63..d4fe2da937 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define LIBAVCODEC_VERSION_MINOR 123
+#define LIBAVCODEC_VERSION_MINOR 124
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.29.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/matroska: Add test for remuxing file with spherical metadata
Andreas Rheinhardt: > Also, test modifying colorspace properties and the default_mode > passthrough which is used here to create a file that has no default > track at all. > > Signed-off-by: Andreas Rheinhardt > --- > tests/fate/matroska.mak | 8 +++ > tests/ref/fate/matroska-spherical-mono-remux | 66 > 2 files changed, 74 insertions(+) > create mode 100644 tests/ref/fate/matroska-spherical-mono-remux > > diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak > index 1d2921194f..e03579def2 100644 > --- a/tests/fate/matroska.mak > +++ b/tests/fate/matroska.mak > @@ -57,6 +57,14 @@ FATE_MATROSKA_FFMPEG_FFPROBE-$(call ALLYES, > MATROSKA_DEMUXER OGG_DEMUXER \ > += fate-webm-dash-chapters > fate-webm-dash-chapters: CMD = transcode ogg > $(TARGET_SAMPLES)/vorbis/vorbis_chapter_extension_demo.ogg webm "-c copy > -cluster_time_limit 1500 -dash 1 -dash_track_number 124 -reserve_index_space > 400" "-c copy -t 0.5" "" -show_chapters > > +# This test the following features of the Matroska muxer: Writing projection > +# stream side-data; not setting any track to default if the user requested > it; > +# and modifying and writing colorspace properties. > +FATE_MATROSKA_FFMPEG_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER MATROSKA_MUXER \ > +H264_DECODER H264_PARSER) \ > + += fate-matroska-spherical-mono-remux > +fate-matroska-spherical-mono-remux: CMD = transcode matroska > $(TARGET_SAMPLES)/mkv/spherical.mkv matroska "-map 0 -map 0 -c copy > -disposition:0 -default+forced -disposition:1 -default -default_mode > passthrough -color_primaries:1 bt709 -color_trc:1 smpte170m -colorspace:1 > bt2020c -color_range:1 pc" "-map 0 -c copy -t 0" "" "-show_entries > stream_side_data_list:stream_disposition=default,forced:stream=color_range,color_space,color_primaries,color_transfer" > + > FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) += > fate-matroska-spherical-mono > fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF) > -show_entries stream_side_data_list -select_streams v -v 0 > $(TARGET_SAMPLES)/mkv/spherical.mkv > > diff --git a/tests/ref/fate/matroska-spherical-mono-remux > b/tests/ref/fate/matroska-spherical-mono-remux > new file mode 100644 > index 00..c72fc692bc > --- /dev/null > +++ b/tests/ref/fate/matroska-spherical-mono-remux > @@ -0,0 +1,66 @@ > +1a3be6691ace86663faeea688e6bb95a > *tests/data/fate/matroska-spherical-mono-remux.matroska > +161562 tests/data/fate/matroska-spherical-mono-remux.matroska > +#extradata 0: 43, 0x2b0e0d7b > +#extradata 1: 43, 0x2b0e0d7b > +#tb 0: 1/1000 > +#media_type 0: video > +#codec_id 0: h264 > +#dimensions 0: 1920x1080 > +#sar 0: 0/1 > +#tb 1: 1/1000 > +#media_type 1: video > +#codec_id 1: h264 > +#dimensions 1: 1920x1080 > +#sar 1: 0/1 > +0,-80, 0, 40,69118, 0x73cb52f0, S=2, 12, > 0x, 36, 0x2cf8035c > +1,-80, 0, 40,69118, 0x73cb52f0, S=2, 12, > 0x, 36, 0x2cf8035c > +0,-40,160, 40, 1103, 0x082a059f, F=0x0 > +1,-40,160, 40, 1103, 0x082a059f, F=0x0 > +[STREAM] > +color_range=unknown > +color_space=unknown > +color_transfer=unknown > +color_primaries=unknown > +DISPOSITION:default=0 > +DISPOSITION:forced=1 > +[SIDE_DATA] > +side_data_type=Stereo 3D > +type=2D > +inverted=0 > +[/SIDE_DATA] > +[SIDE_DATA] > +side_data_type=Spherical Mapping > +projection=tiled equirectangular > +bound_left=148 > +bound_top=73 > +bound_right=147 > +bound_bottom=72 > +yaw=45 > +pitch=30 > +roll=15 > +[/SIDE_DATA] > +[/STREAM] > +[STREAM] > +color_range=pc > +color_space=bt2020c > +color_transfer=smpte170m > +color_primaries=bt709 > +DISPOSITION:default=0 > +DISPOSITION:forced=0 > +[SIDE_DATA] > +side_data_type=Stereo 3D > +type=2D > +inverted=0 > +[/SIDE_DATA] > +[SIDE_DATA] > +side_data_type=Spherical Mapping > +projection=tiled equirectangular > +bound_left=148 > +bound_top=73 > +bound_right=147 > +bound_bottom=72 > +yaw=45 > +pitch=30 > +roll=15 > +[/SIDE_DATA] > +[/STREAM] > Totally forgot about this one. It applies with one change: The size of the output file is 21B larger due to 4ebfc13c338423cf48f1a1266c890422367f7775. Will apply the updated version later. - 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 12/12] tests/fate: Add test for zero-length Block
Andreas Rheinhardt: > It furthermore tests the demuxer's handling of chained SeekHeads, > level 1-elements after the Clusters and the muxer's capability of > writing huge TrackNumbers as well as expanding the Cues' length field > by one byte if necessary to fill the reserved space. It also tests > propagation of metadata. > > Signed-off-by: Andreas Rheinhardt > --- > tests/fate/matroska.mak | 10 ++ > tests/ref/fate/matroska-zero-length-block | 10 ++ > 2 files changed, 20 insertions(+) > create mode 100644 tests/ref/fate/matroska-zero-length-block > > diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak > index 1d2921194f..101502f668 100644 > --- a/tests/fate/matroska.mak > +++ b/tests/fate/matroska.mak > @@ -57,6 +57,16 @@ FATE_MATROSKA_FFMPEG_FFPROBE-$(call ALLYES, > MATROSKA_DEMUXER OGG_DEMUXER \ > += fate-webm-dash-chapters > fate-webm-dash-chapters: CMD = transcode ogg > $(TARGET_SAMPLES)/vorbis/vorbis_chapter_extension_demo.ogg webm "-c copy > -cluster_time_limit 1500 -dash 1 -dash_track_number 124 -reserve_index_space > 400" "-c copy -t 0.5" "" -show_chapters > > +# The input file has a Block whose payload has a size of zero before > reversing > +# header removal compression; it furthermore uses chained SeekHeads and has > +# level 1-elements after the Cluster. This is tested on the demuxer's side. > +# For the muxer this tests that it can correctly write huge TrackNumbers and > +# that it can expand the Cues element's length field by one byte if > necessary. > +# It furthermore tests correct propagation of the description tag. > +FATE_MATROSKA_FFMPEG_FFPROBE-$(call DEMMUX, MATROSKA, MATROSKA) \ > + += fate-matroska-zero-length-block > +fate-matroska-zero-length-block: CMD = transcode matroska > $(TARGET_SAMPLES)/mkv/zero_length_block.mks matroska "-c:s copy -dash 1 > -dash_track_number 20 -reserve_index_space 62 > -metadata_header_padding 1" "-c:s copy" "" "-show_entries > stream_tags=description" > + > FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) += > fate-matroska-spherical-mono > fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF) > -show_entries stream_side_data_list -select_streams v -v 0 > $(TARGET_SAMPLES)/mkv/spherical.mkv > > diff --git a/tests/ref/fate/matroska-zero-length-block > b/tests/ref/fate/matroska-zero-length-block > new file mode 100644 > index 00..8fae333a4d > --- /dev/null > +++ b/tests/ref/fate/matroska-zero-length-block > @@ -0,0 +1,10 @@ > +46c2885959b8a72ac4f7a221ba456565 > *tests/data/fate/matroska-zero-length-block.matroska > +622 tests/data/fate/matroska-zero-length-block.matroska > +#tb 0: 1/1000 > +#media_type 0: subtitle > +#codec_id 0: subrip > +0, 1000, 1000, 2000,5, 0x05b801df > +0, 3300, 3300, 3700, 16, 0x300705b2 > +[STREAM] > +TAG:DESCRIPTION=This track uses header removal compression and has a Block > of size zero before reversing it. > +[/STREAM] > Totally forgot about this one. It needs to be slightly modified because the created file is now 21B larger due to 4ebfc13c338423cf48f1a1266c890422367f7775, but that's trivial. Will apply it later. - 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 3/3] avformat/rmdec: Check codec_length without overflow
Michael Niedermayer:
> Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type
> 'int'
> Fixes:
> 30333/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5175286983426048
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/rmdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
> index 521b9d0e8c..613fb407df 100644
> --- a/libavformat/rmdec.c
> +++ b/libavformat/rmdec.c
> @@ -223,7 +223,7 @@ static int rm_read_audio_stream_info(AVFormatContext *s,
> AVIOContext *pb,
> if (version == 5)
> avio_r8(pb);
> codecdata_length = avio_rb32(pb);
> -if(codecdata_length + AV_INPUT_BUFFER_PADDING_SIZE <=
> (unsigned)codecdata_length){
> +if(codecdata_length < 0 || codecdata_length > INT_MAX -
> AV_INPUT_BUFFER_PADDING_SIZE){
> av_log(s, AV_LOG_ERROR, "codecdata_length too large\n");
> return -1;
> }
>
The first of these checks can be avoided by making codecdata_length
unsigned.
- 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".
[FFmpeg-devel] [PATCH] avformat/vividas: Use signed n in read_sb_block()
Fixes: OOM Fixes: 27780/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5097985075314688 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/vividas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/vividas.c b/libavformat/vividas.c index d745770dc4..b172a48b29 100644 --- a/libavformat/vividas.c +++ b/libavformat/vividas.c @@ -235,7 +235,7 @@ static uint8_t *read_sb_block(AVIOContext *src, unsigned *size, uint8_t *buf; uint8_t ibuf[8], sbuf[8]; uint32_t k2; -unsigned n; +int n; if (avio_read(src, ibuf, 8) < 8) return NULL; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avformat/rmdec: Check codec_length without overflow
Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type
'int'
Fixes:
30333/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5175286983426048
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/rmdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 521b9d0e8c..613fb407df 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -223,7 +223,7 @@ static int rm_read_audio_stream_info(AVFormatContext *s,
AVIOContext *pb,
if (version == 5)
avio_r8(pb);
codecdata_length = avio_rb32(pb);
-if(codecdata_length + AV_INPUT_BUFFER_PADDING_SIZE <=
(unsigned)codecdata_length){
+if(codecdata_length < 0 || codecdata_length > INT_MAX -
AV_INPUT_BUFFER_PADDING_SIZE){
av_log(s, AV_LOG_ERROR, "codecdata_length too large\n");
return -1;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/vp8: Move end check into MB loop in vp78_decode_mv_mb_modes()
Fixes: Timeout (long -> 5sec)
Fixes:
30269/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5430325004075008
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 5fa7971f8f..89c48e6cb1 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2293,10 +2293,10 @@ int vp78_decode_mv_mb_modes(AVCodecContext *avctx,
VP8Frame *curframe,
s->mv_bounds.mv_min.x = -MARGIN;
s->mv_bounds.mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
-if (vpX_rac_is_end(>c)) {
-return AVERROR_INVALIDDATA;
-}
for (mb_x = 0; mb_x < s->mb_width; mb_x++, mb_xy++, mb++) {
+if (vpX_rac_is_end(>c)) {
+return AVERROR_INVALIDDATA;
+}
if (mb_y == 0)
AV_WN32A((mb - s->mb_width - 1)->intra4x4_pred_mode_top,
DC_PRED * 0x01010101);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avformat/mov: Check element count in mov_metadata_hmmt()
Fixes: Timeout
Fixes:
30325/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6048395703746560
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9ca0a3ee15..2a701e9f70 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -288,6 +288,8 @@ static int mov_metadata_hmmt(MOVContext *c, AVIOContext
*pb, unsigned len)
return 0;
n_hmmt = avio_rb32(pb);
+if (n_hmmt > len / 4)
+return AVERROR_INVALIDDATA;
for (i = 0; i < n_hmmt && !pb->eof_reached; i++) {
int moment_time = avio_rb32(pb);
avpriv_new_chapter(c->fc, i, av_make_q(1, 1000), moment_time,
AV_NOPTS_VALUE, NULL);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/pnm: Support decoding gray float pbm images.
ff_pfm_parser On Mon, Feb 15, 2021 at 8:29 PM Carl Eugen Hoyos wrote: > Am Mo., 15. Feb. 2021 um 20:18 Uhr schrieb Paul B Mahol >: > > > > then add new parser bellow > > Already working on it: > ff_pnm2_parser or ff_pfm_parser? > Or another idea? > > Thank you, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/pnm: Support decoding gray float pbm images.
Am Mo., 15. Feb. 2021 um 20:18 Uhr schrieb Paul B Mahol : > > then add new parser bellow Already working on it: ff_pnm2_parser or ff_pfm_parser? Or another idea? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/pnm: Support decoding gray float pbm images.
then add new parser bellow On Mon, Feb 15, 2021 at 8:16 PM Carl Eugen Hoyos wrote: > Am Mo., 15. Feb. 2021 um 19:13 Uhr schrieb Carl Eugen Hoyos > : > > > > Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol < > one...@gmail.com>: > > > > > > Why you use pbm decoder for probing of pfm files? > > > > The only samples I found have the extension pbm and I > > simply misunderstood how you designed this since my > > samples were detected as pbm (because of their > > extension). > > > > Will fix, Carl Eugen > > AVParserContext->codec_ids is limited to five elements, > therefore no additional AV_CODEC_ID can be added to > the pnm_parser and AV_CODEC_ID_PFM cannot be used > for the autodetection. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/pnm: Support decoding gray float pbm images.
Am Mo., 15. Feb. 2021 um 19:13 Uhr schrieb Carl Eugen Hoyos : > > Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol : > > > > Why you use pbm decoder for probing of pfm files? > > The only samples I found have the extension pbm and I > simply misunderstood how you designed this since my > samples were detected as pbm (because of their > extension). > > Will fix, Carl Eugen AVParserContext->codec_ids is limited to five elements, therefore no additional AV_CODEC_ID can be added to the pnm_parser and AV_CODEC_ID_PFM cannot be used for the autodetection. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/x86/vf_gblur: add postscale SIMD
On 2/14/2021 11:32 AM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavfilter/x86/vf_gblur.asm| 49 +
libavfilter/x86/vf_gblur_init.c | 17 ++--
2 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/libavfilter/x86/vf_gblur.asm b/libavfilter/x86/vf_gblur.asm
index a25b1659f5..8ccfbdc56b 100644
--- a/libavfilter/x86/vf_gblur.asm
+++ b/libavfilter/x86/vf_gblur.asm
@@ -183,3 +183,52 @@ HORIZ_SLICE
INIT_XMM avx2
HORIZ_SLICE
%endif
+
+%macro POSTSCALE_SLICE 0
+%if UNIX64
+cglobal postscale_slice, 2, 3, 4, ptr, length, x
2, 2, 4, ptr, length
+%else
+cglobal postscale_slice, 5, 6, 4, ptr, length, postscale, min, max, x
5, 5, 4, ptr, length, postscale, min, max
+%endif
+shl lengthd, 2
shl lengthd, 2
add ptrq, lengthq
neg lengthq
+%if WIN64
+SWAP 0, 2
+SWAP 1, 3
+SWAP 2, 4
+%endif
+%if cpuflag(avx2)
+vbroadcastss m0, xm0
+vbroadcastss m1, xm1
+vbroadcastss m2, xm2
+%else
+shufps xm0, xm0, 0
+shufps xm1, xm1, 0
+shufps xm2, xm2, 0
+%endif
+xor xq, xq
remove this instruction.
+
+.loop:
+%if cpuflag(avx2)
+mulps m3, m0, [ptrq + xq]
Replace xq with lengthq here and everywhere else.
+%else
+movu m3, [ptrq + xq]
+mulps m3, m0
+%endif
+maxps m3, m1
+minps m3, m2
+movu [ptrq+xq], m3
+
+add xq, mmsize
+cmp xd, lengthd
remove this cmp.
+jl .loop
+
+RET
+%endmacro
+
+INIT_XMM sse
+POSTSCALE_SLICE
+
+%if HAVE_AVX2_EXTERNAL
+INIT_YMM avx2
+POSTSCALE_SLICE
+%endif
diff --git a/libavfilter/x86/vf_gblur_init.c b/libavfilter/x86/vf_gblur_init.c
index e63e59fe23..9223cb797d 100644
--- a/libavfilter/x86/vf_gblur_init.c
+++ b/libavfilter/x86/vf_gblur_init.c
@@ -27,14 +27,25 @@
void ff_horiz_slice_sse4(float *ptr, int width, int height, int steps, float
nu, float bscale);
void ff_horiz_slice_avx2(float *ptr, int width, int height, int steps, float
nu, float bscale);
+void ff_postscale_slice_sse(float *ptr, int length, float postscale, float min, float max);
+void ff_postscale_slice_avx2(float *ptr, int length, float postscale, float
min, float max);
+
av_cold void ff_gblur_init_x86(GBlurContext *s)
{
-#if ARCH_X86_64
int cpu_flags = av_get_cpu_flags();
-if (EXTERNAL_SSE4(cpu_flags))
+if (EXTERNAL_SSE(cpu_flags)) {
+s->postscale_slice = ff_postscale_slice_sse;
+}
+if (EXTERNAL_AVX2(cpu_flags)) {
EXTERNAL_AVX2_FAST
+s->postscale_slice = ff_postscale_slice_avx2;
+}
+#if ARCH_X86_64
+if (EXTERNAL_SSE4(cpu_flags)) {
s->horiz_slice = ff_horiz_slice_sse4;
-if (EXTERNAL_AVX2(cpu_flags))
+}
+if (EXTERNAL_AVX2(cpu_flags)) {
s->horiz_slice = ff_horiz_slice_avx2;
+}
#endif
}
LGTM with the above.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/pnm: Support decoding gray float pbm images.
Am Mo., 15. Feb. 2021 um 02:39 Uhr schrieb Paul B Mahol : > > Why you use pbm decoder for probing of pfm files? The only samples I found have the extension pbm and I simply misunderstood how you designed this since my samples were detected as pbm (because of their extension). Will fix, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/6] avformat/mxfenc: Fix typo
lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add initial exr image encoder
On 2/15/2021 1:41 PM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/exrenc.c| 480 +
libavformat/img2enc.c | 2 +-
4 files changed, 483 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/exrenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a98ec408bb..5fb735f129 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -321,6 +321,7 @@ OBJS-$(CONFIG_ESCAPE124_DECODER) += escape124.o
OBJS-$(CONFIG_ESCAPE130_DECODER) += escape130.o
OBJS-$(CONFIG_EVRC_DECODER)+= evrcdec.o acelp_vectors.o lsp.o
OBJS-$(CONFIG_EXR_DECODER) += exr.o exrdsp.o
+OBJS-$(CONFIG_EXR_ENCODER) += exrenc.o
OBJS-$(CONFIG_FASTAUDIO_DECODER) += fastaudio.o
OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 16ec182a52..cb3f0e7c18 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -109,6 +109,7 @@ extern AVCodec ff_eightsvx_exp_decoder;
extern AVCodec ff_eightsvx_fib_decoder;
extern AVCodec ff_escape124_decoder;
extern AVCodec ff_escape130_decoder;
+extern AVCodec ff_exr_encoder;
extern AVCodec ff_exr_decoder;
extern AVCodec ff_ffv1_encoder;
extern AVCodec ff_ffv1_decoder;
diff --git a/libavcodec/exrenc.c b/libavcodec/exrenc.c
new file mode 100644
index 00..686c7bac25
--- /dev/null
+++ b/libavcodec/exrenc.c
[...]
+static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+EXRContext *s = avctx->priv_data;
+PutByteContext *pb = >pb;
+int64_t offset;
+int ret;
+int64_t out_size = 2048LL + avctx->height * 16LL +
+ av_image_get_buffer_size(avctx->pix_fmt,
+ avctx->width,
+ avctx->height, 64) * 3LL / 2;
+
+if ((ret = ff_alloc_packet2(avctx, pkt, out_size, 0)) < 0)
Pass out_size as min_packet too, to avoid using the internal
byte_buffer. It will save a memcpy per packet.
+return ret;
[...]
+pkt->size = bytestream2_tell_p(pb);
Use av_shrink_packet(), which will zero the padding bytes.
+pkt->flags |= AV_PKT_FLAG_KEY;
+*got_packet = 1;
+
+return 0;
+}
+
+#define OFFSET(x) offsetof(EXRContext, x)
+#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
+static const AVOption options[] = {
+{ "compression", "set compression type", OFFSET(compression), AV_OPT_TYPE_INT,
{.i64=0}, 0, EXR_NBCOMPR-1, VE, "compr" },
+{ "none","none", 0, AV_OPT_TYPE_CONST,
{.i64=EXR_RAW}, 0, 0, VE, "compr" },
+{ "rle" ,"RLE", 0, AV_OPT_TYPE_CONST,
{.i64=EXR_RLE}, 0, 0, VE, "compr" },
+{ "zip1","ZIP1", 0, AV_OPT_TYPE_CONST,
{.i64=EXR_ZIP1}, 0, 0, VE, "compr" },
+{ "zip16", "ZIP16",0, AV_OPT_TYPE_CONST,
{.i64=EXR_ZIP16}, 0, 0, VE, "compr" },
+{ "gamma", "set gamma", OFFSET(gamma), AV_OPT_TYPE_FLOAT, {.dbl=1.f},
0.001, FLT_MAX, VE },
+{ NULL},
+};
+
+static const AVClass exr_class = {
+.class_name = "exr",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVCodec ff_exr_encoder = {
+.name = "exr",
+.long_name = NULL_IF_CONFIG_SMALL("OpenEXR image"),
+.priv_data_size = sizeof(EXRContext),
+.priv_class = _class,
+.type = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_EXR,
+.init = encode_init,
+.encode2= encode_frame,
+.close = encode_close,
+.capabilities = AV_CODEC_CAP_FRAME_THREADS,
+.pix_fmts = (const enum AVPixelFormat[]) {
+ AV_PIX_FMT_GBRPF32,
+ AV_PIX_FMT_GBRAPF32,
+ AV_PIX_FMT_NONE },
+};
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 84201d3beb..0f7a21ffa0 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -260,7 +260,7 @@ static const AVClass img2mux_class = {
AVOutputFormat ff_image2_muxer = {
.name = "image2",
.long_name = NULL_IF_CONFIG_SMALL("image2 sequence"),
-.extensions =
"bmp,dpx,jls,jpeg,jpg,ljpg,pam,pbm,pcx,pfm,pgm,pgmyuv,png,"
+.extensions =
"bmp,dpx,exr,jls,jpeg,jpg,ljpg,pam,pbm,pcx,pfm,pgm,pgmyuv,png,"
"ppm,sgi,tga,tif,tiff,jp2,j2c,j2k,xwd,sun,ras,rs,im1,im8,im24,"
"sunras,xbm,xface,pix,y",
.priv_data_size = sizeof(VideoMuxData),
[FFmpeg-devel] [PATCH v2 6/6] avformat/mxfenc: Discard audio until valid video has been received
Normally, video packets are muxed before audio packets for mxf (there is
a dedicated interleave function for this); furthermore the first (video)
packet triggers writing the actual header. Yet when the first video packet
fails the checks performed on it, it will be an audio packet that leads
to writing the header and codec_ul (a value set based upon
properties of the bitstream which necessitates actually inspecting
packets) may be wrong. Therefore this commit discards audio packets until
a valid video packet has been received.
Signed-off-by: Andreas Rheinhardt
---
Updated the commit message in light of the fact that #7993 is now fixed
by the earlier commit.
libavformat/mxfenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 72edaa9e30..1c668998e2 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2887,6 +2887,13 @@ static int mxf_write_packet(AVFormatContext *s, AVPacket
*pkt)
MXFIndexEntry ie = {0};
int err;
+if (!mxf->header_written && pkt->stream_index != 0 &&
+s->oformat != _mxf_opatom_muxer) {
+av_log(s, AV_LOG_ERROR, "Received non-video packet before "
+"header has been written\n");
+return AVERROR_INVALIDDATA;
+}
+
if (!mxf->cbr_index && !mxf->edit_unit_byte_count &&
!(mxf->edit_units_count % EDIT_UNITS_PER_BODY)) {
if ((err = av_reallocp_array(>index_entries, mxf->edit_units_count
+ EDIT_UNITS_PER_BODY,
sizeof(*mxf->index_entries))) < 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 v2 5/6] tests/fate-run.sh: Don't overlook errors from md5 tests
The md5 test up until now ignored errors from ffmpeg (the cli) and just
md5'ed whatever ffmpeg has output; while testing scenarios in which
ffmpeg fails has its merits, errors should not be overlooked by default;
doing so also reduces the effectiveness of sanitizers as errors from
them are ignored. This has happened with a memleak in the AV1 decoder.
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 58d5fdbb60..b69176f7c3 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -158,7 +158,7 @@ md5pipe(){
md5(){
encfile="${outdir}/${test}.out"
cleanfiles="$cleanfiles $encfile"
-ffmpeg -y "$@" $(target_path $encfile)
+ffmpeg -y "$@" $(target_path $encfile) || return
do_md5sum $encfile | awk '{print $1}'
}
--
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 v2 4/6] fate/mxf: Fix d10-user-comments test
The mxf_d10 muxer is very picky regarding the input it accepts: The only video accepted is MPEG-2 with absolutely constant bitrate, i.e. all packets need to have exactly the same size; and only a few bitrates are accepted. The sample file used did not abide by this: Writing the first packet (a video packet) errors out and afterwards an audio packet from the muxing queue has been written. That's all besides metadata (which this test is about). The FFmpeg cli returned an error, but said error has been ignored by the md5 test. This commit changes the test to actually send a compliant stream to the muxer, so that it does not error out; furthermore, the test is changed to explicitly check the metadata instead of it only being implicitly included in the md5 checksum. The compliant stream is created by our encoder at runtime. Finally, the test now also covers writing user-specified product/company/version identification. Signed-off-by: Andreas Rheinhardt --- In comparison to the first version [1] I expanded the test to also cover the new product/company/version identification. [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273405.html tests/fate/mxf.mak | 8 tests/ref/fate/mxf-d10-user-comments | 28 +++- 2 files changed, 31 insertions(+), 5 deletions(-) diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak index ca119fa677..3a1096176f 100644 --- a/tests/fate/mxf.mak +++ b/tests/fate/mxf.mak @@ -45,9 +45,8 @@ FATE_MXF_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += fate-mxf-u fate-mxf-user-comments: $(SAMPLES)/mxf/Sony-1.mxf fate-mxf-user-comments: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1.mxf -c copy -metadata "comment_test=value" -fflags +bitexact -f mxf -FATE_MXF_D10_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += fate-mxf-d10-user-comments -fate-mxf-d10-user-comments: $(SAMPLES)/mxf/Sony-1.mxf -fate-mxf-d10-user-comments: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1.mxf -c copy -metadata "comment_test=value" -store_user_comments 1 -fflags +bitexact -f mxf_d10 +FATE_MXF_D10_USER_COMMENTS-$(call ALLYES, FILE_PROTOCOL MXF_DEMUXER DVVIDEO_DECODER SCALE_FILTER MPEG2VIDEO_ENCODER MXF_D10_MUXER EXTRACT_EXTRADATA_BSF MPEGVIDEO_PARSER PIPE_PROTOCOL FRAMECRC_MUXER) += fate-mxf-d10-user-comments +fate-mxf-d10-user-comments: CMD = transcode mxf $(TARGET_SAMPLES)/mxf/Avid-5.mxf mxf_d10 "-c:v mpeg2video -b:v 3k -minrate:v 3k -maxrate:v 3k -bufsize:v 3k -rc_init_occupancy 3k -vf scale=w=1280:h=720 -an -metadata comment_test=value -metadata company_name=FATE-company -metadata product_name=FATE-test -metadata product_version=3.14159 -store_user_comments 1" "-c copy -frames:v 5" "" "-show_entries format_tags" FATE_MXF_OPATOM_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += fate-mxf-opatom-user-comments fate-mxf-opatom-user-comments: $(SAMPLES)/mxf/Sony-1.mxf @@ -56,7 +55,8 @@ fate-mxf-opatom-user-comments: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1. FATE_MXF-$(CONFIG_MXF_DEMUXER) += $(FATE_MXF) FATE_SAMPLES_AVCONV += $(FATE_MXF-yes) $(FATE_MXF_REEL_NAME-yes) -FATE_SAMPLES_AVCONV += $(FATE_MXF_USER_COMMENTS-yes) $(FATE_MXF_D10_USER_COMMENTS-yes) $(FATE_MXF_OPATOM_USER_COMMENTS-yes) +FATE_SAMPLES_AVCONV += $(FATE_MXF_USER_COMMENTS-yes) $(FATE_MXF_OPATOM_USER_COMMENTS-yes) +FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_MXF_D10_USER_COMMENTS-yes) FATE_SAMPLES_FFPROBE += $(FATE_MXF_PROBE-yes) fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes) $(FATE_MXF_REEL_NAME-yes) $(FATE_MXF_USER_COMMENTS-yes) $(FATE_MXF_D10_USER_COMMENTS-yes) $(FATE_MXF_OPATOM_USER_COMMENTS-yes) diff --git a/tests/ref/fate/mxf-d10-user-comments b/tests/ref/fate/mxf-d10-user-comments index c35add0279..0dcb04de30 100644 --- a/tests/ref/fate/mxf-d10-user-comments +++ b/tests/ref/fate/mxf-d10-user-comments @@ -1 +1,27 @@ -7bb9f39e8e05724525154de17f0235d8 +6dc13ae283257e898e069e5041ac8435 *tests/data/fate/mxf-d10-user-comments.mxf_d10 +3782189 tests/data/fate/mxf-d10-user-comments.mxf_d10 +#extradata 0: 34, 0x716b05c4 +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: mpeg2video +#dimensions 0: 1280x720 +#sar 0: 3/4 +0, -1, 0,1, 15, 0x0547870d, S=1, 24, 0x5aa90ad0 +0, 0, 1,1, 15, 0xe80a1612, F=0x0 +0, 1, 2,1, 15, 0xc5c50e2f, F=0x0 +0, 2, 3,1, 15, 0x51e28a04, F=0x0 +0, 3, 4,1, 15, 0x9bbe6feb, F=0x0 +[FORMAT] +TAG:operational_pattern_ul=060e2b34.04010101.0d010201.01010900 +TAG:uid=adab4424-2f25-4dc7-92ff-29bd000c +TAG:generation_uid=adab4424-2f25-4dc7-92ff-29bd000c0001 +TAG:company_name=FATE-company +TAG:product_name=FATE-test +TAG:product_version=3.14159 +TAG:application_platform=Lavf +TAG:product_uid=adab4424-2f25-4dc7-92ff-29bd000c0002 +TAG:toolkit_version=0.0.0.0.0
[FFmpeg-devel] [PATCH v2 3/6] avformat/mxfenc: Fix typo
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3bfe2a5c1a..72edaa9e30 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -752,7 +752,7 @@ static void store_version(AVFormatContext *s){
avio_wb16(pb, 0); // release
}
-#define PLATFROM_IDENT "Lavf " AV_STRINGIFY((OS_NAME))
+#define PLATFORM_IDENT "Lavf " AV_STRINGIFY((OS_NAME))
static void mxf_write_identification(AVFormatContext *s)
{
MXFContext *mxf = s->priv_data;
@@ -762,7 +762,7 @@ static void mxf_write_identification(AVFormatContext *s)
AVDictionaryEntry *version_entry = av_dict_get(s->metadata,
"product_version", NULL, 0);
const char *company = com_entry ? com_entry->value : "FFmpeg";
const char *product = product_entry ? product_entry->value : s->oformat !=
_mxf_opatom_muxer ? "OP1a Muxer" : "OPAtom Muxer";
-const char *platform = s->flags & AVFMT_FLAG_BITEXACT ? "Lavf" :
PLATFROM_IDENT;
+const char *platform = s->flags & AVFMT_FLAG_BITEXACT ? "Lavf" :
PLATFORM_IDENT;
const char *version = version_entry ? version_entry->value :
s->flags & AVFMT_FLAG_BITEXACT ? "0.0.0" :
AV_STRINGIFY(LIBAVFORMAT_VERSION);
--
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 v2 2/6] avformat/mxfenc: Use user-specified version even when bitexact
Doing so is still bitexact. Signed-off-by: Andreas Rheinhardt --- libavformat/mxfenc.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c index 509cae8442..3bfe2a5c1a 100644 --- a/libavformat/mxfenc.c +++ b/libavformat/mxfenc.c @@ -762,16 +762,15 @@ static void mxf_write_identification(AVFormatContext *s) AVDictionaryEntry *version_entry = av_dict_get(s->metadata, "product_version", NULL, 0); const char *company = com_entry ? com_entry->value : "FFmpeg"; const char *product = product_entry ? product_entry->value : s->oformat != _mxf_opatom_muxer ? "OP1a Muxer" : "OPAtom Muxer"; -const char *product_version = version_entry ? version_entry->value : AV_STRINGIFY(LIBAVFORMAT_VERSION); const char *platform = s->flags & AVFMT_FLAG_BITEXACT ? "Lavf" : PLATFROM_IDENT; -const char *version; +const char *version = version_entry ? version_entry->value : + s->flags & AVFMT_FLAG_BITEXACT ? "0.0.0" : + AV_STRINGIFY(LIBAVFORMAT_VERSION); int length; mxf_write_metadata_key(pb, 0x013000); PRINT_KEY(s, "identification key", pb->buf_ptr - 16); -version = s->flags & AVFMT_FLAG_BITEXACT ? -"0.0.0" : product_version; length = 100 +mxf_utf16_local_tag_length(company) + mxf_utf16_local_tag_length(product) + mxf_utf16_local_tag_length(platform) + -- 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 v2 1/6] avformat/mxfenc: Never set codec_ul UID to NULL
mxf distinguishes codec profiles by different UIDs and therefore needs
to check that the input is actually compatible with mxf (i.e. if there
is a defined UID for it). If not, then sometimes the UID would be set to
NULL and writing the (video) packet would fail. Yet the following audio
packet would trigger writing the header (which has been postponed because
the UID is not known at the start) and if the UID is NULL, this can lead
to segfaults. This commit therefore stops setting the UID to NULL if the
input is incompatible with mxf (it has initially been set to a generic
value in mxf_write_header()).
Fixes #7993.
Signed-off-by: Andreas Rheinhardt
---
This has already been sent earlier [1], yet it hasn't been applied
because Baptiste wanted it to be fixed by making sure that it is always
the video track that triggers writing the header. In a discussion on IRC
Tomas indicated that he wants both fixes for this bug and I will
therefore apply this here tomorrow unless there are objections.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/257755.html
libavformat/mxfenc.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 0b399178b5..509cae8442 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2020,7 +2020,6 @@ static int mxf_parse_prores_frame(AVFormatContext *s,
AVStream *st, AVPacket *pk
if (mxf->header_written)
return 1;
-sc->codec_ul = NULL;
profile = st->codecpar->profile;
for (i = 0; i < FF_ARRAY_ELEMS(mxf_prores_codec_uls); i++) {
if (profile == mxf_prores_codec_uls[i].profile) {
@@ -2028,7 +2027,7 @@ static int mxf_parse_prores_frame(AVFormatContext *s,
AVStream *st, AVPacket *pk
break;
}
}
-if (!sc->codec_ul)
+if (i == FF_ARRAY_ELEMS(mxf_prores_codec_uls))
return 0;
sc->frame_size = pkt->size;
@@ -2074,7 +2073,6 @@ static int mxf_parse_dnxhd_frame(AVFormatContext *s,
AVStream *st, AVPacket *pkt
if (pkt->size < 43)
return 0;
-sc->codec_ul = NULL;
cid = AV_RB32(pkt->data + 0x28);
for (i = 0; i < FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls); i++) {
if (cid == mxf_dnxhd_codec_uls[i].cid) {
@@ -2082,7 +2080,7 @@ static int mxf_parse_dnxhd_frame(AVFormatContext *s,
AVStream *st, AVPacket *pkt
break;
}
}
-if (!sc->codec_ul)
+if (i == FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls))
return 0;
sc->component_depth = 0;
@@ -2245,6 +2243,7 @@ static int mxf_parse_h264_frame(AVFormatContext *s,
AVStream *st,
const uint8_t *buf = pkt->data;
const uint8_t *buf_end = pkt->data + pkt->size;
const uint8_t *nal_end;
+const UID *codec_ul = NULL;
uint32_t state = -1;
int extra_size = 512; // support AVC Intra files without SPS/PPS header
int i, frame_size, slice_type, has_sps = 0, intra_only = 0, ret;
@@ -2315,12 +2314,11 @@ static int mxf_parse_h264_frame(AVFormatContext *s,
AVStream *st,
if (!has_sps)
sc->interlaced = st->codecpar->field_order != AV_FIELD_PROGRESSIVE ? 1
: 0;
-sc->codec_ul = NULL;
frame_size = pkt->size + extra_size;
for (i = 0; i < FF_ARRAY_ELEMS(mxf_h264_codec_uls); i++) {
if (frame_size == mxf_h264_codec_uls[i].frame_size && sc->interlaced
== mxf_h264_codec_uls[i].interlaced) {
-sc->codec_ul = _h264_codec_uls[i].uid;
+codec_ul = _h264_codec_uls[i].uid;
sc->component_depth = 10; // AVC Intra is always 10 Bit
sc->aspect_ratio = (AVRational){ 16, 9 }; // 16:9 is mandatory for
broadcast HD
st->codecpar->profile = mxf_h264_codec_uls[i].profile;
@@ -2334,17 +2332,18 @@ static int mxf_parse_h264_frame(AVFormatContext *s,
AVStream *st,
mxf_h264_codec_uls[i].profile == sps->profile_idc &&
(mxf_h264_codec_uls[i].intra_only < 0 ||
mxf_h264_codec_uls[i].intra_only == intra_only)) {
-sc->codec_ul = _h264_codec_uls[i].uid;
+codec_ul = _h264_codec_uls[i].uid;
st->codecpar->profile = sps->profile_idc;
st->codecpar->level = sps->level_idc;
// continue to check for avc intra
}
}
-if (!sc->codec_ul) {
+if (!codec_ul) {
av_log(s, AV_LOG_ERROR, "h264 profile not supported\n");
return 0;
}
+sc->codec_ul = codec_ul;
return 1;
}
@@ -2441,9 +2440,13 @@ static int mxf_parse_mpeg2_frame(AVFormatContext *s,
AVStream *st,
}
}
}
-if (s->oformat != _mxf_d10_muxer)
-sc->codec_ul = mxf_get_mpeg2_codec_ul(st->codecpar);
-return !!sc->codec_ul;
+if (s->oformat != _mxf_d10_muxer) {
+const UID *codec_ul = mxf_get_mpeg2_codec_ul(st->codecpar);
+if (!codec_ul)
+return 0;
+sc->codec_ul = codec_ul;
+}
+return 1;
}
static uint64_t
[FFmpeg-devel] [PATCH] avcodec: add initial exr image encoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/exrenc.c| 480 +
libavformat/img2enc.c | 2 +-
4 files changed, 483 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/exrenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a98ec408bb..5fb735f129 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -321,6 +321,7 @@ OBJS-$(CONFIG_ESCAPE124_DECODER) += escape124.o
OBJS-$(CONFIG_ESCAPE130_DECODER) += escape130.o
OBJS-$(CONFIG_EVRC_DECODER)+= evrcdec.o acelp_vectors.o lsp.o
OBJS-$(CONFIG_EXR_DECODER) += exr.o exrdsp.o
+OBJS-$(CONFIG_EXR_ENCODER) += exrenc.o
OBJS-$(CONFIG_FASTAUDIO_DECODER) += fastaudio.o
OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 16ec182a52..cb3f0e7c18 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -109,6 +109,7 @@ extern AVCodec ff_eightsvx_exp_decoder;
extern AVCodec ff_eightsvx_fib_decoder;
extern AVCodec ff_escape124_decoder;
extern AVCodec ff_escape130_decoder;
+extern AVCodec ff_exr_encoder;
extern AVCodec ff_exr_decoder;
extern AVCodec ff_ffv1_encoder;
extern AVCodec ff_ffv1_decoder;
diff --git a/libavcodec/exrenc.c b/libavcodec/exrenc.c
new file mode 100644
index 00..686c7bac25
--- /dev/null
+++ b/libavcodec/exrenc.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (c) 2021 Paul B Mahol
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * OpenEXR encoder
+ */
+
+#include
+#include
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+enum ExrCompr {
+EXR_RAW,
+EXR_RLE,
+EXR_ZIP1,
+EXR_ZIP16,
+EXR_NBCOMPR,
+};
+
+enum ExrPixelType {
+EXR_UINT,
+EXR_HALF,
+EXR_FLOAT,
+EXR_UNKNOWN,
+};
+
+static const char abgr_chlist[4] = { 'A', 'B', 'G', 'R' };
+static const char bgr_chlist[4] = { 'B', 'G', 'R', 'A' };
+static const uint8_t gbra_order[4] = { 3, 1, 0, 2 };
+static const uint8_t gbr_order[4] = { 1, 0, 2, 0 };
+
+typedef struct EXRScanlineData {
+uint8_t *compressed_data;
+unsigned int compressed_size;
+
+uint8_t *uncompressed_data;
+unsigned int uncompressed_size;
+
+uint8_t *tmp;
+unsigned int tmp_size;
+
+int64_t actual_size;
+} EXRScanlineData;
+
+typedef struct EXRContext {
+const AVClass *class;
+
+int compression;
+int planes;
+int nb_scanlines;
+int scanline_height;
+float gamma;
+const char *ch_names;
+const uint8_t *ch_order;
+PutByteContext pb;
+
+EXRScanlineData *scanline;
+} EXRContext;
+
+static int encode_init(AVCodecContext *avctx)
+{
+EXRContext *s = avctx->priv_data;
+
+switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GBRPF32:
+s->planes = 3;
+s->ch_names = bgr_chlist;
+s->ch_order = gbr_order;
+break;
+case AV_PIX_FMT_GBRAPF32:
+s->planes = 4;
+s->ch_names = abgr_chlist;
+s->ch_order = gbra_order;
+break;
+default:
+av_assert0(0);
+}
+
+switch (s->compression) {
+case EXR_RAW:
+case EXR_RLE:
+case EXR_ZIP1:
+s->scanline_height = 1;
+s->nb_scanlines = avctx->height;
+break;
+case EXR_ZIP16:
+s->scanline_height = 16;
+s->nb_scanlines = (avctx->height + s->scanline_height - 1) /
s->scanline_height;
+break;
+default:
+av_assert0(0);
+}
+
+s->scanline = av_calloc(s->nb_scanlines, sizeof(*s->scanline));
+if (!s->scanline)
+return AVERROR(ENOMEM);
+
+return 0;
+}
+
+static int encode_close(AVCodecContext *avctx)
+{
+EXRContext *s = avctx->priv_data;
+
+for (int y = 0; y < s->nb_scanlines && s->scanline; y++) {
+EXRScanlineData *scanline = >scanline[y];
+
+av_freep(>tmp);
+av_freep(>compressed_data);
+av_freep(>uncompressed_data);
+}
+
+av_freep(>scanline);
+
+
Re: [FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: ignore encoded h264 SEI nalu by default
On Mon, Feb 15, 2021 at 7:51 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> sharpbai:
> > Before macOS 11, the encoded h264 sample contains fixed SEI before
> > IDR frame, which the content is below
> >
> > 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> > 14 bb 29 80
> >
> > The length of the encoded SEI nalu is 20 byte. According to
> > the ITU-T H.264 Recommendation section 7.3.2.3.1, the last byte
> > 0x80 means type. Then there is no length byte, which make the
> > SEI nonstandard.
> >
> Wrong:
> 06: forbidden_zero_bit + nal_ref_idc + nal_unit_type (6 for SEI)
> 05: payload type 5 (user data unregistered) SEI message
> 10: length of this SEI message is 16
> b9-29: the payload of this SEI message (the first 12 byte are an uuid,
> the last are user_data_payload_byte)
> 80: rbsp_trailing_bits: the first bit is rbsp_stop_one_bit (equal to
> one), the remaining bits are padding (with value zero)
>
> You can use trace_headers to inspect this.
>
> (Notice that one needs to know the length of the NAL unit in advance
> before one can start parsing it; how one gets it depends upon the
> framing. There are two common methods for this: Annex B and mp4. The
> former works by using start codes 0x00 00 01 to mark the beginning of a
> new NAL, the latter prefixes the length of the NAL units to the units.)
>
> > On macOS 11, the encoded h264 sample still contains fixed SEI before
> > IDR frame, which length is 5 bytes longer than before.
> >
> > 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> > 14 bb 29 80 00 00 03 00 01
> > ^^ ^^ ^^ ^^ ^^
>
> That looks as if there were a 00 00 00 01 startcode after the SEI that
> some tool has tried to 0x03 escape. That is a bug. Can you share samples
> containing these NAL units?
>
This file is inserting the emulation prevention byte 0x03. I can take a
look later today.
> >
> > This time type the content of the SEI has type 0 payload but
> > invalid length payload data, which violates recommendation
> > appendix D.
> >
> > Whether it is a bug or not, these SEI nalus should be erased to keep
> > the output bytestream not violating the standard. But we may
> > not come across the situration we do need these encoded SEI
> > nalu, so we just reserve a switch and set not to output by default.
> >
> > Signed-off-by: sharpbai
> > ---
> > libavcodec/videotoolboxenc.c | 51 +---
> > 1 file changed, 30 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index cc08cf6a50..c240090f10 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -221,6 +221,7 @@ typedef struct VTEncContext {
> >
> > int64_t allow_sw;
> > int64_t require_sw;
> > +int64_t ignore_internal_sei;
> >
> > bool flushing;
> > bool has_b_frames;
> > @@ -1690,7 +1691,8 @@ static int copy_replace_length_codes(
> > CMSampleBufferRef sample_buffer,
> > ExtraSEI *sei,
> > uint8_t *dst_data,
> > -size_tdst_size)
> > +size_tdst_size,
> > +int ignore_internal_sei)
> > {
> > size_t src_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
> > size_t remaining_src_size = src_size;
> > @@ -1707,8 +1709,8 @@ static int copy_replace_length_codes(
> > }
> >
> > while (remaining_src_size > 0) {
> > -size_t curr_src_len;
> > -size_t curr_dst_len;
> > +size_t curr_src_len = 0;
> > +size_t curr_dst_len = 0;
> > size_t box_len = 0;
> > size_t i;
> >
> > @@ -1740,7 +1742,8 @@ static int copy_replace_length_codes(
> > box_len |= size_buf[i];
> > }
> >
> > -if (sei && !wrote_sei && is_post_sei_nal_type(nal_type)) {
> > +if (sei && !wrote_sei &&
> > +(ignore_internal_sei ||
> is_post_sei_nal_type(nal_type))) {
> > //No SEI NAL unit - insert.
> > int wrote_bytes;
> >
> > @@ -1775,27 +1778,30 @@ static int copy_replace_length_codes(
> > }
> >
> > curr_src_len = box_len + length_code_size;
> > -curr_dst_len = box_len + sizeof(start_code);
> >
> > -if (remaining_src_size < curr_src_len) {
> > -return AVERROR_BUFFER_TOO_SMALL;
> > -}
> > +if (!(ignore_internal_sei && nal_type == H264_NAL_SEI)) {
> > +curr_dst_len = box_len + sizeof(start_code);
> >
> > -if (remaining_dst_size < curr_dst_len) {
> > -return AVERROR_BUFFER_TOO_SMALL;
> > -}
> > +if (remaining_src_size < curr_src_len) {
> > +return AVERROR_BUFFER_TOO_SMALL;
> > +}
> > +
> > +if (remaining_dst_size < curr_dst_len) {
> > +return AVERROR_BUFFER_TOO_SMALL;
> > +}
> >
> > -dst_box = dst_data + sizeof(start_code);
> > +dst_box = dst_data + sizeof(start_code);
> >
> > -memcpy(dst_data,
Re: [FFmpeg-devel] [PATCH] avformat/utils: Add av_assert1 to preclude NULL + len, len != 0
On 2/14/2021 8:20 PM, Andreas Rheinhardt wrote: Such a scenario is undefined behaviour and would also indicate a bug in our code. Suggested-by: James Almer Signed-off-by: Andreas Rheinhardt --- libavformat/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/utils.c b/libavformat/utils.c index cea6d4ca92..652758e98e 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -1426,6 +1426,7 @@ static int parse_packet(AVFormatContext *s, AVPacket *pkt, pkt->pts = pkt->dts = AV_NOPTS_VALUE; pkt->pos = -1; /* increment read pointer */ +av_assert1(data || !len); data = len ? data + len : data; size -= len; LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avformat/mpegenc: Forward error code
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 14b904b152..d37f181eaa 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -1151,7 +1151,7 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
StreamInfo *stream = st->priv_data;
int64_t pts, dts;
PacketDesc *pkt_desc;
-int preload;
+int preload, ret;
const int is_iframe = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
(pkt->flags & AV_PKT_FLAG_KEY);
@@ -1207,8 +1207,9 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
pkt_desc->unwritten_size =
pkt_desc->size = size;
-if (av_fifo_realloc2(stream->fifo, av_fifo_size(stream->fifo) + size) < 0)
-return -1;
+ret = av_fifo_realloc2(stream->fifo, av_fifo_size(stream->fifo) + size);
+if (ret < 0)
+return ret;
if (s->is_dvd) {
// min VOBU length 0.4 seconds (mpucoder)
--
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/4] avformat/mpegenc: Avoid adding invalid packet to queue
Do this by moving the check before the allocation.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 1204e57f04..14b904b152 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -1179,18 +1179,6 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
av_log(ctx, AV_LOG_TRACE, "dts:%f pts:%f flags:%d stream:%d nopts:%d\n",
dts / 9.0, pts / 9.0, pkt->flags,
pkt->stream_index, pts != AV_NOPTS_VALUE);
-pkt_desc = av_mallocz(sizeof(PacketDesc));
-if (!pkt_desc)
-return AVERROR(ENOMEM);
-if (!stream->predecode_packet) {
-stream->predecode_packet = pkt_desc;
-} else
-stream->last_packet->next = pkt_desc;
-stream->last_packet = pkt_desc;
-if (!stream->premux_packet)
-stream->premux_packet = pkt_desc;
-pkt_desc->pts= pts;
-pkt_desc->dts= dts;
if (st->codecpar->codec_id == AV_CODEC_ID_PCM_DVD) {
if (size < 3) {
@@ -1204,6 +1192,18 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
size -= 3;
}
+pkt_desc = av_mallocz(sizeof(PacketDesc));
+if (!pkt_desc)
+return AVERROR(ENOMEM);
+if (!stream->predecode_packet) {
+stream->predecode_packet = pkt_desc;
+} else
+stream->last_packet->next = pkt_desc;
+stream->last_packet = pkt_desc;
+if (!stream->premux_packet)
+stream->premux_packet = pkt_desc;
+pkt_desc->pts= pts;
+pkt_desc->dts= dts;
pkt_desc->unwritten_size =
pkt_desc->size = size;
--
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/4] avformat/mpegenc: Fix leak in case trailer is never written
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 810dd717ca..1204e57f04 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -1262,6 +1262,11 @@ static void mpeg_mux_deinit(AVFormatContext *ctx)
StreamInfo *stream = ctx->streams[i]->priv_data;
if (!stream)
continue;
+for (PacketDesc *pkt = stream->predecode_packet; pkt; ) {
+PacketDesc *tmp = pkt->next;
+av_free(pkt);
+pkt = tmp;
+}
av_fifo_freep(>fifo);
}
}
--
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 1/4] avformat/mpegenc: Ensure packet queue stays valid
The MPEG-PS muxer uses a custom queue of custom packets. To keep track
of it, it has a pointer (named predecode_packet) to the head of the
queue and a pointer to where the next packet is to be added (it points
to the next-pointer of the last element of the queue); furthermore,
there is also a pointer that points into the queue (called premux_packet).
The exact behaviour was as follows: If premux_packet was NULL when a
packet is received, it is taken to mean that the old queue is empty and
a new queue is started. premux_packet will point to the head of said
queue and the next_packet-pointer points to its next pointer. If
predecode_packet is NULL, it will also made to point to the newly
allocated element.
But if premux_packet is NULL and predecode_packet is not, then there
will be two queues with head elements premux_packet and
predecode_packet. Yet only elements reachable from predecode_packet are
ever freed, so the premux_packet queue leaks.
Worse yet, when the predecode_packet queue will be eventually exhausted,
predecode_packet will be made to point into the other queue and when
predecode_packet will be freed, the next pointer of the preceding
element of the queue will still point to the element just freed. This
element might very well be still reachable from premux_packet which
leads to use-after-frees lateron. This happened in the tickets mentioned
below.
Fix this by never creating two queues in the first place by checking for
predecode_packet to know whether the queue is empty. If premux_packet is
NULL, then it is set to the newly allocated element of the queue.
Fixes tickets #6887, #8188 and #8266.
Signed-off-by: Andreas Rheinhardt
---
Disclaimer: I don't know MPEG program streams very well; it might very
well be that the mere fact that premux_packet can be NULL while
predecode_packet isn't is indicative of a deeper bug. All I know is that
this patch only changes behaviour in case the old behaviour was broken
(i.e. led to leaks or use-after-frees).
libavformat/mpegenc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 9bd0a555d4..810dd717ca 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -48,9 +48,9 @@ typedef struct StreamInfo {
uint8_t id;
int max_buffer_size; /* in bytes */
int buffer_index;
-PacketDesc *predecode_packet;
+PacketDesc *predecode_packet; /* start of packet queue */
+PacketDesc *last_packet; /* end of packet queue */
PacketDesc *premux_packet;
-PacketDesc **next_packet;
int packet_number;
uint8_t lpcm_header[3];
int lpcm_align;
@@ -986,6 +986,8 @@ static int remove_decoded_packets(AVFormatContext *ctx,
int64_t scr)
}
stream->buffer_index-= pkt_desc->size;
stream->predecode_packet = pkt_desc->next;
+if (!stream->predecode_packet)
+stream->last_packet = NULL;
av_freep(_desc);
}
}
@@ -1177,12 +1179,16 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
av_log(ctx, AV_LOG_TRACE, "dts:%f pts:%f flags:%d stream:%d nopts:%d\n",
dts / 9.0, pts / 9.0, pkt->flags,
pkt->stream_index, pts != AV_NOPTS_VALUE);
-if (!stream->premux_packet)
-stream->next_packet = >premux_packet;
-*stream->next_packet =
pkt_desc = av_mallocz(sizeof(PacketDesc));
if (!pkt_desc)
return AVERROR(ENOMEM);
+if (!stream->predecode_packet) {
+stream->predecode_packet = pkt_desc;
+} else
+stream->last_packet->next = pkt_desc;
+stream->last_packet = pkt_desc;
+if (!stream->premux_packet)
+stream->premux_packet = pkt_desc;
pkt_desc->pts= pts;
pkt_desc->dts= dts;
@@ -1200,9 +1206,6 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
AVPacket *pkt)
pkt_desc->unwritten_size =
pkt_desc->size = size;
-if (!stream->predecode_packet)
-stream->predecode_packet = pkt_desc;
-stream->next_packet = _desc->next;
if (av_fifo_realloc2(stream->fifo, av_fifo_size(stream->fifo) + size) < 0)
return -1;
--
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".
Re: [FFmpeg-devel] [PATCH 3/8] avcodec/frame_thread_encoder: Avoid allocations of AVPackets, fix deadlock
Andreas Rheinhardt:
> Up until now, when doing frame thread encoding, each worker thread
> tried to allocate an AVPacket for every AVFrame to be encoded; said
> packets would then be handed back to the main thread, where the content
> of said packet is copied into the packet actually destined for output;
> the temporary AVPacket is then freed.
>
> Besides being wasteful this also has another problem: There is a risk of
> deadlock, namely if no AVPacket can be allocated at all. The user
> doesn't get an error at all in this case and the worker threads will
> simply try to allocate a packet again and again. If the user has
> supplied enough frames, the user's thread will block until a task has
> been completed, which just doesn't happen if no packet can ever be
> allocated.
>
> This patch instead modifies the code to allocate the packets during
> init; they are then reused again and again.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/frame_thread_encoder.c | 61 +++
> 1 file changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/libavcodec/frame_thread_encoder.c
> b/libavcodec/frame_thread_encoder.c
> index 9ca34e7ffb..bcd3c94f8b 100644
> --- a/libavcodec/frame_thread_encoder.c
> +++ b/libavcodec/frame_thread_encoder.c
> @@ -32,13 +32,18 @@
> #include "thread.h"
>
> #define MAX_THREADS 64
> -#define BUFFER_SIZE (2*MAX_THREADS)
> +/* There can be as many as MAX_THREADS + 1 outstanding tasks.
> + * An additional + 1 is needed so that one can distinguish
> + * the case of zero and MAX_THREADS + 1 outstanding tasks modulo
> + * the number of buffers. */
> +#define BUFFER_SIZE (MAX_THREADS + 2)
>
> typedef struct{
> AVFrame *indata;
> AVPacket *outdata;
> int64_t return_code;
> unsigned index;
> +int finished;
> } Task;
>
> typedef struct{
> @@ -49,8 +54,9 @@ typedef struct{
> pthread_mutex_t task_fifo_mutex;
> pthread_cond_t task_fifo_cond;
>
> -Task finished_tasks[BUFFER_SIZE];
> -pthread_mutex_t finished_task_mutex;
> +unsigned max_tasks;
> +Task tasks[BUFFER_SIZE];
> +pthread_mutex_t finished_task_mutex; /* Guards tasks[i].finished */
> pthread_cond_t finished_task_cond;
>
> unsigned task_index;
> @@ -63,17 +69,13 @@ typedef struct{
> static void * attribute_align_arg worker(void *v){
> AVCodecContext *avctx = v;
> ThreadContext *c = avctx->internal->frame_thread_encoder;
> -AVPacket *pkt = NULL;
>
> while (!atomic_load(>exit)) {
> int got_packet = 0, ret;
> +AVPacket *pkt;
> AVFrame *frame;
> Task task;
>
> -if(!pkt) pkt = av_packet_alloc();
> -if(!pkt) continue;
> -av_init_packet(pkt);
> -
> pthread_mutex_lock(>task_fifo_mutex);
> while (av_fifo_size(c->task_fifo) <= 0 || atomic_load(>exit)) {
> if (atomic_load(>exit)) {
> @@ -84,7 +86,12 @@ static void * attribute_align_arg worker(void *v){
> }
> av_fifo_generic_read(c->task_fifo, , sizeof(task), NULL);
> pthread_mutex_unlock(>task_fifo_mutex);
> +/* The main thread ensures that any two outstanding tasks have
> + * different indices, ergo each worker thread owns its element
> + * of c->tasks with the exception of finished, which is shared
> + * with the main thread and guarded by finished_task_mutex. */
> frame = task.indata;
> +pkt = c->tasks[task.index].outdata;
>
> ret = avctx->codec->encode2(avctx, pkt, frame, _packet);
> if(got_packet) {
> @@ -101,13 +108,12 @@ static void * attribute_align_arg worker(void *v){
> pthread_mutex_unlock(>buffer_mutex);
> av_frame_free();
> pthread_mutex_lock(>finished_task_mutex);
> -c->finished_tasks[task.index].outdata = pkt; pkt = NULL;
> -c->finished_tasks[task.index].return_code = ret;
> +c->tasks[task.index].return_code = ret;
> +c->tasks[task.index].finished= 1;
> pthread_cond_signal(>finished_task_cond);
> pthread_mutex_unlock(>finished_task_mutex);
> }
> end:
> -av_free(pkt);
> pthread_mutex_lock(>buffer_mutex);
> avcodec_close(avctx);
> pthread_mutex_unlock(>buffer_mutex);
> @@ -194,6 +200,12 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx,
> AVDictionary *options){
> pthread_cond_init(>finished_task_cond, NULL);
> atomic_init(>exit, 0);
>
> +c->max_tasks = avctx->thread_count + 2;
> +for (unsigned i = 0; i < c->max_tasks; i++) {
> +if (!(c->tasks[i].outdata = av_packet_alloc()))
> +goto fail;
> +}
> +
> for(i=0; ithread_count ; i++){
> AVDictionary *tmp = NULL;
> int ret;
> @@ -261,8 +273,8 @@ void ff_frame_thread_encoder_free(AVCodecContext *avctx){
> av_frame_free();
> }
>
> -for (i=0; i -av_packet_free(>finished_tasks[i].outdata);
> +for (unsigned i =
Re: [FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: ignore encoded h264 SEI nalu by default
sharpbai:
> Before macOS 11, the encoded h264 sample contains fixed SEI before
> IDR frame, which the content is below
>
> 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> 14 bb 29 80
>
> The length of the encoded SEI nalu is 20 byte. According to
> the ITU-T H.264 Recommendation section 7.3.2.3.1, the last byte
> 0x80 means type. Then there is no length byte, which make the
> SEI nonstandard.
>
Wrong:
06: forbidden_zero_bit + nal_ref_idc + nal_unit_type (6 for SEI)
05: payload type 5 (user data unregistered) SEI message
10: length of this SEI message is 16
b9-29: the payload of this SEI message (the first 12 byte are an uuid,
the last are user_data_payload_byte)
80: rbsp_trailing_bits: the first bit is rbsp_stop_one_bit (equal to
one), the remaining bits are padding (with value zero)
You can use trace_headers to inspect this.
(Notice that one needs to know the length of the NAL unit in advance
before one can start parsing it; how one gets it depends upon the
framing. There are two common methods for this: Annex B and mp4. The
former works by using start codes 0x00 00 01 to mark the beginning of a
new NAL, the latter prefixes the length of the NAL units to the units.)
> On macOS 11, the encoded h264 sample still contains fixed SEI before
> IDR frame, which length is 5 bytes longer than before.
>
> 06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
> 14 bb 29 80 00 00 03 00 01
> ^^ ^^ ^^ ^^ ^^
That looks as if there were a 00 00 00 01 startcode after the SEI that
some tool has tried to 0x03 escape. That is a bug. Can you share samples
containing these NAL units?
>
> This time type the content of the SEI has type 0 payload but
> invalid length payload data, which violates recommendation
> appendix D.
>
> Whether it is a bug or not, these SEI nalus should be erased to keep
> the output bytestream not violating the standard. But we may
> not come across the situration we do need these encoded SEI
> nalu, so we just reserve a switch and set not to output by default.
>
> Signed-off-by: sharpbai
> ---
> libavcodec/videotoolboxenc.c | 51 +---
> 1 file changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index cc08cf6a50..c240090f10 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -221,6 +221,7 @@ typedef struct VTEncContext {
>
> int64_t allow_sw;
> int64_t require_sw;
> +int64_t ignore_internal_sei;
>
> bool flushing;
> bool has_b_frames;
> @@ -1690,7 +1691,8 @@ static int copy_replace_length_codes(
> CMSampleBufferRef sample_buffer,
> ExtraSEI *sei,
> uint8_t *dst_data,
> -size_tdst_size)
> +size_tdst_size,
> +int ignore_internal_sei)
> {
> size_t src_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
> size_t remaining_src_size = src_size;
> @@ -1707,8 +1709,8 @@ static int copy_replace_length_codes(
> }
>
> while (remaining_src_size > 0) {
> -size_t curr_src_len;
> -size_t curr_dst_len;
> +size_t curr_src_len = 0;
> +size_t curr_dst_len = 0;
> size_t box_len = 0;
> size_t i;
>
> @@ -1740,7 +1742,8 @@ static int copy_replace_length_codes(
> box_len |= size_buf[i];
> }
>
> -if (sei && !wrote_sei && is_post_sei_nal_type(nal_type)) {
> +if (sei && !wrote_sei &&
> +(ignore_internal_sei || is_post_sei_nal_type(nal_type))) {
> //No SEI NAL unit - insert.
> int wrote_bytes;
>
> @@ -1775,27 +1778,30 @@ static int copy_replace_length_codes(
> }
>
> curr_src_len = box_len + length_code_size;
> -curr_dst_len = box_len + sizeof(start_code);
>
> -if (remaining_src_size < curr_src_len) {
> -return AVERROR_BUFFER_TOO_SMALL;
> -}
> +if (!(ignore_internal_sei && nal_type == H264_NAL_SEI)) {
> +curr_dst_len = box_len + sizeof(start_code);
>
> -if (remaining_dst_size < curr_dst_len) {
> -return AVERROR_BUFFER_TOO_SMALL;
> -}
> +if (remaining_src_size < curr_src_len) {
> +return AVERROR_BUFFER_TOO_SMALL;
> +}
> +
> +if (remaining_dst_size < curr_dst_len) {
> +return AVERROR_BUFFER_TOO_SMALL;
> +}
>
> -dst_box = dst_data + sizeof(start_code);
> +dst_box = dst_data + sizeof(start_code);
>
> -memcpy(dst_data, start_code, sizeof(start_code));
> -status = CMBlockBufferCopyDataBytes(block,
> -src_offset + length_code_size,
> -box_len,
> -dst_box);
> +memcpy(dst_data, start_code, sizeof(start_code));
> +status = CMBlockBufferCopyDataBytes(block,
>
Re: [FFmpeg-devel] [PATCH v5 01/10] cbs_h2645: refact, use cbs_h2645_replace_ps to replace cbs_h26*_replace_*ps
Nuo Mi:
> On Mon, Feb 15, 2021 at 3:45 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Nuo Mi:
>>> From: Mark Thompson
>>>
>>>
>>> -}
>>> +static int cbs_h2645_replace_ps(CodedBitstreamContext *ctx,
>>> +CodedBitstreamUnit *unit)
>>> +{
>>> +typedef struct {
>>> +int nal_unit_type;
>>> +int max_count;
>>> +const char *name;
>>
>> If this were a char name[4], these structs could be put in .rodata
>> instead of .data (or .data.rel.ro) when using position-independent code.
>>
> thanks for the suggestion.
> What's the benifite for this?
> thanks
>
When one uses position-independent code, the static linker does not know
the runtime address of the strings here, because their position is not
known until runtime. Therefore the static linker has to create
relocations for them which means that it tells the runtime linker that
it should patch up the char * pointer above to point to the real
(offsetted) address of the relevant string. For platforms other than
Windows, these relocations are expensive (see [1]) and the resultant
pages are dirty and can't be shared between processes; furthermore this
process isn't done in a lazy manner, so that even someone who never uses
cbs_h2645 (or cbs at all) will have the dirty pages from the above as
soon as libavcodec is loaded.
- Andreas
[1]:
https://chromium.googlesource.com/chromium/src/+/master/docs/native_relocations.md
___
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/videotoolboxenc: ignore encoded h264 SEI nalu by default
Before macOS 11, the encoded h264 sample contains fixed SEI before
IDR frame, which the content is below
06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
14 bb 29 80
The length of the encoded SEI nalu is 20 byte. According to
the ITU-T H.264 Recommendation section 7.3.2.3.1, the last byte
0x80 means type. Then there is no length byte, which make the
SEI nonstandard.
On macOS 11, the encoded h264 sample still contains fixed SEI before
IDR frame, which length is 5 bytes longer than before.
06 05 10 b9 ed b9 30 5d 21 4b 71 83 71 2c 10 a3
14 bb 29 80 00 00 03 00 01
^^ ^^ ^^ ^^ ^^
This time type the content of the SEI has type 0 payload but
invalid length payload data, which violates recommendation
appendix D.
Whether it is a bug or not, these SEI nalus should be erased to keep
the output bytestream not violating the standard. But we may
not come across the situration we do need these encoded SEI
nalu, so we just reserve a switch and set not to output by default.
Signed-off-by: sharpbai
---
libavcodec/videotoolboxenc.c | 51 +---
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index cc08cf6a50..c240090f10 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -221,6 +221,7 @@ typedef struct VTEncContext {
int64_t allow_sw;
int64_t require_sw;
+int64_t ignore_internal_sei;
bool flushing;
bool has_b_frames;
@@ -1690,7 +1691,8 @@ static int copy_replace_length_codes(
CMSampleBufferRef sample_buffer,
ExtraSEI *sei,
uint8_t *dst_data,
-size_tdst_size)
+size_tdst_size,
+int ignore_internal_sei)
{
size_t src_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
size_t remaining_src_size = src_size;
@@ -1707,8 +1709,8 @@ static int copy_replace_length_codes(
}
while (remaining_src_size > 0) {
-size_t curr_src_len;
-size_t curr_dst_len;
+size_t curr_src_len = 0;
+size_t curr_dst_len = 0;
size_t box_len = 0;
size_t i;
@@ -1740,7 +1742,8 @@ static int copy_replace_length_codes(
box_len |= size_buf[i];
}
-if (sei && !wrote_sei && is_post_sei_nal_type(nal_type)) {
+if (sei && !wrote_sei &&
+(ignore_internal_sei || is_post_sei_nal_type(nal_type))) {
//No SEI NAL unit - insert.
int wrote_bytes;
@@ -1775,27 +1778,30 @@ static int copy_replace_length_codes(
}
curr_src_len = box_len + length_code_size;
-curr_dst_len = box_len + sizeof(start_code);
-if (remaining_src_size < curr_src_len) {
-return AVERROR_BUFFER_TOO_SMALL;
-}
+if (!(ignore_internal_sei && nal_type == H264_NAL_SEI)) {
+curr_dst_len = box_len + sizeof(start_code);
-if (remaining_dst_size < curr_dst_len) {
-return AVERROR_BUFFER_TOO_SMALL;
-}
+if (remaining_src_size < curr_src_len) {
+return AVERROR_BUFFER_TOO_SMALL;
+}
+
+if (remaining_dst_size < curr_dst_len) {
+return AVERROR_BUFFER_TOO_SMALL;
+}
-dst_box = dst_data + sizeof(start_code);
+dst_box = dst_data + sizeof(start_code);
-memcpy(dst_data, start_code, sizeof(start_code));
-status = CMBlockBufferCopyDataBytes(block,
-src_offset + length_code_size,
-box_len,
-dst_box);
+memcpy(dst_data, start_code, sizeof(start_code));
+status = CMBlockBufferCopyDataBytes(block,
+src_offset + length_code_size,
+box_len,
+dst_box);
-if (status) {
-av_log(avctx, AV_LOG_ERROR, "Cannot copy data: %d\n", status);
-return AVERROR_EXTERNAL;
+if (status) {
+av_log(avctx, AV_LOG_ERROR, "Cannot copy data: %d\n", status);
+return AVERROR_EXTERNAL;
+}
}
if (sei && !wrote_sei && nal_type == H264_NAL_SEI) {
@@ -1931,7 +1937,8 @@ static int vtenc_cm_to_avpacket(
sample_buffer,
sei,
pkt->data + header_size,
-pkt->size - header_size
+pkt->size - header_size,
+vtctx->ignore_internal_sei
);
if (status) {
@@ -2543,6 +2550,8 @@ static const enum AVPixelFormat hevc_pix_fmts[] = {
{ .i64 = 0 }, 0, 1, VE }, \
{ "require_sw", "Require software encoding", OFFSET(require_sw),
AV_OPT_TYPE_BOOL, \
{ .i64 = 0 }, 0, 1, VE }, \
+{ "ignore_internal_sei", "Ignore SEI nalu generated by videotoolbox",
OFFSET(ignore_internal_sei),
