[FFmpeg-devel] [PATCH 2/2] avcodec/anm: Don't unnecessarily use context variables
Signed-off-by: Andreas Rheinhardt
---
libavcodec/anm.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index e9b19d880d..134640ee36 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -31,13 +31,12 @@
typedef struct AnmContext {
AVFrame *frame;
int palette[AVPALETTE_COUNT];
-GetByteContext gb;
-int x; ///< x coordinate position
} AnmContext;
static av_cold int decode_init(AVCodecContext *avctx)
{
AnmContext *s = avctx->priv_data;
+GetByteContext gb;
int i;
if (avctx->extradata_size < 16 * 8 + 4 * 256)
@@ -49,10 +48,10 @@ static av_cold int decode_init(AVCodecContext *avctx)
if (!s->frame)
return AVERROR(ENOMEM);
-bytestream2_init(>gb, avctx->extradata, avctx->extradata_size);
-bytestream2_skipu(>gb, 16 * 8);
+bytestream2_init(, avctx->extradata, avctx->extradata_size);
+bytestream2_skipu(, 16 * 8);
for (i = 0; i < 256; i++)
-s->palette[i] = (0xFFU << 24) | bytestream2_get_le32u(>gb);
+s->palette[i] = (0xFFU << 24) | bytestream2_get_le32u();
return 0;
}
@@ -115,7 +114,8 @@ static int decode_frame(AVCodecContext *avctx,
AnmContext *s = avctx->priv_data;
const int buf_size = avpkt->size;
uint8_t *dst, *dst_end;
-int count, ret;
+GetByteContext gb;
+int count, ret, x = 0;
if (buf_size < 7)
return AVERROR_INVALIDDATA;
@@ -125,37 +125,36 @@ static int decode_frame(AVCodecContext *avctx,
dst = s->frame->data[0];
dst_end = s->frame->data[0] + s->frame->linesize[0]*avctx->height;
-bytestream2_init(>gb, avpkt->data, buf_size);
+bytestream2_init(, avpkt->data, buf_size);
-if (bytestream2_get_byte(>gb) != 0x42) {
+if (bytestream2_get_byte() != 0x42) {
avpriv_request_sample(avctx, "Unknown record type");
return AVERROR_INVALIDDATA;
}
-if (bytestream2_get_byte(>gb)) {
+if (bytestream2_get_byte()) {
avpriv_request_sample(avctx, "Padding bytes");
return AVERROR_PATCHWELCOME;
}
-bytestream2_skip(>gb, 2);
+bytestream2_skip(, 2);
-s->x = 0;
do {
/* if statements are ordered by probability */
#define OP(gb, pixel, count) \
-op(, dst_end, (gb), (pixel), (count), >x, avctx->width,
s->frame->linesize[0])
+op(, dst_end, (gb), (pixel), (count), , avctx->width,
s->frame->linesize[0])
-int type = bytestream2_get_byte(>gb);
+int type = bytestream2_get_byte();
count = type & 0x7F;
type >>= 7;
if (count) {
-if (OP(type ? NULL : >gb, -1, count)) break;
+if (OP(type ? NULL : , -1, count)) break;
} else if (!type) {
int pixel;
-count = bytestream2_get_byte(>gb); /* count==0 gives nop */
-pixel = bytestream2_get_byte(>gb);
+count = bytestream2_get_byte(); /* count==0 gives nop */
+pixel = bytestream2_get_byte();
if (OP(NULL, pixel, count)) break;
} else {
int pixel;
-type = bytestream2_get_le16(>gb);
+type = bytestream2_get_le16();
count = type & 0x3FFF;
type >>= 14;
if (!count) {
@@ -167,11 +166,11 @@ static int decode_frame(AVCodecContext *avctx,
}
continue;
}
-pixel = type == 3 ? bytestream2_get_byte(>gb) : -1;
+pixel = type == 3 ? bytestream2_get_byte() : -1;
if (type == 1) count += 0x4000;
-if (OP(type == 2 ? >gb : NULL, pixel, count)) break;
+if (OP(type == 2 ? : NULL, pixel, count)) break;
}
-} while (bytestream2_get_bytes_left(>gb) > 0);
+} while (bytestream2_get_bytes_left() > 0);
memcpy(s->frame->data[1], s->palette, AVPALETTE_SIZE);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/anm: Check extradata length before allocating frame
Then one doesn't need to free the frame in case the length turns out to
be insufficient.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/anm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index cd1fcc5998..e9b19d880d 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -40,6 +40,9 @@ static av_cold int decode_init(AVCodecContext *avctx)
AnmContext *s = avctx->priv_data;
int i;
+if (avctx->extradata_size < 16 * 8 + 4 * 256)
+return AVERROR_INVALIDDATA;
+
avctx->pix_fmt = AV_PIX_FMT_PAL8;
s->frame = av_frame_alloc();
@@ -47,11 +50,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
return AVERROR(ENOMEM);
bytestream2_init(>gb, avctx->extradata, avctx->extradata_size);
-if (bytestream2_get_bytes_left(>gb) < 16 * 8 + 4 * 256) {
-av_frame_free(>frame);
-return AVERROR_INVALIDDATA;
-}
-
bytestream2_skipu(>gb, 16 * 8);
for (i = 0; i < 256; i++)
s->palette[i] = (0xFFU << 24) | bytestream2_get_le32u(>gb);
--
2.20.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] Here has a problem on doc/examples/filtering_audio.c
Hi, everyone,
I do some tests with doc/examples/filtering_audio.c on audio formats like mp3,
m4a(aac), mpc, ogg, ape, flac, tta, wma and so on. The original
program(filtering_audio.c) always failed with audio format ape, and I do some
modifications on this program, and runs properly after test. I attached my
modification as attachment.
regards,
jackyxinli
/*
* Copyright (c) 2010 Nicolas George
* Copyright (c) 2011 Stefano Sabatini
* Copyright (c) 2012 Clément BÅsch
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
/**
* @file
* API example for audio decoding and filtering
* @example filtering_audio.c
*/
#include
#include
#include
#include
#include
#include
#include
static const char *filter_descr =
"aresample=44100,aformat=sample_fmts=s16:channel_layouts=stereo";
static const char *player = "ffplay -f s16le -ar 44100 -ac 2 -";
static AVFormatContext *fmt_ctx;
static AVCodecContext *dec_ctx;
AVFilterContext *buffersink_ctx;
AVFilterContext *buffersrc_ctx;
AVFilterGraph *filter_graph;
static int audio_stream_index = -1;
FILE *file;
static int open_input_file(const char *filename)
{
int ret;
AVCodec *dec;
if ((ret = avformat_open_input(_ctx, filename, NULL, NULL)) < 0) {
av_log(NULL, AV_LOG_ERROR, "Cannot open input file\n");
return ret;
}
if ((ret = avformat_find_stream_info(fmt_ctx, NULL)) < 0) {
av_log(NULL, AV_LOG_ERROR, "Cannot find stream information\n");
return ret;
}
/* select the audio stream */
ret = av_find_best_stream(fmt_ctx, AVMEDIA_TYPE_AUDIO, -1, -1, , 0);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Cannot find an audio stream in the input
file\n");
return ret;
}
audio_stream_index = ret;
/* create decoding context */
dec_ctx = avcodec_alloc_context3(dec);
if (!dec_ctx)
return AVERROR(ENOMEM);
avcodec_parameters_to_context(dec_ctx,
fmt_ctx->streams[audio_stream_index]->codecpar);
/* init the audio decoder */
if ((ret = avcodec_open2(dec_ctx, dec, NULL)) < 0) {
av_log(NULL, AV_LOG_ERROR, "Cannot open audio decoder\n");
return ret;
}
return 0;
}
static int init_filters(const char *filters_descr)
{
char args[512];
int ret = 0;
const AVFilter *abuffersrc = avfilter_get_by_name("abuffer");
const AVFilter *abuffersink = avfilter_get_by_name("abuffersink");
AVFilterInOut *outputs = avfilter_inout_alloc();
AVFilterInOut *inputs = avfilter_inout_alloc();
static const enum AVSampleFormat out_sample_fmts[] = { AV_SAMPLE_FMT_S16,
-1 };
static const int64_t out_channel_layouts[] = { AV_CH_LAYOUT_STEREO, -1 };
static const int out_sample_rates[] = { 44100, -1 };
const AVFilterLink *outlink;
AVRational time_base = fmt_ctx->streams[audio_stream_index]->time_base;
filter_graph = avfilter_graph_alloc();
if (!outputs || !inputs || !filter_graph) {
ret = AVERROR(ENOMEM);
goto end;
}
/* buffer audio source: the decoded frames from the decoder will be
inserted here. */
if (!dec_ctx->channel_layout)
dec_ctx->channel_layout =
av_get_default_channel_layout(dec_ctx->channels);
snprintf(args, sizeof(args),
"time_base=%d/%d:sample_rate=%d:sample_fmt=%s:channel_layout=0x%"PRIx64,
time_base.num, time_base.den, dec_ctx->sample_rate,
av_get_sample_fmt_name(dec_ctx->sample_fmt),
dec_ctx->channel_layout);
ret = avfilter_graph_create_filter(_ctx, abuffersrc, "in",
args, NULL, filter_graph);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Cannot create audio buffer source\n");
goto end;
}
/* buffer audio sink: to terminate the filter chain. */
ret = avfilter_graph_create_filter(_ctx, abuffersink, "out",
NULL, NULL, filter_graph);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR,
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_lut3d: prelut support for 3d cinespace luts
On Sat, May 23, 2020 at 7:04 PM wrote:
> From: Mark Reid
>
> changes since v1:
> * cleaned up code style
> * slightly reworked apply_lut functions to feel more consistent with code
>
> ---
> libavfilter/vf_lut3d.c | 372 +++--
> 1 file changed, 317 insertions(+), 55 deletions(-)
>
> diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
> index 482e2394a7..e5d9fcc068 100644
> --- a/libavfilter/vf_lut3d.c
> +++ b/libavfilter/vf_lut3d.c
> @@ -59,6 +59,15 @@ struct rgbvec {
> /* 3D LUT don't often go up to level 32, but it is common to have a Hald
> CLUT
> * of 512x512 (64x64x64) */
> #define MAX_LEVEL 256
> +#define PRELUT_SIZE 65536
> +
> +typedef struct Lut3DPreLut {
> +int size;
> +float min[3];
> +float max[3];
> +float scale[3];
> +float* lut[3];
> +} Lut3DPreLut;
>
> typedef struct LUT3DContext {
> const AVClass *class;
> @@ -71,6 +80,7 @@ typedef struct LUT3DContext {
> struct rgbvec *lut;
> int lutsize;
> int lutsize2;
> +Lut3DPreLut prelut;
> #if CONFIG_HALDCLUT_FILTER
> uint8_t clut_rgba_map[4];
> int clut_step;
> @@ -234,11 +244,39 @@ static inline struct rgbvec interp_tetrahedral(const
> LUT3DContext *lut3d,
> return c;
> }
>
> +static inline float prelut_interp_1d_linear(const Lut3DPreLut *prelut,
> +int idx, const float s)
> +{
> +const int lut_max = prelut->size - 1;
> +const float scaled = (s - prelut->min[idx]) * prelut->scale[idx];
> +const float x = av_clipf(scaled, 0.0f, lut_max);
> +const int prev = PREV(x);
> +const int next = FFMIN((int)(x) + 1, lut_max);
> +const float p = prelut->lut[idx][prev];
> +const float n = prelut->lut[idx][next];
> +const float d = x - (float)prev;
> +return lerpf(p, n, d);
> +}
> +
> +static inline struct rgbvec apply_prelut(const Lut3DPreLut *prelut,
> + const struct rgbvec *s)
> +{
> +if (prelut->size <= 0)
> +return *s;
> +
> +struct rgbvec c;
> +c.r = prelut_interp_1d_linear(prelut, 0, s->r);
> +c.g = prelut_interp_1d_linear(prelut, 1, s->g);
> +c.b = prelut_interp_1d_linear(prelut, 2, s->b);
> +return c;
> +}
> +
> #define DEFINE_INTERP_FUNC_PLANAR(name, nbits, depth)
> \
> static int interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void
> *arg, int jobnr, int nb_jobs) \
> {
> \
> int x, y;
> \
> const LUT3DContext *lut3d = ctx->priv;
> \
> +const Lut3DPreLut *prelut = >prelut;
> \
> const ThreadData *td = arg;
> \
> const AVFrame *in = td->in;
> \
> const AVFrame *out = td->out;
> \
> @@ -253,9 +291,11 @@ static int
> interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
> const uint8_t *srcbrow = in->data[1] + slice_start *
> in->linesize[1]; \
> const uint8_t *srcrrow = in->data[2] + slice_start *
> in->linesize[2]; \
> const uint8_t *srcarow = in->data[3] + slice_start *
> in->linesize[3]; \
> -const float scale_r = (lut3d->scale.r / ((1< (lut3d->lutsize - 1); \
> -const float scale_g = (lut3d->scale.g / ((1< (lut3d->lutsize - 1); \
> -const float scale_b = (lut3d->scale.b / ((1< (lut3d->lutsize - 1); \
> +const float lut_max = lut3d->lutsize - 1;
> \
> +const float scale_f = 1.0f / ((1< \
> +const float scale_r = lut3d->scale.r * lut_max;
> \
> +const float scale_g = lut3d->scale.g * lut_max;
> \
> +const float scale_b = lut3d->scale.b * lut_max;
> \
>
> \
> for (y = slice_start; y < slice_end; y++) {
> \
> uint##nbits##_t *dstg = (uint##nbits##_t *)grow;
> \
> @@ -267,9 +307,13 @@ static int
> interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
> const uint##nbits##_t *srcr = (const uint##nbits##_t *)srcrrow;
> \
> const uint##nbits##_t *srca = (const uint##nbits##_t *)srcarow;
> \
> for (x = 0; x < in->width; x++) {
> \
> -const struct rgbvec scaled_rgb = {srcr[x] * scale_r,
> \
> - srcg[x] * scale_g,
> \
> - srcb[x] * scale_b};
> \
> +
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: update text requesting samples
On Sun, 10. May 15:01, Andriy Gelman wrote:
> From: Andriy Gelman
>
> Signed-off-by: Andriy Gelman
> ---
>
> Same as commit d1e52e396b8aa778bd8d12bf25864beca0937d0a
>
> doc/developer.texi | 2 +-
> fftools/cmdutils.c | 2 +-
> fftools/ffmpeg.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 51e7299b1d..b33cab0fc7 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -625,7 +625,7 @@ If the patch fixes a bug, did you provide a verbose
> analysis of the bug?
> If the patch fixes a bug, did you provide enough information, including
> a sample, so the bug can be reproduced and the fix can be verified?
> Note please do not attach samples >100k to mails but rather provide a
> -URL, you can upload to ftp://upload.ffmpeg.org.
> +URL, you can upload to @url{https://streams.videolan.org/upload/}.
>
> @item
> Did you provide a verbose summary about what the patch does change?
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 7f5a5ca664..072589e358 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2217,7 +2217,7 @@ double get_rotation(AVStream *st)
> if (fabs(theta - 90*round(theta/90)) > 2)
> av_log(NULL, AV_LOG_WARNING, "Odd rotation angle.\n"
> "If you want to help, upload a sample "
> - "of this file to ftp://upload.ffmpeg.org/incoming/ "
> + "of this file to https://streams.videolan.org/upload/ "
> "and contact the ffmpeg-devel mailing list.
> (ffmpeg-devel@ffmpeg.org)");
>
> return theta;
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index f697460a30..c86b413f73 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2370,7 +2370,7 @@ static int decode_video(InputStream *ist, AVPacket
> *pkt, int *got_output, int64_
> av_log(ist->dec_ctx, AV_LOG_WARNING,
> "video_delay is larger in decoder than demuxer %d > %d.\n"
> "If you want to help, upload a sample "
> - "of this file to ftp://upload.ffmpeg.org/incoming/ "
> + "of this file to https://streams.videolan.org/upload/ "
> "and contact the ffmpeg-devel mailing list.
> (ffmpeg-devel@ffmpeg.org)\n",
> ist->dec_ctx->has_b_frames,
> ist->st->codecpar->video_delay);
ping
--
Andriy
___
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] avutil/attributes: Fix too many warning: false is not defined [-Wundef]
On Fri, May 29, 2020 at 11:46 PM Carl Eugen Hoyos wrote: > > > > > > Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com: > > > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > try to avoid floods of warning message for my testing linux host. If you > > have better way, fix it anyway. > > > > Below is my Linux system information and gcc version: > > > > [lmwang@vpn2 ffmpeg.git]$ gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > > Target: x86_64-redhat-linux > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > > --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > > --enable-bootstrap --enable-shared --enable-threads=posix > > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > > --disable-libunwind-exceptions --enable-gnu-unique-object > > --enable-linker-build-id --with-linker-hash-style=gnu > > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto > > --enable-plugin --enable-initfini-array --disable-libgcj > > --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install > > > > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install > > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 > > --build=x86_64-redhat-linux > > Thread model: posix > > gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > > [lmwang@vpn2 ffmpeg.git]$ cat /etc/centos-release > > CentOS Linux release 7.4.1708 (Core) > > > > libavutil/attributes.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > > index ab2a1fd..5cb9fe3 100644 > > --- a/libavutil/attributes.h > > +++ b/libavutil/attributes.h > > @@ -37,7 +37,7 @@ > > #ifdef __has_builtin > > #define AV_HAS_BUILTIN(x) __has_builtin(x) > > #else > > -#define AV_HAS_BUILTIN(x) false > > +#define AV_HAS_BUILTIN(x) 0 > > #endif > > Please move the define to an internal header. > > This has to be detected in configure, I just have to find time to implement > this. > Your request is not related to a fix for these warnings. The original patch is fine as-is, any further changes can and should be done seperately, if there is a consensus to do them. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hq_hqa: Check info size
On Sat, May 30, 2020 at 2:01 AM Michael Niedermayer
wrote:
>
> Fixes: assertion failure
> Fixes:
> 21079/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5737046523248640
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hq_hqa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
> index eec2e980b3..8404e80ec8 100644
> --- a/libavcodec/hq_hqa.c
> +++ b/libavcodec/hq_hqa.c
> @@ -321,7 +321,7 @@ static int hq_hqa_decode_frame(AVCodecContext *avctx,
> void *data,
> int info_size;
> bytestream2_skip(>gbc, 4);
> info_size = bytestream2_get_le32(>gbc);
> -if (bytestream2_get_bytes_left(>gbc) < info_size) {
> +if (info_size < 0 || bytestream2_get_bytes_left(>gbc) <
> info_size) {
> av_log(avctx, AV_LOG_ERROR, "Invalid INFO size (%d).\n",
> info_size);
> return AVERROR_INVALIDDATA;
> }
> --
bytestream2_get_le32 returns an unsigned type, wouldn't it be better
to make info_size unsigned and avoid the type cast and signed overflow
that results in this check failing?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 1/1] avformat: add kvag muxer
On Fri, 29 May 2020 23:41:46 +0200 "Michael Niedermayer" wrote: > > On Fri, May 29, 2020 at 10:54:59AM +, Zane van Iperen wrote: > > Signed-off-by: Zane van Iperen > > --- > > Changelog| 1 + > > libavformat/Makefile | 1 + > > libavformat/allformats.c | 1 + > > libavformat/kvag.c | 82 > > +++- libavformat/version.h| > > 2 +- 5 files changed, 85 insertions(+), 2 deletions(-) > > should the muxer not be in its own file ? > that would avoid #if* > Normally, I'd agree. However, it's a very simple format and there's not actually that much code, so I think separate files is overkill for this. Zane ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/hq_hqa: Check info size
Fixes: assertion failure
Fixes:
21079/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5737046523248640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hq_hqa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
index eec2e980b3..8404e80ec8 100644
--- a/libavcodec/hq_hqa.c
+++ b/libavcodec/hq_hqa.c
@@ -321,7 +321,7 @@ static int hq_hqa_decode_frame(AVCodecContext *avctx, void
*data,
int info_size;
bytestream2_skip(>gbc, 4);
info_size = bytestream2_get_le32(>gbc);
-if (bytestream2_get_bytes_left(>gbc) < info_size) {
+if (info_size < 0 || bytestream2_get_bytes_left(>gbc) <
info_size) {
av_log(avctx, AV_LOG_ERROR, "Invalid INFO size (%d).\n",
info_size);
return AVERROR_INVALIDDATA;
}
--
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] avutil/attributes: Fix too many warning: false is not defined [-Wundef]
On Fri, May 29, 2020 at 11:46:05PM +0200, Carl Eugen Hoyos wrote: > > > > > Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com: > > > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > try to avoid floods of warning message for my testing linux host. If you > > have better way, fix it anyway. > > > > Below is my Linux system information and gcc version: > > > > [lmwang@vpn2 ffmpeg.git]$ gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > > Target: x86_64-redhat-linux > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > > --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > > --enable-bootstrap --enable-shared --enable-threads=posix > > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > > --disable-libunwind-exceptions --enable-gnu-unique-object > > --enable-linker-build-id --with-linker-hash-style=gnu > > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto > > --enable-plugin --enable-initfini-array --disable-libgcj > > --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install > > > > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install > > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 > > --build=x86_64-redhat-linux > > Thread model: posix > > gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > > [lmwang@vpn2 ffmpeg.git]$ cat /etc/centos-release > > CentOS Linux release 7.4.1708 (Core) > > > > libavutil/attributes.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > > index ab2a1fd..5cb9fe3 100644 > > --- a/libavutil/attributes.h > > +++ b/libavutil/attributes.h > > @@ -37,7 +37,7 @@ > > #ifdef __has_builtin > > #define AV_HAS_BUILTIN(x) __has_builtin(x) > > #else > > -#define AV_HAS_BUILTIN(x) false > > +#define AV_HAS_BUILTIN(x) 0 > > #endif > > Please move the define to an internal header. I'm not clear about the macro usage, so I prefer to fix the warning first. > > This has to be detected in configure, I just have to find time to implement > this. > > Thank you, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- 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 v5] avcodec/mpeg12enc: support mpeg2 encoder const profile
On Fri, May 29, 2020 at 09:07:52PM +0200, Marton Balint wrote:
>
>
> On Fri, 29 May 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/mpeg12enc.c | 2 ++
> > libavcodec/profiles.h | 6 ++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> > index cab7076..9fbbcef 100644
> > --- a/libavcodec/mpeg12enc.c
> > +++ b/libavcodec/mpeg12enc.c
> > @@ -41,6 +41,7 @@
> > #include "mpeg12data.h"
> > #include "mpegutils.h"
> > #include "mpegvideo.h"
> > +#include "profiles.h"
> >
> > static const uint8_t svcd_scan_offset_placeholder[] = {
> > 0x10, 0x0E, 0x00, 0x80, 0x81, 0x00, 0x80,
> > @@ -1167,6 +1168,7 @@ static const AVOption mpeg2_options[] = {
> > { "mac", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> > VIDEO_FORMAT_MAC}, 0, 0, VE, "video_format" },
> > { "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> > VIDEO_FORMAT_UNSPECIFIED}, 0, 0, VE, "video_format" },
> > FF_MPV_COMMON_OPTS
> > +FF_MPEG2_PROFILE_OPTS
> > { NULL },
> > };
> >
> > diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> > index e414ea7..d6a139e 100644
> > --- a/libavcodec/profiles.h
> > +++ b/libavcodec/profiles.h
> > @@ -43,6 +43,12 @@
> > FF_AVCTX_PROFILE_OPTION("mpeg4_main",NULL, VIDEO,
> > FF_PROFILE_MPEG4_MAIN)\
> > FF_AVCTX_PROFILE_OPTION("mpeg4_asp", NULL, VIDEO,
> > FF_PROFILE_MPEG4_ADVANCED_SIMPLE)\
> >
> > +#define FF_MPEG2_PROFILE_OPTS \
> > +FF_AVCTX_PROFILE_OPTION("mpeg2_422", NULL, VIDEO,
> > FF_PROFILE_MPEG2_422)\
> > +FF_AVCTX_PROFILE_OPTION("mpeg2_high",NULL, VIDEO,
> > FF_PROFILE_MPEG2_HIGH)\
> > +FF_AVCTX_PROFILE_OPTION("mpeg2_main",NULL, VIDEO,
> > FF_PROFILE_MPEG2_MAIN)\
> > +FF_AVCTX_PROFILE_OPTION("mpeg2_simple", NULL, VIDEO,
> > FF_PROFILE_MPEG2_SIMPLE)\
>
> You no longer need the mpeg2 prefix. Also please add the supported profiles
That's great to hear, why the mpeg4 and aac has the prefix, it's misleading.
So I understand in the cli, it's not necessary to use the mpeg2 prefix anymore?
> to the documentation of the mpeg2 encoder. There are also some profiles
OK, I'll update the document, I haven't see other native mpeg4, aac document
for the profile, even encoder, so I haven't update it.
> (spatially scalable and snr scalable) missing. Is it intentional?
Yes, I haven't used them yet, I'm not sure it's supported by the native encoder.
>
> Thanks,
> Marton
>
> > +
> > extern const AVProfile ff_aac_profiles[];
> > extern const AVProfile ff_dca_profiles[];
> > extern const AVProfile ff_dnxhd_profiles[];
> > --
> > 1.8.3.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
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] avcodec/snow: ensure current_picture is writable before modifying its data
On 5/29/2020 7:38 PM, Michael Niedermayer wrote: > On Fri, May 29, 2020 at 07:00:12PM -0300, James Almer wrote: >> On 5/29/2020 5:37 PM, Michael Niedermayer wrote: >>> On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote: current_picture was not writable here because a reference existed in at least avctx->coded_frame, and potentially elsewhere if the caller created new ones from it. >>> >>> Please elaborate when and how the encoder internal buffer becomes >>> read only >>> i simply took your code and replaced >>> >>> -ret = av_frame_make_writable(s->current_picture); >>> -if (ret < 0) >>> -return ret; >>> +ret = av_frame_is_writable(s->current_picture); >>> +if (ret <= 0) >>> +return -1; >>> >>> and fate is fully happy which tests both the encoder and the filters >>> using it >>> also if this is for coded_frame then shouldnt it be under >>> FF_API_CODED_FRAME? >>> iam clearly missing something here >> >> You need to also move the av_frame_unref(avctx->coded_frame) line back to >> where it was before my patch. I moved it before this check to ensure at >> least the reference stored there is freed before current_picture is written >> to, > > i quite intentionally did not move that, my question was just about > "why av_frame_make_writable" after all the other changes > > >> but there of course could still exist other references created by the >> user, and that's what this make_writable() call is for. > > ok, understand this. I guess my gut feeling was that creating references > to coded_frame was not allowed. but i guess there is nothing that forbids > it so teh API allowes it, and the av_frame_make_writable is ok > > >> >> And since this specific chunk is not strictly coded_frame related, it >> doesn't need to be under that guard. > > but coded_frame is the only current way by which a user can create a > reference, unless iam missing something > Am i guessing correctly that you intend to add another way to export > the frame or is there something iam missing ? No, i expected you'd change this and find a way to get this functionality in lavfi, since it's your code and the only non standard coded_frame usage that's blocking its removal. I mentioned you as much last major bump when we postponed the removal of coded_frame. As i mentioned before, an encoder should not work as some sort of interface to access lavc image processing features. Lavfi should either use some lavc API, or feature its own implementation of this functionality that's currently done here. This patch is only to remove the current wrong behavior or writing on potentially non writable frames, for the purpose of backporting to existing branches (and so it's also present in 4.3). It should not matter after the major bump. > because without some other method this make_writable doesnt make sense > without coded_frame and should be removed in case coded_frame is removed Alright, i'll wrap it with the FF_API_ check before pushing. > > 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] Don't adjust start time for MP3 files; packets are not adjusted.
On Thu, May 28, 2020 at 1:33 PM Michael Niedermayer
wrote:
> I dont really have an oppinion about start_time, its more the change in
> timestamps & duratiion on the output side which is whats user vissible
> and that looked worse for the testcase
>
The difference is due to the decode stage applying the skip samples to pts:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/decode.c#L421
That makes my statement in the commit "skip_samples are applied by deleting
data from a packet without changing the timestamp" incorrect - sorry for
getting that wrong. Since we use decoders other than ffmpeg, Chromium's
implementation deletes skip samples indicated by the side data without
changing the packet timestamps so audio and video line up properly. ffmpeg
seems to do the same thing but in a more roundabout fashion that I don't
fully understand.
Prior to my patch, avformat_find_stream_info() indicated a non-zero start
time, av_read_frame() returned packets from time zero, but with skip
samples marked as side data. Later avcodec_receive_frame() adjusts the pts,
dts, and duration. Finally some other piece of code is adjusting the pts by
the start time before it reaches the framecrc muxer. I haven't been able to
figure out where that happens though.
I'm not sure what the right fix is here. As an API user, we've always
expected start_time to refer to the pts of the first packet returned by
av_read_frame(). Indeed avformat.h says "pts of the first frame of the
stream in presentation order". If that's not the case, then it'd be helpful
to have some guidance on how seeking works (e.g., even ffmpeg.c seeks to
start_time, but that skips the preroll if it's non-zero) and what should be
done with frames before the start time.
I'm less sure about this last point, but adjusting the pts during the
decode stage seems incompatible with how edit lists are applied for mp4
during the demuxing stage. E.g., IIUC, if an edit list slices out the time
range [0,6] across two keyframe packets p0={pts=0, dur=5} and p1={pts=5,
dur=5} the mov demuxer would discard p0 and p1 would be become {pts=7,
dur=5, skip_samples=2}.
In any case, it seems incorrect that ffmpeg no longer has a timestamp of
zero for the first decoded mp3 frame when skip samples are present. So at
the very least that does seem to need a fix. Either by reverting this patch
or another mechanism.
- dale
___
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] [WIP][RFC] [PATCH] FLIF16 Decoder
Just to clarify, the raangecoded bitstream is decoded in function flif16_read_second_header in libavcodec/flif16dec.c. Here the aforementioned switch statement - segment variable system is used. Regards, Anamitra ___ 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/snow: ensure current_picture is writable before modifying its data
On Fri, May 29, 2020 at 07:00:12PM -0300, James Almer wrote: > On 5/29/2020 5:37 PM, Michael Niedermayer wrote: > > On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote: > > > current_picture was not writable here because a reference existed in > > > at least avctx->coded_frame, and potentially elsewhere if the caller > > > created new ones from it. > > > > Please elaborate when and how the encoder internal buffer becomes > > read only > > i simply took your code and replaced > > > > -ret = av_frame_make_writable(s->current_picture); > > -if (ret < 0) > > -return ret; > > +ret = av_frame_is_writable(s->current_picture); > > +if (ret <= 0) > > +return -1; > > > > and fate is fully happy which tests both the encoder and the filters > > using it > > also if this is for coded_frame then shouldnt it be under > > FF_API_CODED_FRAME? > > iam clearly missing something here > > You need to also move the av_frame_unref(avctx->coded_frame) line back to > where it was before my patch. I moved it before this check to ensure at > least the reference stored there is freed before current_picture is written > to, i quite intentionally did not move that, my question was just about "why av_frame_make_writable" after all the other changes > but there of course could still exist other references created by the > user, and that's what this make_writable() call is for. ok, understand this. I guess my gut feeling was that creating references to coded_frame was not allowed. but i guess there is nothing that forbids it so teh API allowes it, and the av_frame_make_writable is ok > > And since this specific chunk is not strictly coded_frame related, it > doesn't need to be under that guard. but coded_frame is the only current way by which a user can create a reference, unless iam missing something Am i guessing correctly that you intend to add another way to export the frame or is there something iam missing ? because without some other method this make_writable doesnt make sense without coded_frame and should be removed in case coded_frame is removed thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable 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] x86: cabac: Disable the inline asm on clang on windows on i386
On Fri, 29 May 2020, Carl Eugen Hoyos wrote: Am 28.05.2020 um 12:37 schrieb Martin Storsjö : Any further comments on this patch? Please wait a few days more, I am not happy about the patch and at least I’d like to understand better why this is a good and why there is no alternative. Fair enough, take your time. A different alternative would maybe be to just disable HAVE_7REGS for this configuration, that would leave a couple more inline functions that might work. (I haven't tested that configuration to see if it fails as easily.) // 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] x86: cabac: Disable the inline asm on clang on windows on i386
> Am 28.05.2020 um 12:37 schrieb Martin Storsjö : > >> On Mon, 25 May 2020, Martin Storsjö wrote: >> >>> On Sun, 24 May 2020, Carl Eugen Hoyos wrote: >>> >>> Am So., 24. Mai 2020 um 21:53 Uhr schrieb Martin Storsjö >> : >>> configure --enable-gpl --arch=i686 --cc=clang-cl --ld=lld-link --target-os=win32 --toolchain=msvc --enable-cross-compile --ar=llvm-ar --nm=llvm-nm --disable-stripping --extra-cflags=-m32 >>> >>> Why are you cross-compiling? >>> On which system are you testing this? >> >> Because I normally only ever cross compile for windows. >> >> There seems to be a subtle difference in this case, between using clang-cl >> and "clang -target i686-win32-msvc"; clang-cl passes "-mdisable-fp-elim" to >> the compiler internals, while "clang -target i686-win32-msvc" doesn't. >> >> And cross compiling does seem to affect this particular case; there's a >> check for whether ebp is available, which requires running the built >> executable. When cross compiling, it's assumed the built executable is ok >> and it isn't test run. >> >> So with clang-cl running on windows, you'll end up with "#define >> HAVE_EBP_AVAILABLE 0" in config.h, and the x86 cabac code won't end up used >> at all - i.e. this patch wouldn't make any difference. >> >> With clang-cl in cross compilation, and other invocations of "clang" instead >> of "clang-cl", targeting i686 windows, you'll end up with ebp_available >> enabled. >> >> For a case where it does make a difference, in the same setup, try >> configuring this way instead: >> >> --cc='clang -target i686-win32-msvc' --ld=lld-link >> --extra-ldflags='msvcrt.lib oldnames.lib' --toolchain=msvc >> >> In this case, the ebp_available test will succeed, it will proceed to trying >> to build the x86 inline cabac code, which fails. > > Any further comments on this patch? Please wait a few days more, I am not happy about the patch and at least I’d like to understand better why this is a good and why there is no alternative. 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] avcodec/snow: ensure current_picture is writable before modifying its data
On 5/29/2020 5:37 PM, Michael Niedermayer wrote: On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote: current_picture was not writable here because a reference existed in at least avctx->coded_frame, and potentially elsewhere if the caller created new ones from it. Please elaborate when and how the encoder internal buffer becomes read only i simply took your code and replaced -ret = av_frame_make_writable(s->current_picture); -if (ret < 0) -return ret; +ret = av_frame_is_writable(s->current_picture); +if (ret <= 0) +return -1; and fate is fully happy which tests both the encoder and the filters using it also if this is for coded_frame then shouldnt it be under FF_API_CODED_FRAME? iam clearly missing something here You need to also move the av_frame_unref(avctx->coded_frame) line back to where it was before my patch. I moved it before this check to ensure at least the reference stored there is freed before current_picture is written to, but there of course could still exist other references created by the user, and that's what this make_writable() call is for. And since this specific chunk is not strictly coded_frame related, it doesn't need to be under that guard. 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: add clean aperture (CLAP) side data.
On Mon, May 11, 2020 at 9:37 PM Neil Birkbeck
wrote:
>
>
> On Wed, May 6, 2020 at 8:45 AM James Almer wrote:
>
>> On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
>> > On Tue, May 5, 2020 at 5:11 AM Kieran O Leary > >
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I broke the threading with my last reply, i apologise. Here goes
>> another
>> >> attempt:
>> >>
>> >> On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck > >
>> >> wrote:
>> >>
>> >>> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George
>> wrote:
>> >>>
>> Andreas Rheinhardt (12020-04-28):
>> > That's expected. The patch provided only provides the structure in
>> >>> which
>> > the values are intended to be exported; it does not add any demuxing
>> >> or
>> > muxing capabilities for mov or mkv (as you can see from the fact
>> that
>> > none of these (de)muxers have been changed in the patch).
>>
>> Which is something I intended to comment on: adding code without
>> users
>> is rarely a good idea. I suggest we do not commit until at least one
>> demuxer use it, preferably at least two. Otherwise, we may realize
>> that
>> “oh crap, it doesn't work” because of a tiny unforeseen detail.
>> >>>
>> >>>
>> >>> Thanks for the feedback. I also have patches for the demux (MOV/MKV)
>> and
>> >>> mux (MOV/MKV).
>> >>>
>> >>> As there is still the alternative of using the fields in the
>> >>> AVCodecParameters/AVCodecContext, my intention was to keep the first
>> >> patch
>> >>> small to resolve discussion on that point.
>> >>>
>> >>> I've included the patches, if you'd like to try test it, Kieren. I
>> see on
>> >>> your test file that there may be some slight rounding error making
>> output
>> >>> crop 704 not 703 (MKV file ends up with pixel_crop_{left,right} = 8).
>> >>>
>> >>> /ffprobe ../testdata/clap.mov 2>&1 | grep -A1 "Side"
>> >>> Side data:
>> >>> Clean aperture:[width 41472/59 height:576/1 h_offset:0/1
>> >>> v_offset:0/1]
>> >>> ./ffmpeg -i ../testdata/clap.mov -vcodec copy -acodec copy
>> /tmp/clap.mkv
>> >>> ./ffprobe /tmp/clap.mkv 2>&1 | grep -A1 "Side"
>> >>> Side data:
>> >>> Clean aperture:[width 704/1 height:576/1 h_offset:0/1
>> v_offset:0/1]
>> >>>
>> >>
>> >> I have to look deeper into the MKV side of things and most likely
>> raise it
>> >> with the cellar mailing list so that better minds than mine can weigh
>> in. I
>> >> do see that the rounding up to 704 could be an issue alright.
>> >> As for MOV, your patch appears to generate the same output clap values
>> as
>> >> the input, so that's really great! command line and mediainfo trace
>> below:
>> >>
>> >
>> > Thanks for testing, Kieran and for linking the discussion on the cellar
>> > list.
>> >
>> > Any additional thoughts from ffmpeg devs on container-level SideData vs
>> > adding the extra fields into AVCodecParameters/AVCodecContext and
>> plumbing
>> > into the frame instead? I anticipate some situations where there can be
>> > interaction between cropping in bitstream and container-level cropping.
>> > Maybe the best way forward is for me to share some sample patches for
>> the
>> > alternative to validate whether it supports the various use cases
>> > (transmux, decode+crop, any other application level handling), and to
>> > confirm the interface changes for the structs.
>>
>> One option could be to also introduce a frame side data for this new
>> struct and have it replace the AVFrame fields, which would then be
>> deprecated (But of course keep working until removed).
>> This would allow to either inject stream side data from clap atoms and
>> Matroska crop fields into packets (Which would then be propagated to
>> frames to be applied during decoding), or use and export the bitstream
>> cropping information as it's the case right now, all while preventing
>> the addition of new fields to AVCodecParameters.
>>
>>
> I agree that sharing the SideData with the frame could be nice for the
> above reasons. I guess any interaction or conflict between bitstream &
> container cropping could then get resolved at the decoder (e.g., assuming
> that say SPS from h264 and container-level cropping should be composed).
>
>
>> I would like a developer that makes use of this feature to also comment,
>> especially seeing how the AVFrame fields and this clap side data are
>> pretty different.
>>
>
> The current CleanAperture representation was in part motivated to 1) keep
> the representation capable of representing the CLAP atom (same
> representation and rationals), and 2) to make it unambiguous that this was
> container-level stream metadata. The representation is a tiny bit more
> tedious when trying to actually perform a crop (e.g., to extract the
> top-left corner offset). If sharing as AVFrame side data, a representation
> closer to AVFrame's crop_{top,bottom,left,right} may be more natural.
>
> Within ffmpeg, I see that the existing codecs using AVFrame cropping
> include:
> -libavcodec/h264_slice.c: propagating the crop_fields from the
Re: [FFmpeg-devel] [PATCH] avutil/attributes: Fix too many warning: false is not defined [-Wundef]
> Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com: > > From: Limin Wang > > Signed-off-by: Limin Wang > --- > try to avoid floods of warning message for my testing linux host. If you > have better way, fix it anyway. > > Below is my Linux system information and gcc version: > > [lmwang@vpn2 ffmpeg.git]$ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > --enable-bootstrap --enable-shared --enable-threads=posix > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-linker-build-id --with-linker-hash-style=gnu > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin > --enable-initfini-array --disable-libgcj > --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install > > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > [lmwang@vpn2 ffmpeg.git]$ cat /etc/centos-release > CentOS Linux release 7.4.1708 (Core) > > libavutil/attributes.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > index ab2a1fd..5cb9fe3 100644 > --- a/libavutil/attributes.h > +++ b/libavutil/attributes.h > @@ -37,7 +37,7 @@ > #ifdef __has_builtin > #define AV_HAS_BUILTIN(x) __has_builtin(x) > #else > -#define AV_HAS_BUILTIN(x) false > +#define AV_HAS_BUILTIN(x) 0 > #endif Please move the define to an internal header. This has to be detected in configure, I just have to find time to implement this. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 1/1] avformat: add kvag muxer
On Fri, May 29, 2020 at 10:54:59AM +, Zane van Iperen wrote: > Signed-off-by: Zane van Iperen > --- > Changelog| 1 + > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/kvag.c | 82 +++- > libavformat/version.h| 2 +- > 5 files changed, 85 insertions(+), 2 deletions(-) should the muxer not be in its own file ? that would avoid #if* thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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] [WIP][RFC] [PATCH] FLIF16 Decoder
Hello, This is a partial implementation of the decoder of the FLIF16 image format [1]. A large amount of this code has been adapted from the reference implementation of the FLIF16 (de)coder, written in C++ [2]. The main reason I am posting this patch is to get comments on the method the rangecoder used in FLIF is written. Since this format has no way to predetermine the size of the rangecoded bitstream, we have to deal with arbitrary packet sizes in the decoder. This means that the rangecoder's renormalisation loop has to be written in such a manner that the moment we run out of bytes in the AVPacket, the decoder is able to exit, and is able to start back at the same state it was in, in the next call of the decode function. There are higher order functions for reading integer types from the bitstream (uni_int, nz_int etc.[3]), that depend on the "get" function of the rangecoder, which adds another layer of complexity. Plus there are conditional statements dependent on the encoded values. I ultimately decided on a switch statement and a segment variable that will be incremented to go to the next segment in the bitstream, with the whole switch statement being in an infinite loop. The last switch case or segment jumps out of this loop. All state variables are kept in the decoder and rangecoder contexts. This whole solution however looks quite cumbersome. Is there a better way to do this? Please look here [4] for the same functions if they were written in the "normal" manner, i.e. if packet size is non-arbitrary. Please ignore the following files and functions in the code: * flif16_transform.(c|h): These files are being handled by Kartik K. Khullar , and are not ready yet. * ff_flif16_rac_read_nz_int, ff_flif16_rac_read_gnz_int: These functions are still being written from the old to the new format. * There are several printf statements in the code and are meant solely for debugging. These will be removed later. (An entry in libavformat needs to be made in the future, but for now the entry is in img2.c which works but is incorrect) Regards, Anamitra [1]: https://flif.info/spec.html [2]: https://github.com/FLIF-hub/FLIF [3]: https://flif.info/spec.html#_uniform_symbol_coding [4]: https://github.com/daujerrine/ffmpeg/blob/master/libavcodec/flif16_rangecoder.h Signed-off-by: Anamitra Ghorui --- Changelog | 1 + configure | 2 + libavcodec/Makefile| 6 + libavcodec/allcodecs.c | 2 + libavcodec/avcodec.h | 1 + libavcodec/codec_desc.c| 7 + libavcodec/flif16.h| 37 +++ libavcodec/flif16_parser.c | 189 libavcodec/flif16_rangecoder.c | 134 +++ libavcodec/flif16_rangecoder.h | 395 + libavcodec/flif16_transform.c | 247 + libavcodec/flif16_transform.h | 60 + libavcodec/flif16dec.c | 372 +++ libavcodec/flif16enc.c | 25 +++ libavcodec/parsers.c | 1 + libavformat/img2.c | 1 + 16 files changed, 1480 insertions(+) create mode 100644 libavcodec/flif16.h create mode 100644 libavcodec/flif16_parser.c create mode 100644 libavcodec/flif16_rangecoder.c create mode 100644 libavcodec/flif16_rangecoder.h create mode 100644 libavcodec/flif16_transform.c create mode 100644 libavcodec/flif16_transform.h create mode 100644 libavcodec/flif16dec.c create mode 100644 libavcodec/flif16enc.c diff --git a/Changelog b/Changelog index cb310a3abc..4f88dbaadb 100644 --- a/Changelog +++ b/Changelog @@ -43,6 +43,7 @@ version : - Rayman 2 ADPCM decoder - Rayman 2 APM demuxer - cas video filter +- FLIF16 decoder version 4.2: diff --git a/configure b/configure index 06e3a7b2a8..872ee750e0 100755 --- a/configure +++ b/configure @@ -2709,6 +2709,8 @@ ffvhuff_encoder_select="huffyuv_encoder" fic_decoder_select="golomb" flac_decoder_select="flacdsp" flac_encoder_select="bswapdsp flacdsp lpc" +flif16_decoder_select="flif16dec" +flif16_encoder_select="flif16enc" flashsv2_decoder_deps="zlib" flashsv2_encoder_deps="zlib" flashsv_decoder_deps="zlib" diff --git a/libavcodec/Makefile b/libavcodec/Makefile index f1c032b456..2b86341a75 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -76,6 +76,7 @@ OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o OBJS-$(CONFIG_FAANDCT) += faandct.o OBJS-$(CONFIG_FAANIDCT)+= faanidct.o OBJS-$(CONFIG_FDCTDSP) += fdctdsp.o jfdctfst.o jfdctint.o +OBJS-$(CONFIG_FLIF16_RANGECODER) += flif16_rangecoder.o FFT-OBJS-$(CONFIG_HARDCODED_TABLES)+= cos_tables.o cos_fixed_tables.o OBJS-$(CONFIG_FFT) += avfft.o fft_fixed.o fft_float.o \ fft_fixed_32.o fft_init_table.o \ @@ -314,11 +315,15 @@ OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o fits.o OBJS-$(CONFIG_FITS_ENCODER)
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parser: Fix undefined left shift
On Fri, May 29, 2020 at 06:17:54PM +0200, Andreas Rheinhardt wrote: > Use an uint32_t for the NAL unit size of an AVC H.264 NAL unit instead > of an int as a left shift of a signed value is undefined behaviour > if the result doesn't fit into the target type. > > Also make the log message never output negative lengths. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/h264_parser.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) probably ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/snow: ensure current_picture is writable before modifying its data
On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote: > current_picture was not writable here because a reference existed in > at least avctx->coded_frame, and potentially elsewhere if the caller > created new ones from it. Please elaborate when and how the encoder internal buffer becomes read only i simply took your code and replaced -ret = av_frame_make_writable(s->current_picture); -if (ret < 0) -return ret; +ret = av_frame_is_writable(s->current_picture); +if (ret <= 0) +return -1; and fate is fully happy which tests both the encoder and the filters using it also if this is for coded_frame then shouldnt it be under FF_API_CODED_FRAME? iam clearly missing something here thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle 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] avutil/attributes: Fix too many warning: false is not defined [-Wundef]
On 5/29/2020 8:18 AM, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > try to avoid floods of warning message for my testing linux host. If you > have better way, fix it anyway. > > Below is my Linux system information and gcc version: > > [lmwang@vpn2 ffmpeg.git]$ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > --enable-bootstrap --enable-shared --enable-threads=posix > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-linker-build-id --with-linker-hash-style=gnu > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin > --enable-initfini-array --disable-libgcj > --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install > > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > [lmwang@vpn2 ffmpeg.git]$ cat /etc/centos-release > CentOS Linux release 7.4.1708 (Core) > > libavutil/attributes.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > index ab2a1fd..5cb9fe3 100644 > --- a/libavutil/attributes.h > +++ b/libavutil/attributes.h > @@ -37,7 +37,7 @@ > #ifdef __has_builtin > #define AV_HAS_BUILTIN(x) __has_builtin(x) > #else > -#define AV_HAS_BUILTIN(x) false > +#define AV_HAS_BUILTIN(x) 0 > #endif > > #ifndef av_always_inline LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5] avcodec/mpeg12enc: support mpeg2 encoder const profile
On Fri, 29 May 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpeg12enc.c | 2 ++
libavcodec/profiles.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index cab7076..9fbbcef 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -41,6 +41,7 @@
#include "mpeg12data.h"
#include "mpegutils.h"
#include "mpegvideo.h"
+#include "profiles.h"
static const uint8_t svcd_scan_offset_placeholder[] = {
0x10, 0x0E, 0x00, 0x80, 0x81, 0x00, 0x80,
@@ -1167,6 +1168,7 @@ static const AVOption mpeg2_options[] = {
{ "mac", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VIDEO_FORMAT_MAC},
0, 0, VE, "video_format" },
{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VIDEO_FORMAT_UNSPECIFIED},
0, 0, VE, "video_format" },
FF_MPV_COMMON_OPTS
+FF_MPEG2_PROFILE_OPTS
{ NULL },
};
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index e414ea7..d6a139e 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -43,6 +43,12 @@
FF_AVCTX_PROFILE_OPTION("mpeg4_main",NULL, VIDEO,
FF_PROFILE_MPEG4_MAIN)\
FF_AVCTX_PROFILE_OPTION("mpeg4_asp", NULL, VIDEO,
FF_PROFILE_MPEG4_ADVANCED_SIMPLE)\
+#define FF_MPEG2_PROFILE_OPTS \
+FF_AVCTX_PROFILE_OPTION("mpeg2_422", NULL, VIDEO,
FF_PROFILE_MPEG2_422)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_high",NULL, VIDEO,
FF_PROFILE_MPEG2_HIGH)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_main",NULL, VIDEO,
FF_PROFILE_MPEG2_MAIN)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_simple", NULL, VIDEO,
FF_PROFILE_MPEG2_SIMPLE)\
You no longer need the mpeg2 prefix. Also please add the supported
profiles to the documentation of the mpeg2 encoder. There are also some
profiles (spatially scalable and snr scalable) missing. Is it intentional?
Thanks,
Marton
+
extern const AVProfile ff_aac_profiles[];
extern const AVProfile ff_dca_profiles[];
extern const AVProfile ff_dnxhd_profiles[];
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Don't update start time when lastpts is AV_NOPTS_VALUE.
Signed-off-by: Dale Curtis --- libavformat/oggparsetheora.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) no_start_time_update_v0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/jpeg2000_parser: Add jpeg2000 parser
On Fri, May 29, 2020 at 11:23:20PM +0530, Gautam Ramakrishnan wrote: > On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer > wrote: > > > > On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote: > > > From: Gautam Ramakrishnan > > > > > > I have attempted to write a JPEG2000 Parser. Have tested > > > by generating a file containing 14 frames, as mentioned > > > by Micheal. Have also tried testing with various packet > > > sizes by setting -frame_size option. Need feedback on the > > > code and on further testing. > > > --- > > > libavcodec/Makefile | 1 + > > > libavcodec/jpeg2000_parser.c | 190 +++ > > > libavcodec/parsers.c | 1 + > > > 3 files changed, 192 insertions(+) > > > create mode 100644 libavcodec/jpeg2000_parser.c > > > > can you add some test to fate for this ? > > (doesnt need to be related to the tests you did, but can of course) > > such a test would also make it easy for others to test the code on > > less common hardware like big endian ... > > This can also be very simple test if its not easy > Small doubt, so the jpeg2000 stream to be parsed goes in the > test-suite directory and the corresponding framecrc goes into the > test/ref directory? Is my understanding right? ideally the teststream is generated by our muxers / encoders, that way it doesnt need to be added to the fate suite and it also teste more code as a side effect thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. 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] [RFC PATCH] libavcodec/jpeg2000_parser: Add jpeg2000 parser
On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer wrote: > > On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote: > > From: Gautam Ramakrishnan > > > > I have attempted to write a JPEG2000 Parser. Have tested > > by generating a file containing 14 frames, as mentioned > > by Micheal. Have also tried testing with various packet > > sizes by setting -frame_size option. Need feedback on the > > code and on further testing. > > --- > > libavcodec/Makefile | 1 + > > libavcodec/jpeg2000_parser.c | 190 +++ > > libavcodec/parsers.c | 1 + > > 3 files changed, 192 insertions(+) > > create mode 100644 libavcodec/jpeg2000_parser.c > > can you add some test to fate for this ? > (doesnt need to be related to the tests you did, but can of course) > such a test would also make it easy for others to test the code on > less common hardware like big endian ... > This can also be very simple test if its not easy Small doubt, so the jpeg2000 stream to be parsed goes in the test-suite directory and the corresponding framecrc goes into the test/ref directory? Is my understanding right? > > > > > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > > index d0917a656f..1f7c91a91b 100644 > > --- a/libavcodec/Makefile > > +++ b/libavcodec/Makefile > > @@ -1073,6 +1073,7 @@ OBJS-$(CONFIG_H261_PARSER) += > > h261_parser.o > > OBJS-$(CONFIG_H263_PARSER) += h263_parser.o > > OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o > > h264data.o > > OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o > > +OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o > > OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o > > OBJS-$(CONFIG_MLP_PARSER) += mlp_parse.o mlp_parser.o mlp.o > > OBJS-$(CONFIG_MPEG4VIDEO_PARSER) += mpeg4video_parser.o h263.o \ > > diff --git a/libavcodec/jpeg2000_parser.c b/libavcodec/jpeg2000_parser.c > > new file mode 100644 > > index 00..c28b694219 > > > --- /dev/null > > +++ b/libavcodec/jpeg2000_parser.c > > @@ -0,0 +1,190 @@ > > +/* > > + * JPEG2000 parser > > > + * Copyright (c) 2000, 2001 Fabrice Bellard > > Thats ok if you used code from fabrice but you probably want to > add your name assuming you wrote the parser > > [...] > > thx > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The smallest minority on earth is the individual. Those who deny > individual rights cannot claim to be defenders of minorities. - Ayn Rand > ___ > 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". -- - 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".
[FFmpeg-devel] [PATCH] avcodec/decode: actually propagate AVHWAccel.alloc_frame() return value
Finishes fixing the regression introduced in
a1133db30ef07896afd96f067e5c51531a4e85ab
after the partial fix in b6d6597bef66531ec07c07a7125b88aee38fb220.
Signed-off-by: James Almer
---
libavcodec/decode.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index eed89a89a7..a4e50c0d03 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1911,10 +1911,12 @@ end:
frame->height = avctx->height;
}
-return 0;
fail:
-av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n");
-av_frame_unref(frame);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n");
+av_frame_unref(frame);
+}
+
return ret;
}
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] [oggparsetheora] Use av_sat_sub64() when updating pts by duration.
On Thu, May 14, 2020 at 03:31:49PM -0700, Dale Curtis wrote: > Signed-off-by: Dale Curtis > --- > libavformat/oggparsetheora.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] Use av_sat_add64() when updating start_time by skip_samples.
On Thu, May 14, 2020 at 03:31:47PM -0700, Dale Curtis wrote: > Avoids overflow from fuzzed skip_samples values. > > Signed-off-by: Dale Curtis > --- > libavformat/utils.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/adpcm_data: extend ff_adpcm_ima_cunning_index_table
On Fri, May 29, 2020 at 03:47:03AM +, Zane van Iperen wrote: > On Thu, 28 May 2020 18:44:55 +0200 > "Michael Niedermayer" wrote: > > > > > The index table should only ever be indexed between [0,7], so this > > > looks like a bug in adpcm_ima_cunning_expand_nibble() instead. > > > > maybe it should be only 0..7 but abs(-8 .. 7) needs a 8th entrty or a > > check > > > > > > > > > > Where would one go to see the inputs for this? I'd like to > > > investigate (and test against the original decoder). > > > > The file is from a fuzzer so is random trash and it needs > > target_dec_fuzzer.c to be read. It wont be read as "Pro Pinball > > Series Soundbank" so i think that file will not be useful to test the > > behavior of the original decoder as i would assume it will not accept > > the target_dec_fuzzer data but i surely can send it to you privatly > > if you need it. just say if you want me to send you the file > > > > No need, I've found an existing file that has the same problem. Out of > all the 453 files I have, only one of them triggers this. > > tl;dr: Change the 5 to -1. > > > ff_adpcm_ima_cunning_index_table[abs(nibble)] is wrong in the case > where nibble == -8. > > If you take the unsigned nibble, and apply f(): > f(x) = 16 - x if x > 8 else x & 0x7 > > you'll get the same value as abs() applied with the signed nibble, > except for this one case (abs(-8) == 8, f(8) == 0). > > > Instead of changing the abs(), a cleaner fix is to simply change the 5 > to -1. That should give the correct output. will apply with -1 thanks [...] -- 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".
[FFmpeg-devel] [PATCH] avcodec/snow: ensure current_picture is writable before modifying its data
current_picture was not writable here because a reference existed in
at least avctx->coded_frame, and potentially elsewhere if the caller
created new ones from it.
Signed-off-by: James Almer
---
For that matter, there are two filters that depend on whatever
s->mpvencdsp.draw_edges is doing on this buffer, accessing it through
avctx->coded_frame after passing their input to this encoder.
This is very hacky and the main blocker to remove coded_frame in the
next bump, so it must be changed.
If mpvencdsp.draw_edges needs to be accessed from lavfi, then it could
be shared, or its code duplicated. But the current snow usage from lavfi
is crazy and beyond the scope of coded_frame, which was meant to export
quality stats and not work as some sort of interface to access lavc image
processing features.
libavcodec/snowenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index 3f2a75a670..3543574ec5 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -1624,10 +1624,20 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
s->lambda = 0;
}//else keep previous frame's qlog until after motion estimation
+#if FF_API_CODED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+av_frame_unref(avctx->coded_frame);
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
if (s->current_picture->data[0]) {
int w = s->avctx->width;
int h = s->avctx->height;
+ret = av_frame_make_writable(s->current_picture);
+if (ret < 0)
+return ret;
+
s->mpvencdsp.draw_edges(s->current_picture->data[0],
s->current_picture->linesize[0], w , h ,
EDGE_WIDTH , EDGE_WIDTH , EDGE_TOP |
EDGE_BOTTOM);
@@ -1645,7 +1655,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
ff_snow_frame_start(s);
#if FF_API_CODED_FRAME
FF_DISABLE_DEPRECATION_WARNINGS
-av_frame_unref(avctx->coded_frame);
ret = av_frame_ref(avctx->coded_frame, s->current_picture);
FF_ENABLE_DEPRECATION_WARNINGS
#endif
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 5/29/20, Jean-Baptiste Kempf wrote: > > > On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote: >> > The responses are "aggressive" because many people want "fast" mode >> > gone. >> >> >> This still doesnt explain the aggressive tone we have here. > > 1% agree > > Whatever the technical discussion, there is no reason to be uncivil to each > other. It never works to be uncivil and has never worked... > > This discussion feels a bit silly because I feel there is an easy way to > solve it. > I see no aggression at all here. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/h264_parser: Fix undefined left shift
Use an uint32_t for the NAL unit size of an AVC H.264 NAL unit instead
of an int as a left shift of a signed value is undefined behaviour
if the result doesn't fit into the target type.
Also make the log message never output negative lengths.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_parser.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d9249e578d..1d2ce3870c 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -84,12 +84,13 @@ static int h264_find_frame_end(H264ParseContext *p, const
uint8_t *buf,
for (i = 0; i < buf_size; i++) {
if (i >= next_avc) {
-int nalsize = 0;
+uint32_t nalsize = 0;
i = next_avc;
for (j = 0; j < p->nal_length_size; j++)
nalsize = (nalsize << 8) | buf[i++];
-if (nalsize <= 0 || nalsize > buf_size - i) {
-av_log(logctx, AV_LOG_ERROR, "AVC-parser: nal size %d
remaining %d\n", nalsize, buf_size - i);
+if (!nalsize || nalsize > buf_size - i) {
+av_log(logctx, AV_LOG_ERROR, "AVC-parser: nal size %"PRIu32" "
+ "remaining %d\n", nalsize, buf_size - i);
return buf_size;
}
next_avc = i + nalsize;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/h2645_parse: Don't report negative NAL unit sizes
This could happen if a four byte NAL unit size is encountered that is
bigger than INT_MAX when read as an uint32_t. This has been changed:
The size is now treated as uint32_t (so that no cast is needed any more
to prevent undefined behaviour when shifting) throughout the code.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h2645_parse.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
index 3e47f86c53..fd2c945c54 100644
--- a/libavcodec/h2645_parse.h
+++ b/libavcodec/h2645_parse.h
@@ -118,18 +118,19 @@ void ff_h2645_packet_uninit(H2645Packet *pkt);
static inline int get_nalsize(int nal_length_size, const uint8_t *buf,
int buf_size, int *buf_index, void *logctx)
{
-int i, nalsize = 0;
+uint32_t nalsize = 0;
if (*buf_index >= buf_size - nal_length_size) {
// the end of the buffer is reached, refill it
return AVERROR(EAGAIN);
}
-for (i = 0; i < nal_length_size; i++)
-nalsize = ((unsigned)nalsize << 8) | buf[(*buf_index)++];
-if (nalsize <= 0 || nalsize > buf_size - *buf_index) {
+for (int i = 0; i < nal_length_size; i++)
+nalsize = (nalsize << 8) | buf[(*buf_index)++];
+if (!nalsize || nalsize > buf_size - *buf_index) {
av_log(logctx, AV_LOG_ERROR,
- "Invalid NAL unit size (%d > %d).\n", nalsize, buf_size -
*buf_index);
+ "Invalid NAL unit size (%"PRIu32" > %d).\n",
+ nalsize, buf_size - *buf_index);
return AVERROR_INVALIDDATA;
}
return nalsize;
--
2.20.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 v2] avcodec/h264_parser: Try to avoid (un)referencing
When a slice is encountered, the H.264 parser up until now always
unreferenced and reset the currently active PPS; immediately
afterwards, the currently active PPS is set again which includes
referencing it. Given that it is typical for the active parameter
sets to change only seldomly, most of the time the new active PPS will
be the old one. Therefore this commit checks for this and only
unreferences the PPS if it changed.
Signed-off-by: Andreas Rheinhardt
---
New and much simplified version of [1]. This has been made possible by
5e316096fa9ba4493d9dbb48847ad8e0b0e188c3.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248374.html
libavcodec/h264_parser.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d988484660..c6fd049f46 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -363,6 +363,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
goto fail;
}
+if (p->ps.pps != (const PPS*)p->ps.pps_list[pps_id]->data) {
av_buffer_unref(>ps.pps_ref);
p->ps.pps = NULL;
p->ps.sps = NULL;
@@ -371,6 +372,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
goto fail;
p->ps.pps = (const PPS*)p->ps.pps_ref->data;
p->ps.sps = p->ps.pps->sps;
+}
sps = p->ps.sps;
// heuristic to detect non marked keyframes
--
2.20.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] [FFmpeg-cvslog] lavfi/vulkan: use all enabled queues in the queue family
May 29, 2020, 00:09 by mich...@niedermayer.cc: > On Sat, May 23, 2020 at 06:09:06PM +, Lynne wrote: > > This modifies global state, is neither thread safe nor can it be used from a > library (it breaks a user application using rand()) > Thanks for noticing, changed to use av_get_random_seed(). ___ 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 05/11] avcodec/h264_parser: Reuse the RBSP buffer
Andreas Rheinhardt: > Kieran Kunhya: >> On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt < >> andreas.rheinha...@gmail.com> wrote: >> >>> Kieran Kunhya: On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Up until now, the H.264 parser has allocated a new buffer for every > frame in order to store the unescaped RBSP in case the part of the RBSP > that will be unescaped contains 0x03 escape bytes. This is expensive > and this commit changes this: The buffer is now kept and reused. > > For an AVC file with an average framesize of 15304 B (without in-band > parameter sets etc.) and 132044 frames (131072 of which ended up in the > results) this reduced the average time used by the H.264 parser from > 87708 decicycles (excluding about 1100-1200 skips in each iteration) > to 16963 decicycles (excluding about 10-15 skips in each iteration). > The test has been iterated 10 times. > If I understand correctly, this patch means if you have a large frame (or large NAL) you are stuck with the large allocation of memory until the decoder is closed. Not sure if you have read the discussion here https://patchwork.ffmpeg.org/patch/5631/ Kieran >>> I am aware of said discussion; and also of your solution [1] to it. It >>> actually does exactly the same as I propose for the parser: It keeps a >>> single buffer that does not shrink. Given that this is used for the >>> decoders (and for cbs_h2645), I didn't deem this to be problematic. >>> (There is clearly no quadratic memory usage and what Derek warns about >>> (with huge NALs at specific positions) is a no issue for both.) >>> >>> - Andreas >>> >>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219100.html >> >> >> My solution frees the buffer when it's done. With yours it stays around as >> a large buffer essentially forever. >> >> Kieran >> > Your solution frees the buffer in the parser when it's done, but the > buffers for the decoders are kept (and only grow) during decoding. So > this commit merely does for the parser what is already done for the > deocder. > Anyway, it would be easy to add a check to the parser to free the > buffer if it is considered excessively large. I don't know how easy it > would be to add such precautions to the decoder, though. I am also not > sure what should be considered excessively large? 5 MB? 10 MB? Setting > it so high that even the highest profiles can't hit it is impossible, > because for certain profiles ((Progressive) High 10, High 4:2:2, ...) > no limit is imposed at all (apart from that, such a limit would surely > be too high). > > - Andreas > Ping. What is other's opinion on this matter? Notice that the current behaviour is suboptimal even if it is decided that the buffer should not be kept: It allocates 1/16 more than needed (in addition to AV_INPUT_BUFFER_PADDING_SIZE) that is guaranteed not to be used; and it uses mallocz for the allocation. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/jpeg2000_parser: Add jpeg2000 parser
On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer wrote: > > On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote: > > From: Gautam Ramakrishnan > > > > I have attempted to write a JPEG2000 Parser. Have tested > > by generating a file containing 14 frames, as mentioned > > by Micheal. Have also tried testing with various packet > > sizes by setting -frame_size option. Need feedback on the > > code and on further testing. > > --- > > libavcodec/Makefile | 1 + > > libavcodec/jpeg2000_parser.c | 190 +++ > > libavcodec/parsers.c | 1 + > > 3 files changed, 192 insertions(+) > > create mode 100644 libavcodec/jpeg2000_parser.c > > can you add some test to fate for this ? > (doesnt need to be related to the tests you did, but can of course) > such a test would also make it easy for others to test the code on > less common hardware like big endian ... > This can also be very simple test if its not easy I'll look into FATE > > > > > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > > index d0917a656f..1f7c91a91b 100644 > > --- a/libavcodec/Makefile > > +++ b/libavcodec/Makefile > > @@ -1073,6 +1073,7 @@ OBJS-$(CONFIG_H261_PARSER) += > > h261_parser.o > > OBJS-$(CONFIG_H263_PARSER) += h263_parser.o > > OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o > > h264data.o > > OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o > > +OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o > > OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o > > OBJS-$(CONFIG_MLP_PARSER) += mlp_parse.o mlp_parser.o mlp.o > > OBJS-$(CONFIG_MPEG4VIDEO_PARSER) += mpeg4video_parser.o h263.o \ > > diff --git a/libavcodec/jpeg2000_parser.c b/libavcodec/jpeg2000_parser.c > > new file mode 100644 > > index 00..c28b694219 > > > --- /dev/null > > +++ b/libavcodec/jpeg2000_parser.c > > @@ -0,0 +1,190 @@ > > +/* > > + * JPEG2000 parser > > > + * Copyright (c) 2000, 2001 Fabrice Bellard > > Thats ok if you used code from fabrice but you probably want to > add your name assuming you wrote the parser Missed that out :) > > [...] > > thx > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The smallest minority on earth is the individual. Those who deny > individual rights cannot claim to be defenders of minorities. - Ayn Rand > ___ > 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". -- - 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] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote: > > The responses are "aggressive" because many people want "fast" mode gone. > > > This still doesnt explain the aggressive tone we have here. 1% agree Whatever the technical discussion, there is no reason to be uncivil to each other. It never works to be uncivil and has never worked... This discussion feels a bit silly because I feel there is an easy way to solve it. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020 at 10:37:59AM -0300, James Almer wrote: > On 5/29/2020 10:10 AM, Michael Niedermayer wrote: > > while, what you quote above was not about h264 at all > > let me provide benchmarks of most fate h264 samples with and without > > flag_unsafe > > the script that made that is after it. a reply to the 2nd part of your mail > > is > > also below > > > > > > h264-444/444_10bit_cabac.h264 > > 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > > 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > > So the fast flag currently prevents ff_h2645_packet_split() from copying > each NAL into a padded buffer (in the situations where there's are no > emulation_prevention_three_byte to filter). Why is such padding needed > to prevent overreads? > > cbs_h264 always calls ff_h2645_packet_split() with the small_padding > argument as 1, and fuzzing has shown that it seemingly generated no > issues whatsoever, so why can't the bitstream reading code in h264dec > handle it safely? > Or it could but it would be costly? yes, it would cause a slowdown > And even if > costly, wouldn't the the speedup gained in a normal run with no flags > set (where most NALs would not be copied anymore to another buffer) > offset the slowdown from the extra sanity checks? When this code was written the copy was faster than the checks IIRC. That said, it is very possible we could do a more inteligent mix of checks and copying. for example check after each MB that there is enough space left and only copy the last few of a slice to a seperate buffer. but then the max size we use is rather large so we need to calculate a tigher bound there first and hope this is smaller than the average slice Or maybe there are even other ways. Now if we do a check per MB and copy, we could do a step beyond this and also skip copy when unescaping is needed as long as we know the MB is completely before or after all escaped points in the bitstream maybe that complexity isnt worth it, maybe it is for some high bitrate files. We could also keep track of allocated sizes of the bitstream and allocate more from where it comes from or have per codec padding bitstream suggestions. Or maybe theres even some other trick like there exist for mpeg1/2/4ASP which avoids the whole need for checks that all said, this is of course not going to make a huge difference in speed, its just 1 copy of the compressed bitstream. but many use h264 ... all just a bunch of random ideas, i hope something of this helps ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, May 29, 2020 at 02:22:03PM +0100, Kieran Kunhya wrote: > On Fri, 29 May 2020 at 14:11, Michael Niedermayer > wrote: > > > On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > > > > > More generally though (outside this unsafe flag case) > > > > i do disagree with your argument a bit, performance does matter. > > > > Iam regularly reminded of that for example, so much software becomes > > > > slower on each upgrade with few if any features added the real users > > > > care about. Just to pick one, the editor i use to write replies in mutt > > > > is slower to close than before i upgraded the OS. > > > > > > > > Also again to stay general here, this does not apply to the unsafe > > flag. > > > > speed / cpu load does add up. Slower code means more CO2 emissions if > > > > the software is used alot. > > > > If you want a real example insetad of this flag where we could improve > > > > IIRC there was some code iterating over options in the iteration over > > > > options resulting in some sort of O(n^3) or so. Thats from memory > > though > > > > would need to check where that was exactly but thats something we > > should > > > > fix. > > > > > > > > > > Please provide evidence that the H.264 Decoder has got slower. > > > > while, what you quote above was not about h264 at all > > let me provide benchmarks of most fate h264 samples with and without > > flag_unsafe > > the script that made that is after it. a reply to the 2nd part of your > > mail is > > also below > > > > Yes, it's no surprise that a "fast" mode that violates the spec to produce > some undefined and unsafe output is going to be faster. this case does not violate the spec. The spec only describes a valid bitstream. for valid bitstreams the h264 fast_unsafe case here is just faster, same output. > The responses are "aggressive" because many people want "fast" mode gone. > > I also would like it gone and I think the consensus is there to remove it. This still doesnt explain the aggressive tone we have here. You know, one problem with this is when people are angry they do not think as clear as when they are calm and there is the risk that this leads to a different choice the same people would have picked had they looked at the problem calmly. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Fri, 29 May 2020 at 14:11, Michael Niedermayer wrote: > On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > > > More generally though (outside this unsafe flag case) > > > i do disagree with your argument a bit, performance does matter. > > > Iam regularly reminded of that for example, so much software becomes > > > slower on each upgrade with few if any features added the real users > > > care about. Just to pick one, the editor i use to write replies in mutt > > > is slower to close than before i upgraded the OS. > > > > > > Also again to stay general here, this does not apply to the unsafe > flag. > > > speed / cpu load does add up. Slower code means more CO2 emissions if > > > the software is used alot. > > > If you want a real example insetad of this flag where we could improve > > > IIRC there was some code iterating over options in the iteration over > > > options resulting in some sort of O(n^3) or so. Thats from memory > though > > > would need to check where that was exactly but thats something we > should > > > fix. > > > > > > > Please provide evidence that the H.264 Decoder has got slower. > > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your > mail is > also below > Yes, it's no surprise that a "fast" mode that violates the spec to produce some undefined and unsafe output is going to be faster. The responses are "aggressive" because many people want "fast" mode gone. I also would like it gone and I think the consensus is there to remove it. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On 5/29/2020 10:10 AM, Michael Niedermayer wrote: > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your mail is > also below > > > h264-444/444_10bit_cabac.h264 > 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips So the fast flag currently prevents ff_h2645_packet_split() from copying each NAL into a padded buffer (in the situations where there's are no emulation_prevention_three_byte to filter). Why is such padding needed to prevent overreads? cbs_h264 always calls ff_h2645_packet_split() with the small_padding argument as 1, and fuzzing has shown that it seemingly generated no issues whatsoever, so why can't the bitstream reading code in h264dec handle it safely? Or it could but it would be costly? And even if costly, wouldn't the the speedup gained in a normal run with no flags set (where most NALs would not be copied anymore to another buffer) offset the slowdown from the extra sanity checks? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it
On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > More generally though (outside this unsafe flag case) > > i do disagree with your argument a bit, performance does matter. > > Iam regularly reminded of that for example, so much software becomes > > slower on each upgrade with few if any features added the real users > > care about. Just to pick one, the editor i use to write replies in mutt > > is slower to close than before i upgraded the OS. > > > > Also again to stay general here, this does not apply to the unsafe flag. > > speed / cpu load does add up. Slower code means more CO2 emissions if > > the software is used alot. > > If you want a real example insetad of this flag where we could improve > > IIRC there was some code iterating over options in the iteration over > > options resulting in some sort of O(n^3) or so. Thats from memory though > > would need to check where that was exactly but thats something we should > > fix. > > > > Please provide evidence that the H.264 Decoder has got slower. while, what you quote above was not about h264 at all let me provide benchmarks of most fate h264 samples with and without flag_unsafe the script that made that is after it. a reply to the 2nd part of your mail is also below h264-444/444_10bit_cabac.h264 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_10bit_cavlc.h264 1928995 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 676244 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_8bit_cabac.h264 1975800 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 01 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_8bit_cavlc.h264 1957577 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 719418 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_9bit_cabac.h264 1957739 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 633440 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/444_9bit_cavlc.h264 1943795 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 702884 decicycles in ff_h2645_packet_split, 16 runs, 0 skips h264-444/i444_hybrid_+i8x8_+pcm.264 1668108 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 399896 decicycles in ff_h2645_packet_split, 15 runs, 1 skips h264-444/old_i444_lossless_+i8x8_+pcm.264 1626002 decicycles in ff_h2645_packet_split, 15 runs, 1 skips 339882 decicycles in ff_h2645_packet_split, 15 runs, 1 skips h264/attachment631-small.mp4 110095 decicycles in ff_h2645_packet_split, 512 runs, 0 skips 39631 decicycles in ff_h2645_packet_split, 509 runs, 3 skips h264/bbc2.sample.h264 1270163 decicycles in ff_h2645_packet_split, 63 runs, 1 skips 696605 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264/brokensps.flv 721112 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 218294 decicycles in ff_h2645_packet_split, 64 runs, 0 skips h264-conformance/AUD_MW_E.264 674261 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 61366 decicycles in ff_h2645_packet_split, 48 runs, 16 skips h264-conformance/BA1_FT_C.264 219061 decicycles in ff_h2645_packet_split, 256 runs, 0 skips 85335 decicycles in ff_h2645_packet_split, 255 runs, 1 skips h264-conformance/BA1_Sony_D.jsv 1529117 decicycles in ff_h2645_packet_split, 16 runs, 0 skips 44400 decicycles in ff_h2645_packet_split, 7 runs, 9 skips h264-conformance/BA2_Sony_F.jsv 26672 decicycles in ff_h2645_packet_split, 240 runs, 16 skips 31297 decicycles in ff_h2645_packet_split, 240 runs, 16 skips h264-conformance/BA3_SVA_C.264 1305464 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 19725 decicycles in ff_h2645_packet_split, 16 runs, 16 skips h264-conformance/BAMQ1_JVC_C.264 1519809 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 440427 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/BAMQ2_JVC_C.264 1426419 decicycles in ff_h2645_packet_split, 32 runs, 0 skips 359686 decicycles in ff_h2645_packet_split, 32 runs, 0 skips h264-conformance/BA_MW_D.264 671156 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 126140 decicycles in ff_h2645_packet_split, 63 runs, 1 skips h264-conformance/BANM_MW_D.264 657848 decicycles in ff_h2645_packet_split, 64 runs, 0 skips 24498 decicycles in ff_h2645_packet_split, 47 runs, 17 skips h264-conformance/BASQP1_Sony_C.jsv 2208853 decicycles in ff_h2645_packet_split, 8 runs, 0 skips 875512 decicycles in ff_h2645_packet_split, 8 runs, 0 skips h264-conformance/CABA1_Sony_D.jsv 1312540 decicycles in
Re: [FFmpeg-devel] [PATCH] libavformat/dashenc.c:add mimetype
On 5/29/2020 4:18 AM, Siyuan Huang wrote: > according iso 23009-1 , mimetype is mandatory attibutes, must contain it > > > > Signed-off-by: SiyuanHuang > > --- > > libavformat/dashenc.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > > index 6f8de5762b..f71c1364b4 100755 > > --- a/libavformat/dashenc.c > > +++ b/libavformat/dashenc.c > > @@ -807,8 +807,8 @@ static int write_adaptation_set(AVFormatContext *s, > AVIOContext *out, int as_ind > > AVDictionaryEntry *lang, *role; > > int i; > > -avio_printf(out, "\t\t startWithSAP=\"1\" segmentAlignment=\"true\" bitstreamSwitching=\"true\"", > > -as->id, as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : > "audio"); > > +avio_printf(out, "\t\t mimeType=\"%s/mp4\" startWithSAP=\"1\" segmentAlignment=\"true\" > bitstreamSwitching=\"true\"", > > +as->id, as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : > "audio",as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio"); No, mimetype is already being applied in a per-Representation basis. > > if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num && > !as->ambiguous_frame_rate && av_cmp_q(as->min_frame_rate, > as->max_frame_rate) < 0) > > avio_printf(out, " maxFrameRate=\"%d/%d\"", as->max_frame_rate.num, > as->max_frame_rate.den); > > else if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num > && !as->ambiguous_frame_rate && !av_cmp_q(as->min_frame_rate, > as->max_frame_rate)) > ___ 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:make a sample Latency element
On 5/29/2020 4:19 AM, Siyuan Huang wrote:
> according iso 23009-1 4th , one Latency element should contain
>
> referenceId , target , max ,min atrributes
>
>
>
> Signed-off-by: SiyuanHuang
>
> ---
>
> libavformat/dashenc.c | 2 +-
>
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>
> index f71c1364b4..df081ce3ef 100755
>
> --- a/libavformat/dashenc.c
>
> +++ b/libavformat/dashenc.c
>
> @@ -1211,7 +1211,7 @@ static int write_manifest(AVFormatContext *s, int
> final)
>
> avio_printf(out, "\t\n");
>
> if (!final && c->target_latency && c->target_latency_refid >= 0) {
>
> -avio_printf(out, "\t\t c->target_latency / 1000);
>
> +avio_printf(out, "\t\t "\" max=\"3000\" min=\"1000\"", c->target_latency / 1000);
referenceId is already applied below. It's only needed when there's more
than one stream using prft, so this is an unnecessary hardcoded duplicate.
min/max are both optional, and if you hardcode them like this, you'd end
up with an invalid mpd if the user were to set target_latency to for
example 4. So if you still want them in, make them configurable with the
required range checks.
>
> if (s->nb_streams > 1)
>
> avio_printf(out, " referenceId=\"%d\"",
> c->target_latency_refid);
>
> avio_printf(out, "/>\n");
>
___
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:add support to change mpd update interval
On 5/29/2020 4:18 AM, Siyuan Huang wrote:
> according iso 23009-1 , in live cases , mpd refresh period should be
> changeable
>
> and default 500 seconds is too long , in normal live cases , it should be
> 2~5 seconds
It's set to 500 when timeline isn't used (for example, template only),
in which case there's no need to get a new mpd so often as it rarely, if
at all, ever changes.
When timeline is enabled, it's already set to update much more often.
Also, your email client mangled this patch and can't be applied.
>
>
>
> Signed-off-by: SiyuanHuang
>
> ---
>
> libavformat/dashenc.c | 6 +-
>
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> mode change 100644 => 100755 libavformat/dashenc.c
>
>
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>
> old mode 100644
>
> new mode 100755
>
> index 0cf0df50ef..6f8de5762b
>
> --- a/libavformat/dashenc.c
>
> +++ b/libavformat/dashenc.c
>
> @@ -196,6 +196,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 {
>
> @@ -1177,7 +1178,9 @@ static int write_manifest(AVFormatContext *s, int
> final)
>
> int64_t update_period = c->last_duration / AV_TIME_BASE;
>
> char now_str[100];
>
> if (c->use_template && !c->use_timeline)
>
> -update_period = 500;
>
> +update_period = 5;
>
> +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);
>
> @@ -2368,6 +2371,7 @@ static const AVOption options[] = {
>
> { "dvb_dash", "DVB-DASH profile", 0, AV_OPT_TYPE_CONST, {.i64 =
> MPD_PROFILE_DVB }, 0, UINT_MAX, E, "mpd_profile"},
>
> { "http_opts", "HTTP protocol options", OFFSET(http_opts),
> AV_OPT_TYPE_DICT, { .str = NULL }, 0, 0, E },
>
> { "target_latency", "Set desired target latency for Low-latency dash",
> OFFSET(target_latency), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT_MAX, E },
>
> +{ "update_period", "Set the mpd update interval",
> OFFSET(update_period),AV_OPT_TYPE_INT,{ .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
> },
>
> { NULL },
>
___
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:keep same with streaming , when live end
On 5/29/2020 4:19 AM, Siyuan Huang wrote: > sidx box is used for single file cases , should not apply to streaming/live > case > > > > Signed-off-by: SiyuanHuang > > --- > > libavformat/dashenc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c > > index df081ce3ef..2b2a77267b 100755 > > --- a/libavformat/dashenc.c > > +++ b/libavformat/dashenc.c > > @@ -1616,7 +1616,7 @@ static int dash_init(AVFormatContext *s) > > if (c->global_sidx) > > av_dict_set(, "movflags", > "+dash+delay_moov+global_sidx+skip_trailer", AV_DICT_APPEND); > > else > > -av_dict_set(, "movflags", > "+dash+delay_moov+skip_trailer", AV_DICT_APPEND); > > +av_dict_set(, "movflags", > "+dash+delay_moov+skip_sidx+skip_trailer", AV_DICT_APPEND); This is not the live/streaming case. You should instead separately check for c->single_file and then append +skip_sidx based on its value. > > } > > if (os->frag_type == FRAG_TYPE_EVERY_FRAME) > > av_dict_set(, "movflags", "+frag_every_frame", > AV_DICT_APPEND); > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/17] framesync: switch to child_class_iterate()
Anton Khirnov (12020-05-28):
> ---
> libavfilter/framesync.c | 7 +++
> libavfilter/framesync.h | 3 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
> index b32a5cba6c..04119d686c 100644
> --- a/libavfilter/framesync.c
> +++ b/libavfilter/framesync.c
> @@ -53,6 +53,13 @@ static const AVClass framesync_class = {
> .parent_log_context_offset = OFFSET(parent),
> };
>
> +const AVClass *ff_framesync_child_class_iterate(void **iter)
> +{
> +const AVClass *c = *iter ? NULL : _class;
> +*iter = (void*)(uintptr_t)c;
"void *" please.
> +return c;
> +}
> +
> enum {
> STATE_BOF,
> STATE_RUN,
> diff --git a/libavfilter/framesync.h b/libavfilter/framesync.h
> index 37743cccb7..51bab16285 100644
> --- a/libavfilter/framesync.h
> +++ b/libavfilter/framesync.h
> @@ -297,6 +297,8 @@ int ff_framesync_dualinput_get(FFFrameSync *fs, AVFrame
> **f0, AVFrame **f1);
> */
> int ff_framesync_dualinput_get_writable(FFFrameSync *fs, AVFrame **f0,
> AVFrame **f1);
>
> +const AVClass *ff_framesync_child_class_iterate(void **iter);
> +
> #define FRAMESYNC_DEFINE_CLASS(name, context, field) \
> static int name##_framesync_preinit(AVFilterContext *ctx) { \
> context *s = ctx->priv; \
> @@ -318,6 +320,7 @@ static const AVClass name##_class = { \
> .version = LIBAVUTIL_VERSION_INT, \
> .category = AV_CLASS_CATEGORY_FILTER, \
> .child_class_next = name##_child_class_next, \
> +.child_class_iterate = ff_framesync_child_class_iterate, \
> .child_next = name##_child_next, \
> }
>
LGTM.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 05/17] lavu/opt: add a more general child class iteration API
Anton Khirnov (12020-05-28):
> Use opaque iteration state instead of the previous child class. This
> mirrors similar changes done in lavf/lavc.
>
> Deprecate the av_opt_child_class_next() API.
> ---
> libavutil/log.h | 13 +
> libavutil/opt.c | 24 ++--
> libavutil/opt.h | 31 +++
> libavutil/version.h | 3 +++
> 4 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/libavutil/log.h b/libavutil/log.h
> index 9c14188a9c..4a7fdca8c2 100644
> --- a/libavutil/log.h
> +++ b/libavutil/log.h
> @@ -112,6 +112,7 @@ typedef struct AVClass {
> */
> void* (*child_next)(void *obj, void *prev);
>
> +#if FF_API_CHILD_CLASS_NEXT
> /**
> * Return an AVClass corresponding to the next potential
> * AVOptions-enabled child.
> @@ -120,7 +121,9 @@ typedef struct AVClass {
> * child_next iterates over _already existing_ objects, while
> * child_class_next iterates over _all possible_ children.
> */
> +attribute_deprecated
> const struct AVClass* (*child_class_next)(const struct AVClass *prev);
> +#endif
>
> /**
> * Category used for visualization (like color)
> @@ -140,6 +143,16 @@ typedef struct AVClass {
> * available since version (52.12)
> */
> int (*query_ranges)(struct AVOptionRanges **, void *obj, const char
> *key, int flags);
> +
> +/**
> + * Return an AVClass corresponding to the next potential
> + * AVOptions-enabled child.
> + *
> + * The difference between child_next and this is that
> + * child_next iterates over _already existing_ objects, while
> + * child_class_next iterates over _all possible_ children.
> + */
> +const struct AVClass* (*child_class_iterate)(void **iter);
Since "iter" is no longer named "prev", its semantic is no longer
obvious, and the documentation need to be a little more explicit.
Iterate the AVClass corresponding to the potential
AVOptions-enabled children.
iter points to an opaque pointer that can be updated to keep
track of the current child. On the first call, this pointer is
NULL.
> } AVClass;
>
> /**
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index 423313bce2..2c3f998d97 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -1679,8 +1679,9 @@ const AVOption *av_opt_find2(void *obj, const char
> *name, const char *unit,
>
> if (search_flags & AV_OPT_SEARCH_CHILDREN) {
> if (search_flags & AV_OPT_SEARCH_FAKE_OBJ) {
> -const AVClass *child = NULL;
> -while (child = av_opt_child_class_next(c, child))
> +void *iter = NULL;
> +const AVClass *child;
> +while (child = av_opt_child_class_iterate(c, ))
> if (o = av_opt_find2(, name, unit, opt_flags,
> search_flags, NULL))
> return o;
> } else {
> @@ -1715,12 +1716,31 @@ void *av_opt_child_next(void *obj, void *prev)
> return NULL;
> }
>
> +#if FF_API_CHILD_CLASS_NEXT
> +FF_DISABLE_DEPRECATION_WARNINGS
> const AVClass *av_opt_child_class_next(const AVClass *parent, const AVClass
> *prev)
> {
> if (parent->child_class_next)
> return parent->child_class_next(prev);
> return NULL;
> }
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
> +
> +const AVClass *av_opt_child_class_iterate(const AVClass *parent, void **iter)
> +{
> +if (parent->child_class_iterate)
> +return parent->child_class_iterate(iter);
> +#if FF_API_CHILD_CLASS_NEXT
> +FF_DISABLE_DEPRECATION_WARNINGS
> +if (parent->child_class_next) {
> +*iter = parent->child_class_next(*iter);
> +return *iter;
> +}
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
> +return NULL;
> +}
>
> void *av_opt_ptr(const AVClass *class, void *obj, const char *name)
> {
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index e46119572a..8dc020a820 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -114,7 +114,7 @@
> * libavcodec exports generic options, while its priv_data field exports
> * codec-specific options). In such a case, it is possible to set up the
> * parent struct to export a child's options. To do that, simply
> - * implement AVClass.child_next() and AVClass.child_class_next() in the
> + * implement AVClass.child_next() and AVClass.child_class_iterate() in
> the
> * parent struct's AVClass.
> * Assuming that the test_struct from above now also contains a
> * child_struct field:
> @@ -143,23 +143,25 @@
> * return t->child_struct;
> * return NULL
> * }
> - * const AVClass child_class_next(const AVClass *prev)
> + * const AVClass child_class_iterate(void **iter)
> * {
> - * return prev ? NULL : _class;
> + * const AVClass *c = *iter ? NULL : _class;
> + * *iter = (void*)(uintptr_t)c;
> + *
[FFmpeg-devel] [PATCH v5] avcodec/mpeg12enc: support mpeg2 encoder const profile
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpeg12enc.c | 2 ++
libavcodec/profiles.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index cab7076..9fbbcef 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -41,6 +41,7 @@
#include "mpeg12data.h"
#include "mpegutils.h"
#include "mpegvideo.h"
+#include "profiles.h"
static const uint8_t svcd_scan_offset_placeholder[] = {
0x10, 0x0E, 0x00, 0x80, 0x81, 0x00, 0x80,
@@ -1167,6 +1168,7 @@ static const AVOption mpeg2_options[] = {
{ "mac", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
VIDEO_FORMAT_MAC}, 0, 0, VE, "video_format" },
{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
VIDEO_FORMAT_UNSPECIFIED}, 0, 0, VE, "video_format" },
FF_MPV_COMMON_OPTS
+FF_MPEG2_PROFILE_OPTS
{ NULL },
};
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index e414ea7..d6a139e 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -43,6 +43,12 @@
FF_AVCTX_PROFILE_OPTION("mpeg4_main",NULL, VIDEO,
FF_PROFILE_MPEG4_MAIN)\
FF_AVCTX_PROFILE_OPTION("mpeg4_asp", NULL, VIDEO,
FF_PROFILE_MPEG4_ADVANCED_SIMPLE)\
+#define FF_MPEG2_PROFILE_OPTS \
+FF_AVCTX_PROFILE_OPTION("mpeg2_422", NULL, VIDEO,
FF_PROFILE_MPEG2_422)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_high",NULL, VIDEO,
FF_PROFILE_MPEG2_HIGH)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_main",NULL, VIDEO,
FF_PROFILE_MPEG2_MAIN)\
+FF_AVCTX_PROFILE_OPTION("mpeg2_simple", NULL, VIDEO,
FF_PROFILE_MPEG2_SIMPLE)\
+
extern const AVProfile ff_aac_profiles[];
extern const AVProfile ff_dca_profiles[];
extern const AVProfile ff_dnxhd_profiles[];
--
1.8.3.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] avutil/attributes: Fix too many warning: false is not defined [-Wundef]
From: Limin Wang Signed-off-by: Limin Wang --- try to avoid floods of warning message for my testing linux host. If you have better way, fix it anyway. Below is my Linux system information and gcc version: [lmwang@vpn2 ffmpeg.git]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) [lmwang@vpn2 ffmpeg.git]$ cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) libavutil/attributes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/attributes.h b/libavutil/attributes.h index ab2a1fd..5cb9fe3 100644 --- a/libavutil/attributes.h +++ b/libavutil/attributes.h @@ -37,7 +37,7 @@ #ifdef __has_builtin #define AV_HAS_BUILTIN(x) __has_builtin(x) #else -#define AV_HAS_BUILTIN(x) false +#define AV_HAS_BUILTIN(x) 0 #endif #ifndef av_always_inline -- 1.8.3.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 02/17] avdevice: deprecate av_*_device_next()
Anton Khirnov (12020-05-28): > These functions rely on deprecated libavformat APIs and apparently have > zero users outside of cmdutils. Since the functionality they provide is > apparently not useful to anyone, deprecate them without replacement. Unacceptable and fallacious. Libavdevice is a library, and as such its point is to provide a public API. cmdutils is the part of FFmpeg where we factored the common used of the public APIs: it is absolutely normal for an API to be used only there. Furthermore, since it is a library and a public API, it can be used by other projects, including unpublished projects, closed-source projects, etc. I can work with you to update the implementation so that it does not use deprecated lavf APIs if you point me where the issue was discussed. But just removing these libavdevices API is not acceptable. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 0/1] adpcm_ima_ssi encoder + kvag muxer
Add support for encoding adpcm_ima_ssi and muxing to kvag.
v6: [2]
- move seekable check into kvag_write_init()
v5: [1]
- change AVERROR(EINVAL) to AVERROR_PATCHWELCOME
- Split "capabilities" argument and formatting out into new commits
- If too verbose, patch 3 may be squashed into patch 2
v{4,3,2,1}:
- ancient history
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262730.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/263494.html
Zane van Iperen (1):
avformat: add kvag muxer
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/kvag.c | 82 +++-
libavformat/version.h| 2 +-
5 files changed, 85 insertions(+), 2 deletions(-)
--
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/1] avformat: add kvag muxer
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/kvag.c | 82 +++-
libavformat/version.h| 2 +-
5 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index 24dbbc2208..f40938187d 100644
--- a/Changelog
+++ b/Changelog
@@ -72,6 +72,7 @@ version :
- MediaFoundation encoder wrapper
- untile filter
- Simon & Schuster Interactive ADPCM encoder
+- Real War KVAG muxer
version 4.2:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index efe82f9f08..0658fa3710 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -285,6 +285,7 @@ OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o
rawenc.o
OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
OBJS-$(CONFIG_KUX_DEMUXER) += flvdec.o
OBJS-$(CONFIG_KVAG_DEMUXER) += kvag.o
+OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 3919c9e4c1..a7c5c9db89 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -220,6 +220,7 @@ extern AVOutputFormat ff_jacosub_muxer;
extern AVInputFormat ff_jv_demuxer;
extern AVInputFormat ff_kux_demuxer;
extern AVInputFormat ff_kvag_demuxer;
+extern AVOutputFormat ff_kvag_muxer;
extern AVOutputFormat ff_latm_muxer;
extern AVInputFormat ff_lmlm4_demuxer;
extern AVInputFormat ff_loas_demuxer;
diff --git a/libavformat/kvag.c b/libavformat/kvag.c
index 71b0eb4118..0a11fc0556 100644
--- a/libavformat/kvag.c
+++ b/libavformat/kvag.c
@@ -1,5 +1,5 @@
/*
- * Simon & Schuster Interactive VAG demuxer
+ * Simon & Schuster Interactive VAG (de)muxer
*
* Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
*
@@ -21,6 +21,7 @@
*/
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
#include "libavutil/intreadwrite.h"
#define KVAG_TAGMKTAG('K', 'V', 'A', 'G')
@@ -34,6 +35,7 @@ typedef struct KVAGHeader {
uint16_tstereo;
} KVAGHeader;
+#if CONFIG_KVAG_DEMUXER
static int kvag_probe(const AVProbeData *p)
{
if (AV_RL32(p->buf) != KVAG_TAG)
@@ -115,3 +117,81 @@ AVInputFormat ff_kvag_demuxer = {
.read_header= kvag_read_header,
.read_packet= kvag_read_packet
};
+#endif
+
+#if CONFIG_KVAG_MUXER
+static int kvag_write_init(AVFormatContext *s)
+{
+AVCodecParameters *par;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "KVAG files have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+par = s->streams[0]->codecpar;
+
+if (par->codec_id != AV_CODEC_ID_ADPCM_IMA_SSI) {
+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, "KVAG files only support up to 2 channels\n");
+return AVERROR(EINVAL);
+}
+
+if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL)) {
+av_log(s, AV_LOG_WARNING, "Stream not seekable, unable to write output
file\n");
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+static int kvag_write_header(AVFormatContext *s)
+{
+uint8_t buf[KVAG_HEADER_SIZE];
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+AV_WL32(buf + 0, KVAG_TAG);
+AV_WL32(buf + 4, 0); /* Data size, we fix this up later. */
+AV_WL32(buf + 8, par->sample_rate);
+AV_WL16(buf + 12, par->channels == 2);
+
+avio_write(s->pb, buf, sizeof(buf));
+return 0;
+}
+
+static int kvag_write_trailer(AVFormatContext *s)
+{
+int64_t file_size, data_size;
+
+file_size = avio_tell(s->pb);
+data_size = file_size - KVAG_HEADER_SIZE;
+if (data_size < UINT32_MAX) {
+avio_seek(s->pb, 4, SEEK_SET);
+avio_wl32(s->pb, (uint32_t)data_size);
+avio_seek(s->pb, file_size, SEEK_SET);
+} else {
+av_log(s, AV_LOG_WARNING,
+ "Filesize %"PRId64" invalid for KVAG, output file will be
broken\n",
+ file_size);
+}
+
+return 0;
+}
+
+AVOutputFormat ff_kvag_muxer = {
+.name = "kvag",
+.long_name = NULL_IF_CONFIG_SMALL("Simon & Schuster Interactive VAG"),
+.extensions = "vag",
+.audio_codec= AV_CODEC_ID_ADPCM_IMA_SSI,
+.video_codec= AV_CODEC_ID_NONE,
+.init = kvag_write_init,
+.write_header = kvag_write_header,
+.write_packet = ff_raw_write_packet,
+.write_trailer = kvag_write_trailer
+};
+#endif
diff --git a/libavformat/version.h b/libavformat/version.h
index 493a0b337f..e0135fc7d3 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467,
[FFmpeg-devel] [PATCH] libavformat/dashenc.c:make a sample Latency element
according iso 23009-1 4th , one Latency element should contain
referenceId , target , max ,min atrributes
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f71c1364b4..df081ce3ef 100755
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1211,7 +1211,7 @@ static int write_manifest(AVFormatContext *s, int
final)
avio_printf(out, "\t\n");
if (!final && c->target_latency && c->target_latency_refid >= 0) {
-avio_printf(out, "\t\ttarget_latency / 1000);
+avio_printf(out, "\t\ttarget_latency / 1000);
if (s->nb_streams > 1)
avio_printf(out, " referenceId=\"%d\"",
c->target_latency_refid);
avio_printf(out, "/>\n");
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/dashenc.c:keep same with streaming , when live end
sidx box is used for single file cases , should not apply to streaming/live case Signed-off-by: SiyuanHuang --- libavformat/dashenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index df081ce3ef..2b2a77267b 100755 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -1616,7 +1616,7 @@ static int dash_init(AVFormatContext *s) if (c->global_sidx) av_dict_set(, "movflags", "+dash+delay_moov+global_sidx+skip_trailer", AV_DICT_APPEND); else -av_dict_set(, "movflags", "+dash+delay_moov+skip_trailer", AV_DICT_APPEND); +av_dict_set(, "movflags", "+dash+delay_moov+skip_sidx+skip_trailer", AV_DICT_APPEND); } if (os->frag_type == FRAG_TYPE_EVERY_FRAME) av_dict_set(, "movflags", "+frag_every_frame", AV_DICT_APPEND); -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/dashenc.c:add support to change mpd update interval
according iso 23009-1 , in live cases , mpd refresh period should be
changeable
and default 500 seconds is too long , in normal live cases , it should be
2~5 seconds
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
mode change 100644 => 100755 libavformat/dashenc.c
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
old mode 100644
new mode 100755
index 0cf0df50ef..6f8de5762b
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -196,6 +196,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 {
@@ -1177,7 +1178,9 @@ static int write_manifest(AVFormatContext *s, int
final)
int64_t update_period = c->last_duration / AV_TIME_BASE;
char now_str[100];
if (c->use_template && !c->use_timeline)
-update_period = 500;
+update_period = 5;
+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);
@@ -2368,6 +2371,7 @@ static const AVOption options[] = {
{ "dvb_dash", "DVB-DASH profile", 0, AV_OPT_TYPE_CONST, {.i64 =
MPD_PROFILE_DVB }, 0, UINT_MAX, E, "mpd_profile"},
{ "http_opts", "HTTP protocol options", OFFSET(http_opts),
AV_OPT_TYPE_DICT, { .str = NULL }, 0, 0, E },
{ "target_latency", "Set desired target latency for Low-latency dash",
OFFSET(target_latency), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT_MAX, E },
+{ "update_period", "Set the mpd update interval",
OFFSET(update_period),AV_OPT_TYPE_INT,{ .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
},
{ NULL },
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/dashenc.c:add mimetype
according iso 23009-1 , mimetype is mandatory attibutes, must contain it Signed-off-by: SiyuanHuang --- libavformat/dashenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index 6f8de5762b..f71c1364b4 100755 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -807,8 +807,8 @@ static int write_adaptation_set(AVFormatContext *s, AVIOContext *out, int as_ind AVDictionaryEntry *lang, *role; int i; -avio_printf(out, "\t\tid, as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio"); +avio_printf(out, "\t\tid, as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",as->media_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio"); if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num && !as->ambiguous_frame_rate && av_cmp_q(as->min_frame_rate, as->max_frame_rate) < 0) avio_printf(out, " maxFrameRate=\"%d/%d\"", as->max_frame_rate.num, as->max_frame_rate.den); else if (as->media_type == AVMEDIA_TYPE_VIDEO && as->max_frame_rate.num && !as->ambiguous_frame_rate && !av_cmp_q(as->min_frame_rate, as->max_frame_rate)) -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfilter/vf_drawtext.c:add support to generte ms level timestamp
for test latency , need sub-seconds level timestamp watermark
Signed-off-by: SiyuanHuang
---
libavfilter/vf_drawtext.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
mode change 100644 => 100755 libavfilter/vf_drawtext.c
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
old mode 100644
new mode 100755
index abe1ca6c35..cfd08b4092
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -61,6 +61,8 @@
#include "internal.h"
#include "video.h"
+#include
+#include
#if CONFIG_LIBFRIBIDI
#include
#endif
@@ -1322,8 +1324,22 @@ static int draw_text(AVFilterContext *ctx, AVFrame
*frame,
return ret;
break;
case EXP_STRFTIME:
-localtime_r(, );
-av_bprint_strftime(bp, s->text, );
+if(NULL!=av_stristr(s->text,"mspts")) {
+struct tm *ptm;
+struct timeb stTimeb;
+static char szTime[24];
+
+ftime();
+ptm = localtime();
+sprintf(szTime, "%04d-%02d-%02d %02d:%02d:%02d.%03d",
+ptm->tm_year+1900,ptm->tm_mon + 1, ptm->tm_mday,
ptm->tm_hour, ptm->tm_min, ptm->tm_sec, stTimeb.millitm);
+szTime[23] = 0;
+av_bprintf(bp, "%s", szTime);
+} else {
+localtime_r(, );
+av_bprint_strftime(bp, s->text, );
+}
+
break;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [Please Ignore] send test
Test content ___ 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] [Please Ignore] send test
___ 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".
