[FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for QSV transpose filter
Add transpose support for qsv_vpp with rotate and hflip:
- rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
- hflip: [0, 1] support horizontal flip;
Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
Limitation:
If pipeline contains resize, mirroring and other, VPP skips other filters
in MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
will not work in d3d->d3d condition.
CMD:
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
-vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -f rawvideo
-pix_fmt nv12 -s:v 1920x1080 -i input.nv12 -vf
'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hflip'
-f rawvideo -pix_fmt nv12 -y ./transpose.yuv
Signed-off-by: Linjie Fu
---
libavfilter/vf_vpp_qsv.c | 95 +++-
1 file changed, 93 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index dd05e8baff..974fc7a255 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -36,12 +36,15 @@
#include "libavformat/avformat.h"
#include "qsvvpp.h"
+#include "transpose.h"
#define OFFSET(x) offsetof(VPPContext, x)
#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
/* number of video enhancement filters */
-#define ENH_FILTERS_COUNT (5)
+#define ENH_FILTERS_COUNT (7)
+#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
+#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
typedef struct VPPContext{
const AVClass *class;
@@ -54,6 +57,8 @@ typedef struct VPPContext{
mfxExtVPPDenoise denoise_conf;
mfxExtVPPDetail detail_conf;
mfxExtVPPProcAmp procamp_conf;
+mfxExtVPPRotation rotation_conf;
+mfxExtVPPMirroring mirroring_conf;
int out_width;
int out_height;
@@ -70,6 +75,10 @@ typedef struct VPPContext{
int crop_x;
int crop_y;
+int transpose;
+int rotate; /* rotate angle : [0, 90, 180, 270] */
+int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL flip */
+
/* param for the procamp */
intprocamp;/* enable procamp */
float hue;
@@ -95,6 +104,15 @@ static const AVOption options[] = {
{ "contrast","ProcAmp contrast", OFFSET(contrast),
AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
{ "brightness", "ProcAmp brightness", OFFSET(brightness),
AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
+{ "transpose", "set transpose direction", OFFSET(transpose),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
+{ "cclock_hflip", "rotate counter-clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock", "rotate clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "cclock","rotate counter-clockwise",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK }, .flags=FLAGS, .unit =
"transpose" },
+{ "clock_hflip", "rotate clockwise with horizontal flip",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "reversal", "rotate by half-turn",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit =
"transpose" },
+{ "hflip", "flip horizontally",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_HFLIP }, .flags=FLAGS, .unit =
"transpose" },
+{ "vflip", "flip vertically",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_VFLIP }, .flags=FLAGS, .unit =
"transpose" },
+
{ "cw", "set the width crop area expression", OFFSET(cw),
AV_OPT_TYPE_STRING, { .str = "iw" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "ch", "set the height crop area expression", OFFSET(ch),
AV_OPT_TYPE_STRING, { .str = "ih" }, CHAR_MIN, CHAR_MAX, FLAGS },
{ "cx", "set the x crop area expression", OFFSET(cx),
AV_OPT_TYPE_STRING, { .str = "(in_w-out_w)/2" }, CHAR_MIN, CHAR_MAX, FLAGS },
@@ -322,8 +340,81 @@ static int config_output(AVFilterLink *outlink)
param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)&vpp->procamp_conf;
}
+if (vpp->transpose >= 0) {
+switch (vpp->transpose) {
+case TRANSPOSE_CCLOCK_FLIP:
+vpp->rotate = MFX_ANGLE_270;
+vpp->hflip = MFX_MIRRORING_HORIZONTAL;
+break;
+case TRANSPOSE_CLOCK:
+vpp->rotate = MFX_ANGLE_90;
+vpp->hflip = MFX_MIRRORING_DISABLED;
+break;
+case TRANSPOSE_CCLOCK:
+vpp->rotate = MFX_ANGLE_270;
+v
[FFmpeg-devel] [PATCH, v4 1/2] lavf/qsvvpp:allocate continuous memory
Mediasdk calls CMRT to copy from video to system memory and requires
memory to be continuously allocated across Y and UV.
Add a new path to allocate continuous memory when using system out.
Use get_continuous_buffer to arrange data according to pixfmt.
Signed-off-by: Linjie Fu
---
libavfilter/qsvvpp.c | 67
1 file changed, 62 insertions(+), 5 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 8d5ff2eb65..07fe53573d 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -27,6 +27,7 @@
#include "libavutil/hwcontext_qsv.h"
#include "libavutil/time.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/imgutils.h"
#include "internal.h"
#include "qsvvpp.h"
@@ -346,6 +347,57 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
AVFilterLink *inlink, AVFrame *p
return qsv_frame;
}
+static int get_continuous_buffer(AVFrame *frame, int align)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+int ret, i, padded_height;
+
+if (!desc)
+return AVERROR(EINVAL);
+
+if ((ret = av_image_check_size(frame->width, frame->height, 0, NULL)) < 0)
+return ret;
+
+if (!frame->linesize[0]) {
+if (align <= 0)
+align = 32; /* STRIDE_ALIGN. Should be av_cpu_max_align() */
+
+for (i=1; i<=align; i+=i) {
+ret = av_image_fill_linesizes(frame->linesize, frame->format,
+ FFALIGN(frame->width, i));
+if (ret < 0)
+return ret;
+if (!(frame->linesize[0] & (align-1)))
+break;
+}
+
+for (i = 0; i < 4 && frame->linesize[i]; i++)
+frame->linesize[i] = FFALIGN(frame->linesize[i], align);
+}
+
+padded_height = FFALIGN(frame->height, 64);
+if ((ret = av_image_fill_pointers(frame->data, frame->format,
padded_height,
+ NULL, frame->linesize)) < 0)
+return ret;
+
+frame->buf[0] = av_buffer_alloc(ret);
+if (!frame->buf[0]) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+if ((ret = av_image_fill_pointers(frame->data, frame->format,
padded_height,
+ frame->buf[0]->data, frame->linesize)) <
0)
+goto fail;
+
+frame->extended_data = frame->data;
+
+return 0;
+fail:
+av_frame_unref(frame);
+return ret;
+}
+
/* get the output surface */
static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink *outlink)
{
@@ -375,15 +427,20 @@ static QSVFrame *query_frame(QSVVPPContext *s,
AVFilterLink *outlink)
out_frame->surface = (mfxFrameSurface1 *)out_frame->frame->data[3];
} else {
/* Get a frame with aligned dimensions.
- * Libmfx need system memory being 128x64 aligned */
-out_frame->frame = ff_get_video_buffer(outlink,
- FFALIGN(outlink->w, 128),
- FFALIGN(outlink->h, 64));
-if (!out_frame->frame)
+ * Libmfx need system memory being 128x64 aligned
+ * and continuously allocated across Y and UV */
+out_frame->frame = av_frame_alloc();
+if (!out_frame->frame) {
return NULL;
+}
out_frame->frame->width = outlink->w;
out_frame->frame->height = outlink->h;
+out_frame->frame->format = outlink->format;
+
+ret = get_continuous_buffer(out_frame->frame, 128);
+if (ret < 0)
+return NULL;
ret = map_frame_to_surface(out_frame->frame,
&out_frame->surface_internal);
--
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] av_format/hlsenc: fix %v handling by format_name function
Bodecs Bela 于2019年6月18日周二 上午5:57写道： > > Hi All, > > When multiple variant streams are specified by var_stream_map option, %v > placeholder in various names ensures that each variant has its unique > names. Most of %v handlng is done in format_name function. Currently > in this function the result buffer is the same as the > input pattern buffer, so you must allocate it before calling format_name > function. It also means, that it is silently assumed that the result > string will NOT be > longer that the pattern string. It is true most of the time, because %v > may appear only once in the pattern string and number of variant streams > is less than 100 in practical cases. But theoretically it will fail if > specified number of variant streams is greater than 100 (i.e. longer > than 2 digits). > This patch fixes this behaviour by altering format_name function to > allocate the > result buffer and return it to the caller. > > Please, review this patch. > > best, > > Bela > > ___ > 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". LGTM Thanks Steven ___ 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] dash: change default MP4 extension to .m4s
Alfred E. Heggestad 于2019年6月17日周一 下午4:02写道：
>
> From 923da82598bddd1ed05750427dbc71e607d296a2 Mon Sep 17 00:00:00 2001
> From: "Alfred E. Heggestad"
> Date: Mon, 17 Jun 2019 09:59:04 +0200
> Subject: [PATCH] dash: change default MP4 extension to .m4s
>
> this was changed in commit 281a21ed50849e3c8c0d03005230e9fd07c24370
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 3fd7e78166..a51a1da0ca 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -166,7 +166,7 @@ static struct format_string {
> const char *str;
> } formats[] = {
> { SEGMENT_TYPE_AUTO, "auto" },
> -{ SEGMENT_TYPE_MP4, "mp4" },
> +{ SEGMENT_TYPE_MP4, "m4s" },
> { SEGMENT_TYPE_WEBM, "webm" },
> { 0, NULL }
> };
> --
> 2.20.1 (Apple Git-117)
>
> ___
> 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".
LGTM
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/oggdec: only parse headers before data
+James
On Mon, Jun 17, 2019 at 6:31 PM Chris Cunningham
wrote:
> This behavior was added in 2010 to suport some old (and invalid) ogm
> files.
> https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94
>
> But this makes it possible to change the codec in the later headers,
> causing codec to be out of sync with internal avctx (eventually
> triggering Abrt). Updating the internal ctx for this degenerate case
> was deemed not worth it. See discussion here:
> https://patchwork.ffmpeg.org/patch/11983/
> ---
> libavformat/oggdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index e815f42134..19d77f3107 100644
> --- a/libavformat/oggdec.c
> +++ b/libavformat/oggdec.c
> @@ -545,7 +545,7 @@ static int ogg_packet(AVFormatContext *s, int *sid,
> int *dstart, int *dsize,
> ogg->curidx= idx;
> os->incomplete = 0;
>
> -if (os->header) {
> +if (!ogg->headers) {
> if ((ret = os->codec->header(s, idx)) < 0) {
> av_log(s, AV_LOG_ERROR, "Header processing failed: %s\n",
> av_err2str(ret));
> return ret;
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: unknown codec triggers error
New patch implements the other half of James suggestion (stop parsing headers after data) and does not include the AVERROR_INVALIDDATA returns. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245502.html On Sun, Jun 16, 2019 at 6:16 AM Reimar Döffinger wrote: > On 14.06.2019, at 17:01, James Almer wrote: > > > On 6/14/2019 11:52 AM, Reimar Döffinger wrote: > >> > >> > >> On 14.06.2019, at 03:15, Chris Cunningham > wrote: > >> > >>> Only "succeed" to read a header if the codec is valid. Otherwise > >>> return AVERROR_INVALIDDATA. > >> > >> That doesn't sound right to me, an unknown codec in (possibly) a single > stream is not an error. > >> I understood the discussion more to say the if it's an unknown codec, > we should not try to override valid codec configuration with a broken one. > > > > I did request this change, seeing that returning codec_id none in this > > scenario results in a crash at a later point due to conflicting > parameters. > > > > Do you suggest we should limit the change to only reject any duplicate > > header that may show up after the first one (and before the first data > > packet)? > > I don't know or understand the details, but I understood the suggestion as > "do not override a valid codec ID to NONE". > Either way, I would have suggested only skipping the affected stream - but > I admit I have not checked how far-reaching it is to return an error here. > ___ > 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] avformat/oggdec: only parse headers before data
This behavior was added in 2010 to suport some old (and invalid) ogm
files.
https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94
But this makes it possible to change the codec in the later headers,
causing codec to be out of sync with internal avctx (eventually
triggering Abrt). Updating the internal ctx for this degenerate case
was deemed not worth it. See discussion here:
https://patchwork.ffmpeg.org/patch/11983/
---
libavformat/oggdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index e815f42134..19d77f3107 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -545,7 +545,7 @@ static int ogg_packet(AVFormatContext *s, int *sid, int
*dstart, int *dsize,
ogg->curidx= idx;
os->incomplete = 0;
-if (os->header) {
+if (!ogg->headers) {
if ((ret = os->codec->header(s, idx)) < 0) {
av_log(s, AV_LOG_ERROR, "Header processing failed: %s\n",
av_err2str(ret));
return ret;
--
2.22.0.410.gd8fdbe21b5-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 1/2] lavf/vf_transpose: add exif orientation support
On Sat, Jun 15, 2019 at 7:09 PM Jun Li wrote:
>
>
> On Tue, Jun 11, 2019 at 7:05 PM Jun Li wrote:
>
>>
>> On Sun, Jun 9, 2019 at 2:28 PM Jun Li wrote:
>>
>>> Add exif orientation support and expose an option.
>>> ---
>>> libavfilter/hflip.h| 2 +
>>> libavfilter/transpose.h| 14
>>> libavfilter/vf_hflip.c | 40 ++---
>>> libavfilter/vf_transpose.c | 168 -
>>> 4 files changed, 192 insertions(+), 32 deletions(-)
>>>
>>> diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
>>> index 204090dbb4..4e89bae3fc 100644
>>> --- a/libavfilter/hflip.h
>>> +++ b/libavfilter/hflip.h
>>> @@ -35,5 +35,7 @@ typedef struct FlipContext {
>>>
>>> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes);
>>> void ff_hflip_init_x86(FlipContext *s, int step[4], int nb_planes);
>>> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink);
>>> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out,
>>> int job, int nb_jobs, int vlifp);
>>>
>>> #endif /* AVFILTER_HFLIP_H */
>>> diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
>>> index aa262b9487..5da08bddc0 100644
>>> --- a/libavfilter/transpose.h
>>> +++ b/libavfilter/transpose.h
>>> @@ -34,4 +34,18 @@ enum TransposeDir {
>>> TRANSPOSE_VFLIP,
>>> };
>>>
>>> +enum OrientationType {
>>> +ORIENTATION_AUTO_TRANSPOSE = -2,
>>> +ORIENTATION_AUTO_FLIP = -1,
>>> +ORIENTATION_NONE = 0,
>>> +ORIENTATION_NORMAL,
>>> +ORIENTATION_HFLIP,
>>> +ORIENTATION_ROTATE180,
>>> +ORIENTATION_VFLIP,
>>> +ORIENTATION_HFLIP_ROTATE270CW,
>>> +ORIENTATION_ROTATE90CW,
>>> +ORIENTATION_HFLIP_ROTATE90CW,
>>> +ORIENTATION_ROTATE270CW
>>> +};
>>> +
>>> #endif
>>> diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
>>> index b77afc77fc..d24ca5c2e7 100644
>>> --- a/libavfilter/vf_hflip.c
>>> +++ b/libavfilter/vf_hflip.c
>>> @@ -125,9 +125,8 @@ static void hflip_qword_c(const uint8_t *ssrc,
>>> uint8_t *ddst, int w)
>>> dst[j] = src[-j];
>>> }
>>>
>>> -static int config_props(AVFilterLink *inlink)
>>> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink)
>>> {
>>> -FlipContext *s = inlink->dst->priv;
>>> const AVPixFmtDescriptor *pix_desc =
>>> av_pix_fmt_desc_get(inlink->format);
>>> const int hsub = pix_desc->log2_chroma_w;
>>> const int vsub = pix_desc->log2_chroma_h;
>>> @@ -144,6 +143,12 @@ static int config_props(AVFilterLink *inlink)
>>> return ff_hflip_init(s, s->max_step, nb_planes);
>>> }
>>>
>>> +static int config_props(AVFilterLink *inlink)
>>> +{
>>> +FlipContext *s = inlink->dst->priv;
>>> +return ff_hflip_config_props(s, inlink);
>>> +}
>>> +
>>> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes)
>>> {
>>> int i;
>>> @@ -170,14 +175,10 @@ typedef struct ThreadData {
>>> AVFrame *in, *out;
>>> } ThreadData;
>>>
>>> -static int filter_slice(AVFilterContext *ctx, void *arg, int job, int
>>> nb_jobs)
>>> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out,
>>> int job, int nb_jobs, int vflip)
>>> {
>>> -FlipContext *s = ctx->priv;
>>> -ThreadData *td = arg;
>>> -AVFrame *in = td->in;
>>> -AVFrame *out = td->out;
>>> uint8_t *inrow, *outrow;
>>> -int i, plane, step;
>>> +int i, plane, step, outlinesize;
>>>
>>> for (plane = 0; plane < 4 && in->data[plane] &&
>>> in->linesize[plane]; plane++) {
>>> const int width = s->planewidth[plane];
>>> @@ -187,19 +188,36 @@ static int filter_slice(AVFilterContext *ctx, void
>>> *arg, int job, int nb_jobs)
>>>
>>> step = s->max_step[plane];
>>>
>>> -outrow = out->data[plane] + start * out->linesize[plane];
>>> -inrow = in ->data[plane] + start * in->linesize[plane] +
>>> (width - 1) * step;
>>> +if (vflip) {
>>> +outrow = out->data[plane] + (height - start - 1)*
>>> out->linesize[plane];
>>> +outlinesize = -out->linesize[plane];
>>> +} else {
>>> +outrow = out->data[plane] + start * out->linesize[plane];
>>> +outlinesize = out->linesize[plane];
>>> +}
>>> +
>>> +inrow = in->data[plane] + start * in->linesize[plane] + (width
>>> - 1) * step;
>>> +
>>> for (i = start; i < end; i++) {
>>> s->flip_line[plane](inrow, outrow, width);
>>>
>>> inrow += in ->linesize[plane];
>>> -outrow += out->linesize[plane];
>>> +outrow += outlinesize;
>>> }
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> +static int filter_slice(AVFilterContext *ctx, void *arg, int job, int
>>> nb_jobs)
>>> +{
>>> +FlipContext *s = ctx->priv;
>>> +ThreadData *td = arg;
>>> +AVFrame *in = td->in;
>>> +AVFrame *out = td->out;
>>> +return ff_hflip_filter_slice(s, in, out, job, nb_jobs, 0);
>>> +}
>>> +
>>> static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>>> {
>>> AVFilterContext *ctx =
Re: [FFmpeg-devel] [PATCH] avformat/aviobuf: Delay buffer downsizing until asserts are met
Michael Niedermayer:
> Fixes: Assertion failure
> Fixes:
> 15151/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5757079496687616
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/aviobuf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 5a33f82950..6a5cd97b0a 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -570,7 +570,7 @@ static void fill_buffer(AVIOContext *s)
> }
>
> /* make buffer smaller in case it ended up large after probing */
> -if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> s->orig_buffer_size) {
> +if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> s->orig_buffer_size && len >= s->orig_buffer_size) {
> if (dst == s->buffer && s->buf_ptr != dst) {
> int ret = ffio_set_buf_size(s, s->orig_buffer_size);
> if (ret < 0)
> @@ -578,7 +578,6 @@ static void fill_buffer(AVIOContext *s)
>
> s->checksum_ptr = dst = s->buffer;
> }
> -av_assert0(len >= s->orig_buffer_size);
> len = s->orig_buffer_size;
> }
>
>
I just noticed that ticket #7094 is about this assert. Could you test
whether everything works fine with your fix applied (and then mention
said this ticket in the commit message)?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On 6/17/2019 6:54 PM, Michael Niedermayer wrote:
> On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
>> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
>>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
>>> type 'int'
>>> Fixes:
>>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
>>>
>>> Found-by: continuous fuzzing process
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/hevc_ps.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 80df417e4f..0ed6682bb4 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> if (pps->num_tile_rows <= 0 ||
>>> pps->num_tile_rows >= sps->height) {
>>> av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
>>> range: %d\n",
>>> - pps->num_tile_rows - 1);
>>> + pps->num_tile_rows - 1U);
>>
>> The proper fix for this is making pps->num_tile_rows/cols unsigned.
>
> I dont think "unsigned int" is wise to use as type here, the semantics
> of unsigned ints are unexpected to many
> especially making random subsets of "normal" fields unsigned will make
> the codebase slowly "interresting".
If you make the actual unsigned values as per the spec be unsigned, it
will not be a random subset of values... And i see plenty of unsigned
and uint*_t fields in hevc_ps.h. These for some reason were given the
wrong type.
>
> is this here ok if num_tile_rows is 0 ?
> for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg git)
>
> i would guess nearly everyone wold say yes without having seen the
> discussion about the type. but of course if this is unsigned its not
> going to be safe with it being 0.
pps->num_tile_rows is set to a value returned by "get_ue_golomb_long() +
1", which will always be in the 1..UINT32_MAX range. It can't be 0, as
it would be a bug. Int is definitely not the right type for it.
By making these two fields unsigned you can remove the
"pps->num_tile_{rows,cols} <= 0" checks, leaving only the
"pps->num_tile_{rows,cols} >= sps->{height,width}" checks. Just add an
av_assert0(pps->num_tile_{rows,cols} > 0) before them and the av_log()
calls, which is also before the loop you quoted, if you want to be sure
no change in the future introduces issues.
>
>
>> The
>> minimum allowed value for num_tile_{rows,cols}_minus1 is 0.
>
> yes
>
>
> [...]
>
>
> ___
> 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] av_format/hlsenc: fix %v handling by format_name function
Hi All,
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the
input pattern buffer, so you must allocate it before calling format_name
function. It also means, that it is silently assumed that the result
string will NOT be
longer that the pattern string. It is true most of the time, because %v
may appear only once in the pattern string and number of variant streams
is less than 100 in practical cases. But theoretically it will fail if
specified number of variant streams is greater than 100 (i.e. longer
than 2 digits).
This patch fixes this behaviour by altering format_name function to
allocate the
result buffer and return it to the caller.
Please, review this patch.
best,
Bela
>From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 17 Jun 2019 14:31:36 +0200
Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the input pattern
buffer, so you must allocate it before calling format_name function. It
also means, that it is silently assumed that the result string will NOT
be longer that the pattern string. It is true most of the time, because
%v may appear only once in the pattern string and number of variant
streams is less than 100 in practical cases. But theoretically it will
fail if specified number of variant streams is greater than 100. This
patch fixes this behaviour by altering format_name function to allocate
the result buffer and return it to the caller.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9884f74d51..ebe1ab62e5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1761,33 +1761,34 @@ fail:
return ret;
}
-static int format_name(char *buf, int buf_len, int index)
+static int format_name(const char *buf, char **s, int index)
{
const char *proto, *dir;
-char *orig_buf_dup = NULL, *mod_buf = NULL, *mod_buf_dup = NULL;
+char *orig_buf_dup = NULL, *mod_buf_dup = NULL;
int ret = 0;
-if (!av_stristr(buf, "%v"))
-return ret;
-
orig_buf_dup = av_strdup(buf);
if (!orig_buf_dup) {
ret = AVERROR(ENOMEM);
goto fail;
}
-if (replace_int_data_in_filename(&mod_buf, orig_buf_dup, 'v', index) < 1) {
+if (!av_stristr(buf, "%v")) {
+*s = orig_buf_dup;
+return ret;
+}
+
+if (replace_int_data_in_filename(s, orig_buf_dup, 'v', index) < 1) {
ret = AVERROR(EINVAL);
goto fail;
}
-av_strlcpy(buf, mod_buf, buf_len);
proto = avio_find_protocol_name(orig_buf_dup);
dir = av_dirname(orig_buf_dup);
/* if %v is present in the file's directory, create sub-directory */
if (av_stristr(dir, "%v") && proto && !strcmp(proto, "file")) {
-mod_buf_dup = av_strdup(buf);
+mod_buf_dup = av_strdup(*s);
if (!mod_buf_dup) {
ret = AVERROR(ENOMEM);
goto fail;
@@ -1803,7 +1804,6 @@ static int format_name(char *buf, int buf_len, int index)
fail:
av_freep(&orig_buf_dup);
av_freep(&mod_buf_dup);
-av_freep(&mod_buf);
return ret;
}
@@ -2634,7 +2634,7 @@ static int hls_init(AVFormatContext *s)
ret = AVERROR(ENOMEM);
goto fail;
}
-ret = format_name(vs->m3u8_name, strlen(s->url) + 1, i);
+ret = format_name(s->url, i, vs->m3u8_name);
if (ret < 0)
goto fail;
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/hevc_ps: Fix integer overflow with num_tile_rows
On Sun, Jun 16, 2019 at 11:10:43PM -0300, James Almer wrote:
> On 6/13/2019 3:32 PM, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> > type 'int'
> > Fixes:
> > 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevc_ps.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 80df417e4f..0ed6682bb4 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1596,7 +1596,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > if (pps->num_tile_rows <= 0 ||
> > pps->num_tile_rows >= sps->height) {
> > av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> > range: %d\n",
> > - pps->num_tile_rows - 1);
> > + pps->num_tile_rows - 1U);
>
> The proper fix for this is making pps->num_tile_rows/cols unsigned.
I dont think "unsigned int" is wise to use as type here, the semantics
of unsigned ints are unexpected to many
especially making random subsets of "normal" fields unsigned will make
the codebase slowly "interresting".
is this here ok if num_tile_rows is 0 ?
for (i = 0; i < pps->num_tile_rows - 1; i++) { (example line from ffmpeg git)
i would guess nearly everyone wold say yes without having seen the
discussion about the type. but of course if this is unsigned its not
going to be safe with it being 0.
> The
> minimum allowed value for num_tile_{rows,cols}_minus1 is 0.
yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed
On Sun, Jun 16, 2019 at 01:09:45AM -0400, Andriy Gelman wrote:
> Michael,
>
> On Thu, 16. May 00:43, Michael Niedermayer wrote:
> > On Tue, May 14, 2019 at 05:54:21PM -0400, Andriy Gelman wrote:
> > > From: Andriy Gelman
> > >
> > > Fixes Ticket #7895.
> > >
> > > Currently, timestamp interpolation is disabled by default in H264 and
> > > HEVC. This creates playback issues when the demuxer does not output a
> > > valid timestamp. This patch allows interpolation when no b-frames have
> > > been observed during decoding, which fixes playback issues for some
> > > missing timestamp cases.
> > > ---
> > > libavformat/utils.c | 11 +--
> > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > index a63d71b0f4..3dd0bf0d66 100644
> > > --- a/libavformat/utils.c
> > > +++ b/libavformat/utils.c
> > > @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s,
> > > AVStream *st,
> > > int64_t offset;
> > > AVRational duration;
> > > int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> > > - st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> > > + st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> > > + (!st->internal->avctx->max_b_frames &&
> > > +st->cur_dts != RELATIVE_TS_BASE); /*skip when no
> > > timing info from demuxer */
> > >
> > > if (s->flags & AVFMT_FLAG_NOFILLIN)
> > > return;
> > > @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s,
> > > AVStream *st,
> > > delay = st->internal->avctx->has_b_frames;
> > > presentation_delayed = 0;
> > >
> > > +/*update max_b_frames if delay is larger */
> > > +if (delay > st->internal->avctx->max_b_frames)
> > > + st->internal->avctx->max_b_frames = delay;
> > > +
> > > /* XXX: need has_b_frame, but cannot get it if the codec is
> > > * not initialized */
> > > if (delay &&
> > > @@ -1337,7 +1343,8 @@ static void compute_pkt_fields(AVFormatContext *s,
> > > AVStream *st,
> > > presentation_delayed, av_ts2str(pkt->pts),
> > > av_ts2str(pkt->dts), av_ts2str(st->cur_dts),
> > > pkt->stream_index, pc, pkt->duration, delay, onein_oneout);
> > >
> > > -/* Interpolate PTS and DTS if they are not present. We skip H264
> > > +/* Interpolate PTS and DTS if they are not present. H264/HEVC
> > > timestamps are
> > > + * interpolated only if no b-frames have been observed. Otherwise,
> > > we skip H264/HEVC
> > > * currently because delay and has_b_frames are not reliably set. */
> > > if ((delay == 0 || (delay == 1 && pc)) &&
> > > onein_oneout) {
> >
> > This may produce some approximate values that are sometimes wrong.
> >
> > If you want to compute exact timestamps, see "Conditional coding of
> > timestamps"
> > in H.222. I only have a older draft here so mine only covers mpeg & h264
> > but
> > maybe the next covers hevc too.
>
> In H.222 it says:
>
> "The decoding time tdn(j) is specified in the DTS or PTS fields (refer to
> 2.4.3.6). Decoding times tdn(j + 1), tdn(j + 2), ... of access units without
> encoded DTS or PTS fields which directly follow access unit j may be derived
> from information in the elementary stream"
>
> If we decode the POC, then we compute the correct pts/dts even for B-frames.
> Would you agree with this strategy, or did you have something else in mind.
The POC would provide the ordering but not the exact timestamps
Also see "2.7.5 Conditional coding of timestamps"
Its a bit ugly sadly, there are many cases, or basically probably every
way by which codec level timing can be provided
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avcodec/libvorbisdec: Check extradata size
Fixes: out of array read
Fixes:
15261/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVORBIS_fuzzer-5764908467093504
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/libvorbisdec.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/libvorbisdec.c b/libavcodec/libvorbisdec.c
index ecf690a553..89cbbb41b6 100644
--- a/libavcodec/libvorbisdec.c
+++ b/libavcodec/libvorbisdec.c
@@ -49,8 +49,16 @@ static int oggvorbis_decode_init(AVCodecContext *avccontext)
{
vorbis_comment_init(&context->vc) ;
if(p[0] == 0 && p[1] == 30) {
+int sizesum = 0;
for(i = 0; i < 3; i++){
hsizes[i] = bytestream_get_be16((const uint8_t **)&p);
+sizesum += 2 + hsizes[i];
+if (sizesum > avccontext->extradata_size) {
+av_log(avccontext, AV_LOG_ERROR, "vorbis extradata too
small\n");
+ret = AVERROR_INVALIDDATA;
+goto error;
+}
+
headers[i] = p;
p += hsizes[i];
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avcodec/m101: Fix off be 2 error
Fixes: out of array read
Fixes:
15263/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_M101_fuzzer-5728999453491200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/m101.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/m101.c b/libavcodec/m101.c
index d2549668fd..70f1da4f45 100644
--- a/libavcodec/m101.c
+++ b/libavcodec/m101.c
@@ -61,7 +61,7 @@ static int m101_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
stride = AV_RL32(avctx->extradata + 5*4);
if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
-min_stride = (avctx->width + 15) / 16 * 20;
+min_stride = (avctx->width + 15) / 16 * 40;
if (stride < min_stride || avpkt->size < stride * (uint64_t)avctx->height)
{
av_log(avctx, AV_LOG_ERROR, "stride (%d) is invalid for packet sized
%d\n",
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/qdm2: Move fft_order check up
This avoids undefined computations with unchecked values
Fixes: shift exponent -21 is negative
Fixes:
15262/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5651261753393152
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/qdm2.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qdm2.c b/libavcodec/qdm2.c
index 88b6b19d11..1397218bdd 100644
--- a/libavcodec/qdm2.c
+++ b/libavcodec/qdm2.c
@@ -1702,6 +1702,12 @@ static av_cold int qdm2_decode_init(AVCodecContext
*avctx)
s->fft_order = av_log2(s->fft_size) + 1;
+// Fail on unknown fft order
+if ((s->fft_order < 7) || (s->fft_order > 9)) {
+avpriv_request_sample(avctx, "Unknown FFT order %d", s->fft_order);
+return AVERROR_PATCHWELCOME;
+}
+
// something like max decodable tones
s->group_order = av_log2(s->group_size) + 1;
s->frame_size = s->group_size / 16; // 16 iterations per super block
@@ -1735,11 +1741,6 @@ static av_cold int qdm2_decode_init(AVCodecContext
*avctx)
else
s->coeff_per_sb_select = 2;
-// Fail on unknown fft order
-if ((s->fft_order < 7) || (s->fft_order > 9)) {
-avpriv_request_sample(avctx, "Unknown FFT order %d", s->fft_order);
-return AVERROR_PATCHWELCOME;
-}
if (s->fft_size != (1 << (s->fft_order - 1))) {
av_log(avctx, AV_LOG_ERROR, "FFT size %d not power of 2.\n",
s->fft_size);
return AVERROR_INVALIDDATA;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 10/18] cbs: Remove superfluous checks for ff_cbs_delete_unit
James Almer: > On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote: >> ff_cbs_delete_unit never fails if the index of the unit to delete is >> valid; document this behaviour explicitly and remove the checks for >> whether ff_cbs_delete_unit failed, because all the callers of >> ff_cbs_delete_unit already make sure that the index is valid. > > Add a comment about why you're ignoring the return values in all three > filters. If for whatever reason the filters are changed in the future > and it can no longer be ensured the call will never fail, the developer > should be aware of it. > Ok. I just noticed that the call for deleting AV1 temporal delimiters doesn't check whether the fragment has a unit at all (in fact, the check before that call already presupposes it). The only way for ff_cbs_read_packet to return an empty fragment and no error is if the packet's buf has a size of zero (this is legal according to the API if the packet has side-data). What should be done about packets that don't result in a single unit and more specifically about zero-sized packets? The obvious answer would be to simply add a check to av1_metadata like the already existing in h264_metadata; but discarding side-data only packets is no good. (If the zero-sized packet had new extradata as side-data, then that's something that may be parsed and rewritten; the other side-data stuff should simply be passed through.) - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/18] cbs: Allow non-blank packets in ff_cbs_write_packet
On 6/17/2019 11:34 AM, Andreas Rheinhardt wrote: > James Almer: >> On 6/17/2019 9:44 AM, James Almer wrote: >>> On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote: Up until now, ff_cbs_write_packet always initialized the packet structure it received without documenting this behaviour; furthermore, the packet's buffer would (on success) be overwritten with the new buffer without unreferencing the old. This meant that the input packet had to be either clean (otherwise there would be memleaks) in which case the initialization is redundant or uninitialized. ff_cbs_write_packet was never used with uninitialized packets, so the initialization was redundant. Worse yet, it forced callers to use more than one packet and made it difficult to add side-data to a packet designated for output, because said side-data could only be attached after the call to ff_cbs_write_packet. This has been changed. It is now allowed to use a non-blank packet. The currently existing buffer will be unreferenced and replaced by the new one, as will be the accompanying fields (i.e. data and size). The rest isn't touched at all. This change will enable us to use only one packet in the bitstream filters that rely on CBS. This commit also updates the documentation of ff_cbs_write_extradata and ff_cbs_write_packet (to better describe existing behaviour and in the latter case to also describe the new behaviour). Signed-off-by: Andreas Rheinhardt --- I could also have made it unref the packet's buffer at the beginning; this would have the advantage that the packet's buffer would be freed after the units have been rewritten (if they are rewritten) and after the fragment's buffer has been unreferenced, so that maximum memory consumption would decrease. It would also be in line with all current callers of ff_cbs_write_packet, but maybe it wouldn't be what a future caller wants. What do you think? libavcodec/cbs.c | 3 ++- libavcodec/cbs.h | 10 +- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c index 0260ba6f67..47679eca1b 100644 --- a/libavcodec/cbs.c +++ b/libavcodec/cbs.c @@ -357,7 +357,8 @@ int ff_cbs_write_packet(CodedBitstreamContext *ctx, if (!buf) return AVERROR(ENOMEM); -av_init_packet(pkt); +av_buffer_unref(&pkt->buf); >>> >>> You should probably unref the packet, not just the AVBufferRef. >> >> Right, i see in patch 2 why you did this. I don't like much how with >> this change ff_cbs_write_packet would leave the packet in a weird state >> of having the filtered data alongside unrelated props already in packet >> provided by the caller. If CBS is ever made public, i'm not sure it's a >> behavior we should keep. >> >> But if right now it allows us to use ff_bsf_get_packet_ref() and remove >> av_packet_copy_props() calls, then it's good. >> > Would you prefer if ff_cbs_write_packet gets renamed to > ff_cbs_update_packet_data? > Anyway, thanks for taking your time to review this. No, it's fine as is. > > - Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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 01/18] cbs: Allow non-blank packets in ff_cbs_write_packet
James Almer: > On 6/17/2019 9:44 AM, James Almer wrote: >> On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote: >>> Up until now, ff_cbs_write_packet always initialized the packet >>> structure it received without documenting this behaviour; furthermore, >>> the packet's buffer would (on success) be overwritten with the new >>> buffer without unreferencing the old. This meant that the input packet >>> had to be either clean (otherwise there would be memleaks) in which case >>> the initialization is redundant or uninitialized. ff_cbs_write_packet >>> was never used with uninitialized packets, so the initialization was >>> redundant. Worse yet, it forced callers to use more than one packet and >>> made it difficult to add side-data to a packet designated for output, >>> because said side-data could only be attached after the call to >>> ff_cbs_write_packet. >>> >>> This has been changed. It is now allowed to use a non-blank packet. >>> The currently existing buffer will be unreferenced and replaced by >>> the new one, as will be the accompanying fields (i.e. data and size). >>> The rest isn't touched at all. >>> >>> This change will enable us to use only one packet in the bitstream >>> filters that rely on CBS. >>> >>> This commit also updates the documentation of ff_cbs_write_extradata >>> and ff_cbs_write_packet (to better describe existing behaviour and in >>> the latter case to also describe the new behaviour). >>> >>> Signed-off-by: Andreas Rheinhardt >>> --- >>> I could also have made it unref the packet's buffer at the beginning; >>> this would have the advantage that the packet's buffer would be freed >>> after the units have been rewritten (if they are rewritten) and after >>> the fragment's buffer has been unreferenced, so that maximum memory >>> consumption would decrease. It would also be in line with all current >>> callers of ff_cbs_write_packet, but maybe it wouldn't be what a future >>> caller wants. What do you think? >>> libavcodec/cbs.c | 3 ++- >>> libavcodec/cbs.h | 10 +- >>> 2 files changed, 11 insertions(+), 2 deletions(-) >>> >>> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c >>> index 0260ba6f67..47679eca1b 100644 >>> --- a/libavcodec/cbs.c >>> +++ b/libavcodec/cbs.c >>> @@ -357,7 +357,8 @@ int ff_cbs_write_packet(CodedBitstreamContext *ctx, >>> if (!buf) >>> return AVERROR(ENOMEM); >>> >>> -av_init_packet(pkt); >>> +av_buffer_unref(&pkt->buf); >> >> You should probably unref the packet, not just the AVBufferRef. > > Right, i see in patch 2 why you did this. I don't like much how with > this change ff_cbs_write_packet would leave the packet in a weird state > of having the filtered data alongside unrelated props already in packet > provided by the caller. If CBS is ever made public, i'm not sure it's a > behavior we should keep. > > But if right now it allows us to use ff_bsf_get_packet_ref() and remove > av_packet_copy_props() calls, then it's good. > Would you prefer if ff_cbs_write_packet gets renamed to ff_cbs_update_packet_data? Anyway, thanks for taking your time to review this. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/18] cbs_h264, h264_metadata: Deleting SEI messages never fails
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
> Deleting a unit from a fragment in CBS only fails if there is no unit
> in the fragment corresponding to the position given as argument to
> ff_cbs_delete_unit. Given that ff_cbs_h264_delete_sei_message asserts
> this to be so, we know that the call to ff_cbs_delete_unit can never
> fail and hence ff_cbs_h264_delete_sei_message doesn't need a return
> value at all. The existing checks for these return values can be deleted.
Same here. A single line saying it can't fail within the current loop
constrains or something like that should be enough.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/cbs_h264.h | 8
> libavcodec/cbs_h2645.c | 12 +---
> libavcodec/h264_metadata_bsf.c | 21 +
> 3 files changed, 14 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index a31be298ba..f63c19ffc0 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -479,9 +479,9 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
> *ctx,
> * Deletes from nal_unit, which must be an SEI NAL unit. If this is the
> * last message in nal_unit, also deletes it from access_unit.
> */
> -int ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> - CodedBitstreamFragment *access_unit,
> - CodedBitstreamUnit *nal_unit,
> - int position);
> +void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> +CodedBitstreamFragment *access_unit,
> +CodedBitstreamUnit *nal_unit,
> +int position);
>
> #endif /* AVCODEC_CBS_H264_H */
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 0456937710..a3bad83736 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -1644,10 +1644,10 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
> *ctx,
> return 0;
> }
>
> -int ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> - CodedBitstreamFragment *au,
> - CodedBitstreamUnit *nal,
> - int position)
> +void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> +CodedBitstreamFragment *au,
> +CodedBitstreamUnit *nal,
> +int position)
> {
> H264RawSEI *sei = nal->content;
>
> @@ -1664,7 +1664,7 @@ int
> ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> }
> av_assert0(i < au->nb_units && "NAL unit not in access unit.");
>
> -return ff_cbs_delete_unit(ctx, au, i);
> +ff_cbs_delete_unit(ctx, au, i);
> } else {
> cbs_h264_free_sei_payload(&sei->payload[position]);
>
> @@ -1672,7 +1672,5 @@ int
> ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
> memmove(sei->payload + position,
> sei->payload + position + 1,
> (sei->payload_count - position) * sizeof(*sei->payload));
> -
> -return 0;
> }
> }
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index d05b75be14..c7969f1152 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -438,15 +438,9 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *pkt)
>
> for (j = sei->payload_count - 1; j >= 0; j--) {
> if (sei->payload[j].payload_type ==
> -H264_SEI_TYPE_FILLER_PAYLOAD) {
> -err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
> - &au->units[i],
> j);
> -if (err < 0) {
> -av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> - "filler SEI message.\n");
> -goto fail;
> -}
> -}
> +H264_SEI_TYPE_FILLER_PAYLOAD)
> +ff_cbs_h264_delete_sei_message(ctx->cbc, au,
> + &au->units[i], j);
> }
> }
> }
> @@ -470,13 +464,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *pkt)
>
> if (ctx->display_orientation == REMOVE ||
> ctx->display_orientation == INSERT) {
> -err = ff_cbs_h264_delete_sei_message(ctx->cbc, au,
> - &au->units[i], j);
> -if (err < 0) {
> -av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> -
Re: [FFmpeg-devel] [PATCH v2] avfilter/avf_aphasemeter: Add out-of-phase and mono detection
Hello,
Thank you for your feedback.
I made a third version of my patch.
Regards,
Romane
Le lun. 27 mai 2019 à 21:07, Moritz Barsnick a écrit :
> On Mon, May 20, 2019 at 14:40:24 +0200, Romane Lafon wrote:
> > +float tolerance = 1.0 - s->tolerance;
>
> Strictly speaking 1.0f (or 1.f).
>
> > +float angle = cos(s->angle/180.0*PI);
>
> If you want a float as result, use cosf(s->angle / 180.f * M_PI). (I'm
> aware PI and M_PI aren't explicitly marked as float, but you can't have
> it all.)
>
> > +if (!s->is_mono && ((tolerance - fphase) < FLT_EPSILON)) {
> [...]
> > +if (s->is_mono && ((tolerance - fphase) < FLT_EPSILON) &&
> s->start_mono_presence) {
> [...]
> > +if (s->is_mono && ((tolerance - fphase) > FLT_EPSILON)) {
> [...]
>
> As tolerance and fphase are constant throughout this block of code, you
> could do this floating point comparison once, and reuse the boolean
> result.
>
> BTW, I reckon the third of those comparisons should be ">=", to
> properly complement the "<".
>
> > +if (!s->is_out_phase && (angle - fphase) > FLT_EPSILON) {
> [...]
> > +if (s->is_out_phase && ((angle - fphase) > FLT_EPSILON) &&
> s->start_out_phase_presence) {
> [...]
> > +if (s->is_out_phase && (angle - fphase) < FLT_EPSILON) {
> [...]
>
> Same here.
>
> > +float tolerance = 1.0 - s->tolerance;
> > +float angle = cos(s->angle/180.0*PI);
>
> Same as above.
>
> Cheers,
> Moritz
> ___
> 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 v3] avfilter/avf_aphasemeter: Add out-of-phase and mono detection
New version of the patch that extends aphasemeter filter.
It allows to get metadata for out-of-phase or mono sequences of stereo
streams.
It displays start, end and duration as for silencedetect filter.
From 8eacd044bb4c69553e25fbd08c3be07c00af5be0 Mon Sep 17 00:00:00 2001
From: Romane Lafon
Date: Mon, 17 Jun 2019 14:31:14 +0200
Subject: [PATCH] avfilter/avf_aphasemeter: Add out of phase and mono detection
Signed-off-by: Romane Lafon
---
libavfilter/avf_aphasemeter.c | 127 --
1 file changed, 123 insertions(+), 4 deletions(-)
diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
index f497bc9969..77701e5cde 100644
--- a/libavfilter/avf_aphasemeter.c
+++ b/libavfilter/avf_aphasemeter.c
@@ -28,26 +28,41 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "libavutil/parseutils.h"
+#include "libavutil/timestamp.h"
#include "avfilter.h"
#include "formats.h"
#include "audio.h"
#include "video.h"
#include "internal.h"
+#include "stdbool.h"
+#include "float.h"
typedef struct AudioPhaseMeterContext {
const AVClass *class;
AVFrame *out;
int do_video;
+int do_phasing_detection;
int w, h;
AVRational frame_rate;
int contrast[4];
uint8_t *mpc_str;
uint8_t mpc[4];
int draw_median_phase;
+int is_mono;
+int is_out_phase;
+int start_mono_presence;
+int start_out_phase_presence;
+float tolerance;
+float angle;
+float phase;
+float mono_idx[2];
+float out_phase_idx[2];
+double duration;
} AudioPhaseMeterContext;
#define OFFSET(x) offsetof(AudioPhaseMeterContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+#define get_duration(index) (index[1] - index[0])
static const AVOption aphasemeter_options[] = {
{ "rate", "set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE, {.str="25"}, 0, INT_MAX, FLAGS },
@@ -59,6 +74,10 @@ static const AVOption aphasemeter_options[] = {
{ "bc", "set blue contrast", OFFSET(contrast[2]), AV_OPT_TYPE_INT, {.i64=1}, 0, 255, FLAGS },
{ "mpc", "set median phase color", OFFSET(mpc_str), AV_OPT_TYPE_STRING, {.str = "none"}, 0, 0, FLAGS },
{ "video", "set video output", OFFSET(do_video), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+{ "phasing", "set mono and out-of-phase detection output", OFFSET(do_phasing_detection), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
+{ "tolerance", "set phase tolerance for mono detection", OFFSET(tolerance), AV_OPT_TYPE_FLOAT, {.dbl = 0.}, 0, 1, FLAGS },
+{ "angle", "set angle threshold for out-of-phase detection", OFFSET(angle), AV_OPT_TYPE_FLOAT, {.dbl = 170.}, 90, 180, FLAGS },
+{ "duration", "set minimum mono or out-of-phase duration in seconds", OFFSET(duration), AV_OPT_TYPE_DOUBLE, {.dbl=2.}, 0, 24*60*60, FLAGS },
{ NULL }
};
@@ -140,6 +159,22 @@ static inline int get_x(float phase, int w)
return (phase + 1.) / 2. * (w - 1);
}
+static inline float get_index(AVFilterLink *inlink, AVFrame *in)
+{
+char *index_str = av_ts2timestr(in->pts, &inlink->time_base);
+return atof(index_str);
+}
+
+static inline void add_metadata(AVFrame *insamples, const char *key, float value)
+{
+char buf[128];
+char str[128];
+
+snprintf(str, sizeof(str), "%f", value);
+snprintf(buf, sizeof(buf), "lavfi.aphasemeter.%s", key);
+av_dict_set(&insamples->metadata, buf, str, 0);
+}
+
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
AVFilterContext *ctx = inlink->dst;
@@ -154,6 +189,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
AVFrame *out;
uint8_t *dst;
int i;
+int mono_measurement;
+int out_phase_measurement;
+float tolerance = 1.0f - s->tolerance;
+float angle = cosf(s->angle/180.0f*M_PI);
if (s->do_video && (!s->out || s->out->width != outlink->w ||
s->out->height != outlink->h)) {
@@ -193,7 +232,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
fphase += phase;
}
fphase /= in->nb_samples;
-
+s->phase = fphase;
if (s->do_video) {
if (s->draw_median_phase) {
dst = out->data[0] + get_x(fphase, s->w) * 4;
@@ -206,10 +245,64 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
metadata = &in->metadata;
if (metadata) {
-uint8_t value[128];
+add_metadata(in, "phase", fphase);
+}
-snprintf(value, sizeof(value), "%f", fphase);
-av_dict_set(metadata, "lavfi.aphasemeter.phase", value, 0);
+if (s->do_phasing_detection) {
+mono_measurement = (tolerance - fphase) < FLT_EPSILON;
+out_phase_measurement = (angle - fphase) > FLT_EPSILON;
+if (!s->is_mono && mono_measurement) {
+s->is_mono = 1;
+s->start_mono_presence = 1;
+s->mono_idx[0] = get_index(inlink, in);
+}
+if (s->is_mono && mono_measuremen
Re: [FFmpeg-devel] [PATCH 10/18] cbs: Remove superfluous checks for ff_cbs_delete_unit
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote:
> ff_cbs_delete_unit never fails if the index of the unit to delete is
> valid; document this behaviour explicitly and remove the checks for
> whether ff_cbs_delete_unit failed, because all the callers of
> ff_cbs_delete_unit already make sure that the index is valid.
Add a comment about why you're ignoring the return values in all three
filters. If for whatever reason the filters are changed in the future
and it can no longer be ensured the call will never fail, the developer
should be aware of it.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Several callers already ignored to check the return value.
>
> libavcodec/av1_metadata_bsf.c | 9 ++---
> libavcodec/cbs.h| 2 ++
> libavcodec/h264_metadata_bsf.c | 7 +--
> libavcodec/h264_redundant_pps_bsf.c | 4 +---
> 4 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
> index 842b80c201..dafddced63 100644
> --- a/libavcodec/av1_metadata_bsf.c
> +++ b/libavcodec/av1_metadata_bsf.c
> @@ -161,13 +161,8 @@ static int av1_metadata_filter(AVBSFContext *bsf,
> AVPacket *pkt)
>
> if (ctx->delete_padding) {
> for (i = frag->nb_units - 1; i >= 0; i--) {
> -if (frag->units[i].type == AV1_OBU_PADDING) {
> -err = ff_cbs_delete_unit(ctx->cbc, frag, i);
> -if (err < 0) {
> -av_log(bsf, AV_LOG_ERROR, "Failed to delete Padding
> OBU.\n");
> -goto fail;
> -}
> -}
> +if (frag->units[i].type == AV1_OBU_PADDING)
> +ff_cbs_delete_unit(ctx->cbc, frag, i);
> }
> }
>
> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
> index 5260a39c63..e1e6055ceb 100644
> --- a/libavcodec/cbs.h
> +++ b/libavcodec/cbs.h
> @@ -380,6 +380,8 @@ int ff_cbs_insert_unit_data(CodedBitstreamContext *ctx,
>
> /**
> * Delete a unit from a fragment and free all memory it uses.
> + *
> + * Never returns failure if position is >= 0 and < frag->nb_units.
> */
> int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
> CodedBitstreamFragment *frag,
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index f7ca1f0f09..d05b75be14 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -428,12 +428,7 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *pkt)
> for (i = au->nb_units - 1; i >= 0; i--) {
> if (au->units[i].type == H264_NAL_FILLER_DATA) {
> // Filler NAL units.
> -err = ff_cbs_delete_unit(ctx->cbc, au, i);
> -if (err < 0) {
> -av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> - "filler NAL.\n");
> -goto fail;
> -}
> +ff_cbs_delete_unit(ctx->cbc, au, i);
> continue;
> }
>
> diff --git a/libavcodec/h264_redundant_pps_bsf.c
> b/libavcodec/h264_redundant_pps_bsf.c
> index db8717d69a..8526b5b4c4 100644
> --- a/libavcodec/h264_redundant_pps_bsf.c
> +++ b/libavcodec/h264_redundant_pps_bsf.c
> @@ -95,9 +95,7 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
> AVPacket *out)
> if (!au_has_sps) {
> av_log(bsf, AV_LOG_VERBOSE, "Deleting redundant PPS "
> "at %"PRId64".\n", in->pts);
> -err = ff_cbs_delete_unit(ctx->input, au, i);
> -if (err < 0)
> -goto fail;
> +ff_cbs_delete_unit(ctx->input, au, i);
> }
> }
> if (nal->type == H264_NAL_SLICE ||
>
___
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 01/18] cbs: Allow non-blank packets in ff_cbs_write_packet
On 6/17/2019 9:44 AM, James Almer wrote: > On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote: >> Up until now, ff_cbs_write_packet always initialized the packet >> structure it received without documenting this behaviour; furthermore, >> the packet's buffer would (on success) be overwritten with the new >> buffer without unreferencing the old. This meant that the input packet >> had to be either clean (otherwise there would be memleaks) in which case >> the initialization is redundant or uninitialized. ff_cbs_write_packet >> was never used with uninitialized packets, so the initialization was >> redundant. Worse yet, it forced callers to use more than one packet and >> made it difficult to add side-data to a packet designated for output, >> because said side-data could only be attached after the call to >> ff_cbs_write_packet. >> >> This has been changed. It is now allowed to use a non-blank packet. >> The currently existing buffer will be unreferenced and replaced by >> the new one, as will be the accompanying fields (i.e. data and size). >> The rest isn't touched at all. >> >> This change will enable us to use only one packet in the bitstream >> filters that rely on CBS. >> >> This commit also updates the documentation of ff_cbs_write_extradata >> and ff_cbs_write_packet (to better describe existing behaviour and in >> the latter case to also describe the new behaviour). >> >> Signed-off-by: Andreas Rheinhardt >> --- >> I could also have made it unref the packet's buffer at the beginning; >> this would have the advantage that the packet's buffer would be freed >> after the units have been rewritten (if they are rewritten) and after >> the fragment's buffer has been unreferenced, so that maximum memory >> consumption would decrease. It would also be in line with all current >> callers of ff_cbs_write_packet, but maybe it wouldn't be what a future >> caller wants. What do you think? >> libavcodec/cbs.c | 3 ++- >> libavcodec/cbs.h | 10 +- >> 2 files changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c >> index 0260ba6f67..47679eca1b 100644 >> --- a/libavcodec/cbs.c >> +++ b/libavcodec/cbs.c >> @@ -357,7 +357,8 @@ int ff_cbs_write_packet(CodedBitstreamContext *ctx, >> if (!buf) >> return AVERROR(ENOMEM); >> >> -av_init_packet(pkt); >> +av_buffer_unref(&pkt->buf); > > You should probably unref the packet, not just the AVBufferRef. Right, i see in patch 2 why you did this. I don't like much how with this change ff_cbs_write_packet would leave the packet in a weird state of having the filtered data alongside unrelated props already in packet provided by the caller. If CBS is ever made public, i'm not sure it's a behavior we should keep. But if right now it allows us to use ff_bsf_get_packet_ref() and remove av_packet_copy_props() calls, then it's good. > >> + >> pkt->buf = buf; >> pkt->data = frag->data; >> pkt->size = frag->data_size; >> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h >> index 967dcd1468..5260a39c63 100644 >> --- a/libavcodec/cbs.h >> +++ b/libavcodec/cbs.h >> @@ -297,7 +297,8 @@ int ff_cbs_write_fragment_data(CodedBitstreamContext >> *ctx, >> /** >> * Write the bitstream of a fragment to the extradata in codec parameters. >> * >> - * This replaces any existing extradata in the structure. >> + * Modifies context and fragment as ff_cbs_write_fragment_data does and >> + * replaces any existing extradata in the structure. >> */ >> int ff_cbs_write_extradata(CodedBitstreamContext *ctx, >> AVCodecParameters *par, >> @@ -305,6 +306,13 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx, >> >> /** >> * Write the bitstream of a fragment to a packet. >> + * >> + * Modifies context and fragment as ff_cbs_write_fragment_data does. >> + * >> + * On success, the packet's buf is unreferenced and its buf, data and >> + * size fields are set to the corresponding values from the newly updated >> + * fragment; other fields are not touched. On failure, the packet is not >> + * touched at all. >> */ >> int ff_cbs_write_packet(CodedBitstreamContext *ctx, >> AVPacket *pkt, >> > ___ 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 01/18] cbs: Allow non-blank packets in ff_cbs_write_packet
On 6/17/2019 12:42 AM, Andreas Rheinhardt wrote: > Up until now, ff_cbs_write_packet always initialized the packet > structure it received without documenting this behaviour; furthermore, > the packet's buffer would (on success) be overwritten with the new > buffer without unreferencing the old. This meant that the input packet > had to be either clean (otherwise there would be memleaks) in which case > the initialization is redundant or uninitialized. ff_cbs_write_packet > was never used with uninitialized packets, so the initialization was > redundant. Worse yet, it forced callers to use more than one packet and > made it difficult to add side-data to a packet designated for output, > because said side-data could only be attached after the call to > ff_cbs_write_packet. > > This has been changed. It is now allowed to use a non-blank packet. > The currently existing buffer will be unreferenced and replaced by > the new one, as will be the accompanying fields (i.e. data and size). > The rest isn't touched at all. > > This change will enable us to use only one packet in the bitstream > filters that rely on CBS. > > This commit also updates the documentation of ff_cbs_write_extradata > and ff_cbs_write_packet (to better describe existing behaviour and in > the latter case to also describe the new behaviour). > > Signed-off-by: Andreas Rheinhardt > --- > I could also have made it unref the packet's buffer at the beginning; > this would have the advantage that the packet's buffer would be freed > after the units have been rewritten (if they are rewritten) and after > the fragment's buffer has been unreferenced, so that maximum memory > consumption would decrease. It would also be in line with all current > callers of ff_cbs_write_packet, but maybe it wouldn't be what a future > caller wants. What do you think? > libavcodec/cbs.c | 3 ++- > libavcodec/cbs.h | 10 +- > 2 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c > index 0260ba6f67..47679eca1b 100644 > --- a/libavcodec/cbs.c > +++ b/libavcodec/cbs.c > @@ -357,7 +357,8 @@ int ff_cbs_write_packet(CodedBitstreamContext *ctx, > if (!buf) > return AVERROR(ENOMEM); > > -av_init_packet(pkt); > +av_buffer_unref(&pkt->buf); You should probably unref the packet, not just the AVBufferRef. > + > pkt->buf = buf; > pkt->data = frag->data; > pkt->size = frag->data_size; > diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h > index 967dcd1468..5260a39c63 100644 > --- a/libavcodec/cbs.h > +++ b/libavcodec/cbs.h > @@ -297,7 +297,8 @@ int ff_cbs_write_fragment_data(CodedBitstreamContext *ctx, > /** > * Write the bitstream of a fragment to the extradata in codec parameters. > * > - * This replaces any existing extradata in the structure. > + * Modifies context and fragment as ff_cbs_write_fragment_data does and > + * replaces any existing extradata in the structure. > */ > int ff_cbs_write_extradata(CodedBitstreamContext *ctx, > AVCodecParameters *par, > @@ -305,6 +306,13 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx, > > /** > * Write the bitstream of a fragment to a packet. > + * > + * Modifies context and fragment as ff_cbs_write_fragment_data does. > + * > + * On success, the packet's buf is unreferenced and its buf, data and > + * size fields are set to the corresponding values from the newly updated > + * fragment; other fields are not touched. On failure, the packet is not > + * touched at all. > */ > int ff_cbs_write_packet(CodedBitstreamContext *ctx, > AVPacket *pkt, > ___ 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] movenc: calculate track_duration without packet duration
On 17-06-2019 01:37 PM, Alfred E. Heggestad wrote:
From c69b63a7af5531257753754e64ac33b7ef530e75 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad"
Date: Mon, 17 Jun 2019 10:04:08 +0200
Subject: [PATCH] movenc: calculate track_duration without packet duration
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 46d314ff17..fa5833962b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5486,7 +5486,7 @@ int ff_mov_write_packet(AVFormatContext *s,
AVPacket *pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
- trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
+ trk->track_duration = pkt->dts - trk->start_dts;
Why?
trk->last_sample_is_subtitle_end = 0;
if (pkt->pts == AV_NOPTS_VALUE) {
Gyan
___
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/dnn: move dnn files from libavfilter to libavfilter/dnn
it is expected that there will be more files to support native mode,
so put all the dnn codes under libavfilter/dnn
The main change of this patch is to move the file location, see below:
modified: libavfilter/Makefile
new file: libavfilter/dnn/Makefile
renamed:libavfilter/dnn_backend_native.c ->
libavfilter/dnn/dnn_backend_native.c
renamed:libavfilter/dnn_backend_native.h ->
libavfilter/dnn/dnn_backend_native.h
renamed:libavfilter/dnn_backend_tf.c -> libavfilter/dnn/dnn_backend_tf.c
renamed:libavfilter/dnn_backend_tf.h -> libavfilter/dnn/dnn_backend_tf.h
renamed:libavfilter/dnn_interface.c -> libavfilter/dnn/dnn_interface.c
Signed-off-by: Guo, Yejun
---
libavfilter/Makefile | 3 +-
libavfilter/dnn/Makefile | 6 +
libavfilter/dnn/dnn_backend_native.c | 389 ++
libavfilter/dnn/dnn_backend_native.h | 74 +
libavfilter/dnn/dnn_backend_tf.c | 603 +++
libavfilter/dnn/dnn_backend_tf.h | 38 +++
libavfilter/dnn/dnn_interface.c | 63
libavfilter/dnn_backend_native.c | 389 --
libavfilter/dnn_backend_native.h | 74 -
libavfilter/dnn_backend_tf.c | 603 ---
libavfilter/dnn_backend_tf.h | 38 ---
libavfilter/dnn_interface.c | 63
12 files changed, 1174 insertions(+), 1169 deletions(-)
create mode 100644 libavfilter/dnn/Makefile
create mode 100644 libavfilter/dnn/dnn_backend_native.c
create mode 100644 libavfilter/dnn/dnn_backend_native.h
create mode 100644 libavfilter/dnn/dnn_backend_tf.c
create mode 100644 libavfilter/dnn/dnn_backend_tf.h
create mode 100644 libavfilter/dnn/dnn_interface.c
delete mode 100644 libavfilter/dnn_backend_native.c
delete mode 100644 libavfilter/dnn_backend_native.h
delete mode 100644 libavfilter/dnn_backend_tf.c
delete mode 100644 libavfilter/dnn_backend_tf.h
delete mode 100644 libavfilter/dnn_interface.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 07ea8d7..dd34c5f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -26,9 +26,8 @@ OBJS-$(HAVE_THREADS) += pthread.o
# subsystems
OBJS-$(CONFIG_QSVVPP)+= qsvvpp.o
-DNN-OBJS-$(CONFIG_LIBTENSORFLOW) += dnn_backend_tf.o
-OBJS-$(CONFIG_DNN) += dnn_interface.o
dnn_backend_native.o $(DNN-OBJS-yes)
OBJS-$(CONFIG_SCENE_SAD) += scene_sad.o
+include $(SRC_PATH)/libavfilter/dnn/Makefile
# audio filters
OBJS-$(CONFIG_ABENCH_FILTER) += f_bench.o
diff --git a/libavfilter/dnn/Makefile b/libavfilter/dnn/Makefile
new file mode 100644
index 000..1d12ade
--- /dev/null
+++ b/libavfilter/dnn/Makefile
@@ -0,0 +1,6 @@
+OBJS-$(CONFIG_DNN) += dnn/dnn_interface.o
+OBJS-$(CONFIG_DNN) += dnn/dnn_backend_native.o
+
+DNN-OBJS-$(CONFIG_LIBTENSORFLOW) += dnn/dnn_backend_tf.o
+
+OBJS-$(CONFIG_DNN) += $(DNN-OBJS-yes)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
new file mode 100644
index 000..82e900b
--- /dev/null
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -0,0 +1,389 @@
+/*
+ * Copyright (c) 2018 Sergey Lavrushkin
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * DNN native backend implementation.
+ */
+
+#include "dnn_backend_native.h"
+#include "libavutil/avassert.h"
+
+static DNNReturnType set_input_output_native(void *model, DNNInputData *input,
const char *input_name, const char **output_names, uint32_t nb_output)
+{
+ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
+InputParams *input_params;
+ConvolutionalParams *conv_params;
+DepthToSpaceParams *depth_to_space_params;
+int cur_width, cur_height, cur_channels;
+int32_t layer;
+
+if (network->layers_num <= 0 || network->layers[0].type != INPUT){
+return DNN_ERROR;
+}
+else{
+input_params = (InputParams *)network->layers[0].params;
+input_params->width = cur_width = input->width;
+input_params->height = cur_height = input->height;
+input_params->chann
Re: [FFmpeg-devel] [PATCH 2/3] lavf/webm_chunk: Fix NULL dereference
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> Andreas Rheinhardt:
>>> The earlier version of the webm_chunk muxer had several bugs:
>>>
>>> 1. If the first packet of an audio stream didn't have a PTS of zero,
>>> then no chunk will be started before a packet is delivered to the
>>> underlying Matroska/WebM muxer, i.e. the AVFormatContext used to write
>>> these packets had a NULL as AVIOContext for output. This is behind the
>>> crash in ticket #5752.
>>>
>>> 2. If an error happens during writing a packet, the underlyimg
>>> Matroska/WebM muxer context is freed. This leads to a use-after-free
>>> coupled with a double-free in webm_chunk_write_trailer (which supposes
>>> that the underlying AVFormatContext is still valid).
>>>
>>> 3. Even when no error occurs at all, webm_chunk_write_trailer is still
>>> buggy: After the underlying Matroska/WebM muxer has written its trailer,
>>> ending the chunk implicitly flushes it again which is illegal at this
>>> point.
>>>
>>> These bugs have been fixed.
>>>
>>> Fixes #5752.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavformat/webm_chunk.c | 44 +---
>>> 1 file changed, 23 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
>>> index 2c99753b5b..391fee721a 100644
>>> --- a/libavformat/webm_chunk.c
>>> +++ b/libavformat/webm_chunk.c
>>> @@ -168,7 +168,7 @@ static int chunk_start(AVFormatContext *s)
>>> return 0;
>>> }
>>>
>>> -static int chunk_end(AVFormatContext *s)
>>> +static int chunk_end(AVFormatContext *s, int flush)
>>> {
>>> WebMChunkContext *wc = s->priv_data;
>>> AVFormatContext *oc = wc->avf;
>>> @@ -179,11 +179,14 @@ static int chunk_end(AVFormatContext *s)
>>> char filename[MAX_FILENAME_SIZE];
>>> AVDictionary *options = NULL;
>>>
>>> -if (wc->chunk_start_index == wc->chunk_index)
>>> +if (!oc->pb)
>>> return 0;
>>> -// Flush the cluster in WebM muxer.
>>> -oc->oformat->write_packet(oc, NULL);
>>> +
>>> +if (flush)
>>> +// Flush the cluster in WebM muxer.
>>> +oc->oformat->write_packet(oc, NULL);
>>> buffer_size = avio_close_dyn_buf(oc->pb, &buffer);
>>> +oc->pb = NULL;
>>> ret = get_chunk_filename(s, 0, filename);
>>> if (ret < 0)
>>> goto fail;
>>> @@ -194,7 +197,6 @@ static int chunk_end(AVFormatContext *s)
>>> goto fail;
>>> avio_write(pb, buffer, buffer_size);
>>> ff_format_io_close(s, &pb);
>>> -oc->pb = NULL;
>>> fail:
>>> av_dict_free(&options);
>>> av_free(buffer);
>>> @@ -216,27 +218,19 @@ static int webm_chunk_write_packet(AVFormatContext
>>> *s, AVPacket *pkt)
>>> }
>>>
>>> // For video, a new chunk is started only on key frames. For audio, a
>>> new
>>> -// chunk is started based on chunk_duration.
>>> -if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>>> +// chunk is started based on chunk_duration. Also, a new chunk is
>>> started
>>> +// unconditionally if there is no currently open chunk.
>>> +if (!oc->pb || (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>>> (pkt->flags & AV_PKT_FLAG_KEY)) ||
>>> (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
>>> - (pkt->pts == 0 || wc->duration_written >= wc->chunk_duration))) {
>>> + wc->duration_written >= wc->chunk_duration)) {
>>> wc->duration_written = 0;
>>> -if ((ret = chunk_end(s)) < 0 || (ret = chunk_start(s)) < 0) {
>>> -goto fail;
>>> +if ((ret = chunk_end(s, 1)) < 0 || (ret = chunk_start(s)) < 0) {
>>> +return ret;
>>> }
>>> }
>>>
>>> ret = oc->oformat->write_packet(oc, pkt);
>>> -if (ret < 0)
>>> -goto fail;
>>> -
>>> -fail:
>>> -if (ret < 0) {
>>> -oc->streams = NULL;
>>> -oc->nb_streams = 0;
>>> -avformat_free_context(oc);
>>> -}
>>>
>>> return ret;
>>> }
>>> @@ -245,12 +239,20 @@ static int webm_chunk_write_trailer(AVFormatContext
>>> *s)
>>> {
>>> WebMChunkContext *wc = s->priv_data;
>>> AVFormatContext *oc = wc->avf;
>>> +int ret;
>>> +
>>> +if (!oc->pb) {
>>> +ret = chunk_start(s);
>>> +if (ret < 0)
>>> +goto fail;
>>> +}
>>> oc->oformat->write_trailer(oc);
>>> -chunk_end(s);
>>> +ret = chunk_end(s, 0);
>>> +fail:
>>> oc->streams = NULL;
>>> oc->nb_streams = 0;
>>> avformat_free_context(oc);
>>> -return 0;
>>> +return ret;
>>> }
>>>
>>> #define OFFSET(x) offsetof(WebMChunkContext, x)
>>>
>>>
>> Ping for the last two patches of this patchset (i.e. this one and
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242902.html)
>>
>> - Andreas
>>
> And another ping for these two patches.
>
> - Andreas
>
Ping #3.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/f
[FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet duration
From c69b63a7af5531257753754e64ac33b7ef530e75 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad"
Date: Mon, 17 Jun 2019 10:04:08 +0200
Subject: [PATCH] movenc: calculate track_duration without packet duration
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 46d314ff17..fa5833962b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5486,7 +5486,7 @@ int ff_mov_write_packet(AVFormatContext *s,
AVPacket *pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
-trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
+trk->track_duration = pkt->dts - trk->start_dts;
trk->last_sample_is_subtitle_end = 0;
if (pkt->pts == AV_NOPTS_VALUE) {
--
2.20.1 (Apple Git-117)
___
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] avformat/ifv: added support for ifv cctv files
On Sun, Jun 16, 2019 at 07:19:54PM +0530, Swaraj Hota wrote: > On Sun, Jun 16, 2019 at 2:12 PM Paul B Mahol wrote: > > > On 6/16/19, Swaraj Hota wrote: > > > On Sun 16 Jun, 2019, 8:24 AM Peter Ross, wrote: > > > > > >> On Mon, Jun 10, 2019 at 09:25:27AM +0530, Swaraj Hota wrote: > > >> > Fixes ticket #2956. > > >> > > > >> > Signed-off-by: Swaraj Hota > > >> > --- > > >> > Added entry in "doc/general.texi". > > >> > --- > > >> > Changelog| 1 + > > >> > doc/general.texi | 2 + > > >> > libavformat/Makefile | 1 + > > >> > libavformat/allformats.c | 1 + > > >> > libavformat/ifv.c| 304 > > +++ > > >> > libavformat/version.h| 4 +- > > >> > 6 files changed, 311 insertions(+), 2 deletions(-) > > >> > create mode 100644 libavformat/ifv.c > > >> > > >> i think this is now ready to push. > > >> > > >> can you do that? if this for gsoc2019, does it first need blessing from > > >> mentor? > > >> > > > > > > I don't think that's required. ':D > > > > It is required, for sure. Mentor did not replied at all. > > > > Sorry I didn't know that. But he did tell me before (personally) to get it > pushed iirc. I guess he is busy right now. Anyway, I think it would be fair > to wait for a few days and then push if no further objections? agree. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] dash: change default MP4 extension to .m4s
From 923da82598bddd1ed05750427dbc71e607d296a2 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad"
Date: Mon, 17 Jun 2019 09:59:04 +0200
Subject: [PATCH] dash: change default MP4 extension to .m4s
this was changed in commit 281a21ed50849e3c8c0d03005230e9fd07c24370
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 3fd7e78166..a51a1da0ca 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -166,7 +166,7 @@ static struct format_string {
const char *str;
} formats[] = {
{ SEGMENT_TYPE_AUTO, "auto" },
-{ SEGMENT_TYPE_MP4, "mp4" },
+{ SEGMENT_TYPE_MP4, "m4s" },
{ SEGMENT_TYPE_WEBM, "webm" },
{ 0, NULL }
};
--
2.20.1 (Apple Git-117)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/segment: fix increment_tc
On 15-06-2019 04:57 PM, Gyan wrote: On 14-06-2019 10:45 PM, Gyan wrote: Fixes an issue brought to my attention at Super User. v2 fixes inadvertent stream TC creation when non existed. Plan to push tomorrow. Gyan ___ 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".
