Re: [FFmpeg-devel] [PATCH] avfilter: add chromanr video filter
On 7/4/20, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 19 > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_chromanr.c | 211 ++ > 4 files changed, 232 insertions(+) > create mode 100644 libavfilter/vf_chromanr.c > Will apply soon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5] avdevice/xcbgrab: Add select_region option
This patch adds a select_region option to the xcbgrab input device.
If set to 1, the user will be prompted to select the grabbing area
graphically by clicking and dragging. A rectangle will be drawn to
mark the grabbing area. A single click with no dragging will select
the whole screen. The option overwrites the video_size, grab_x, and
grab_y options if set by the user.
For testing, just set the select_region option as follows:
ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
The drawing happens directly on the root window using standard rubber
banding techniques, so it is very efficient and doesn't depend on any
X extensions or compositors.
Signed-off-by: Omar Emara
---
doc/indevs.texi | 7 +++
libavdevice/xcbgrab.c | 126 ++
2 files changed, 133 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf344..b5df111801 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1478,6 +1478,13 @@ ffmpeg -f x11grab -framerate 25 -video_size cif -i
:0.0+10,20 out.mpg
@subsection Options
@table @option
+@item select_region
+Specify whether to select the grabbing area graphically using the pointer.
+A value of @code{1} prompts the user to select the grabbing area graphically
+by clicking and dragging. A single click with no dragging will select the
+whole screen. This option overwrites the @var{video_size}, @var{grab_x},
+and @var{grab_y} options. Default value is @code{0}.
+
@item draw_mouse
Specify whether to draw the mouse pointer. A value of @code{0} specifies
not to draw the pointer. Default value is @code{1}.
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 6f6b2dbf15..04f888c142 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -22,6 +22,7 @@
#include "config.h"
#include
+#include
#include
#if CONFIG_LIBXCB_XFIXES
@@ -69,6 +70,7 @@ typedef struct XCBGrabContext {
int show_region;
int region_border;
int centered;
+int select_region;
const char *framerate;
@@ -92,6 +94,7 @@ static const AVOption options[] = {
{ "centered", "Keep the mouse pointer at the center of grabbing region
when following.", 0, AV_OPT_TYPE_CONST, { .i64 = -1 }, INT_MIN, INT_MAX, D,
"follow_mouse" },
{ "show_region", "Show the grabbing region.", OFFSET(show_region),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
{ "region_border", "Set the region border thickness.",
OFFSET(region_border), AV_OPT_TYPE_INT, { .i64 = 3 }, 1, 128, D },
+{ "select_region", "Select the grabbing region graphically using the
pointer.", OFFSET(select_region), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
{ NULL },
};
@@ -668,6 +671,121 @@ static void setup_window(AVFormatContext *s)
draw_rectangle(s);
}
+#define CROSSHAIR_CURSOR 34
+
+static xcb_rectangle_t rectangle_from_corners(xcb_point_t *corner_a,
+ xcb_point_t *corner_b)
+{
+xcb_rectangle_t rectangle;
+rectangle.x = FFMIN(corner_a->x, corner_b->x);
+rectangle.y = FFMIN(corner_a->y, corner_b->y);
+rectangle.width = FFABS(corner_a->x - corner_b->x);
+rectangle.height = FFABS(corner_a->y - corner_b->y);
+return rectangle;
+}
+
+static int select_region(AVFormatContext *s)
+{
+XCBGrabContext *c = s->priv_data;
+xcb_connection_t *conn = c->conn;
+xcb_screen_t *screen = c->screen;
+
+int ret = 0;
+int done = 0;
+int was_pressed = 0;
+xcb_cursor_t cursor;
+xcb_font_t cursor_font;
+xcb_point_t press_position;
+xcb_generic_event_t *event;
+xcb_rectangle_t rectangle = {0};
+xcb_grab_pointer_reply_t *reply;
+xcb_grab_pointer_cookie_t cookie;
+
+xcb_window_t root_window = screen->root;
+xcb_gcontext_t gc = xcb_generate_id(conn);
+uint32_t mask = XCB_GC_FUNCTION | XCB_GC_SUBWINDOW_MODE;
+uint32_t values[] = {XCB_GX_INVERT,
+ XCB_SUBWINDOW_MODE_INCLUDE_INFERIORS};
+xcb_create_gc(conn, gc, root_window, mask, values);
+
+cursor_font = xcb_generate_id(conn);
+xcb_open_font(conn, cursor_font, strlen("cursor"), "cursor");
+cursor = xcb_generate_id(conn);
+xcb_create_glyph_cursor(conn, cursor, cursor_font, cursor_font,
+CROSSHAIR_CURSOR, CROSSHAIR_CURSOR + 1, 0, 0, 0,
+0x, 0x, 0x);
+cookie = xcb_grab_pointer(conn, 0, root_window,
+ XCB_EVENT_MASK_BUTTON_PRESS |
+ XCB_EVENT_MASK_BUTTON_RELEASE |
+ XCB_EVENT_MASK_BUTTON_MOTION,
+ XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC,
+ root_window, cursor, XCB_CURRENT_TIME);
+reply = xcb_grab_pointer_reply(conn, cookie, NULL);
+if (!reply || reply->status != XCB_GRAB_STATUS_SUCCESS) {
+av_log(s, AV_LOG_ERROR,
+ "Failed to select region. Could not grab pointer.\n");
+ret = AVERROR(E
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: add support for animated WebP decoding
On Wed, Jul 8, 2020 at 11:57 AM Lynne wrote:
> Jul 8, 2020, 06:28 by jo...@pex.com:
>
> > Fixes: 4907
> >
> > Adds support for decoding of animated WebP.
> >
> > The WebP parser now splits the input stream into packets containing one
> frame.
> >
> > The WebP decoder adds the animation related features according to the
> specs:
> > https://developers.google.com/speed/webp/docs/riff_container#animation
> > The frames of the animation may be smaller than the image canvas.
> > Therefore, the frame is decoded to a temporary frame,
> > then it is blended into the canvas, the canvas is copied to the output
> frame,
> > and finally the frame is disposed from the canvas.
> >
> > The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
> > The background color is specified only as BGRA in the WebP file
> > so it is converted to YUVA if YUV formats are output.
> >
>
> We don't convert pixel formats in decoders, and I wouldn't want to have
> libavcodec
> depend on libswscale. I wouldn't trust libswscale to make accurate
> conversions either.
>
> Can you use the macros in libavutil/colorspace.h to convert the BGRA value
> to YUVA
> and then just memcpy it across the frame?
>
Thank you for the tip!
I could not find out how to do it better than I did.
Also, there are a lot of frame memcpys in the code. Could you get rid of
> most of them
> by refcounting?
>
The memcpy is needed. The frames of the WebP animation do not cover the
whole canvas of the picture,
i.e. the decoded VP8 frame is just a sub-rectangle of the canvas. The frame
changes just a part of the canvas.
The frame needs to be copied to the proper position in the canvas, or
merged into the canvas using alpha blending.
The canvas is then copied to the output frame, and we need to keep it
because it will be partially overwritten by subsequent frames.
> -.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,> +
> .capabilities = AV_CODEC_CAP_DR1,
> Why?
>
As described before, the subsequent frame depends on the previous ones.
With threading enabled, only some frames are decoded and many errors are
printed.
I will experiment with marking partial frames as not key frames, maybe it
will fix the problems with threading.
> +if (component == 1 || component == 2) {> +
> height = AV_CEIL_RSHIFT(height, desc->log2_chroma_h);> +}
> We don't wrap 1-line if statements in brackets.
>
I will fix such occurrences in my code.
Thank you!
Josef
___
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/riffenc: indicate storage of flipped RGB bitmaps
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading of these files.
Option flipped_raw_rgb added to AVI and Matroska muxers
which will write positive value for height when enabled.
Note that the user has to flip the bitmaps beforehand using other
means such as the vflip filter.
---
doc/muxers.texi | 13 +
libavformat/asfenc.c | 2 +-
libavformat/avienc.c | 4 +++-
libavformat/matroskaenc.c | 5 -
libavformat/riff.h| 2 +-
libavformat/riffenc.c | 7 ---
libavformat/wtvenc.c | 2 +-
7 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index b1389a3227..2f26494bfa 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -89,6 +89,12 @@ specific scenarios, e.g. when merging multiple audio streams
into one for
compatibility with software that only supports a single audio stream in AVI
(see @ref{amerge,,the "amerge" section in the ffmpeg-filters
manual,ffmpeg-filters}).
+@item flipped_raw_rgb
+If set to true, store positive height for raw RGB bitmaps, which indicates
+bitmap is stored bottom-up. Note that this option does not flip the bitmap
+which has to be done manually beforehand, e.g. by using the vflip filter.
+Default is @var{false} and indicates bitmap is stored top down.
+
@end table
@anchor{chromaprint}
@@ -1409,6 +1415,13 @@ disposition default exists, no subtitle track will be
marked as default.
In this mode the FlagDefault is set if and only if the AV_DISPOSITION_DEFAULT
flag is set in the disposition of the corresponding stream.
@end table
+
+@item flipped_raw_rgb
+If set to true, store positive height for raw RGB bitmaps, which indicates
+bitmap is stored bottom-up. Note that this option does not flip the bitmap
+which has to be done manually beforehand, e.g. by using the vflip filter.
+Default is @var{false} and indicates bitmap is stored top down.
+
@end table
@anchor{md5}
diff --git a/libavformat/asfenc.c b/libavformat/asfenc.c
index 73afb13200..8b24264c94 100644
--- a/libavformat/asfenc.c
+++ b/libavformat/asfenc.c
@@ -682,7 +682,7 @@ static int asf_write_header1(AVFormatContext *s, int64_t
file_size,
avio_wl16(pb, 40 + par->extradata_size); /* size */
/* BITMAPINFOHEADER header */
-ff_put_bmp_header(pb, par, 1, 0);
+ff_put_bmp_header(pb, par, 1, 0, 0);
}
end_header(pb, hpos);
}
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 297d5b8964..1b2cb529b9 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -72,6 +72,7 @@ typedef struct AVIContext {
int reserve_index_space;
int master_index_max_size;
int write_channel_mask;
+int flipped_raw_rgb;
} AVIContext;
typedef struct AVIStream {
@@ -449,7 +450,7 @@ static int avi_write_header(AVFormatContext *s)
&& par->bits_per_coded_sample == 15)
par->bits_per_coded_sample = 16;
avist->pal_offset = avio_tell(pb) + 40;
-ff_put_bmp_header(pb, par, 0, 0);
+ff_put_bmp_header(pb, par, 0, 0, avi->flipped_raw_rgb);
pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
par->bits_per_coded_sample);
if ( !par->codec_tag
@@ -993,6 +994,7 @@ static void avi_deinit(AVFormatContext *s)
static const AVOption options[] = {
{ "reserve_index_space", "reserve space (in bytes) at the beginning of the
file for each stream index", OFFSET(reserve_index_space), AV_OPT_TYPE_INT, {
.i64 = 0 }, 0, INT_MAX, ENC },
{ "write_channel_mask", "write channel mask into wave format header",
OFFSET(write_channel_mask), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, ENC },
+{ "flipped_raw_rgb", "Raw RGB bitmaps are stored bottom-up",
OFFSET(flipped_raw_rgb), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
{ NULL },
};
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 105ed5197e..233c472b8f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -154,6 +154,7 @@ typedef struct MatroskaMuxContext {
int is_dash;
int dash_track_number;
int allow_raw_vfw;
+int flipped_raw_rgb;
int default_mode;
uint32_tsegment_uid[4];
@@ -764,6 +765,7 @@ static int mkv_write_codecprivate(AVFormatContext *s,
AVIOContext *pb,
int native_id, int qt_id)
{
AVIOContext *dyn_cp;
+MatroskaMuxContext *mkv = s->priv_data;
uint8_t *codecpriv;
int ret, codecpriv_size;
@@ -802,7 +804,7 @@ static int mkv_write_codecprivate(AVFormatContext *s,
AVIOContext *pb,
ret = AVERROR(EINVAL);
[FFmpeg-devel] [PATCH v6 2/7] avformat/apm: use the entire APMState structure as extradata
Is the "actual" codec extradata instead of the hand-crafted one from the previous revision. Signed-off-by: Zane van Iperen --- libavformat/apm.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/libavformat/apm.c b/libavformat/apm.c index 4158b81457..8d655d0a33 100644 --- a/libavformat/apm.c +++ b/libavformat/apm.c @@ -26,6 +26,7 @@ #define APM_FILE_HEADER_SIZE18 #define APM_FILE_EXTRADATA_SIZE 80 +#define APM_EXTRADATA_SIZE 28 #define APM_MAX_READ_SIZE 4096 @@ -160,13 +161,11 @@ static int apm_read_header(AVFormatContext *s) return AVERROR_PATCHWELCOME; } -if ((ret = ff_alloc_extradata(st->codecpar, 16)) < 0) +if ((ret = ff_alloc_extradata(st->codecpar, APM_EXTRADATA_SIZE)) < 0) return ret; -AV_WL32(st->codecpar->extradata + 0, vs12.state.predictor_l); -AV_WL32(st->codecpar->extradata + 4, vs12.state.step_index_l); -AV_WL32(st->codecpar->extradata + 8, vs12.state.predictor_r); -AV_WL32(st->codecpar->extradata + 12, vs12.state.step_index_r); +/* Use the entire state as extradata. */ +memcpy(st->codecpar->extradata, buf + 20, APM_EXTRADATA_SIZE); avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate); st->start_time = 0; -- 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 v6 0/7] Add support for encoding adpcm_ima_apm and muxing to apm.
v6: [8] * split out header and extradata fixes * add more-descriptive commit messages * fix bit_rate overflow v5: [7] * split out cosmetic changes into their own patch v4: * fix rebase issues v3: [4][5][6] * Support both extradata formats - fixes FATE failure + preserves compatibility * EINVAL->ERANGE v2: [1][2][3] * fix mixed declarations and code * remove unused variable * fix array initialisation * LOG_WARNING->LOG_ERROR * reorder "name and probe fix" [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264310.html [2] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264309.html [3] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264308.html [4] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264328.html [5] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264329.html [6] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264326.html [7] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265218.html [8] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265840.html Zane van Iperen (7): avformat/apm: read header correctly avformat/apm: use the entire APMState structure as extradata avformat/apm: fix variable/structure names and cosmetics avcodec: add adpcm_ima_apm encoder avformat: add apm muxer fate: add adpcm_ima_apm encoding test avcodec/adpcmenc: cleanup trellis checks Changelog | 2 + doc/general.texi | 2 +- libavcodec/Makefile| 1 + libavcodec/adpcmenc.c | 63 ++--- libavcodec/allcodecs.c | 1 + libavcodec/utils.c | 1 + libavcodec/version.h | 2 +- libavformat/Makefile | 3 +- libavformat/allformats.c | 1 + libavformat/apm.c | 240 - libavformat/version.h | 2 +- tests/fate/acodec.mak | 2 + tests/ref/acodec/adpcm-ima_apm | 4 + 13 files changed, 244 insertions(+), 80 deletions(-) create mode 100644 tests/ref/acodec/adpcm-ima_apm -- 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 v6 1/7] avformat/apm: read header correctly
The leading WAVEFORMATEX in .APM files is malformed:
* The nAvgBytesPerSec field is wrong, and
* sizeof(cbSize) is 4 instead of 2.
Signed-off-by: Zane van Iperen
---
libavformat/Makefile | 2 +-
libavformat/apm.c| 50
2 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 26af859a28..a4113fe644 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -93,7 +93,7 @@ OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
-OBJS-$(CONFIG_APM_DEMUXER) += apm.o riffdec.o
+OBJS-$(CONFIG_APM_DEMUXER) += apm.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
OBJS-$(CONFIG_APTX_DEMUXER) += aptxdec.o rawdec.o
diff --git a/libavformat/apm.c b/libavformat/apm.c
index dc59c16562..4158b81457 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -21,12 +21,12 @@
*/
#include "avformat.h"
#include "internal.h"
-#include "riff.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
-#define APM_FILE_HEADER_SIZE20
-#define APM_VS12_CHUNK_SIZE 76
+#define APM_FILE_HEADER_SIZE18
+#define APM_FILE_EXTRADATA_SIZE 80
+
#define APM_MAX_READ_SIZE 4096
#define APM_TAG_CODEC 0x2000
@@ -51,6 +51,7 @@ typedef struct APMVS12Chunk {
uint32_tunk2;
APMStatestate;
uint32_tpad[7];
+uint32_tdata;
} APMVS12Chunk;
static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
@@ -71,6 +72,8 @@ static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t
*buf)
for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
+
+vs12->data = AV_RL32(buf + 76);
}
static int apm_probe(const AVProbeData *p)
@@ -95,24 +98,37 @@ static int apm_read_header(AVFormatContext *s)
int64_t ret;
AVStream *st;
APMVS12Chunk vs12;
-uint8_t buf[APM_VS12_CHUNK_SIZE];
+uint8_t buf[APM_FILE_EXTRADATA_SIZE];
if (!(st = avformat_new_stream(s, NULL)))
return AVERROR(ENOMEM);
-/* The header starts with a WAVEFORMATEX */
-if ((ret = ff_get_wav_header(s, s->pb, st->codecpar, APM_FILE_HEADER_SIZE,
0)) < 0)
+/*
+ * This is 98% a WAVEFORMATEX, but there's something screwy with the
extradata
+ * that ff_get_wav_header() can't (and shouldn't) handle properly.
+ */
+if (avio_rl16(s->pb) != APM_TAG_CODEC)
+return AVERROR_INVALIDDATA;
+
+st->codecpar->channels = avio_rl16(s->pb);
+st->codecpar->sample_rate = avio_rl32(s->pb);
+
+/* Skip the bitrate, it's usually wrong anyway. */
+if ((ret = avio_skip(s->pb, 4)) < 0)
return ret;
-if (st->codecpar->bits_per_coded_sample != 4)
+st->codecpar->block_align = avio_rl16(s->pb);
+st->codecpar->bits_per_coded_sample = avio_rl16(s->pb);
+
+if (avio_rl32(s->pb) != APM_FILE_EXTRADATA_SIZE)
return AVERROR_INVALIDDATA;
-if (st->codecpar->codec_tag != APM_TAG_CODEC)
+/* I've never seen files greater than this. */
+if (st->codecpar->sample_rate > 44100)
return AVERROR_INVALIDDATA;
-/* ff_get_wav_header() does most of the work, but we need to fix a few
things. */
-st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_APM;
-st->codecpar->codec_tag = 0;
+if (st->codecpar->bits_per_coded_sample != 4)
+return AVERROR_INVALIDDATA;
if (st->codecpar->channels == 2)
st->codecpar->channel_layout= AV_CH_LAYOUT_STEREO;
@@ -121,31 +137,29 @@ static int apm_read_header(AVFormatContext *s)
else
return AVERROR_INVALIDDATA;
+st->codecpar->codec_type= AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_APM;
st->codecpar->format= AV_SAMPLE_FMT_S16;
st->codecpar->bits_per_raw_sample = 16;
st->codecpar->bit_rate = st->codecpar->channels *
st->codecpar->sample_rate *
st->codecpar->bits_per_coded_sample;
-if ((ret = avio_read(s->pb, buf, APM_VS12_CHUNK_SIZE)) < 0)
+if ((ret = avio_read(s->pb, buf, APM_FILE_EXTRADATA_SIZE)) < 0)
return ret;
-else if (ret != APM_VS12_CHUNK_SIZE)
+else if (ret != APM_FILE_EXTRADATA_SIZE)
return AVERROR(EIO);
apm_parse_vs12(&vs12, buf);
-if (vs12.magic != APM_TAG_VS12) {
+if (vs12.magic != APM_TAG_VS12 || vs12.data != APM_TAG_DATA)
return AVERROR_INVALIDDATA;
-}
if (vs12.state.has_saved) {
avpriv_request_sample(s, "Saved Samples");
return AVERROR_PAT
[FFmpeg-devel] [PATCH v6 3/7] avformat/apm: fix variable/structure names and cosmetics
Signed-off-by: Zane van Iperen
---
libavformat/apm.c | 100 +++---
1 file changed, 51 insertions(+), 49 deletions(-)
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 8d655d0a33..0d88e1099a 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -44,37 +44,37 @@ typedef struct APMState {
int32_t saved_l;
} APMState;
-typedef struct APMVS12Chunk {
+typedef struct APMExtraData {
uint32_tmagic;
uint32_tfile_size;
uint32_tdata_size;
uint32_tunk1;
uint32_tunk2;
APMStatestate;
-uint32_tpad[7];
+uint32_tunk3[7];
uint32_tdata;
-} APMVS12Chunk;
+} APMExtraData;
-static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
+static void apm_parse_extradata(APMExtraData *ext, const uint8_t *buf)
{
-vs12->magic = AV_RL32(buf + 0);
-vs12->file_size = AV_RL32(buf + 4);
-vs12->data_size = AV_RL32(buf + 8);
-vs12->unk1 = AV_RL32(buf + 12);
-vs12->unk2 = AV_RL32(buf + 16);
-
-vs12->state.has_saved = AV_RL32(buf + 20);
-vs12->state.predictor_r = AV_RL32(buf + 24);
-vs12->state.step_index_r= AV_RL32(buf + 28);
-vs12->state.saved_r = AV_RL32(buf + 32);
-vs12->state.predictor_l = AV_RL32(buf + 36);
-vs12->state.step_index_l= AV_RL32(buf + 40);
-vs12->state.saved_l = AV_RL32(buf + 44);
-
-for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
-vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
-
-vs12->data = AV_RL32(buf + 76);
+ext->magic = AV_RL32(buf + 0);
+ext->file_size = AV_RL32(buf + 4);
+ext->data_size = AV_RL32(buf + 8);
+ext->unk1 = AV_RL32(buf + 12);
+ext->unk2 = AV_RL32(buf + 16);
+
+ext->state.has_saved= AV_RL32(buf + 20);
+ext->state.predictor_r = AV_RL32(buf + 24);
+ext->state.step_index_r = AV_RL32(buf + 28);
+ext->state.saved_r = AV_RL32(buf + 32);
+ext->state.predictor_l = AV_RL32(buf + 36);
+ext->state.step_index_l = AV_RL32(buf + 40);
+ext->state.saved_l = AV_RL32(buf + 44);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(ext->unk3); i++)
+ext->unk3[i]= AV_RL32(buf + 48 + (i * 4));
+
+ext->data = AV_RL32(buf + 76);
}
static int apm_probe(const AVProbeData *p)
@@ -98,7 +98,8 @@ static int apm_read_header(AVFormatContext *s)
{
int64_t ret;
AVStream *st;
-APMVS12Chunk vs12;
+APMExtraData extradata;
+AVCodecParameters *par;
uint8_t buf[APM_FILE_EXTRADATA_SIZE];
if (!(st = avformat_new_stream(s, NULL)))
@@ -111,67 +112,68 @@ static int apm_read_header(AVFormatContext *s)
if (avio_rl16(s->pb) != APM_TAG_CODEC)
return AVERROR_INVALIDDATA;
-st->codecpar->channels = avio_rl16(s->pb);
-st->codecpar->sample_rate = avio_rl32(s->pb);
+par = st->codecpar;
+par->channels = avio_rl16(s->pb);
+par->sample_rate = avio_rl32(s->pb);
/* Skip the bitrate, it's usually wrong anyway. */
if ((ret = avio_skip(s->pb, 4)) < 0)
return ret;
-st->codecpar->block_align = avio_rl16(s->pb);
-st->codecpar->bits_per_coded_sample = avio_rl16(s->pb);
+par->block_align = avio_rl16(s->pb);
+par->bits_per_coded_sample = avio_rl16(s->pb);
if (avio_rl32(s->pb) != APM_FILE_EXTRADATA_SIZE)
return AVERROR_INVALIDDATA;
/* I've never seen files greater than this. */
-if (st->codecpar->sample_rate > 44100)
+if (par->sample_rate > 44100)
return AVERROR_INVALIDDATA;
-if (st->codecpar->bits_per_coded_sample != 4)
+if (par->bits_per_coded_sample != 4)
return AVERROR_INVALIDDATA;
-if (st->codecpar->channels == 2)
-st->codecpar->channel_layout= AV_CH_LAYOUT_STEREO;
-else if (st->codecpar->channels == 1)
-st->codecpar->channel_layout= AV_CH_LAYOUT_MONO;
+if (par->channels == 2)
+par->channel_layout= AV_CH_LAYOUT_STEREO;
+else if (par->channels == 1)
+par->channel_layout= AV_CH_LAYOUT_MONO;
else
return AVERROR_INVALIDDATA;
-st->codecpar->codec_type= AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_APM;
-st->codecpar->format= AV_SAMPLE_FMT_S16;
-st->codecpar->bits_per_raw_sample = 16;
-st->codecpar->bit_rate = st->codecpar->channels *
- st->codecpar->sample_rate *
- st->codecpar->bits_per_coded_sample;
+par->codec_type= AVMEDIA_TYPE_AUDIO;
+par->codec_id = AV_CODEC_ID_ADPCM_IMA_APM;
+par->format= AV_SAMPLE_FMT_S16;
+par->bits_per_raw_
[FFmpeg-devel] [PATCH v6 7/7] avcodec/adpcmenc: cleanup trellis checks
Signed-off-by: Zane van Iperen
---
libavcodec/adpcmenc.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 4985abb163..adb7bf0bbf 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -69,25 +69,26 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-if (avctx->trellis && (unsigned)avctx->trellis > 16U) {
-av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
-return AVERROR(EINVAL);
-}
+if (avctx->trellis) {
+int frontier, max_paths;
-if (avctx->trellis &&
- (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
-avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
-/*
- * The current trellis implementation doesn't work for extended
- * runs of samples without periodic resets. Disallow it.
- */
-av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
-return AVERROR_PATCHWELCOME;
-}
+if ((unsigned)avctx->trellis > 16U) {
+av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
+return AVERROR(EINVAL);
+}
-if (avctx->trellis) {
-int frontier = 1 << avctx->trellis;
-int max_paths = frontier * FREEZE_INTERVAL;
+if (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM) {
+/*
+ * The current trellis implementation doesn't work for extended
+ * runs of samples without periodic resets. Disallow it.
+ */
+av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
+frontier = 1 << avctx->trellis;
+max_paths = frontier * FREEZE_INTERVAL;
if (!FF_ALLOC_TYPED_ARRAY(s->paths,max_paths)||
!FF_ALLOC_TYPED_ARRAY(s->node_buf, 2 * frontier) ||
!FF_ALLOC_TYPED_ARRAY(s->nodep_buf,2 * frontier) ||
--
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 v6 4/7] avcodec: add adpcm_ima_apm encoder
Signed-off-by: Zane van Iperen
---
Changelog | 1 +
doc/general.texi | 2 +-
libavcodec/Makefile| 1 +
libavcodec/adpcmenc.c | 34 --
libavcodec/allcodecs.c | 1 +
libavcodec/utils.c | 1 +
libavcodec/version.h | 2 +-
7 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/Changelog b/Changelog
index 1bb9931c0d..e986327172 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
- AudioToolbox output device
- MacCaption demuxer
- PGX decoder
+- ADPCM IMA Ubisoft APM encoder
version 4.3:
diff --git a/doc/general.texi b/doc/general.texi
index 53d556c56c..68d386b655 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1113,7 +1113,7 @@ following image formats are supported:
@item ADPCM IMA High Voltage Software ALP @tab @tab X
@item ADPCM IMA QuickTime@tab X @tab X
@item ADPCM IMA Simon & Schuster Interactive @tab X @tab X
-@item ADPCM IMA Ubisoft APM @tab @tab X
+@item ADPCM IMA Ubisoft APM @tab X @tab X
@item ADPCM IMA Loki SDL MJPEG @tab @tab X
@item ADPCM IMA WAV @tab X @tab X
@item ADPCM IMA Westwood @tab @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 12aa43fe51..86b92aeded 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -854,6 +854,7 @@ OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER) += adpcm.o
adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_ALP_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_APM_DECODER) += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_APM_ENCODER) += adpcmenc.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_CUNNING_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_DK3_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 1e94ef4047..4985abb163 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -74,7 +74,9 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-if (avctx->trellis && avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI) {
+if (avctx->trellis &&
+ (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
/*
* The current trellis implementation doesn't work for extended
* runs of samples without periodic resets. Disallow it.
@@ -145,6 +147,14 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
avctx->frame_size = BLKSIZE * 2 / avctx->channels;
avctx->block_align = BLKSIZE;
break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+avctx->frame_size = BLKSIZE * 2 / avctx->channels;
+avctx->block_align = BLKSIZE;
+
+if (!(avctx->extradata = av_mallocz(28 +
AV_INPUT_BUFFER_PADDING_SIZE)))
+return AVERROR(ENOMEM);
+avctx->extradata_size = 28;
+break;
default:
return AVERROR(EINVAL);
}
@@ -486,7 +496,8 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
if (avctx->codec_id == AV_CODEC_ID_ADPCM_SWF)
pkt_size = (2 + avctx->channels * (22 + 4 * (frame->nb_samples - 1)) +
7) / 8;
-else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI)
+else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+ avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_APM)
pkt_size = (frame->nb_samples * avctx->channels) / 2;
else
pkt_size = avctx->block_align;
@@ -711,6 +722,24 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
*dst++ = nibble;
}
break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+{
+PutBitContext pb;
+init_put_bits(&pb, dst, pkt_size);
+
+av_assert0(avctx->trellis == 0);
+
+for (n = frame->nb_samples / 2; n > 0; n--) {
+for (ch = 0; ch < avctx->channels; ch++) {
+put_bits(&pb, 4, adpcm_ima_qt_compress_sample(c->status + ch,
*samples++));
+put_bits(&pb, 4, adpcm_ima_qt_compress_sample(c->status + ch,
samples[st]));
+}
+samples += avctx->channels;
+}
+
+flush_put_bits(&pb);
+break;
+}
default:
return AVERROR(EINVAL);
}
@@ -743,6 +772,7 @@ AVCodec ff_ ## name_ ## _encoder = {
\
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP, \
}
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_APM, adpcm_ima_apm, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Ubisoft APM");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactiv
[FFmpeg-devel] [PATCH v6 6/7] fate: add adpcm_ima_apm encoding test
Signed-off-by: Zane van Iperen --- tests/fate/acodec.mak | 2 ++ tests/ref/acodec/adpcm-ima_apm | 4 2 files changed, 6 insertions(+) create mode 100644 tests/ref/acodec/adpcm-ima_apm diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak index bb6bfe5ada..197b6ed7c0 100644 --- a/tests/fate/acodec.mak +++ b/tests/fate/acodec.mak @@ -45,6 +45,7 @@ fate-acodec-pcm-u%le: FMT = nut fate-acodec-pcm-f%be: FMT = au FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_ADX, ADX) += adx +FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_APM, APM) += ima_apm FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_QT, AIFF) += ima_qt FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_SSI, KVAG) += ima_ssi FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_WAV, WAV) += ima_wav @@ -59,6 +60,7 @@ fate-acodec-adpcm: $(FATE_ACODEC_ADPCM) fate-acodec-adpcm-%: CODEC = adpcm_$(@:fate-acodec-adpcm-%=%) fate-acodec-adpcm-adx: FMT = adx +fate-acodec-adpcm-ima_apm: FMT = apm fate-acodec-adpcm-ima_qt: FMT = aiff fate-acodec-adpcm-ima_ssi: FMT = kvag fate-acodec-adpcm-ima_wav: FMT = wav diff --git a/tests/ref/acodec/adpcm-ima_apm b/tests/ref/acodec/adpcm-ima_apm new file mode 100644 index 00..83bd21f831 --- /dev/null +++ b/tests/ref/acodec/adpcm-ima_apm @@ -0,0 +1,4 @@ +2e795c6c06baabe01ab92864d963e71b *tests/data/fate/acodec-adpcm-ima_apm.apm +264700 tests/data/fate/acodec-adpcm-ima_apm.apm +201607bf7610f062b9a1e6524354c569 *tests/data/fate/acodec-adpcm-ima_apm.out.wav +stddev: 904.76 PSNR: 37.20 MAXDIFF:34029 bytes: 1058400/ 1058400 -- 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 v6 5/7] avformat: add apm muxer
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apm.c| 107 ++-
libavformat/version.h| 2 +-
5 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index e986327172..d905e5dc45 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
- MacCaption demuxer
- PGX decoder
- ADPCM IMA Ubisoft APM encoder
+- Rayman 2 APM muxer
version 4.3:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a4113fe644..62d8cbb54e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -94,6 +94,7 @@ OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
OBJS-$(CONFIG_APM_DEMUXER) += apm.o
+OBJS-$(CONFIG_APM_MUXER) += apm.o rawenc.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
OBJS-$(CONFIG_APTX_DEMUXER) += aptxdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index f8527b1fd4..fd9e46e233 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -55,6 +55,7 @@ extern AVInputFormat ff_anm_demuxer;
extern AVInputFormat ff_apc_demuxer;
extern AVInputFormat ff_ape_demuxer;
extern AVInputFormat ff_apm_demuxer;
+extern AVOutputFormat ff_apm_muxer;
extern AVInputFormat ff_apng_demuxer;
extern AVOutputFormat ff_apng_muxer;
extern AVInputFormat ff_aptx_demuxer;
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 0d88e1099a..d060e526e0 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -1,5 +1,5 @@
/*
- * Rayman 2 APM Demuxer
+ * Rayman 2 APM (De)muxer
*
* Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
*
@@ -21,6 +21,8 @@
*/
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
+#include "libavutil/avassert.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
@@ -55,6 +57,7 @@ typedef struct APMExtraData {
uint32_tdata;
} APMExtraData;
+#if CONFIG_APM_DEMUXER
static void apm_parse_extradata(APMExtraData *ext, const uint8_t *buf)
{
ext->magic = AV_RL32(buf + 0);
@@ -205,3 +208,105 @@ AVInputFormat ff_apm_demuxer = {
.read_header= apm_read_header,
.read_packet= apm_read_packet
};
+#endif
+
+#if CONFIG_APM_MUXER
+static int apm_write_init(AVFormatContext *s)
+{
+AVCodecParameters *par;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "APM files have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+par = s->streams[0]->codecpar;
+
+if (par->codec_id != AV_CODEC_ID_ADPCM_IMA_APM) {
+av_log(s, AV_LOG_ERROR, "%s codec not supported\n",
+ avcodec_get_name(par->codec_id));
+return AVERROR(EINVAL);
+}
+
+if (par->channels > 2) {
+av_log(s, AV_LOG_ERROR, "APM files only support up to 2 channels\n");
+return AVERROR(EINVAL);
+}
+
+if (par->extradata_size != APM_EXTRADATA_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid/missing extradata\n");
+return AVERROR(EINVAL);
+}
+
+if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL)) {
+av_log(s, AV_LOG_ERROR, "Stream not seekable, unable to write output
file\n");
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+static int apm_write_header(AVFormatContext *s)
+{
+uint8_t buf[APM_FILE_EXTRADATA_SIZE] = { 0 };
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+/*
+ * Bodge a WAVEFORMATEX manually, ff_put_wav_header() can't
+ * be used because of the extra 2 bytes.
+ */
+avio_wl16(s->pb, APM_TAG_CODEC);
+avio_wl16(s->pb, par->channels);
+avio_wl32(s->pb, par->sample_rate);
+/* This is the wrong calculation, but it's what the orginal files have. */
+avio_wl32(s->pb, par->sample_rate * par->channels * 2);
+avio_wl16(s->pb, par->block_align);
+avio_wl16(s->pb, par->bits_per_coded_sample);
+avio_wl32(s->pb, APM_FILE_EXTRADATA_SIZE);
+
+/*
+ * Build the extradata. Assume the codec's given us correct data.
+ * File and data sizes are fixed later.
+ */
+AV_WL32(buf + 0, APM_TAG_VS12); /* magic */
+AV_WL32(buf + 12, 0x); /* unk1 */
+memcpy( buf + 20, par->extradata, APM_EXTRADATA_SIZE);
+AV_WL32(buf + 76, APM_TAG_DATA); /* data */
+
+avio_write(s->pb, buf, APM_FILE_EXTRADATA_SIZE);
+return 0;
+}
+
+static int apm_write_trailer(AVFormatContext *s)
+{
+int64_t file_size, data_size;
+
+file_size = avio_tell(s->pb);
+data_size = file_size - (APM_FILE_HEADER_SIZE + 2 +
APM_FILE_EXTRADATA_SIZE);
+
+if (file_size >= UINT32_MAX) {
+av_log(s, AV_LOG_ERROR,
+ "Filesize %"PRId64" invalid for APM, output file will be
broken\n",
+
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: add support for animated WebP decoding
Jul 8, 2020, 06:28 by jo...@pex.com:
> Fixes: 4907
>
> Adds support for decoding of animated WebP.
>
> The WebP parser now splits the input stream into packets containing one frame.
>
> The WebP decoder adds the animation related features according to the specs:
> https://developers.google.com/speed/webp/docs/riff_container#animation
> The frames of the animation may be smaller than the image canvas.
> Therefore, the frame is decoded to a temporary frame,
> then it is blended into the canvas, the canvas is copied to the output frame,
> and finally the frame is disposed from the canvas.
>
> The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
> The background color is specified only as BGRA in the WebP file
> so it is converted to YUVA if YUV formats are output.
>
We don't convert pixel formats in decoders, and I wouldn't want to have
libavcodec
depend on libswscale. I wouldn't trust libswscale to make accurate conversions
either.
Can you use the macros in libavutil/colorspace.h to convert the BGRA value to
YUVA
and then just memcpy it across the frame?
Also, there are a lot of frame memcpys in the code. Could you get rid of most
of them
by refcounting?
> -.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,> +
> .capabilities = AV_CODEC_CAP_DR1,
Why?
> +if (component == 1 || component == 2) {> +height
> = AV_CEIL_RSHIFT(height, desc->log2_chroma_h);> +}
We don't wrap 1-line if statements in brackets.
___
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/libaomenc: fix build w/libaom v1.0.0
On Mon, Jul 6, 2020 at 10:50 AM James Zern wrote: > > James, > > On Thu, Jul 2, 2020 at 10:28 AM James Zern wrote: > > > > broken since: > > aa5c6f382b avcodec/libaomenc: Add command-line options to control the use > > of partition tools > > > > Signed-off-by: James Zern > > --- > > doc/encoders.texi | 20 ++-- > > libavcodec/libaomenc.c | 4 > > 2 files changed, 14 insertions(+), 10 deletions(-) > > > > I think this addresses the comments from the first patch. I'll submit > this in the next day or so if there aren't any more comments. > pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/jpeg2000dec: Fix RPCL progression order
On Thu, Jul 9, 2020 at 12:50 AM wrote: > > From: Gautam Ramakrishnan > > This patch fixes a check in the RPCL progression order, > making it similar to the openjpeg implementation. > --- > libavcodec/jpeg2000dec.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c > index 18a933077e..3ea939f7d9 100644 > --- a/libavcodec/jpeg2000dec.c > +++ b/libavcodec/jpeg2000dec.c > @@ -1393,22 +1393,28 @@ static int > jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2 > uint8_t reducedresno = codsty->nreslevels - 1 > -reslevelno; // ==> N_L - r > Jpeg2000ResLevel *rlevel = comp->reslevel + > reslevelno; > unsigned prcx, prcy; > +int trx0, try0; > > -int xc = x / s->cdx[compno]; > -int yc = y / s->cdy[compno]; > +if (!s->cdx[compno] || !s->cdy[compno]) > +return AVERROR_INVALIDDATA; > + > +trx0 = ff_jpeg2000_ceildiv(tile->coord[0][0], > s->cdx[compno] << reslevelno); > +try0 = ff_jpeg2000_ceildiv(tile->coord[1][0], > s->cdy[compno] << reslevelno); > > if (reslevelno >= codsty->nreslevels) > continue; > > -if (yc % (1LL << (rlevel->log2_prec_height + > reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the > check > +if (!(y % ((uint64_t)s->cdy[compno] << > (rlevel->log2_prec_height + reducedresno)) == 0 || > + (y == tile->coord[1][0] && (try0 << > reducedresno) % (1U << (reducedresno + rlevel->log2_prec_height) > continue; > > -if (xc % (1LL << (rlevel->log2_prec_width + > reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the > check > +if (!(x % ((uint64_t)s->cdx[compno] << > (rlevel->log2_prec_width + reducedresno)) == 0 || > + (x == tile->coord[0][0] && (trx0 << > reducedresno) % (1U << (reducedresno + rlevel->log2_prec_width) > continue; > > // check if a precinct exists > -prcx = ff_jpeg2000_ceildivpow2(xc, reducedresno) > >> rlevel->log2_prec_width; > -prcy = ff_jpeg2000_ceildivpow2(yc, reducedresno) > >> rlevel->log2_prec_height; > +prcx = ff_jpeg2000_ceildiv(x, s->cdx[compno] << > reducedresno) >> rlevel->log2_prec_width; > +prcy = ff_jpeg2000_ceildiv(y, s->cdy[compno] << > reducedresno) >> rlevel->log2_prec_height; > prcx -= > ff_jpeg2000_ceildivpow2(comp->coord_o[0][0], reducedresno) >> > rlevel->log2_prec_width; > prcy -= > ff_jpeg2000_ceildivpow2(comp->coord_o[1][0], reducedresno) >> > rlevel->log2_prec_height; > > @@ -1906,7 +1912,6 @@ static inline void > tile_codeblocks(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile > continue; > x = cblk->coord[0][0] - band->coord[0][0]; > y = cblk->coord[1][0] - band->coord[1][0]; > - > if (comp->roi_shift) > roi_scale_cblk(cblk, comp, &t1); > if (codsty->transform == FF_DWT97) > -- > 2.17.1 > This patch was verified on p1_07.j2k, by allowing it to take up the ya8 pixel format. However, p1_07.j2k was allowed to get decoded to ya8 solely for the purpose of testing. p1_07.j2k is still not decodable due to it having 2 components with different sub sampling rates. I suspect PCRL and CPRL progression orders to have the same issue. I shall try finding an appropriate test case and shall fix those as well. -- - Gautam | ___ 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] libavutil/imgutils: UBSan nullptr-with-offset in av_image_fill_pointer
On Tue, Jul 07, 2020 at 01:14:41PM -0700, Brian Kim wrote: > On Tue, Jul 7, 2020 at 4:35 AM Michael Niedermayer > wrote: > [...] > > I wonder if linesizes for newly added functions should be ptrdiff_t > > this would add some type converting loops though > > > > And size probably should be ptrdiff_t or int64_t to similarly be more future > > proof > > Can these values be negative? Or is there some other reason not to use size_t? size should not be negative, size_t is a option for that linesize in principle can be negative thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus 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] libavutil/imgutils: UBSan nullptr-with-offset in av_image_fill_pointer
On Tue, Jul 07, 2020 at 05:41:11PM -0300, James Almer wrote:
> On 7/7/2020 5:07 PM, Brian Kim wrote:
> > On Tue, Jul 7, 2020 at 6:34 AM James Almer wrote:
> >>
> >> If i understand this right, you could easily solve it with just the
> >> following changes:
> >>
> >>> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> >>> index 7f9c1b632c..48a373db01 100644
> >>> --- a/libavutil/imgutils.c
> >>> +++ b/libavutil/imgutils.c
> >>> @@ -126,7 +126,8 @@ int av_image_fill_pointers(uint8_t *data[4], enum
> >>> AVPixelFormat pix_fmt, int hei
> >>>
> >>> if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
> >>> desc->flags & FF_PSEUDOPAL) {
> >>> -data[1] = ptr + size[0]; /* palette is stored here as 256 32
> >>> bits words */
> >>> +if (ptr)
> >>> +data[1] = ptr + size[0]; /* palette is stored here as 256 32
> >>> bits words */
> >>> return size[0] + 256 * 4;
> >>> }
> >>>
> >>> @@ -136,7 +137,8 @@ int av_image_fill_pointers(uint8_t *data[4], enum
> >>> AVPixelFormat pix_fmt, int hei
> >>> total_size = size[0];
> >>> for (i = 1; i < 4 && has_plane[i]; i++) {
> >>> int h, s = (i == 1 || i == 2) ? desc->log2_chroma_h : 0;
> >>> -data[i] = data[i-1] + size[i-1];
> >>> +if (data[i - 1])
> >>> +data[i] = data[i - 1] + size[i - 1];
> >>> h = (height + (1 << s) - 1) >> s;
> >>> if (linesizes[i] > INT_MAX / h)
> >>> return AVERROR(EINVAL);
> >
> > Do we have to worry about backwards compatibility here? Some places
> > (e.g. libavcodec/decode.c:1497) have been using data to calculate the
> > sizes.
>
> That code depended on undefined behavior, for both C and the
> av_image_fill_pointers() function. So IMO no, we don't need to worry
> about it.
If you break the size = data0 - data1 usecase then
you must bump the major abi version because if you dont then
distros will have things break and this is our own libs that break
because they use this before we fix it.
I hope iam wrong, of course because this is a mess
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
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] libavcodec/jpeg2000dec: Fix RPCL progression order
From: Gautam Ramakrishnan This patch fixes a check in the RPCL progression order, making it similar to the openjpeg implementation. --- libavcodec/jpeg2000dec.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c index 18a933077e..3ea939f7d9 100644 --- a/libavcodec/jpeg2000dec.c +++ b/libavcodec/jpeg2000dec.c @@ -1393,22 +1393,28 @@ static int jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2 uint8_t reducedresno = codsty->nreslevels - 1 -reslevelno; // ==> N_L - r Jpeg2000ResLevel *rlevel = comp->reslevel + reslevelno; unsigned prcx, prcy; +int trx0, try0; -int xc = x / s->cdx[compno]; -int yc = y / s->cdy[compno]; +if (!s->cdx[compno] || !s->cdy[compno]) +return AVERROR_INVALIDDATA; + +trx0 = ff_jpeg2000_ceildiv(tile->coord[0][0], s->cdx[compno] << reslevelno); +try0 = ff_jpeg2000_ceildiv(tile->coord[1][0], s->cdy[compno] << reslevelno); if (reslevelno >= codsty->nreslevels) continue; -if (yc % (1LL << (rlevel->log2_prec_height + reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the check +if (!(y % ((uint64_t)s->cdy[compno] << (rlevel->log2_prec_height + reducedresno)) == 0 || + (y == tile->coord[1][0] && (try0 << reducedresno) % (1U << (reducedresno + rlevel->log2_prec_height) continue; -if (xc % (1LL << (rlevel->log2_prec_width + reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the check +if (!(x % ((uint64_t)s->cdx[compno] << (rlevel->log2_prec_width + reducedresno)) == 0 || + (x == tile->coord[0][0] && (trx0 << reducedresno) % (1U << (reducedresno + rlevel->log2_prec_width) continue; // check if a precinct exists -prcx = ff_jpeg2000_ceildivpow2(xc, reducedresno) >> rlevel->log2_prec_width; -prcy = ff_jpeg2000_ceildivpow2(yc, reducedresno) >> rlevel->log2_prec_height; +prcx = ff_jpeg2000_ceildiv(x, s->cdx[compno] << reducedresno) >> rlevel->log2_prec_width; +prcy = ff_jpeg2000_ceildiv(y, s->cdy[compno] << reducedresno) >> rlevel->log2_prec_height; prcx -= ff_jpeg2000_ceildivpow2(comp->coord_o[0][0], reducedresno) >> rlevel->log2_prec_width; prcy -= ff_jpeg2000_ceildivpow2(comp->coord_o[1][0], reducedresno) >> rlevel->log2_prec_height; @@ -1906,7 +1912,6 @@ static inline void tile_codeblocks(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile continue; x = cblk->coord[0][0] - band->coord[0][0]; y = cblk->coord[1][0] - band->coord[1][0]; - if (comp->roi_shift) roi_scale_cblk(cblk, comp, &t1); if (codsty->transform == FF_DWT97) -- 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] libavcodec/jpeg2000dec: Fix RPCL progression order
Am Mi., 8. Juli 2020 um 21:30 Uhr schrieb Gautam Ramakrishnan : > This patch was verified on p1_07.j2k Then please add this (important) information to the commit message, we don't want to get "more similar to openjpeg", you can therefore remove this sentence. 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] libavutil/imgutils: UBSan nullptr-with-offset in av_image_fill_pointer
On 7/8/2020 4:44 PM, Michael Niedermayer wrote:
> On Tue, Jul 07, 2020 at 05:41:11PM -0300, James Almer wrote:
>> On 7/7/2020 5:07 PM, Brian Kim wrote:
>>> On Tue, Jul 7, 2020 at 6:34 AM James Almer wrote:
If i understand this right, you could easily solve it with just the
following changes:
> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> index 7f9c1b632c..48a373db01 100644
> --- a/libavutil/imgutils.c
> +++ b/libavutil/imgutils.c
> @@ -126,7 +126,8 @@ int av_image_fill_pointers(uint8_t *data[4], enum
> AVPixelFormat pix_fmt, int hei
>
> if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
> desc->flags & FF_PSEUDOPAL) {
> -data[1] = ptr + size[0]; /* palette is stored here as 256 32
> bits words */
> +if (ptr)
> +data[1] = ptr + size[0]; /* palette is stored here as 256 32
> bits words */
> return size[0] + 256 * 4;
> }
>
> @@ -136,7 +137,8 @@ int av_image_fill_pointers(uint8_t *data[4], enum
> AVPixelFormat pix_fmt, int hei
> total_size = size[0];
> for (i = 1; i < 4 && has_plane[i]; i++) {
> int h, s = (i == 1 || i == 2) ? desc->log2_chroma_h : 0;
> -data[i] = data[i-1] + size[i-1];
> +if (data[i - 1])
> +data[i] = data[i - 1] + size[i - 1];
> h = (height + (1 << s) - 1) >> s;
> if (linesizes[i] > INT_MAX / h)
> return AVERROR(EINVAL);
>>>
>>> Do we have to worry about backwards compatibility here? Some places
>>> (e.g. libavcodec/decode.c:1497) have been using data to calculate the
>>> sizes.
>>
>> That code depended on undefined behavior, for both C and the
>> av_image_fill_pointers() function. So IMO no, we don't need to worry
>> about it.
>
> If you break the size = data0 - data1 usecase then
> you must bump the major abi version because if you dont then
> distros will have things break and this is our own libs that break
> because they use this before we fix it.
Leaving *data[4] zeroed when ptr == NULL would only break size = data1 -
data0 for prt == NULL. And if this is UB, then we can't even be sure the
above is guaranteed with every compiler.
In any case, I'm fine with postponing that change until after a bump. As
i said it should be a matter of adding a simple check.
The addition of av_image_fill_plane_sizes() should be enough for now.
>
> I hope iam wrong, of course because this is a mess
>
> thx
>
> [...]
>
>
> ___
> 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] libavutil/video_enc_params: add block type
On Tue, Jul 7, 2020 at 12:59 AM Anton Khirnov wrote:
> Quoting Yongle Lin (2020-07-06 23:08:17)
> > add block type field to AVVideoBlockParams so we could either export or
> visualize it later.
> > ---
> > libavutil/video_enc_params.h | 20
> > 1 file changed, 20 insertions(+)
>
> We generally require new APIs to be immediately useful. So in this case,
> there should also be a patch that makes some decoder export those
> fields.
>
I plan to send separate patches for H264 and VP9 to export type data and
another patch to visualize the block type in codecview filter when I get
approved for this patch.
Do you want me to add the "decoder export" code to this patch so that it
will be immediately useful? Thanks
> >
> > diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
> > index 43fa443154..55b9fc4031 100644
> > --- a/libavutil/video_enc_params.h
> > +++ b/libavutil/video_enc_params.h
> > @@ -101,6 +101,21 @@ typedef struct AVVideoEncParams {
> > int32_t delta_qp[4][2];
> > } AVVideoEncParams;
> >
> > +typedef struct MacroBlockType {
> > +/**
> > + * Is intra prediction
> > + */
> > +int intra;
> > +/**
> > + * Skip flag
> > + */
> > +int skip;
>
> These structures are stored per-block, so it seems pretty wasteful to
> spend a whole int (4 bytes) when only one bit is used.
>
> --
> 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".
Re: [FFmpeg-devel] [PATCH] swscale/tests: check return value of sws_scale
On Tue, 7 Jul 2020, Lynne wrote: Patch attached. From a89bfd810cf40e3005fbcbdcf43a7b858b4dd12c Mon Sep 17 00:00:00 2001 From: Lynne Date: Tue, 7 Jul 2020 22:19:14 +0100 Subject: [PATCH] swscale/tests: check return value of sws_scale --- libswscale/tests/swscale.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c index 19878a7877..693f439bf5 100644 --- a/libswscale/tests/swscale.c +++ b/libswscale/tests/swscale.c @@ -422,7 +422,9 @@ bad_option: for (y = 0; y < H; y++) for (x = 0; x < W * 4; x++) rgb_data[ x + y * 4 * W] = av_lfg_get(&rand); -sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) src, stride); +res = sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) src, stride); +if (res < 0 || res != (H / 12)) +goto error; This looks good to me. Unfortunately (for me, for fixing the arm side of it), I noticed that the full test takes a tremendous amount of time to run and isn't part of the normal fate run, but I do see that there's options for reducing the number of cases tested, that should allow me to test the arm side. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libavformat: add WebP demuxer
Am Mi., 8. Juli 2020 um 07:28 Uhr schrieb Josef Zlomek :
>
> Fixes: 4907
It seems surprising that two commits should fix a ticket.
> Adds support for demuxing of animated WebP.
Does this demuxer also support single frame files?
What about concatenated webps?
[...]
> +static int webp_probe(const AVProbeData *p)
> +{
> +const uint8_t *b = p->buf;
> +
> +if (p->filename && ff_guess_image2_codec(p->filename)) {
Why is this useful?
> +if (AV_RB32(b) == MKBETAG('R', 'I', 'F', 'F') &&
> +AV_RB32(b + 8) == MKBETAG('W', 'E', 'B', 'P'))
> +return AVPROBE_SCORE_MAX;
> +}
[...]
> +frame_end = avio_tell(pb);
> +
> +if (avio_seek(pb, frame_start, SEEK_SET) != frame_start)
> +return AVERROR(EIO);
Instead I believe you should use ffio_ensure_seekback() or do
I miss something?
Same above.
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 v6 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Wed, 8 Jul 2020, lance.lmw...@gmail.com wrote:
On Wed, Jul 01, 2020 at 09:39:58PM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavdevice/decklink_dec.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 82106aa..0fc1489 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -41,6 +41,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/time.h"
+#include "libavutil/timecode.h"
#include "libavutil/mathematics.h"
#include "libavutil/reverse.h"
#include "avdevice.h"
@@ -778,6 +779,21 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
AVDictionary* metadata_dict = NULL;
int metadata_len;
uint8_t* packed_metadata;
+AVTimecode tcr;
+uint32_t tc_data;
+uint8_t *sd;
+int size = sizeof(uint32_t) * 4;
You can push some of these initializers into the blocks in which they are
used.
+
+if (av_timecode_init_from_string(&tcr,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
+if ((tc_data =
av_timecode_get_smpte_from_framenum(&tcr, 0)) > 0) {
av_timecode_get_smpte_from_framenum() always succeeds, so this check is
wrong.
Also in theory you could query the color framing flag from the decklink
api.
Regards,
Marton
+sd = av_packet_new_side_data(&pkt,
AV_PKT_DATA_S12M_TIMECODE, size);
+if (sd) {
+AV_WL32(sd, 1); // one TC ;
+AV_WL32(sd + 4, tc_data); // TC;
+}
+}
+}
+
if (av_dict_set(&metadata_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
packed_metadata =
av_packet_pack_dictionary(metadata_dict, &metadata_len);
av_dict_free(&metadata_dict);
--
1.8.3.1
Marton, please help to review and give comments.
--
Thanks,
Limin Wang
___
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] swscale/tests: check return value of sws_scale
On Tue, Jul 07, 2020 at 11:22:20PM +0200, Lynne wrote: > Patch attached. > > swscale.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > e4eb17aee95423afb258e2368ac1503720393263 > 0001-swscale-tests-check-return-value-of-sws_scale.patch > From a89bfd810cf40e3005fbcbdcf43a7b858b4dd12c Mon Sep 17 00:00:00 2001 > From: Lynne > Date: Tue, 7 Jul 2020 22:19:14 +0100 > Subject: [PATCH] swscale/tests: check return value of sws_scale > > --- > libswscale/tests/swscale.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c > index 19878a7877..693f439bf5 100644 > --- a/libswscale/tests/swscale.c > +++ b/libswscale/tests/swscale.c > @@ -422,7 +422,9 @@ bad_option: > for (y = 0; y < H; y++) > for (x = 0; x < W * 4; x++) > rgb_data[ x + y * 4 * W] = av_lfg_get(&rand); > -sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) src, > stride); > +res = sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) > src, stride); > +if (res < 0 || res != (H / 12)) if iam not mistaken, this should be res != H, not /12 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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 v6 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Wed, Jul 08, 2020 at 11:59:17PM +0200, Marton Balint wrote:
>
>
> On Wed, 8 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Wed, Jul 01, 2020 at 09:39:58PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavdevice/decklink_dec.cpp | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > > index 82106aa..0fc1489 100644
> > > --- a/libavdevice/decklink_dec.cpp
> > > +++ b/libavdevice/decklink_dec.cpp
> > > @@ -41,6 +41,7 @@ extern "C" {
> > > #include "libavutil/imgutils.h"
> > > #include "libavutil/intreadwrite.h"
> > > #include "libavutil/time.h"
> > > +#include "libavutil/timecode.h"
> > > #include "libavutil/mathematics.h"
> > > #include "libavutil/reverse.h"
> > > #include "avdevice.h"
> > > @@ -778,6 +779,21 @@ HRESULT
> > > decklink_input_callback::VideoInputFrameArrived(
> > > AVDictionary* metadata_dict = NULL;
> > > int metadata_len;
> > > uint8_t* packed_metadata;
> > > +AVTimecode tcr;
> > > +uint32_t tc_data;
> > > +uint8_t *sd;
> > > +int size = sizeof(uint32_t) * 4;
>
> You can push some of these initializers into the blocks in which they are
> used.
Sure, will fix it.
>
> > > +
> > > +if (av_timecode_init_from_string(&tcr,
> > > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > +if ((tc_data =
> > > av_timecode_get_smpte_from_framenum(&tcr, 0)) > 0) {
>
> av_timecode_get_smpte_from_framenum() always succeeds, so this check is
> wrong.
OK, will fix it.
>
> Also in theory you could query the color framing flag from the decklink api.
av_timecode_get_smpte_from_framenum() assume the Color Frame flag is zero
always, and the conversion from frame to string didn't support the color frame
flag also, so even we set the flag, it's not used still. Do you insist that
this version must support this feature?
>
> Regards,
> Marton
>
> > > +sd = av_packet_new_side_data(&pkt,
> > > AV_PKT_DATA_S12M_TIMECODE, size);
> > > +if (sd) {
> > > +AV_WL32(sd, 1); // one TC ;
> > > +AV_WL32(sd + 4, tc_data); // TC;
> > > +}
> > > +}
> > > +}
> > > +
> > > if (av_dict_set(&metadata_dict, "timecode", tc,
> > > AV_DICT_DONT_STRDUP_VAL) >= 0) {
> > > packed_metadata =
> > > av_packet_pack_dictionary(metadata_dict, &metadata_len);
> > > av_dict_free(&metadata_dict);
> > > --
> > > 1.8.3.1
> > >
> >
> > Marton, please help to review and give comments.
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".
--
Thanks,
Limin Wang
___
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 v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.
On Tue, 7 Jul 2020 at 19:14, Michael Niedermayer wrote: > > a lot of patchwork patch maintaince can be automated, ive written a script > to do that. > What this does is basically look at local git, fetch all patches from > patchwork > (and cache them locally) > and then find stuff which is either invalid, superseeded, applied, ... but > not > marked correctly > last it dumps the command line commands to the screen for a human to decide > if they are correct and should be run as is or not. > See: > https://github.com/michaelni/patchwork-update-bot > > It worked fine until the server was updated or maybe the number of patches > became too big. > now it times out while fetching patches, the command line tool (pwclient) > times out too (xmlrpclib.ProtocolError: patchwork.ffmpeg.org/xmlrpc/: 504 Gateway Time-out>) > so the bug is not in patchwork-update-bot > Someone has to investigate why this timeout happens and make it not timeout > then run this automatically in regular intervalls > > thx > > Since it's python, I can take a look, provided it doesn't need any special permissions. M. ___ 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 v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.
On Tue, 7 Jul 2020 at 16:00, Nicolas George wrote:
> Manolis Stamatogiannakis (12020-07-05):
> > The section has been expanded to outline how to manage patch revisions.
> > ---
> > doc/developer.texi | 37 ++---
> > 1 file changed, 26 insertions(+), 11 deletions(-)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index b33cab0fc7..dec27cb509 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -491,18 +491,25 @@ as base64-encoded attachments, so your patch is
> not trashed during
> > transmission. Also ensure the correct mime type is used
> > (text/x-diff or text/x-patch or at least text/plain) and that only one
> > patch is inline or attached per mail.
> > -You can check @url{https://patchwork.ffmpeg.org}, if your patch does
> not show up, its mime type
> > -likely was wrong.
> > +You can check the most recently received patches on
> > +@url{https://patchwork.ffmpeg.org, patchwork}.
> > +If your patch does not show up, its mime type likely was wrong.
> >
> > -Your patch will be reviewed on the mailing list. You will likely be
> asked
> > +Your patch will be reviewed on the mailing list. Give us a few days to
> react.
> > +But if some time passes without reaction, send a reminder by email.
> > +Your patch should eventually be dealt with. However, you will likely be
> asked
> > to make some changes and are expected to send in an improved version
> that
> > incorporates the requests from the review. This process may go through
> > several iterations. Once your patch is deemed good enough, some
> developer
> > will pick it up and commit it to the official FFmpeg tree.
> >
> > -Give us a few days to react. But if some time passes without reaction,
> > -send a reminder by email. Your patch should eventually be dealt with.
> > -
>
> > +When preparing an updated version of you patch, make sure you increment
> > +its @emph{roll-counter}. This is achieved by adding a @code{-v }
> argument
> > +to @code{git format-patch}/@code{git send-email} commands.
>
> I know many core developers do not bother with that, and I never found
> these "v3" very useful: if I am not involved in the discussion, I will
> not remember what number is the latest. And if I become involved in the
> discussions, my mail client can sort the patch by date and I take the
> latest.
>
The documentation aims to establish some good practices for people who want
to start contributing to the project.
By the patches arriving to the list, adding a roll counter seems to be an
established good practice. So it should probably be included in the docs.
But keep in mind that this is only a recommendation anyway. Maybe changing
"make sure" to "should" would make that more clear.
Core developers can stray off recommendations, since they are in position
to make an informed decision when they are not relevant.
In this case, you have a very well setup email-based workflow. Other people
may not have that, and the roll counter may come handy.
Would normalizing the verbs in developer.texi help to avoid confusion?
Maybe it's just me, but when I'm reading any technical documents, I
interpret the verbs according to RFC2119 to understand what is mandatory,
what is recommended and what optional.
>
> > +Additionally, it is recommended to register for a
> > +@uref{https://patchwork.ffmpeg.org, patchwork account}.
> > +This will allow you to mark previous version of your patches as
> "Superseded",
> > +and reduce the chance of someone spending time to review a stale patch.
>
> Is interacting with Patchwork to become mandatory when submitting
> patches?
>
Nicolas, why would you ever interpret "recommended" as mandatory? I think
it's as clear as it gets that it is not mandatory.
Again, this is a good practice which was not mentioned in the
documentation. I have no attachment whatsoever to the tool, or intention to
impose it to anyone.
@Michael Niedermayer, since you seem to be the most involved with patchwork
in the thread, what would be better for this? Keep the wording as a
recommendation, or to move it outside the list as purely informational text?
> There is this classic scenario:
>
> 1. People work on something.
>
> 2. Somebody sets up a tool to make the work easier.
>
> 3. People start relying on the tool.
>
> 4. The tool proves imperfect.
>
> 5. People are required extra work to go around the flaws of the tool.
>
> 6. Overall, the tool has made the work not easier but harder.
>
> Are we going that way with Patchwork?
>
So your recommendation is to not setup any tool ever, because people may
start relying on it?
Tools come and go. As long as use is optional and there's no data lock-in,
I don't see why we should be wary of any tool that makes running the
project smoother.
>
> If I am required to log into a website and do maintenance each time I
> send an updated patch, I will just send less updated patches.
You certainly don't need to do that each time. A weekly cleanup would
pro
Re: [FFmpeg-devel] Project orientation
On Tue, 7 Jul 2020 at 16:27, Nicolas George wrote: > Manolis Stamatogiannakis (12020-07-07): > > If I reply to the email, my response will appear online in the issue/PR > > page. > > That is good to know. I have never noticed it documented. Does it work > reliably? > > Haven't noticed any glitches so far. I can help you test the feature if you want. Just make a dummy public github repo and send me the details with email. > > Now, if you also want to review the code of a PRs from mutt, that's > another > > discussion. > > Not necessarily mutt, but if it's a web browser, then find somebody else > to review. > Code review on github is pretty nice, if you haven't tried it. > > Is tree threading that important? A PR is essentially a single thread of > > discussion. > > It is a single thread of discussion until the discussion becomes complex > and has branches. > This doesn't sound like the common case. But it should be straightforward to get some statistics on that from the list archives when a transition is officially discussed. > > > I would first ask why keep using a mailing list to post patches and not > use > > PRs. For a 3 commit patch, and 3 people sending feedback a few days > apart, > > you have a minimum of 15 emails for everyone on the list. Is that > efficient? > > Actually, since mail servers are much much less resource-consuming that > web interfaces, it probably is. > Valuing hardware resources more than the time any of us volunteers is a pretty unorthodox approach. We are not living in the 60s. Hardware is cheap, programmers are expensive [1]. [1] https://blog.codinghorror.com/hardware-is-cheap-programmers-are-expensive/ Best regards, Manolis ___ 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/3] libavutil/imgutils: add utility to get plane sizes
Patch attached.
Main changes from v1 are switching to from int to size_t/ptrdiff_t
where relevant and removing av_image_fill_pointers_from_sizes()
Some things to note:
- The av_image_fill_planes_sizes uses size_t/ptrdiff_t for buffer
sizes, but as mentioned during the v1 review, this leads to some
inconvenient conversions and range checks when using it with existing
functions. We could keep the return type as int to alleviate this, but
that seems like it would somewhat defeat the purpose of moving to
these types.
- SIZE_MAX is used in several places in libavutil, so I used
PTRDIFF_MAX, but I could not see any mention of these being allowed.
From a47b3f3b5c2ed4a1caf9f0a3429dd425ce708bb1 Mon Sep 17 00:00:00 2001
From: Brian Kim
Date: Tue, 7 Jul 2020 11:36:19 -0700
Subject: [PATCH 1/3] libavutil/imgutils: add utility to get plane sizes
This utility helps avoid undefined behavior when doing things like
checking how much memory we need to allocate for an image before we have
allocated a buffer.
Signed-off-by: Brian Kim
---
doc/APIchanges | 3 ++
libavutil/frame.c| 15 ++---
libavutil/imgutils.c | 74
libavutil/imgutils.h | 12 +++
libavutil/version.h | 2 +-
5 files changed, 82 insertions(+), 24 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1d6cc36b8c..44defd9ca8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-07-xx - xx - lavu 56.56.100 - imgutils.h
+ Add av_image_fill_plane_sizes().
+
2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
Add AV_PIX_FMT_X2RGB10.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9884eae054..b664dcfbe8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -214,6 +214,8 @@ static int get_video_buffer(AVFrame *frame, int align)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
int ret, i, padded_height;
int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
+ptrdiff_t total_size, linesizes[4];
+size_t size[4];
if (!desc)
return AVERROR(EINVAL);
@@ -238,12 +240,17 @@ static int get_video_buffer(AVFrame *frame, int align)
frame->linesize[i] = FFALIGN(frame->linesize[i], align);
}
+for (i = 0; i < 4; i++)
+linesizes[i] = frame->linesize[i];
+
padded_height = FFALIGN(frame->height, 32);
-if ((ret = av_image_fill_pointers(frame->data, frame->format, padded_height,
- NULL, frame->linesize)) < 0)
-return ret;
+if ((total_size = av_image_fill_plane_sizes(size, frame->format, padded_height,
+linesizes)) < 0)
+return total_size;
+if (total_size > INT_MAX - 4*plane_padding)
+return AVERROR(EINVAL);
-frame->buf[0] = av_buffer_alloc(ret + 4*plane_padding);
+frame->buf[0] = av_buffer_alloc(total_size + 4*plane_padding);
if (!frame->buf[0]) {
ret = AVERROR(ENOMEM);
goto fail;
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 7f9c1b632c..082229cfaf 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -108,26 +108,26 @@ int av_image_fill_linesizes(int linesizes[4], enum AVPixelFormat pix_fmt, int wi
return 0;
}
-int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int height,
- uint8_t *ptr, const int linesizes[4])
+ptrdiff_t av_image_fill_plane_sizes(size_t size[4], enum AVPixelFormat pix_fmt,
+int height, const ptrdiff_t linesizes[4])
{
-int i, total_size, size[4] = { 0 }, has_plane[4] = { 0 };
+int i, has_plane[4] = { 0 };
+ptrdiff_t total_size;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-memset(data , 0, sizeof(data[0])*4);
+memset(size , 0, sizeof(size[0])*4);
if (!desc || desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
return AVERROR(EINVAL);
-data[0] = ptr;
-if (linesizes[0] > (INT_MAX - 1024) / height)
+if (linesizes[0] > (PTRDIFF_MAX - 1024) / height)
return AVERROR(EINVAL);
size[0] = linesizes[0] * height;
if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
desc->flags & FF_PSEUDOPAL) {
-data[1] = ptr + size[0]; /* palette is stored here as 256 32 bits words */
-return size[0] + 256 * 4;
+size[1] = 256 * 4; /* palette is stored here as 256 32 bits words */
+return size[0] + size[1];
}
for (i = 0; i < 4; i++)
@@ -136,12 +136,11 @@ int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int hei
total_size = size[0];
for (i = 1; i < 4 && has_plane[i]; i++) {
int h, s = (i == 1 || i == 2) ? desc->log2_chroma_h : 0;
-data[i] = data[i-1] + size[i-1];
h = (height + (1 << s) - 1) >> s;
-if (linesizes[i] > INT_MAX / h)
+if (line
[FFmpeg-devel] [PATCH v2 2/3] libavcodec/decode: avoid UB when getting plane sizes
Patch attached
From 6e28dfde91443fba276fdd792dee9480c0b00558 Mon Sep 17 00:00:00 2001
From: Brian Kim
Date: Tue, 7 Jul 2020 11:42:04 -0700
Subject: [PATCH 2/3] libavcodec/decode: avoid UB when getting plane sizes
This uses av_image_fill_plane_sizes instead of av_image_fill_pointers
when we are getting plane sizes to avoid UB from adding offsets to NULL.
Signed-off-by: Brian Kim
---
libavcodec/decode.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index de9c079f9d..c1753cfffb 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1471,12 +1471,12 @@ static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
switch (avctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: {
-uint8_t *data[4];
int linesize[4];
-int size[4] = { 0 };
int w = frame->width;
int h = frame->height;
-int tmpsize, unaligned;
+int unaligned;
+ptrdiff_t tmpsize, linesize1[4];
+size_t size[4];
avcodec_align_dimensions2(avctx, &w, &h, pool->stride_align);
@@ -1494,20 +1494,22 @@ static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
unaligned |= linesize[i] % pool->stride_align[i];
} while (unaligned);
-tmpsize = av_image_fill_pointers(data, avctx->pix_fmt, h,
- NULL, linesize);
+for (i = 0; i < 4; i++)
+linesize1[i] = linesize[i];
+tmpsize = av_image_fill_plane_sizes(size, avctx->pix_fmt, h,
+linesize1);
if (tmpsize < 0) {
ret = tmpsize;
goto fail;
}
-for (i = 0; i < 3 && data[i + 1]; i++)
-size[i] = data[i + 1] - data[i];
-size[i] = tmpsize - (data[i] - data[0]);
-
for (i = 0; i < 4; i++) {
pool->linesize[i] = linesize[i];
if (size[i]) {
+if (size[i] > INT_MAX - (16 + STRIDE_ALIGN - 1)) {
+ret = AVERROR(EINVAL);
+goto fail;
+}
pool->pools[i] = av_buffer_pool_init(size[i] + 16 + STRIDE_ALIGN - 1,
CONFIG_MEMORY_POISONING ?
NULL :
--
2.27.0.383.g050319c2ae-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 3/3] libavutil/imgutils: check for non-null buffer in av_image_fill_pointer
Patch attached. There was some discussion on the v1 thread on whether it was acceptable to break code that was relying on UB, so this patch will probably want to get delayed until a major version bump to avoid breaking places that were relying on av_image_fill_pointers() populating data when the input ptr is null From 2c269118523de0911f17a4b560b016c34fc3002f Mon Sep 17 00:00:00 2001 From: Brian Kim Date: Tue, 7 Jul 2020 11:42:35 -0700 Subject: [PATCH 3/3] libavutil/imgutils: check for non-null buffer in av_image_fill_pointers We were previously always filling data by adding offsets to ptr, which was undefined behavior when ptr was NULL. Signed-off-by: Brian Kim --- libavutil/imgutils.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c index 082229cfaf..3898c5e771 100644 --- a/libavutil/imgutils.c +++ b/libavutil/imgutils.c @@ -155,6 +155,9 @@ int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int hei ptrdiff_t ret, linesizes1[4]; size_t size[4]; +if (!ptr) +return AVERROR(EINVAL); + for (i = 0; i < 4; i++) linesizes1[i] = linesizes[i]; -- 2.27.0.383.g050319c2ae-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 3/3] libavutil/imgutils: check for non-null buffer in av_image_fill_pointer
On 7/8/2020 10:54 PM, Brian Kim wrote: > Patch attached. > > There was some discussion on the v1 thread on whether it was > acceptable to break code that was relying on UB, so this patch will > probably want to get delayed until a major version bump to avoid > breaking places that were relying on av_image_fill_pointers() > populating data when the input ptr is null > From 2c269118523de0911f17a4b560b016c34fc3002f Mon Sep 17 00:00:00 2001 > From: Brian Kim > Date: Tue, 7 Jul 2020 11:42:35 -0700 > Subject: [PATCH 3/3] libavutil/imgutils: check for non-null buffer in > av_image_fill_pointers > > We were previously always filling data by adding offsets to ptr, which > was undefined behavior when ptr was NULL. > > Signed-off-by: Brian Kim > --- > libavutil/imgutils.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c > index 082229cfaf..3898c5e771 100644 > --- a/libavutil/imgutils.c > +++ b/libavutil/imgutils.c > @@ -155,6 +155,9 @@ int av_image_fill_pointers(uint8_t *data[4], enum > AVPixelFormat pix_fmt, int hei > ptrdiff_t ret, linesizes1[4]; > size_t size[4]; > > +if (!ptr) > +return AVERROR(EINVAL); No, check !ptr immediately after the memset() call (to zero the data array), and if it's NULL then return the value from av_image_fill_plane_sizes(). No reason to break calls with ptr == NULL since calling it to get the total size of the buffer you want to allocate is a valid scenario where the contents of *data[4] are meaningless and thus ignored. You just want to fix the UB of adding offsets to NULL. This will still need to wait until a major bump nonetheless. > + > for (i = 0; i < 4; i++) > linesizes1[i] = linesizes[i]; > > -- > 2.27.0.383.g050319c2ae-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 1/3] libavutil/imgutils: add utility to get plane sizes
On 7/8/2020 10:50 PM, Brian Kim wrote:
> Patch attached.
>
> Main changes from v1 are switching to from int to size_t/ptrdiff_t
> where relevant and removing av_image_fill_pointers_from_sizes()
>
> Some things to note:
> - The av_image_fill_planes_sizes uses size_t/ptrdiff_t for buffer
> sizes, but as mentioned during the v1 review, this leads to some
> inconvenient conversions and range checks when using it with existing
> functions. We could keep the return type as int to alleviate this, but
> that seems like it would somewhat defeat the purpose of moving to
> these types.
> - SIZE_MAX is used in several places in libavutil, so I used
> PTRDIFF_MAX, but I could not see any mention of these being allowed.
[...]
> From a47b3f3b5c2ed4a1caf9f0a3429dd425ce708bb1 Mon Sep 17 00:00:00 2001
> From: Brian Kim
> Date: Tue, 7 Jul 2020 11:36:19 -0700
> Subject: [PATCH 1/3] libavutil/imgutils: add utility to get plane sizes
>
> This utility helps avoid undefined behavior when doing things like
> checking how much memory we need to allocate for an image before we have
> allocated a buffer.
>
> Signed-off-by: Brian Kim
> ---
> doc/APIchanges | 3 ++
> libavutil/frame.c| 15 ++---
> libavutil/imgutils.c | 74
> libavutil/imgutils.h | 12 +++
> libavutil/version.h | 2 +-
> 5 files changed, 82 insertions(+), 24 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 1d6cc36b8c..44defd9ca8 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-07-xx - xx - lavu 56.56.100 - imgutils.h
> + Add av_image_fill_plane_sizes().
> +
> 2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
>Add AV_PIX_FMT_X2RGB10.
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 9884eae054..b664dcfbe8 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
Changes to frame.c should be in a separate commit as well.
> @@ -214,6 +214,8 @@ static int get_video_buffer(AVFrame *frame, int align)
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
> int ret, i, padded_height;
> int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
> +ptrdiff_t total_size, linesizes[4];
> +size_t size[4];
>
> if (!desc)
> return AVERROR(EINVAL);
> @@ -238,12 +240,17 @@ static int get_video_buffer(AVFrame *frame, int align)
> frame->linesize[i] = FFALIGN(frame->linesize[i], align);
> }
>
> +for (i = 0; i < 4; i++)
> +linesizes[i] = frame->linesize[i];
> +
> padded_height = FFALIGN(frame->height, 32);
> -if ((ret = av_image_fill_pointers(frame->data, frame->format,
> padded_height,
> - NULL, frame->linesize)) < 0)
> -return ret;
> +if ((total_size = av_image_fill_plane_sizes(size, frame->format,
> padded_height,
> +linesizes)) < 0)
> +return total_size;
> +if (total_size > INT_MAX - 4*plane_padding)
> +return AVERROR(EINVAL);
>
> -frame->buf[0] = av_buffer_alloc(ret + 4*plane_padding);
> +frame->buf[0] = av_buffer_alloc(total_size + 4*plane_padding);
> if (!frame->buf[0]) {
> ret = AVERROR(ENOMEM);
> goto fail;
> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> index 7f9c1b632c..082229cfaf 100644
> --- a/libavutil/imgutils.c
> +++ b/libavutil/imgutils.c
> @@ -108,26 +108,26 @@ int av_image_fill_linesizes(int linesizes[4], enum
> AVPixelFormat pix_fmt, int wi
> return 0;
> }
>
> -int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int
> height,
> - uint8_t *ptr, const int linesizes[4])
> +ptrdiff_t av_image_fill_plane_sizes(size_t size[4], enum AVPixelFormat
> pix_fmt,
The sum of all sizes should be size_t if each size is a size_t. But if
you do that you can't return error values, so i'm not sure what to
suggest other than just stick to ints for both (ptrdiff_t linesizes
should be ok).
I'd like to hear Michael's opinion about it.
For that matter, as it is right now i think this would be the first
function that returns ptrdiff_t to signal AVERROR values.
> +int height, const ptrdiff_t linesizes[4])
> {
> -int i, total_size, size[4] = { 0 }, has_plane[4] = { 0 };
> +int i, has_plane[4] = { 0 };
> +ptrdiff_t total_size;
>
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> -memset(data , 0, sizeof(data[0])*4);
> +memset(size , 0, sizeof(size[0])*4);
>
> if (!desc || desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
> return AVERROR(EINVAL);
>
> -data[0] = ptr;
> -if (linesizes[0] > (INT_MAX - 1024) / height)
> +if (linesizes[0] > (PTRDIFF_MAX - 1024) / height)
This check would need to ensure the calculation below fits in a size_t
instead.
Re: [FFmpeg-devel] [PATCH V3] tests/dnn/mathunary: fix the issue of NAN
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年7月8日 14:10
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V3] tests/dnn/mathunary: fix the issue of NAN
>
> When one of output[i] & expected_output is NAN, the unit test will always
> pass.
>
> Signed-off-by: Ting Fu
> ---
> tests/dnn/dnn-layer-mathunary-test.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/dnn/dnn-layer-mathunary-test.c
> b/tests/dnn/dnn-layer-mathunary-test.c
> index 683e623d95..5afc5c157e 100644
> --- a/tests/dnn/dnn-layer-mathunary-test.c
> +++ b/tests/dnn/dnn-layer-mathunary-test.c
> @@ -86,7 +86,10 @@ static int test(DNNMathUnaryOperation op)
> output = operands[1].data;
> for (int i = 0; i < sizeof(input) / sizeof(float); ++i) {
> float expected_output = get_expected(input[i], op);
> -if(fabs(output[i] - expected_output) > EPS) {
> +int output_nan = isnan(output[i]);
> +int expected_nan = isnan(expected_output);
> +if ((!output_nan && !expected_nan && fabs(output[i] -
> expected_output) > EPS) ||
> +(output_nan && !expected_nan) || (!output_nan &&
> + expected_nan)) {
> printf("at index %d, output: %f, expected_output: %f\n", i,
> output[i], expected_output);
> av_freep(&output);
> return 1;
LGTM, will push soon, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/dashenc.c:support mpd update period
Pushed the patch, with minor change to commit message.
Thanks,
Karthick
On 6/30/20 11:14 AM, Siyuan Huang wrote:
> Update with no file mode changes :
>
>
>
> From 818095d4f0aa50dfee3cb0622146a2180801c5fe Mon Sep 17 00:00:00 2001
>
> From: Siyuan Huang
>
> Date: Tue, 30 Jun 2020 13:41:46 +0800
>
> Subject: [PATCH] libavformat/dashenc.c:support mpd update period v3
>
>
>
> according iso 23009-1 , in live cases , mpd refresh
>
> period should be changeable
>
>
>
> Signed-off-by: Siyuan Huang
>
> ---
>
> doc/muxers.texi | 4
>
> libavformat/dashenc.c | 4
>
> 2 files changed, 8 insertions(+)
>
>
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
>
> index b1389a3227..86976f4f61 100644
>
> --- a/doc/muxers.texi
>
> +++ b/doc/muxers.texi
>
> @@ -366,6 +366,10 @@ adjusting playback latency and buffer occupancy during
> normal playback by client
>
> Set the maximum playback rate indicated as appropriate for the purposes of
> automatically
>
> adjusting playback latency and buffer occupancy during normal playback by
> clients.
>
> +@item update_period @var{update_period}
>
> + Set the mpd update period ,for dynamic content.
>
> + The unit is second.
>
> +
>
> @end table
>
> @anchor{framecrc}
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>
> index 62193058d7..dc3306a56a 100644
>
> --- a/libavformat/dashenc.c
>
> +++ b/libavformat/dashenc.c
>
> @@ -198,6 +198,7 @@ typedef struct DASHContext {
>
> int target_latency_refid;
>
> AVRational min_playback_rate;
>
> AVRational max_playback_rate;
>
> +int64_t update_period;
>
> } DASHContext;
>
> static struct codec_string {
>
> @@ -1184,6 +1185,8 @@ static int write_manifest(AVFormatContext *s, int
> final)
>
> char now_str[100];
>
> if (c->use_template && !c->use_timeline)
>
> update_period = 500;
>
> +if (c->update_period)
>
> +update_period = c->update_period;
>
> avio_printf(out, "\tminimumUpdatePeriod=\"PT%"PRId64"S\"\n",
> update_period);
>
> if (!c->ldash)
>
> avio_printf(out,
> "\tsuggestedPresentationDelay=\"PT%"PRId64"S\"\n", c->last_duration /
> AV_TIME_BASE);
>
> @@ -2380,6 +2383,7 @@ static const AVOption options[] = {
>
> { "target_latency", "Set desired target latency for Low-latency dash",
> OFFSET(target_latency), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT_MAX, E },
>
> { "min_playback_rate", "Set desired minimum playback rate",
> OFFSET(min_playback_rate), AV_OPT_TYPE_RATIONAL, { .dbl = 1.0 }, 0.5, 1.5, E
> },
>
> { "max_playback_rate", "Set desired maximum playback rate",
> OFFSET(max_playback_rate), AV_OPT_TYPE_RATIONAL, { .dbl = 1.0 }, 0.5, 1.5, E
> },
>
> +{ "update_period", "Set the mpd update interval",
> OFFSET(update_period), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, E},
>
> { NULL },
>
> };
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ffmpeg.org_mailman_listinfo_ffmpeg-2Ddevel&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=xOoesbz-6ff1GPXp5Lg4jf1ZG99yp4a1qhxVn_YOwRU&m=4YPMEclN8LjEF9ay98BehLzHoqtCqzgK4hxGam47mRQ&s=5Xpoq0cZZUGetVqh7mK1Wpmgm1JwFfS8cH8wVHYwpuk&e=
>
>
> 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] libavcodec/jpeg2000dec: Fix RPCL progression order
From: Gautam Ramakrishnan This patch fixes a check in the RPCL progression order, tested on p1_07.j2k. --- libavcodec/jpeg2000dec.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c index 18a933077e..3ea939f7d9 100644 --- a/libavcodec/jpeg2000dec.c +++ b/libavcodec/jpeg2000dec.c @@ -1393,22 +1393,28 @@ static int jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2 uint8_t reducedresno = codsty->nreslevels - 1 -reslevelno; // ==> N_L - r Jpeg2000ResLevel *rlevel = comp->reslevel + reslevelno; unsigned prcx, prcy; +int trx0, try0; -int xc = x / s->cdx[compno]; -int yc = y / s->cdy[compno]; +if (!s->cdx[compno] || !s->cdy[compno]) +return AVERROR_INVALIDDATA; + +trx0 = ff_jpeg2000_ceildiv(tile->coord[0][0], s->cdx[compno] << reslevelno); +try0 = ff_jpeg2000_ceildiv(tile->coord[1][0], s->cdy[compno] << reslevelno); if (reslevelno >= codsty->nreslevels) continue; -if (yc % (1LL << (rlevel->log2_prec_height + reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the check +if (!(y % ((uint64_t)s->cdy[compno] << (rlevel->log2_prec_height + reducedresno)) == 0 || + (y == tile->coord[1][0] && (try0 << reducedresno) % (1U << (reducedresno + rlevel->log2_prec_height) continue; -if (xc % (1LL << (rlevel->log2_prec_width + reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the check +if (!(x % ((uint64_t)s->cdx[compno] << (rlevel->log2_prec_width + reducedresno)) == 0 || + (x == tile->coord[0][0] && (trx0 << reducedresno) % (1U << (reducedresno + rlevel->log2_prec_width) continue; // check if a precinct exists -prcx = ff_jpeg2000_ceildivpow2(xc, reducedresno) >> rlevel->log2_prec_width; -prcy = ff_jpeg2000_ceildivpow2(yc, reducedresno) >> rlevel->log2_prec_height; +prcx = ff_jpeg2000_ceildiv(x, s->cdx[compno] << reducedresno) >> rlevel->log2_prec_width; +prcy = ff_jpeg2000_ceildiv(y, s->cdy[compno] << reducedresno) >> rlevel->log2_prec_height; prcx -= ff_jpeg2000_ceildivpow2(comp->coord_o[0][0], reducedresno) >> rlevel->log2_prec_width; prcy -= ff_jpeg2000_ceildivpow2(comp->coord_o[1][0], reducedresno) >> rlevel->log2_prec_height; @@ -1906,7 +1912,6 @@ static inline void tile_codeblocks(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile continue; x = cblk->coord[0][0] - band->coord[0][0]; y = cblk->coord[1][0] - band->coord[1][0]; - if (comp->roi_shift) roi_scale_cblk(cblk, comp, &t1); if (codsty->transform == FF_DWT97) -- 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] libavformat/dashenc.c:kill latency when ldash on
On 6/30/20 11:16 AM, Siyuan Huang wrote: > > Soory for wrong commit messge > > Update to no file mode modify at version2 > > From efd83d91a9bd9a485bcda6799f5f681c203a7449 Mon Sep 17 00:00:00 2001 > From: Siyuan Huang > Date: Tue, 30 Jun 2020 13:44:01 +0800 > Subject: [PATCH] libavformat/dashenc.c:kill latency when ldash on v2 > > disable write tmp file to let it using chunk downloading at last segment > > Signed-off-by: Siyuan Huang > --- > libavformat/dashenc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > index dc3306a56a..ef6e3d29c6 100644 > --- a/libavformat/dashenc.c > +++ b/libavformat/dashenc.c > @@ -2232,6 +2232,8 @@ static int dash_write_packet(AVFormatContext *s, > AVPacket *pkt) > AVDictionary *opts = NULL; > const char *proto = avio_find_protocol_name(s->url); > int use_rename = proto && !strcmp(proto, "file"); > +if (c->ldash) > +use_rename = 0; I guess, rename was added for file protocol to handle some corner-cases related to concurrent file access. Hence it may not be safe to disable them internally. Instead, I propose a new option for disabling rename feature so that users know exactly what they are asking for. > if (os->segment_type == SEGMENT_TYPE_MP4) > write_styp(os->ctx->pb); > os->filename[0] = os->full_path[0] = os->temp_path[0] = '\0'; > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__ffmpeg.org_mailman_listinfo_ffmpeg-2Ddevel&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=xOoesbz-6ff1GPXp5Lg4jf1ZG99yp4a1qhxVn_YOwRU&m=GHkxeN_WIsYgq8XYQY4j0c4OsL-Sgjc5Tmhf5Xl2kuU&s=XRu2dw1vQat2TOD1pmN6ua82e_1eNpvBWuN1jPAL8OE&e= > > > 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".
