Re: [FFmpeg-devel] [PATCH v3 02/25] avfilter/avfilter: Allow to free non-static pads generically

[Nicolas George]

Andreas Rheinhardt (12021-08-22):
> This can be enabled/disabled on a per-pad basis by setting
> the AVFILTERPAD_FLAG_FREE_NAME flag; variants of ff_append_(in|out)pads
> that do this for you have been added and will be put to use in the
> following commits.

This is an even better solution, kudos.

> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/avfilter.c | 21 -
>  libavfilter/internal.h | 10 ++
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 2681d04fc0..4b6a3d1e8f 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -123,8 +123,11 @@ static int append_pad(unsigned *count, AVFilterPad 
> **pads,
>  *pads  = newpads;
>  if (newlinks)
>  *links = newlinks;
> -if (!newpads || !newlinks)
> +if (!newpads || !newlinks) {
> +if (newpad->flags & AVFILTERPAD_FLAG_FREE_NAME)
> +av_freep(&newpad->name);
>  return AVERROR(ENOMEM);
> +}
>  
>  memcpy(*pads + idx, newpad, sizeof(AVFilterPad));
>  (*links)[idx] = NULL;
> @@ -139,11 +142,23 @@ int ff_append_inpad(AVFilterContext *f, AVFilterPad *p)
>  return append_pad(&f->nb_inputs, &f->input_pads, &f->inputs, p);
>  }
>  

> +int ff_append_inpad_free_name(AVFilterContext *f, AVFilterPad *p)
> +{
> +p->flags |= AVFILTERPAD_FLAG_FREE_NAME;
> +return ff_append_inpad(f, p);
> +}

Suggestion for a later patch:

if (!p->name)
return AVERROR(ENOMEM);

That way, we can remove the checks in the filters.

> +
>  int ff_append_outpad(AVFilterContext *f, AVFilterPad *p)
>  {
>  return append_pad(&f->nb_outputs, &f->output_pads, &f->outputs, p);
>  }
>  
> +int ff_append_outpad_free_name(AVFilterContext *f, AVFilterPad *p)
> +{
> +p->flags |= AVFILTERPAD_FLAG_FREE_NAME;
> +return ff_append_outpad(f, p);
> +}
> +
>  int avfilter_link(AVFilterContext *src, unsigned srcpad,
>AVFilterContext *dst, unsigned dstpad)
>  {
> @@ -754,9 +769,13 @@ void avfilter_free(AVFilterContext *filter)
>  
>  for (i = 0; i < filter->nb_inputs; i++) {
>  free_link(filter->inputs[i]);
> +if (filter->input_pads[i].flags  & AVFILTERPAD_FLAG_FREE_NAME)
> +av_freep(&filter->input_pads[i].name);
>  }
>  for (i = 0; i < filter->nb_outputs; i++) {
>  free_link(filter->outputs[i]);
> +if (filter->output_pads[i].flags & AVFILTERPAD_FLAG_FREE_NAME)
> +av_freep(&filter->output_pads[i].name);
>  }
>  
>  if (filter->filter->priv_class)
> diff --git a/libavfilter/internal.h b/libavfilter/internal.h
> index cc95f06c4c..6ddf024d93 100644
> --- a/libavfilter/internal.h
> +++ b/libavfilter/internal.h
> @@ -68,6 +68,11 @@ struct AVFilterPad {
>   */
>  #define AVFILTERPAD_FLAG_NEEDS_WRITABLE  (1 << 0)
>  
> +/**
> + * The pad's name is allocated and should be freed generically.
> + */
> +#define AVFILTERPAD_FLAG_FREE_NAME   (1 << 1)
> +
>  /**
>   * A combination of AVFILTERPAD_FLAG_* flags.
>   */
> @@ -231,9 +236,14 @@ void ff_tlog_link(void *ctx, AVFilterLink *link, int 
> end);
>  
>  /**
>   * Append a new input/output pad to the filter's list of such pads.
> + *
> + * The *_free_name versions will set the AVFILTERPAD_FLAG_FREE_NAME flag
> + * ensuring that the name will be freed generically (even on insertion 
> error).
>   */
>  int ff_append_inpad (AVFilterContext *f, AVFilterPad *p);
>  int ff_append_outpad(AVFilterContext *f, AVFilterPad *p);
> +int ff_append_inpad_free_name (AVFilterContext *f, AVFilterPad *p);
> +int ff_append_outpad_free_name(AVFilterContext *f, AVFilterPad *p);
>  
>  /**
>   * Request an input frame from the filter at the other end of the link.

LGTM, and patches 1-24 too, I do not maintain most of them but they are
straightforward enough.

(Also, sorry for misspelling your name recently.)

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] libavcodec/libx264: add user data unregistered SEI encoding

[Brad Hards]

On Saturday, 14 August 2021 9:51:03 AM AEST Brad Hards wrote:
> On Friday, 6 August 2021 7:16:33 PM AEST Brad Hards wrote:
> > MISB ST 0604 and ST 2101 require user data unregistered SEI messages
> > (precision timestamps and sensor identifiers) to be included. That
> > currently isn't supported for libx264. This patch adds support
> > for user data unregistered SEI messages in accordance with ISO/IEC
> > 14496-10:2020(E) section D.1.7 (syntax) and D.2.7 (semantics).
> > 
> > This code is based on a similar change for libx265 (commit
> > 1f58503013720700a5adfd72c708e6275aefc165).
> > ---
> > 
> >  libavcodec/libx264.c | 30 ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index 9afaf19547..e9bbe8d494 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -32,6 +32,7 @@
> > 
> >  #include "internal.h"
> >  #include "packet_internal.h"
> >  #include "atsc_a53.h"
> > 
> > +#include "sei.h"
> > 
> >  #if defined(_MSC_VER)
> >  #define X264_API_IMPORTS 1
> > 
> > @@ -114,6 +115,9 @@ typedef struct X264Context {
> > 
> >   * encounter a frame with ROI side data.
> >   */
> >  
> >  int roi_warned;
> > 
> > +
> > +void *sei_data;
> > +int sei_data_size;
> > 
> >  } X264Context;
> >  
> >  static void X264_log(void *p, int level, const char *fmt, va_list args)
> > 
> > @@ -317,6 +321,9 @@ static int X264_frame(AVCodecContext *ctx, AVPacket
> > *pkt, const AVFrame *frame,> 
> >  x4->pic.img.i_plane = avfmt2_num_planes(ctx->pix_fmt);
> >  
> >  if (frame) {
> > 
> > +x264_sei_t *sei = &x4->pic.extra_sei;
> > +sei->num_payloads = 0;
> > +
> > 
> >  for (i = 0; i < x4->pic.img.i_plane; i++) {
> >  
> >  x4->pic.img.plane[i]= frame->data[i];
> >  x4->pic.img.i_stride[i] = frame->linesize[i];
> > 
> > @@ -439,6 +446,27 @@ static int X264_frame(AVCodecContext *ctx, AVPacket
> > *pkt, const AVFrame *frame,> 
> >  }
> >  
> >  }
> >  
> >  }
> > 
> > +
> > +for (int j = 0; j < frame->nb_side_data; j++) {
> > +AVFrameSideData *side_data = frame->side_data[j];
> > +void *tmp;
> > +x264_sei_payload_t *sei_payload;
> > +if (side_data->type != AV_FRAME_DATA_SEI_UNREGISTERED)
> > +continue;
> > +tmp = av_fast_realloc(x4->sei_data, &x4->sei_data_size,
> > (sei->num_payloads + 1) * sizeof(*sei_payload)); +if (!tmp) {
> > +av_freep(&x4->pic.extra_sei.payloads);
> > +av_freep(&x4->pic.prop.quant_offsets);
> > +return AVERROR(ENOMEM);
> > +}
> > +x4->sei_data = tmp;
> > +sei->payloads = x4->sei_data;
> > +sei_payload = &sei->payloads[sei->num_payloads];
> > +sei_payload->payload = side_data->data;
> > +sei_payload->payload_size = side_data->size;
> > +sei_payload->payload_type = SEI_TYPE_USER_DATA_UNREGISTERED;
> > +sei->num_payloads++;
> > +}
> > 
> >  }
> >  
> >  do {
> > 
> > @@ -505,6 +533,8 @@ static av_cold int X264_close(AVCodecContext *avctx)
> > 
> >  x264_param_cleanup(&x4->params);
> >  
> >  #endif
> > 
> > +av_freep(&x4->sei_data);
> > +
> > 
> >  if (x4->enc) {
> >  
> >  x264_encoder_close(x4->enc);
> >  x4->enc = NULL;
> 
> Ping on this patch.
Ping on this patch.

Brad



___
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/4] libavformat/concatdec: remove support for unsafe=-1

[Nicolas George]

Nicolas George (12021-08-20):
> Second patch updated with Andrea's comments.
> Final patch removing the in-protocol option syntax withdrawn for now.
> Other patches unchanged.
> Will push soon.

Series pushed.

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 1/5] avformat/av1dec: Set position of AVPackets given to BSF

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/av1dec.c | 44 +++-
 1 file changed, 15 insertions(+), 29 deletions(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index f6c575069e..e021615c1f 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -22,7 +22,6 @@
 #include "config.h"
 
 #include "libavutil/common.h"
-#include "libavutil/fifo.h"
 #include "libavutil/opt.h"
 #include "libavcodec/av1_parse.h"
 #include "libavcodec/bsf.h"
@@ -299,7 +298,6 @@ typedef struct ObuContext {
 const AVClass *class;
 AVBSFContext *bsf;
 AVRational framerate;
-AVFifoBuffer *fifo;
 } ObuContext;
 
 //For low overhead obu, we can't foresee the obu size before we parsed the 
header.
@@ -372,9 +370,6 @@ static int obu_probe(const AVProbeData *p)
 static int obu_read_header(AVFormatContext *s)
 {
 ObuContext *c = s->priv_data;
-c->fifo = av_fifo_alloc(MAX_OBU_HEADER_SIZE);
-if (!c->fifo)
-return AVERROR(ENOMEM);
 return read_header(s, &c->framerate, &c->bsf, c);
 }
 
@@ -383,37 +378,26 @@ static int obu_get_packet(AVFormatContext *s, AVPacket 
*pkt)
 ObuContext *c = s->priv_data;
 uint8_t header[MAX_OBU_HEADER_SIZE + AV_INPUT_BUFFER_PADDING_SIZE];
 int64_t obu_size;
-int size = av_fifo_space(c->fifo);
+int size;
 int ret, len, type;
 
-av_fifo_generic_write(c->fifo, s->pb, size,
-  (int (*)(void*, void*, int))avio_read);
-size = av_fifo_size(c->fifo);
-if (!size)
-return 0;
-
-av_fifo_generic_peek(c->fifo, header, size, NULL);
+if ((ret = ffio_ensure_seekback(s->pb, MAX_OBU_HEADER_SIZE)) < 0)
+return ret;
+size = avio_read(s->pb, header, MAX_OBU_HEADER_SIZE);
+if (size < 0)
+return size;
 
 len = read_obu_with_size(header, size, &obu_size, &type);
 if (len < 0) {
 av_log(c, AV_LOG_ERROR, "Failed to read obu\n");
 return len;
 }
+avio_seek(s->pb, -size, SEEK_CUR);
 
-ret = av_new_packet(pkt, len);
-if (ret < 0) {
-av_log(c, AV_LOG_ERROR, "Failed to allocate packet for obu\n");
-return ret;
-}
-size = FFMIN(size, len);
-av_fifo_generic_read(c->fifo, pkt->data, size, NULL);
-len -= size;
-if (len > 0) {
-ret = avio_read(s->pb, pkt->data + size, len);
-if (ret != len) {
-av_log(c, AV_LOG_ERROR, "Failed to read %d frome file\n", len);
-return ret < 0 ? ret : AVERROR_INVALIDDATA;
-}
+ret = av_get_packet(s->pb, pkt, len);
+if (ret != len) {
+av_log(c, AV_LOG_ERROR, "Failed to get packet for obu\n");
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
 }
 return 0;
 }
@@ -425,7 +409,10 @@ static int obu_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 while (1) {
 ret = obu_get_packet(s, pkt);
-if (ret < 0)
+/* In case of AVERROR_EOF we need to flush the BSF. Conveniently
+ * obu_get_packet() returns a blank pkt in this case which
+ * can be used to signal that the BSF should be flushed. */
+if (ret < 0 && ret != AVERROR_EOF)
 return ret;
 ret = av_bsf_send_packet(c->bsf, pkt);
 if (ret < 0) {
@@ -448,7 +435,6 @@ static int obu_read_close(AVFormatContext *s)
 {
 ObuContext *c = s->priv_data;
 
-av_fifo_freep(&c->fifo);
 av_bsf_free(&c->bsf);
 return 0;
 }
-- 
2.30.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".

[FFmpeg-devel] [PATCH 2/5] avformat/av1dec: Deduplicate Annex B and low overhead OBU AV1 demuxer

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/av1dec.c | 133 +++
 1 file changed, 47 insertions(+), 86 deletions(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index e021615c1f..d5d4548d8b 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -29,6 +29,14 @@
 #include "avio_internal.h"
 #include "internal.h"
 
+typedef struct AV1DemuxContext {
+const AVClass *class;
+AVBSFContext *bsf;
+AVRational framerate;
+uint32_t temporal_unit_size;
+uint32_t frame_unit_size;
+} AV1DemuxContext;
+
 //return < 0 if we need more data
 static int get_score(int type, int *seq)
 {
@@ -48,14 +56,15 @@ static int get_score(int type, int *seq)
 return 0;
 }
 
-static int read_header(AVFormatContext *s, const AVRational *framerate, 
AVBSFContext **bsf, void *logctx)
+static int av1_read_header(AVFormatContext *s)
 {
+AV1DemuxContext *const c = s->priv_data;
 const AVBitStreamFilter *filter = av_bsf_get_by_name("av1_frame_merge");
 AVStream *st;
 int ret;
 
 if (!filter) {
-av_log(logctx, AV_LOG_ERROR, "av1_frame_merge bitstream filter "
+av_log(s, AV_LOG_ERROR, "av1_frame_merge bitstream filter "
"not found. This is a bug, please report it.\n");
 return AVERROR_BUG;
 }
@@ -68,35 +77,49 @@ static int read_header(AVFormatContext *s, const AVRational 
*framerate, AVBSFCon
 st->codecpar->codec_id = AV_CODEC_ID_AV1;
 st->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
 
-st->internal->avctx->framerate = *framerate;
+st->internal->avctx->framerate = c->framerate;
 // taken from rawvideo demuxers
 avpriv_set_pts_info(st, 64, 1, 120);
 
-ret = av_bsf_alloc(filter, bsf);
+ret = av_bsf_alloc(filter, &c->bsf);
 if (ret < 0)
 return ret;
 
-ret = avcodec_parameters_copy((*bsf)->par_in, st->codecpar);
+ret = avcodec_parameters_copy(c->bsf->par_in, st->codecpar);
 if (ret < 0)
 return ret;
 
-ret = av_bsf_init(*bsf);
+ret = av_bsf_init(c->bsf);
 if (ret < 0)
 return ret;
 
 return 0;
 }
 
+static int av1_read_close(AVFormatContext *s)
+{
+AV1DemuxContext *const c = s->priv_data;
+
+av_bsf_free(&c->bsf);
+return 0;
+}
+
 #define DEC AV_OPT_FLAG_DECODING_PARAM
+#define OFFSET(x) offsetof(AV1DemuxContext, x)
+static const AVOption av1_options[] = {
+{ "framerate", "", OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
"25"}, 0, INT_MAX, DEC},
+{ NULL },
+};
+#undef OFFSET
+
+static const AVClass av1_demuxer_class = {
+.class_name = "AV1 Annex B/low overhead OBU demuxer",
+.item_name  = av_default_item_name,
+.option = av1_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
 
 #if CONFIG_AV1_DEMUXER
-typedef struct AnnexBContext {
-const AVClass *class;
-AVBSFContext *bsf;
-uint32_t temporal_unit_size;
-uint32_t frame_unit_size;
-AVRational framerate;
-} AnnexBContext;
 
 static int leb(AVIOContext *pb, uint32_t *len) {
 int more, i = 0;
@@ -193,15 +216,9 @@ static int annexb_probe(const AVProbeData *p)
 return 0;
 }
 
-static int annexb_read_header(AVFormatContext *s)
-{
-AnnexBContext *c = s->priv_data;
-return read_header(s, &c->framerate, &c->bsf, c);
-}
-
 static int annexb_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
-AnnexBContext *c = s->priv_data;
+AV1DemuxContext *const c = s->priv_data;
 uint32_t obu_unit_size;
 int ret, len;
 
@@ -256,50 +273,22 @@ end:
 return ret;
 }
 
-static int annexb_read_close(AVFormatContext *s)
-{
-AnnexBContext *c = s->priv_data;
-
-av_bsf_free(&c->bsf);
-return 0;
-}
-
-#define OFFSET(x) offsetof(AnnexBContext, x)
-static const AVOption annexb_options[] = {
-{ "framerate", "", OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
"25"}, 0, INT_MAX, DEC},
-{ NULL },
-};
-#undef OFFSET
-
-static const AVClass annexb_demuxer_class = {
-.class_name = "AV1 Annex B demuxer",
-.item_name  = av_default_item_name,
-.option = annexb_options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
 const AVInputFormat ff_av1_demuxer = {
 .name   = "av1",
 .long_name  = NULL_IF_CONFIG_SMALL("AV1 Annex B"),
-.priv_data_size = sizeof(AnnexBContext),
+.priv_data_size = sizeof(AV1DemuxContext),
 .flags_internal = FF_FMT_INIT_CLEANUP,
 .read_probe = annexb_probe,
-.read_header= annexb_read_header,
+.read_header= av1_read_header,
 .read_packet= annexb_read_packet,
-.read_close = annexb_read_close,
+.read_close = av1_read_close,
 .extensions = "obu",
 .flags  = AVFMT_GENERIC_INDEX,
-.priv_class = &annexb_demuxer_class,
+.priv_class = &av1_demuxer_class,
 };
 #endif
 
 #if CONFIG_OBU_DEMUXER
-typedef struct ObuContext {
-const AVClass *class;
-AVBSFContext *bsf;
-AVRational framerate;
-} ObuContext;
-
 //For low overhead obu, we

[FFmpeg-devel] [PATCH 3/5] avcodec/av1_frame_merge_bsf: Passthrough pos in case of no timestamps

[Andreas Rheinhardt]

This is needed by the AV1-Annex B and AV1-OBU demuxers.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/av1_frame_merge_bsf.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavcodec/av1_frame_merge_bsf.c b/libavcodec/av1_frame_merge_bsf.c
index fce5bdb67e..19b9cd01a8 100644
--- a/libavcodec/av1_frame_merge_bsf.c
+++ b/libavcodec/av1_frame_merge_bsf.c
@@ -103,10 +103,15 @@ eof:
 err = AVERROR(EAGAIN);
 }
 
-// Buffer packets with timestamps. There should be at most one per TU, be 
it split or not.
-if (!buffer_pkt->data && in->pts != AV_NOPTS_VALUE)
+/* Buffer packets with timestamps (there should be at most one per TU)
+ * or any packet if buffer_pkt is empty. The latter is needed to
+ * passthrough positions in case there are no timestamps like with
+ * the raw OBU demuxer. */
+if (!buffer_pkt->data ||
+in->pts != AV_NOPTS_VALUE && buffer_pkt->pts == AV_NOPTS_VALUE) {
+av_packet_unref(buffer_pkt);
 av_packet_move_ref(buffer_pkt, in);
-else
+} else
 av_packet_unref(in);
 
 ff_cbs_fragment_reset(&ctx->frag[ctx->idx]);
-- 
2.30.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".

[FFmpeg-devel] [PATCH 4/5] avformat/utils: Also set io_repositioned for generic seeking

[Andreas Rheinhardt]

It allows demuxers to perform certain tasks after
a successful generic seek.

Signed-off-by: Andreas Rheinhardt 
---
This io_repositioned and the flags which contain which type of seeking
a format supports are IMO implementation details that are only public
because up until recently there were no internal flags.

 libavformat/utils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5754fc1537..39f082d98d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2354,10 +2354,12 @@ static int seek_frame_generic(AVFormatContext *s, int 
stream_index,
 ie = &st->internal->index_entries[st->internal->nb_index_entries - 
1];
 if ((ret = avio_seek(s->pb, ie->pos, SEEK_SET)) < 0)
 return ret;
+s->io_repositioned = 1;
 avpriv_update_cur_dts(s, st, ie->timestamp);
 } else {
 if ((ret = avio_seek(s->pb, s->internal->data_offset, SEEK_SET)) < 
0)
 return ret;
+s->io_repositioned = 1;
 }
 av_packet_unref(pkt);
 for (;;) {
@@ -2392,6 +2394,7 @@ static int seek_frame_generic(AVFormatContext *s, int 
stream_index,
 ie = &st->internal->index_entries[index];
 if ((ret = avio_seek(s->pb, ie->pos, SEEK_SET)) < 0)
 return ret;
+s->io_repositioned = 1;
 avpriv_update_cur_dts(s, st, ie->timestamp);
 
 return 0;
-- 
2.30.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".

[FFmpeg-devel] [PATCH 5/5] avformat/av1dec: Flush BSF upon seeking

[Andreas Rheinhardt]

The av1_merge_frame BSF outputs its cached data when it sees the
beginning of a new frame, i.e. when it sees a temporal delimiter OBU.
Therefore it typically has a temporal delimiter OBU cached after
outputting a packet.

This implies that the OBU demuxer must flush its BSF upon seeking
because otherwise the first frame returned after a seek consists
of an old temporal delimiter OBU only.

Signed-off-by: Andreas Rheinhardt 
---
The AV1 Annex B demuxer also has two issues: It records the wrong
positions (it is off due to the annex b packetization) and it needs to
flush the bsf, too. Will look into it.

 libavformat/av1dec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index d5d4548d8b..88a3c325e4 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -390,6 +390,10 @@ static int obu_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 AV1DemuxContext *const c = s->priv_data;
 int ret;
 
+if (s->io_repositioned) {
+av_bsf_flush(c->bsf);
+s->io_repositioned = 0;
+}
 while (1) {
 ret = obu_get_packet(s, pkt);
 /* In case of AVERROR_EOF we need to flush the BSF. Conveniently
-- 
2.30.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] avformat/mov: add AVFMT_SHOW_IDS flag

[Gyan Doshi]

Pushed as d905af0c2409c854dcd45a05fe4caf9ac49d82ad

On 2021-08-21 10:50 am, Gyan Doshi wrote:

The RFC was posted 10 days ago. Plan to push tomorrow.

On 2021-08-20 05:12 pm, Gyan Doshi wrote:

The MOV muxer can store streamids as track ids but they aren't
visible when probing the result via lavf/dump or ffprobe due to
lack of this flag in the demuxer.
---
  libavformat/mov.c | 2 +-
  tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov | 2 +-
  tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov | 2 +-
  tests/ref/fate/mov-zombie | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 46bc7b5aa3..c556390525 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8216,5 +8216,5 @@ const AVInputFormat ff_mov_demuxer = {
  .read_packet    = mov_read_packet,
  .read_close = mov_read_close,
  .read_seek  = mov_read_seek,
-    .flags  = AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS,
+    .flags  = AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS | 
AVFMT_SHOW_IDS,

  };
diff --git 
a/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov 
b/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov

index 4ef569df89..8d21c396fc 100644
--- a/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
+++ b/tests/ref/fate/hapqa-extract-nosnappy-to-hapalphaonly-mov
@@ -36,7 +36,7 @@ color_primaries=unknown
  chroma_location=unspecified
  field_order=unknown
  refs=1
-id=N/A
+id=0x1
  r_frame_rate=25/1
  avg_frame_rate=25/1
  time_base=1/12800
diff --git a/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov 
b/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov

index 70e7cdc943..6f1f7c543f 100644
--- a/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
+++ b/tests/ref/fate/hapqa-extract-nosnappy-to-hapq-mov
@@ -36,7 +36,7 @@ color_primaries=unknown
  chroma_location=unspecified
  field_order=unknown
  refs=1
-id=N/A
+id=0x1
  r_frame_rate=25/1
  avg_frame_rate=25/1
  time_base=1/12800
diff --git a/tests/ref/fate/mov-zombie b/tests/ref/fate/mov-zombie
index 6e6d43d563..b6656de744 100644
--- a/tests/ref/fate/mov-zombie
+++ b/tests/ref/fate/mov-zombie
@@ -194,5 +194,5 @@ 
frame|media_type=video|stream_index=0|key_frame=0|pts=188623|pts_time=2.095811|p

packet|codec_type=video|stream_index=0|pts=197632|pts_time=2.195911|dts=191625|dts_time=2.129167|duration=3003|duration_time=0.033367|size=580|pos=101820|flags=__
frame|media_type=video|stream_index=0|key_frame=0|pts=191626|pts_time=2.129178|pkt_dts=N/A|pkt_dts_time=N/A|best_effort_timestamp=191626|best_effort_timestamp_time=2.129178|pkt_duration=3003|pkt_duration_time=0.033367|pkt_pos=99180|pkt_size=1666|width=160|height=240|pix_fmt=yuv420p|sample_aspect_ratio=2:1|pict_type=P|coded_picture_number=63|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=tv|color_space=smpte170m|color_primaries=smpte170m|color_transfer=bt709|chroma_location=topleftside_data|side_data_type=H.26[45] 
User Data Unregistered SEI message

-stream|index=0|codec_name=h264|profile=77|codec_type=video|codec_tag_string=avc1|codec_tag=0x31637661|width=160|height=240|coded_width=160|coded_height=240|closed_captions=0|has_b_frames=1|sample_aspect_ratio=2:1|display_aspect_ratio=4:3|pix_fmt=yuv420p|level=12|color_range=tv|color_space=smpte170m|color_transfer=bt709|color_primaries=smpte170m|chroma_location=topleft|field_order=unknown|refs=2|is_avc=true|nal_length_size=4|id=N/A|r_frame_rate=3/1001|avg_frame_rate=6372000/212521|time_base=1/9|start_pts=0|start_time=0.00|duration_ts=2125200|duration=23.61|bit_rate=333874|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=708|nb_read_frames=65|nb_read_packets=66|disposition:default=1|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|disposition:cap

ti
ons=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0|tag:creation_time=2008-05-12T20:59:27.00Z|tag:language=eng|tag:handler_name=Apple 
Video Media Handler|tag:vendor_id=appl|tag:encoder=H.264
+stream|index=0|codec_name=h264|profile=77|codec_type=video|codec_tag_string=avc1|codec_tag=0x31637661|width=160|height=240|coded_width=160|coded_height=240|closed_captions=0|has_b_frames=1|sample_aspect_ratio=2:1|display_aspect_ratio=4:3|pix_fmt=yuv420p|level=12|color_range=tv|color_space=smpte170m|color_transfer=bt709|color_primaries=smpte170m|chroma_location=topleft|field_order=unknown|refs=2|is_avc=true|nal_length_size=4|id=0x1|r_frame_rate=3/1001|avg_frame_rate=6372000/212521|time_base=1/9|start_pts=0|start_time=0.00|duration_ts=2125200|duration=23.61|bit_rate=333874|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=708

[FFmpeg-devel] [PATCH] avcodec/setts_bsf: allow to use input stream timebase too

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/bitstream_filters.texi | 5 -
 libavcodec/setts_bsf.c | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 1900eb4352..b5a0be8ca2 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -777,8 +777,11 @@ The previous output DTS.
 @item PREV_OUTPTS
 The previous output PTS.
 
+@item ITB
+The input timebase of stream packet belongs.
+
 @item TB
-The timebase of stream packet belongs.
+The output timebase of stream packet belongs.
 
 @item SR
 The sample rate of stream packet belongs.
diff --git a/libavcodec/setts_bsf.c b/libavcodec/setts_bsf.c
index d604f91f71..965c999500 100644
--- a/libavcodec/setts_bsf.c
+++ b/libavcodec/setts_bsf.c
@@ -41,7 +41,8 @@ static const char *const var_names[] = {
 "DTS", ///< original DTS in the file of the frame
 "STARTPTS",///< PTS at start of movie
 "STARTDTS",///< DTS at start of movie
-"TB",  ///< timebase of the stream
+"ITB", ///< input timebase of the stream
+"TB",  ///< output timebase of the stream
 "SR",  ///< sample rate of the stream
 "NOPTS",   ///< The AV_NOPTS_VALUE constant
 NULL
@@ -59,6 +60,7 @@ enum var_name {
 VAR_DTS,
 VAR_STARTPTS,
 VAR_STARTDTS,
+VAR_ITB,
 VAR_TB,
 VAR_SR,
 VAR_NOPTS,
@@ -154,6 +156,7 @@ static int setts_filter(AVBSFContext *ctx, AVPacket *pkt)
 s->var_values[VAR_PREV_OUTDTS] = s->prev_outdts;
 s->var_values[VAR_STARTPTS]= s->start_pts;
 s->var_values[VAR_STARTDTS]= s->start_dts;
+s->var_values[VAR_ITB] = ctx->time_base_in.den  ? 
av_q2d(ctx->time_base_in)  : 0;
 s->var_values[VAR_TB]  = ctx->time_base_out.den ? 
av_q2d(ctx->time_base_out) : 0;
 s->var_values[VAR_SR]  = ctx->par_in->sample_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".

Re: [FFmpeg-devel] [PATCH] avcodec/setts_bsf: allow to use input stream timebase too

[Andreas Rheinhardt]

Paul B Mahol:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/bitstream_filters.texi | 5 -
>  libavcodec/setts_bsf.c | 5 -
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 1900eb4352..b5a0be8ca2 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -777,8 +777,11 @@ The previous output DTS.
>  @item PREV_OUTPTS
>  The previous output PTS.
>  
> +@item ITB
> +The input timebase of stream packet belongs.
> +
>  @item TB
> -The timebase of stream packet belongs.
> +The output timebase of stream packet belongs.
>  
>  @item SR
>  The sample rate of stream packet belongs.
> diff --git a/libavcodec/setts_bsf.c b/libavcodec/setts_bsf.c
> index d604f91f71..965c999500 100644
> --- a/libavcodec/setts_bsf.c
> +++ b/libavcodec/setts_bsf.c
> @@ -41,7 +41,8 @@ static const char *const var_names[] = {
>  "DTS", ///< original DTS in the file of the frame
>  "STARTPTS",///< PTS at start of movie
>  "STARTDTS",///< DTS at start of movie
> -"TB",  ///< timebase of the stream
> +"ITB", ///< input timebase of the stream
> +"TB",  ///< output timebase of the stream
>  "SR",  ///< sample rate of the stream
>  "NOPTS",   ///< The AV_NOPTS_VALUE constant
>  NULL
> @@ -59,6 +60,7 @@ enum var_name {
>  VAR_DTS,
>  VAR_STARTPTS,
>  VAR_STARTDTS,
> +VAR_ITB,
>  VAR_TB,
>  VAR_SR,
>  VAR_NOPTS,
> @@ -154,6 +156,7 @@ static int setts_filter(AVBSFContext *ctx, AVPacket *pkt)
>  s->var_values[VAR_PREV_OUTDTS] = s->prev_outdts;
>  s->var_values[VAR_STARTPTS]= s->start_pts;
>  s->var_values[VAR_STARTDTS]= s->start_dts;
> +s->var_values[VAR_ITB] = ctx->time_base_in.den  ? 
> av_q2d(ctx->time_base_in)  : 0;
>  s->var_values[VAR_TB]  = ctx->time_base_out.den ? 
> av_q2d(ctx->time_base_out) : 0;
>  s->var_values[VAR_SR]  = ctx->par_in->sample_rate;
>  
> 
This is of no use: It is the user which sets the input timebase and it
is the bsf which (in its init function) chooses the output timebase (the
generic bsf code sets it equal to the input timebase and most (all?)
filters don't change it). This filter does not change it, so input and
output timebases are always equal.

The bug in #9382 is really in ffmpeg.c, it can't be fixed in this bsf at
all as it lacks the information about the muxing timebase.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 6/6] avformat/av1dec: Disallow seeking by bytes

[Andreas Rheinhardt]

The low overhead OBU format provides no means to resync after performing
a byte-based seek; in other words: Byte based seeking is just not
supported.

Signed-off-by: Andreas Rheinhardt 
---
The reason I didn't disallow this earlier was that there is one scenario
where such a seek would work: When one  already knows the correct
position for the start of a frame. But otherwise it just doesn't work.

Somehow ffplay tries byte based seeking even for formats with the
AVFMT_NO_BYTE_SEEK flag set. Line 2837 should probably be changed to no
longer do that.

 libavformat/av1dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index 88a3c325e4..37f21483b9 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -428,7 +428,7 @@ const AVInputFormat ff_obu_demuxer = {
 .read_packet= obu_read_packet,
 .read_close = av1_read_close,
 .extensions = "obu",
-.flags  = AVFMT_GENERIC_INDEX,
+.flags  = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK,
 .priv_class = &av1_demuxer_class,
 };
 #endif
-- 
2.30.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/5] avformat/av1dec: Set position of AVPackets given to BSF

[James Almer]

On 8/22/2021 8:20 AM, Andreas Rheinhardt wrote:

Signed-off-by: Andreas Rheinhardt 
---
  libavformat/av1dec.c | 44 +++-
  1 file changed, 15 insertions(+), 29 deletions(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index f6c575069e..e021615c1f 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -22,7 +22,6 @@
  #include "config.h"
  
  #include "libavutil/common.h"

-#include "libavutil/fifo.h"
  #include "libavutil/opt.h"
  #include "libavcodec/av1_parse.h"
  #include "libavcodec/bsf.h"
@@ -299,7 +298,6 @@ typedef struct ObuContext {
  const AVClass *class;
  AVBSFContext *bsf;
  AVRational framerate;
-AVFifoBuffer *fifo;
  } ObuContext;
  
  //For low overhead obu, we can't foresee the obu size before we parsed the header.

@@ -372,9 +370,6 @@ static int obu_probe(const AVProbeData *p)
  static int obu_read_header(AVFormatContext *s)
  {
  ObuContext *c = s->priv_data;
-c->fifo = av_fifo_alloc(MAX_OBU_HEADER_SIZE);
-if (!c->fifo)
-return AVERROR(ENOMEM);
  return read_header(s, &c->framerate, &c->bsf, c);
  }
  
@@ -383,37 +378,26 @@ static int obu_get_packet(AVFormatContext *s, AVPacket *pkt)

  ObuContext *c = s->priv_data;
  uint8_t header[MAX_OBU_HEADER_SIZE + AV_INPUT_BUFFER_PADDING_SIZE];
  int64_t obu_size;
-int size = av_fifo_space(c->fifo);
+int size;
  int ret, len, type;
  
-av_fifo_generic_write(c->fifo, s->pb, size,

-  (int (*)(void*, void*, int))avio_read);
-size = av_fifo_size(c->fifo);
-if (!size)
-return 0;
-
-av_fifo_generic_peek(c->fifo, header, size, NULL);
+if ((ret = ffio_ensure_seekback(s->pb, MAX_OBU_HEADER_SIZE)) < 0)
+return ret;
+size = avio_read(s->pb, header, MAX_OBU_HEADER_SIZE);
+if (size < 0)
+return size;
  
  len = read_obu_with_size(header, size, &obu_size, &type);

  if (len < 0) {
  av_log(c, AV_LOG_ERROR, "Failed to read obu\n");
  return len;
  }
+avio_seek(s->pb, -size, SEEK_CUR);
  
-ret = av_new_packet(pkt, len);

-if (ret < 0) {
-av_log(c, AV_LOG_ERROR, "Failed to allocate packet for obu\n");
-return ret;
-}
-size = FFMIN(size, len);
-av_fifo_generic_read(c->fifo, pkt->data, size, NULL);
-len -= size;
-if (len > 0) {
-ret = avio_read(s->pb, pkt->data + size, len);
-if (ret != len) {
-av_log(c, AV_LOG_ERROR, "Failed to read %d frome file\n", len);
-return ret < 0 ? ret : AVERROR_INVALIDDATA;
-}
+ret = av_get_packet(s->pb, pkt, len);
+if (ret != len) {
+av_log(c, AV_LOG_ERROR, "Failed to get packet for obu\n");
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
  }
  return 0;
  }
@@ -425,7 +409,10 @@ static int obu_read_packet(AVFormatContext *s, AVPacket 
*pkt)
  
  while (1) {

  ret = obu_get_packet(s, pkt);
-if (ret < 0)
+/* In case of AVERROR_EOF we need to flush the BSF. Conveniently
+ * obu_get_packet() returns a blank pkt in this case which
+ * can be used to signal that the BSF should be flushed. */
+if (ret < 0 && ret != AVERROR_EOF)
  return ret;
  ret = av_bsf_send_packet(c->bsf, pkt);
  if (ret < 0) {
@@ -448,7 +435,6 @@ static int obu_read_close(AVFormatContext *s)
  {
  ObuContext *c = s->priv_data;
  
-av_fifo_freep(&c->fifo);

  av_bsf_free(&c->bsf);
  return 0;
  }


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 2/5] avformat/av1dec: Deduplicate Annex B and low overhead OBU AV1 demuxer

[James Almer]

On 8/22/2021 8:29 AM, Andreas Rheinhardt wrote:

Signed-off-by: Andreas Rheinhardt 
---
  libavformat/av1dec.c | 133 +++
  1 file changed, 47 insertions(+), 86 deletions(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index e021615c1f..d5d4548d8b 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -29,6 +29,14 @@
  #include "avio_internal.h"
  #include "internal.h"
  
+typedef struct AV1DemuxContext {

+const AVClass *class;
+AVBSFContext *bsf;
+AVRational framerate;
+uint32_t temporal_unit_size;
+uint32_t frame_unit_size;
+} AV1DemuxContext;
+
  //return < 0 if we need more data
  static int get_score(int type, int *seq)
  {
@@ -48,14 +56,15 @@ static int get_score(int type, int *seq)
  return 0;
  }
  
-static int read_header(AVFormatContext *s, const AVRational *framerate, AVBSFContext **bsf, void *logctx)

+static int av1_read_header(AVFormatContext *s)
  {
+AV1DemuxContext *const c = s->priv_data;
  const AVBitStreamFilter *filter = av_bsf_get_by_name("av1_frame_merge");
  AVStream *st;
  int ret;
  
  if (!filter) {

-av_log(logctx, AV_LOG_ERROR, "av1_frame_merge bitstream filter "
+av_log(s, AV_LOG_ERROR, "av1_frame_merge bitstream filter "
 "not found. This is a bug, please report it.\n");
  return AVERROR_BUG;
  }
@@ -68,35 +77,49 @@ static int read_header(AVFormatContext *s, const AVRational 
*framerate, AVBSFCon
  st->codecpar->codec_id = AV_CODEC_ID_AV1;
  st->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
  
-st->internal->avctx->framerate = *framerate;

+st->internal->avctx->framerate = c->framerate;
  // taken from rawvideo demuxers
  avpriv_set_pts_info(st, 64, 1, 120);
  
-ret = av_bsf_alloc(filter, bsf);

+ret = av_bsf_alloc(filter, &c->bsf);
  if (ret < 0)
  return ret;
  
-ret = avcodec_parameters_copy((*bsf)->par_in, st->codecpar);

+ret = avcodec_parameters_copy(c->bsf->par_in, st->codecpar);
  if (ret < 0)
  return ret;
  
-ret = av_bsf_init(*bsf);

+ret = av_bsf_init(c->bsf);
  if (ret < 0)
  return ret;
  
  return 0;

  }
  
+static int av1_read_close(AVFormatContext *s)

+{
+AV1DemuxContext *const c = s->priv_data;
+
+av_bsf_free(&c->bsf);
+return 0;
+}
+
  #define DEC AV_OPT_FLAG_DECODING_PARAM
+#define OFFSET(x) offsetof(AV1DemuxContext, x)
+static const AVOption av1_options[] = {
+{ "framerate", "", OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
"25"}, 0, INT_MAX, DEC},
+{ NULL },
+};
+#undef OFFSET
+
+static const AVClass av1_demuxer_class = {
+.class_name = "AV1 Annex B/low overhead OBU demuxer",
+.item_name  = av_default_item_name,
+.option = av1_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
  
  #if CONFIG_AV1_DEMUXER

-typedef struct AnnexBContext {
-const AVClass *class;
-AVBSFContext *bsf;
-uint32_t temporal_unit_size;
-uint32_t frame_unit_size;
-AVRational framerate;
-} AnnexBContext;
  
  static int leb(AVIOContext *pb, uint32_t *len) {

  int more, i = 0;
@@ -193,15 +216,9 @@ static int annexb_probe(const AVProbeData *p)
  return 0;
  }
  
-static int annexb_read_header(AVFormatContext *s)

-{
-AnnexBContext *c = s->priv_data;
-return read_header(s, &c->framerate, &c->bsf, c);
-}
-
  static int annexb_read_packet(AVFormatContext *s, AVPacket *pkt)
  {
-AnnexBContext *c = s->priv_data;
+AV1DemuxContext *const c = s->priv_data;
  uint32_t obu_unit_size;
  int ret, len;
  
@@ -256,50 +273,22 @@ end:

  return ret;
  }
  
-static int annexb_read_close(AVFormatContext *s)

-{
-AnnexBContext *c = s->priv_data;
-
-av_bsf_free(&c->bsf);
-return 0;
-}
-
-#define OFFSET(x) offsetof(AnnexBContext, x)
-static const AVOption annexb_options[] = {
-{ "framerate", "", OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
"25"}, 0, INT_MAX, DEC},
-{ NULL },
-};
-#undef OFFSET
-
-static const AVClass annexb_demuxer_class = {
-.class_name = "AV1 Annex B demuxer",
-.item_name  = av_default_item_name,
-.option = annexb_options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
  const AVInputFormat ff_av1_demuxer = {
  .name   = "av1",
  .long_name  = NULL_IF_CONFIG_SMALL("AV1 Annex B"),
-.priv_data_size = sizeof(AnnexBContext),
+.priv_data_size = sizeof(AV1DemuxContext),
  .flags_internal = FF_FMT_INIT_CLEANUP,
  .read_probe = annexb_probe,
-.read_header= annexb_read_header,
+.read_header= av1_read_header,
  .read_packet= annexb_read_packet,
-.read_close = annexb_read_close,
+.read_close = av1_read_close,
  .extensions = "obu",
  .flags  = AVFMT_GENERIC_INDEX,
-.priv_class = &annexb_demuxer_class,
+.priv_class = &av1_demuxer_class,
  };
  #endif
  
  #if CONFIG_OBU_DEMUXER

-typedef struct ObuC

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/av1_frame_merge_bsf: Passthrough pos in case of no timestamps

[James Almer]

On 8/22/2021 8:29 AM, Andreas Rheinhardt wrote:

This is needed by the AV1-Annex B and AV1-OBU demuxers.

Signed-off-by: Andreas Rheinhardt 
---
  libavcodec/av1_frame_merge_bsf.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavcodec/av1_frame_merge_bsf.c b/libavcodec/av1_frame_merge_bsf.c
index fce5bdb67e..19b9cd01a8 100644
--- a/libavcodec/av1_frame_merge_bsf.c
+++ b/libavcodec/av1_frame_merge_bsf.c
@@ -103,10 +103,15 @@ eof:
  err = AVERROR(EAGAIN);
  }
  
-// Buffer packets with timestamps. There should be at most one per TU, be it split or not.

-if (!buffer_pkt->data && in->pts != AV_NOPTS_VALUE)
+/* Buffer packets with timestamps (there should be at most one per TU)
+ * or any packet if buffer_pkt is empty. The latter is needed to
+ * passthrough positions in case there are no timestamps like with
+ * the raw OBU demuxer. */
+if (!buffer_pkt->data ||
+in->pts != AV_NOPTS_VALUE && buffer_pkt->pts == AV_NOPTS_VALUE) {
+av_packet_unref(buffer_pkt);
  av_packet_move_ref(buffer_pkt, in);
-else
+} else
  av_packet_unref(in);
  
  ff_cbs_fragment_reset(&ctx->frag[ctx->idx]);




Should be ok.
___
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 6/6] avformat/av1dec: Disallow seeking by bytes

[James Almer]

On 8/22/2021 10:25 AM, Andreas Rheinhardt wrote:

The low overhead OBU format provides no means to resync after performing
a byte-based seek; in other words: Byte based seeking is just not
supported.

Signed-off-by: Andreas Rheinhardt 
---
The reason I didn't disallow this earlier was that there is one scenario
where such a seek would work: When one  already knows the correct
position for the start of a frame. But otherwise it just doesn't work.

Somehow ffplay tries byte based seeking even for formats with the
AVFMT_NO_BYTE_SEEK flag set. Line 2837 should probably be changed to no
longer do that.

  libavformat/av1dec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index 88a3c325e4..37f21483b9 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -428,7 +428,7 @@ const AVInputFormat ff_obu_demuxer = {
  .read_packet= obu_read_packet,
  .read_close = av1_read_close,
  .extensions = "obu",
-.flags  = AVFMT_GENERIC_INDEX,
+.flags  = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK,
  .priv_class = &av1_demuxer_class,
  };
  #endif


LGTM.

Maybe also AVFMT_NOTIMESTAMPS could be added.
___
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 4/5] avformat/utils: Also set io_repositioned for generic seeking

[James Almer]

On 8/22/2021 8:29 AM, Andreas Rheinhardt wrote:

It allows demuxers to perform certain tasks after
a successful generic seek.

Signed-off-by: Andreas Rheinhardt 
---
This io_repositioned and the flags which contain which type of seeking
a format supports are IMO implementation details that are only public
because up until recently there were no internal flags.


io_repositioned could be made internal, yeah. It's apparently meant to 
be used by demuxers, not callers.




  libavformat/utils.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5754fc1537..39f082d98d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2354,10 +2354,12 @@ static int seek_frame_generic(AVFormatContext *s, int 
stream_index,
  ie = &st->internal->index_entries[st->internal->nb_index_entries 
- 1];
  if ((ret = avio_seek(s->pb, ie->pos, SEEK_SET)) < 0)
  return ret;
+s->io_repositioned = 1;
  avpriv_update_cur_dts(s, st, ie->timestamp);
  } else {
  if ((ret = avio_seek(s->pb, s->internal->data_offset, SEEK_SET)) 
< 0)
  return ret;
+s->io_repositioned = 1;
  }
  av_packet_unref(pkt);
  for (;;) {
@@ -2392,6 +2394,7 @@ static int seek_frame_generic(AVFormatContext *s, int 
stream_index,
  ie = &st->internal->index_entries[index];
  if ((ret = avio_seek(s->pb, ie->pos, SEEK_SET)) < 0)
  return ret;
+s->io_repositioned = 1;
  avpriv_update_cur_dts(s, st, ie->timestamp);
  
  return 0;




Should be ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/5] avformat/av1dec: Flush BSF upon seeking

[James Almer]

On 8/22/2021 8:29 AM, Andreas Rheinhardt wrote:

The av1_merge_frame BSF outputs its cached data when it sees the
beginning of a new frame, i.e. when it sees a temporal delimiter OBU.
Therefore it typically has a temporal delimiter OBU cached after
outputting a packet.

This implies that the OBU demuxer must flush its BSF upon seeking
because otherwise the first frame returned after a seek consists
of an old temporal delimiter OBU only.

Signed-off-by: Andreas Rheinhardt 
---
The AV1 Annex B demuxer also has two issues: It records the wrong
positions (it is off due to the annex b packetization) and it needs to
flush the bsf, too. Will look into it.

  libavformat/av1dec.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index d5d4548d8b..88a3c325e4 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -390,6 +390,10 @@ static int obu_read_packet(AVFormatContext *s, AVPacket 
*pkt)
  AV1DemuxContext *const c = s->priv_data;
  int ret;
  
+if (s->io_repositioned) {

+av_bsf_flush(c->bsf);
+s->io_repositioned = 0;
+}
  while (1) {
  ret = obu_get_packet(s, pkt);
  /* In case of AVERROR_EOF we need to flush the BSF. Conveniently


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 v1] lavfi: add nlmeans CUDA filter

[Timo Rothenpieler]

If nobody wants to review the algorithm being implemented, I'm gonna 
apply this soon.
It looks fine by all I can tell, but I never touched the software 
version of this filter.


smime.p7s
Description: S/MIME Cryptographic 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 6/6] avformat/av1dec: Disallow seeking by bytes

[Andreas Rheinhardt]

James Almer:
> On 8/22/2021 10:25 AM, Andreas Rheinhardt wrote:
>> The low overhead OBU format provides no means to resync after performing
>> a byte-based seek; in other words: Byte based seeking is just not
>> supported.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> The reason I didn't disallow this earlier was that there is one scenario
>> where such a seek would work: When one  already knows the correct
>> position for the start of a frame. But otherwise it just doesn't work.
>>
>> Somehow ffplay tries byte based seeking even for formats with the
>> AVFMT_NO_BYTE_SEEK flag set. Line 2837 should probably be changed to no
>> longer do that.
>>
>>   libavformat/av1dec.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
>> index 88a3c325e4..37f21483b9 100644
>> --- a/libavformat/av1dec.c
>> +++ b/libavformat/av1dec.c
>> @@ -428,7 +428,7 @@ const AVInputFormat ff_obu_demuxer = {
>>   .read_packet    = obu_read_packet,
>>   .read_close = av1_read_close,
>>   .extensions = "obu",
>> -    .flags  = AVFMT_GENERIC_INDEX,
>> +    .flags  = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK,
>>   .priv_class = &av1_demuxer_class,
>>   };
>>   #endif
> 
> LGTM.
> 
> Maybe also AVFMT_NOTIMESTAMPS could be added.

But isn't AV1 able to contain timestamps via its timing_info() and
metadata_timecode() structure?

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] lavu/pixdesc: remove get_pix_fmt_depth().

[Nicolas George]

Apart from erroring when nb_components == 0, it is dead code.
nb_components == 0 only for HW formats, and HW formats are handled
earlier in get_pix_fmt_score().

Signed-off-by: Nicolas George 
---
 libavutil/pixdesc.c | 26 +-
 1 file changed, 1 insertion(+), 25 deletions(-)


The strange thing is that it was dead code from the start. Maybe I a
missing something.

I will need to make the score function public to let libavfilter use it.
These two patches were low-hanging fruits and make understanding the
logic easier.


diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 2346138d04..f1898a6a13 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2686,24 +2686,6 @@ static int get_color_type(const AVPixFmtDescriptor 
*desc) {
 return FF_COLOR_YUV;
 }
 
-static int get_pix_fmt_depth(int *min, int *max, enum AVPixelFormat pix_fmt)
-{
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-int i;
-
-if (!desc || !desc->nb_components) {
-*min = *max = 0;
-return AVERROR(EINVAL);
-}
-
-*min = INT_MAX, *max = -INT_MAX;
-for (i = 0; i < desc->nb_components; i++) {
-*min = FFMIN(desc->comp[i].depth, *min);
-*max = FFMAX(desc->comp[i].depth, *max);
-}
-return 0;
-}
-
 static int get_pix_fmt_score(enum AVPixelFormat dst_pix_fmt,
   enum AVPixelFormat src_pix_fmt,
   unsigned *lossp, unsigned consider)
@@ -2711,8 +2693,7 @@ static int get_pix_fmt_score(enum AVPixelFormat 
dst_pix_fmt,
 const AVPixFmtDescriptor *src_desc = av_pix_fmt_desc_get(src_pix_fmt);
 const AVPixFmtDescriptor *dst_desc = av_pix_fmt_desc_get(dst_pix_fmt);
 int src_color, dst_color;
-int src_min_depth, src_max_depth, dst_min_depth, dst_max_depth;
-int ret, loss, i, nb_components;
+int loss, i, nb_components;
 int score = INT_MAX - 1;
 
 if (!src_desc || !dst_desc)
@@ -2732,11 +2713,6 @@ static int get_pix_fmt_score(enum AVPixelFormat 
dst_pix_fmt,
 if (dst_pix_fmt == src_pix_fmt)
 return INT_MAX;
 
-if ((ret = get_pix_fmt_depth(&src_min_depth, &src_max_depth, src_pix_fmt)) 
< 0)
-return -3;
-if ((ret = get_pix_fmt_depth(&dst_min_depth, &dst_max_depth, dst_pix_fmt)) 
< 0)
-return -3;
-
 src_color = get_color_type(src_desc);
 dst_color = get_color_type(dst_desc);
 if (dst_pix_fmt == AV_PIX_FMT_PAL8)
-- 
2.32.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/2] lavi/pixdesc: simplify depth computatoin in get_pix_fmt_score().

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavutil/pixdesc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index f1898a6a13..967de7dcde 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2721,10 +2721,10 @@ static int get_pix_fmt_score(enum AVPixelFormat 
dst_pix_fmt,
 nb_components = FFMIN(src_desc->nb_components, 
dst_desc->nb_components);
 
 for (i = 0; i < nb_components; i++) {
-int depth_minus1 = (dst_pix_fmt == AV_PIX_FMT_PAL8) ? 7/nb_components 
: (dst_desc->comp[i].depth - 1);
-if (src_desc->comp[i].depth - 1 > depth_minus1 && (consider & 
FF_LOSS_DEPTH)) {
+int depth = (dst_pix_fmt == AV_PIX_FMT_PAL8) ? 7/nb_components + 1 : 
dst_desc->comp[i].depth;
+if (src_desc->comp[i].depth > depth && (consider & FF_LOSS_DEPTH)) {
 loss |= FF_LOSS_DEPTH;
-score -= 65536 >> depth_minus1;
+score -= 131072 >> depth;
 }
 }
 
-- 
2.32.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 6/6] avformat/av1dec: Disallow seeking by bytes

[James Almer]

On 8/22/2021 11:37 AM, Andreas Rheinhardt wrote:

James Almer:

On 8/22/2021 10:25 AM, Andreas Rheinhardt wrote:

The low overhead OBU format provides no means to resync after performing
a byte-based seek; in other words: Byte based seeking is just not
supported.

Signed-off-by: Andreas Rheinhardt 
---
The reason I didn't disallow this earlier was that there is one scenario
where such a seek would work: When one  already knows the correct
position for the start of a frame. But otherwise it just doesn't work.

Somehow ffplay tries byte based seeking even for formats with the
AVFMT_NO_BYTE_SEEK flag set. Line 2837 should probably be changed to no
longer do that.

   libavformat/av1dec.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index 88a3c325e4..37f21483b9 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -428,7 +428,7 @@ const AVInputFormat ff_obu_demuxer = {
   .read_packet    = obu_read_packet,
   .read_close = av1_read_close,
   .extensions = "obu",
-    .flags  = AVFMT_GENERIC_INDEX,
+    .flags  = AVFMT_GENERIC_INDEX | AVFMT_NO_BYTE_SEEK,
   .priv_class = &av1_demuxer_class,
   };
   #endif


LGTM.

Maybe also AVFMT_NOTIMESTAMPS could be added.


But isn't AV1 able to contain timestamps via its timing_info() and
metadata_timecode() structure?

- Andreas


But those are not values exported by the demuxer, which is what i 
interpreted the flag is about. But i see other raw demuxers with similar 
codec level timing information that don't set it, so i guess not.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/webp: Check available space in loop in decode_entropy_coded_image()

[Michael Niedermayer]

On Sun, Jul 25, 2021 at 04:01:55PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 35401/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WEBP_fuzzer-5714401821851648
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/webp.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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/vc1dec: ff_print_debug_info() does not support WMV3 field_mode

[Michael Niedermayer]

On Sun, Aug 08, 2021 at 09:32:50PM +0200, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes: 
> 36331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3_fuzzer-5140494328922112.fuzz
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vc1dec.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell


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/setts_bsf: allow to use input stream timebase too

[Paul B Mahol]

On Sun, Aug 22, 2021 at 2:48 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Paul B Mahol:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  doc/bitstream_filters.texi | 5 -
> >  libavcodec/setts_bsf.c | 5 -
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> > index 1900eb4352..b5a0be8ca2 100644
> > --- a/doc/bitstream_filters.texi
> > +++ b/doc/bitstream_filters.texi
> > @@ -777,8 +777,11 @@ The previous output DTS.
> >  @item PREV_OUTPTS
> >  The previous output PTS.
> >
> > +@item ITB
> > +The input timebase of stream packet belongs.
> > +
> >  @item TB
> > -The timebase of stream packet belongs.
> > +The output timebase of stream packet belongs.
> >
> >  @item SR
> >  The sample rate of stream packet belongs.
> > diff --git a/libavcodec/setts_bsf.c b/libavcodec/setts_bsf.c
> > index d604f91f71..965c999500 100644
> > --- a/libavcodec/setts_bsf.c
> > +++ b/libavcodec/setts_bsf.c
> > @@ -41,7 +41,8 @@ static const char *const var_names[] = {
> >  "DTS", ///< original DTS in the file of the frame
> >  "STARTPTS",///< PTS at start of movie
> >  "STARTDTS",///< DTS at start of movie
> > -"TB",  ///< timebase of the stream
> > +"ITB", ///< input timebase of the stream
> > +"TB",  ///< output timebase of the stream
> >  "SR",  ///< sample rate of the stream
> >  "NOPTS",   ///< The AV_NOPTS_VALUE constant
> >  NULL
> > @@ -59,6 +60,7 @@ enum var_name {
> >  VAR_DTS,
> >  VAR_STARTPTS,
> >  VAR_STARTDTS,
> > +VAR_ITB,
> >  VAR_TB,
> >  VAR_SR,
> >  VAR_NOPTS,
> > @@ -154,6 +156,7 @@ static int setts_filter(AVBSFContext *ctx, AVPacket
> *pkt)
> >  s->var_values[VAR_PREV_OUTDTS] = s->prev_outdts;
> >  s->var_values[VAR_STARTPTS]= s->start_pts;
> >  s->var_values[VAR_STARTDTS]= s->start_dts;
> > +s->var_values[VAR_ITB] = ctx->time_base_in.den  ?
> av_q2d(ctx->time_base_in)  : 0;
> >  s->var_values[VAR_TB]  = ctx->time_base_out.den ?
> av_q2d(ctx->time_base_out) : 0;
> >  s->var_values[VAR_SR]  = ctx->par_in->sample_rate;
> >
> >
> This is of no use: It is the user which sets the input timebase and it
> is the bsf which (in its init function) chooses the output timebase (the
> generic bsf code sets it equal to the input timebase and most (all?)
> filters don't change it). This filter does not change it, so input and
> output timebases are always equal.
>
> The bug in #9382 is really in ffmpeg.c, it can't be fixed in this bsf at
> all as it lacks the information about the muxing timebase.
>

Are you telling me that one field there is now useless?
Above Code is correct.


>
> - 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] [fateserver] Cleanup and security strengthening

[Michael Niedermayer]

On Sun, Aug 15, 2021 at 11:24:47AM +0200, Nicolas George wrote:
> Nicolas George (12021-08-08):
> > Here is a patch series for fateserver, to fix warnings and enable Perl's
> > taint checks, thus protecting against a whole class of security issues.
> 
> I would appreciate somebody looks at the code before I deploy it and we
> re-enable the server.

noone in the whole community cares about the server or everyone trusts you
to never make a mistake. At least when limited to people knowing perl and
having time.

seriously, if someone has time and knows perl, please look over this,
even if by the time you do, this has already been applied.

The sooner someone goes over this the sooner the fateserver is online
again

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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] avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames

[Dave Rice]

Hi Marton,

> On Feb 23, 2021, at 3:07 PM, Dave Rice  wrote:
> 
>> On Feb 23, 2021, at 2:42 PM, Marton Balint  wrote:
>> 
>> On Sat, 20 Feb 2021, Dave Rice wrote:
>> 
>>> Hi,
>>> 
 On Oct 31, 2020, at 5:15 PM, Marton Balint >>> > wrote:
 On Sat, 31 Oct 2020, Dave Rice wrote:
>> On Oct 31, 2020, at 3:47 PM, Marton Balint > > wrote:
>> On Sat, 31 Oct 2020, Dave Rice wrote:
>>> Hi Marton,
 On Oct 31, 2020, at 12:56 PM, Marton Balint >>> > wrote:
 Fixes out of sync timestamps in ticket #8762.
>>> Although Michael’s recent patch does address the issue documented in 
>>> 8762, I haven’t found this patch to fix the issue. I tried with -c:a 
>>> copy and with -c:a pcm_s16le with some sample files that exhibit this 
>>> issue but each output was out of sync. I put an output at 
>>> https://gist.github.com/dericed/659bd843bd38b6f24a60198b5e345795 
>>> . 
>>> That output notes that 3597 packages of video are read and 3586 packets 
>>> of audio. In the resulting file, at the end of the timeline the audio 
>>> is 9 frames out of sync and my output video stream is 00:02:00.020 and 
>>> output audio stream is 00:01:59.653.
>>> Beyond copying or encoding the audio, are there other options I should 
>>> use to test this?
>> Well, it depends on what you want. After this patch you should get a 
>> file which has audio packets synced to video, but the audio stream is 
>> sparse, not every video packet has a corresponding audio packet. (It 
>> looks like our MOV muxer does not support muxing of sparse audio 
>> therefore does not produce proper timestamps. But MKV does, please try 
>> that.)
>> You can also make ffmpeg generate the missing audio based on packet 
>> timestamps. Swresample has an async=1 option, so something like this 
>> should get you synced audio with continous audio packets:
>> ffmpeg -y -i 167052_12.dv -c:v copy \
>> -af aresample=async=1:min_hard_comp=0.01 -c:a pcm_s16le 167052_12.mov
> Thank you for this. With the patch and async, the result is synced and 
> the resulting audio was the same as Michael’s patch.
> Could you explain why you used min_hard_comp here? IIUC min_hard_comp is 
> a set a threshold between the strategies of trim/fill or stretch/squeeze 
> to align the audio to time; however, the async documentation says 
> "Setting this to 1 will enable filling and trimming, larger values 
> represent the maximum amount in samples that the data may be stretched or 
> squeezed” so I thought that async=1 would not permit stretch/squeeze 
> anyway.
 It is documented poorly, but if you check the source code you will see 
 that async=1 implicitly sets min_comp to 0.001 enabling trimming/dropping. 
 min_hard_comp decides the threshold when silence injection actually 
 happens, and the default for that is 0.1, which is more than a frame, 
 therefore not acceptable if we want to maintain <1 frame accuracy. Or at 
 least that is how I think it should work.
>>> 
>> 
>>> I’ve found that aresample=async=1:min_hard_comp=0.01, as discussed here, 
>>> works well to add audio samples to maintain timestamp accuracy when muxing 
>>> into a format like mov. However, this approach doesn’t work if the 
>>> sparseness of the audio stream is at the end of the stream. Is there a way 
>>> to use min_hard_comp to consider differences between a timestamp and audio 
>>> data when one of the ends of that range is the end of the file?
>> 
>> I am not aware of a smart method to generate missing audio in the end until 
>> the end of video.
>> 
>> As a possible workaround you may query the video length using
>> ffprobe or mediainfo, and then use a second filter, apad to pad audio:
>> 
>> -af aresample=async=1:min_hard_comp=0.01,apad=whole_dur=
>> 
>> Tnis might do what you want, but requires an additional step to query the 
>> video length…
> 
> 
> […]
> Perfect, thanks for sharing this idea.

I was hoping I could ask your advise on a related issue. There’s a sample to 
show it at https://archive.org/download/test_a_202108/test_a.dv 
. This sample has three 
frames, frame 1 and 3 have 2 tracks of 32k stereo audio. Frame 2 has nulled 
audio in the audio dif blocks and there are no audio metadata packs, so ffmpeg 
(rightly) does not find any audio in this frame.

Using your advice about the aresample filter above, I was using a command like 
this to mux the video and audio into a new container as lossless as feasible 
with:
ffmpeg -y -i test_a.dv -filter_complex 
"[0:a:0]aresample=async=1:min_hard_comp=0.01[aud1]" -c:v:0 copy -map 0:v:0 -c:a 
pcm_s16le -map "[aud1]” test_audio.mov

However here, the resulting audio track of test_audio.mov is 84 ms 

Re: [FFmpeg-devel] [PATCH] [fateserver] Cleanup and security strengthening

[Chad Fraleigh]

On 8/22/2021 11:18 AM, Michael Niedermayer wrote:

On Sun, Aug 15, 2021 at 11:24:47AM +0200, Nicolas George wrote:

Nicolas George (12021-08-08):

Here is a patch series for fateserver, to fix warnings and enable Perl's
taint checks, thus protecting against a whole class of security issues.


I would appreciate somebody looks at the code before I deploy it and we
re-enable the server.


noone in the whole community cares about the server or everyone trusts you
to never make a mistake. At least when limited to people knowing perl and
having time.

seriously, if someone has time and knows perl, please look over this,
even if by the time you do, this has already been applied.

The sooner someone goes over this the sooner the fateserver is online
again


It mostly looks good (from a perl perspective).

Just 3 questionable items..

-<>-<>-

-if ($ENV{HTTP_ACCEPT_ENCODING} =~ /gzip/) {
-print "Content-Encoding: gzip\r\n";
+if (ready_for_gzip) {
 $cat = 'cat';
 }

The old code outputs "\r\n", where ready_for_gzip() outputs "\r\n\r\n". 
Will this be an issue, or should it have done that in the first place?


-<>-<>-

+sub ready_for_gzip() {
+my $ae = $ENV{HTTP_ACCEPT_ENCODING};
+if (defined($ae) && $ae =~ /gzip/) {

It is checking for 'gzip' as a substring, rather than a whole word. If 
it was passed a [hypothetical] encoding type contains the substring gzip 
(e.g. "bigzip"), it could trigger in incompatible output encoding. 
However, it's not any worse than it was previously.


Perhaps changing it to match /\bgzip\b/ ?

-<>-<>-

 sub ready_for_gzip() {
+# Under CGI, $PATH is safe
+($ENV{PATH}) = $ENV{PATH} =~ /(.*)/s;

It is untainting the PATH as "hidden" side effect of calling 
ready_for_gzip(). While technically it works, it feels a little kludgy 
compared to untainting it at the beginning of each taint-enabled script.



___
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] avfilter/vf_scale: reset color matrix in case of identity & non-RGB

[Jan Ekström]

Fixes passing through mismatching metadata from the input side
when RGB input (from f.ex. H.264 or HEVC) gets converted to YCbCr.

Fixes #9132
---
 libavfilter/vf_scale.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index ce39217515..7ca833bbb1 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -738,6 +738,15 @@ scale:
 out->width  = outlink->w;
 out->height = outlink->h;
 
+// Sanity check: If we've got the RGB/XYZ (identity) matrix configured, and
+//   the output is no longer RGB, unset the matrix.
+//   In theory this should be in swscale itself as the AVFrame
+//   based API gets in, so that not every swscale API user has
+//   to go through duplicating such sanity checks.
+if (out->colorspace == AVCOL_SPC_RGB &&
+!(av_pix_fmt_desc_get(out->format)->flags & AV_PIX_FMT_FLAG_RGB))
+out->colorspace = AVCOL_SPC_UNSPECIFIED;
+
 if (scale->output_is_pal)
 avpriv_set_systematic_pal2((uint32_t*)out->data[1], outlink->format == 
AV_PIX_FMT_PAL8 ? AV_PIX_FMT_BGR8 : outlink->format);
 
-- 
2.31.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] [fateserver] Cleanup and security strengthening

[Michael Niedermayer]

On Sun, Aug 22, 2021 at 01:35:26PM -0700, Chad Fraleigh wrote:
> On 8/22/2021 11:18 AM, Michael Niedermayer wrote:
> > On Sun, Aug 15, 2021 at 11:24:47AM +0200, Nicolas George wrote:
> > > Nicolas George (12021-08-08):
> > > > Here is a patch series for fateserver, to fix warnings and enable Perl's
> > > > taint checks, thus protecting against a whole class of security issues.
> > > 
> > > I would appreciate somebody looks at the code before I deploy it and we
> > > re-enable the server.
> > 
> > noone in the whole community cares about the server or everyone trusts you
> > to never make a mistake. At least when limited to people knowing perl and
> > having time.
> > 
> > seriously, if someone has time and knows perl, please look over this,
> > even if by the time you do, this has already been applied.
> > 
> > The sooner someone goes over this the sooner the fateserver is online
> > again
> 
> It mostly looks good (from a perl perspective).
> 
> Just 3 questionable items..

Thanks for the review!

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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] FATE coverage for format negotiation

[Nicolas George]

Hi.

Apparently, we have almost coverage for cases where the format
negotiation in libavfilter is not straightforward.

Disabling swap_samplerates() and swap_channel_layouts() (in
libavfilter/avfiltergraph.c) does not cause any test to fail.

(Disabling swap_sample_fmts() is expected to change nothing because it
is completely overridden by the logic in pick_format().)

Setting ref=NULL in the video branch of pick_format() causes the
following tests to fail:

fate-filter-alphaextract_alphamerge_yuv
fate-filter-histogram-levels
fate-filter-vectorscope_color
fate-filter-vectorscope_color2
fate-filter-vectorscope_color3
fate-filter-vectorscope_color4
fate-filter-vectorscope_gray
fate-filter-vectorscope_xy

In the audio branch:

fate-filter-adelay
fate-filter-channelmap-one-int
fate-filter-channelmap-one-str
fate-filter-channelsplit
fate-filter-hls-append
fate-filter-hls
fate-filter-join

So that makes a little coverage, but not really intentional.

I will be adding a way to observe the negotiation to implement tests.

If somebody wants to help libavfilter move forward, and in particular
open the way for subtitles filters, finding simple graphs where swap_*()
and the logic in pick_format() makes a difference would be a very useful
task.

See the long documentation for AVFilterNegotiation in
libavfilter/formats.h for explanations of what these functions do. In
short, when there are several possible formats on the output of a
filter but the input is already determined, they chose the one that is
most similar.

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 2/2] avcodec/mjpegbdec: Skip SOS on AVDISCARD_ALL as does mjpeg

[Michael Niedermayer]

Fixes: NULL pointer dereference
Fixes: 
36342/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-4579188072906752
Fixes: 
36344/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-5049579300061184
Fixes: 
36345/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-5301149845553152
Fixes: 
36374/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-6056312352931840

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegbdec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mjpegbdec.c b/libavcodec/mjpegbdec.c
index 87eebb8771..218be41192 100644
--- a/libavcodec/mjpegbdec.c
+++ b/libavcodec/mjpegbdec.c
@@ -119,9 +119,13 @@ read_header:
   8 * FFMIN(field_size, buf_end - buf_ptr - sos_offs));
 s->mjpb_skiptosod = (sod_offs - sos_offs - show_bits(&s->gb, 16));
 s->start_code = SOS;
-ret = ff_mjpeg_decode_sos(s, NULL, 0, NULL);
-if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE))
-return ret;
+if (avctx->skip_frame == AVDISCARD_ALL) {
+skip_bits(&s->gb, get_bits_left(&s->gb));
+} else {
+ret = ff_mjpeg_decode_sos(s, NULL, 0, NULL);
+if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE))
+return ret;
+}
 }
 
 if (s->interlaced) {
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Check for bits left in mjpeg_decode_scan_progressive_ac()

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
36262/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-4969052454912000

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 8172dca513..2a5868fe1d 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1580,6 +1580,9 @@ static int 
mjpeg_decode_scan_progressive_ac(MJpegDecodeContext *s, int ss,
 else
 ret = decode_block_progressive(s, *block, last_nnz, 
s->ac_index[0],
quant_matrix, ss, se, Al, 
&EOBRUN);
+
+if (ret >= 0 && get_bits_left(&s->gb) < 0)
+ret = AVERROR_INVALIDDATA;
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_ERROR,
"error y=%d x=%d\n", mb_y, mb_x);
-- 
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] Question regarding ogg cover art implementation

[Jesse Obic]

Hi,

First time using a mailing list and (properly) working with C, so please 
forgive me if I've done something wrong.


I'm looking at implementing https://trac.ffmpeg.org/ticket/4448 
, and I understand what I need to 
do but I'm on the fence about how I should go about doing it.


For the OGG container, cover art is embedded into the file by adding a 
METADATA_BLOCK_PICTURE tag in the vorbis comment section. The data of 
this tag is a base64 representation of the FLAC embedded image data 
structure, which includes the data of the image itself.


I looked at how vorbis comments are currently written, and it's lead me 
to `ff_vorbiscomment_write`. It takes in an AVDictionary for metadata, 
and an array of AVChapters for chapter writing. This is where I get a 
bit concerned.


I see two options as to how I could handle this:


1. Place the METADATA_BLOCK_PICTURE tag in the metadata AVDictionary.

This would be the easiest functionality wise, however it feels like a 
bad idea in my gut because the dictionary would be housing a value that 
is 1.33 * the size of the image(s) being embedded. So for example, if 
you wished to embed a 12 MB image it would require a 16MB malloc which 
doesn't feel right.


The ogg specification allows for multiple embedded images by specifying 
the same METADATA_BLOCK_PICTURE tag multiple times, which would require 
me to use AV_DICT_MULTIKEY when adding values to the dictionary. I 
couldn't find any examples of using it within the source code for either 
writing or reading (which I will have to handle in oggdec.c as well), so 
I'm not sure if other parts of the codebase will handle it well. This is 
probably more paranoia than anything.



2. Change ff_vorbiscomment_write to take in an array of AVStream / 
AVPacket to write it directly to the output IO stream


As far as I know this would classify as an API/ABI change. However it 
would mean that I don't have to allocate such a huge array upfront, and 
can encode smaller chunks at a time as I write them to the output stream.


To mitigate it, it could be created as a new function with the 
additional parameters, and the old function pointing towards the new one 
instead. I'm not entirely sure how APIs / ABIs are exposed and consumed 
in C, so I'm not sure if this will fix the issue.



I'm interested in what people think about how I should tackle this 
issue. It was annoying enough that I downloaded the source code and set 
up a compilation environment, so I'd like to get working on this.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/setts_bsf: allow to use input stream timebase too

[Andreas Rheinhardt]

Paul B Mahol:
> On Sun, Aug 22, 2021 at 2:48 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
> 
>> Paul B Mahol:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  doc/bitstream_filters.texi | 5 -
>>>  libavcodec/setts_bsf.c | 5 -
>>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>>> index 1900eb4352..b5a0be8ca2 100644
>>> --- a/doc/bitstream_filters.texi
>>> +++ b/doc/bitstream_filters.texi
>>> @@ -777,8 +777,11 @@ The previous output DTS.
>>>  @item PREV_OUTPTS
>>>  The previous output PTS.
>>>
>>> +@item ITB
>>> +The input timebase of stream packet belongs.
>>> +
>>>  @item TB
>>> -The timebase of stream packet belongs.
>>> +The output timebase of stream packet belongs.
>>>
>>>  @item SR
>>>  The sample rate of stream packet belongs.
>>> diff --git a/libavcodec/setts_bsf.c b/libavcodec/setts_bsf.c
>>> index d604f91f71..965c999500 100644
>>> --- a/libavcodec/setts_bsf.c
>>> +++ b/libavcodec/setts_bsf.c
>>> @@ -41,7 +41,8 @@ static const char *const var_names[] = {
>>>  "DTS", ///< original DTS in the file of the frame
>>>  "STARTPTS",///< PTS at start of movie
>>>  "STARTDTS",///< DTS at start of movie
>>> -"TB",  ///< timebase of the stream
>>> +"ITB", ///< input timebase of the stream
>>> +"TB",  ///< output timebase of the stream
>>>  "SR",  ///< sample rate of the stream
>>>  "NOPTS",   ///< The AV_NOPTS_VALUE constant
>>>  NULL
>>> @@ -59,6 +60,7 @@ enum var_name {
>>>  VAR_DTS,
>>>  VAR_STARTPTS,
>>>  VAR_STARTDTS,
>>> +VAR_ITB,
>>>  VAR_TB,
>>>  VAR_SR,
>>>  VAR_NOPTS,
>>> @@ -154,6 +156,7 @@ static int setts_filter(AVBSFContext *ctx, AVPacket
>> *pkt)
>>>  s->var_values[VAR_PREV_OUTDTS] = s->prev_outdts;
>>>  s->var_values[VAR_STARTPTS]= s->start_pts;
>>>  s->var_values[VAR_STARTDTS]= s->start_dts;
>>> +s->var_values[VAR_ITB] = ctx->time_base_in.den  ?
>> av_q2d(ctx->time_base_in)  : 0;
>>>  s->var_values[VAR_TB]  = ctx->time_base_out.den ?
>> av_q2d(ctx->time_base_out) : 0;
>>>  s->var_values[VAR_SR]  = ctx->par_in->sample_rate;
>>>
>>>
>> This is of no use: It is the user which sets the input timebase and it
>> is the bsf which (in its init function) chooses the output timebase (the
>> generic bsf code sets it equal to the input timebase and most (all?)
>> filters don't change it). This filter does not change it, so input and
>> output timebases are always equal.
>>
>> The bug in #9382 is really in ffmpeg.c, it can't be fixed in this bsf at
>> all as it lacks the information about the muxing timebase.
>>
> 
> Are you telling me that one field there is now useless?
> Above Code is correct.
> 
time_base_in and time_base_out always coincide, so adding the new
variable would be useless (and confusing). But if your "now" corresponds
to current master, then none of the variables are useless.

- 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] Question regarding ogg cover art implementation

[Chad Fraleigh]

On 8/22/2021 4:49 PM, Jesse Obic wrote:

I'm looking at implementing https://trac.ffmpeg.org/ticket/4448 
, and I understand what I need to 
do but I'm on the fence about how I should go about doing it.


For the OGG container, cover art is embedded into the file by adding a 
METADATA_BLOCK_PICTURE tag in the vorbis comment section. The data of 
this tag is a base64 representation of the FLAC embedded image data 
structure, which includes the data of the image itself.


I looked at how vorbis comments are currently written, and it's lead me 
to `ff_vorbiscomment_write`. It takes in an AVDictionary for metadata, 
and an array of AVChapters for chapter writing. This is where I get a 
bit concerned.


I see two options as to how I could handle this:


1. Place the METADATA_BLOCK_PICTURE tag in the metadata AVDictionary.

This would be the easiest functionality wise, however it feels like a 
bad idea in my gut because the dictionary would be housing a value that 
is 1.33 * the size of the image(s) being embedded. So for example, if 
you wished to embed a 12 MB image it would require a 16MB malloc which 
doesn't feel right.


Would allocating 16M really be a lot, given typically there wouldn't be 
many of them?



2. Change ff_vorbiscomment_write to take in an array of AVStream / 
AVPacket to write it directly to the output IO stream


As far as I know this would classify as an API/ABI change. However it 
would mean that I don't have to allocate such a huge array upfront, and 
can encode smaller chunks at a time as I write them to the output stream.


To mitigate it, it could be created as a new function with the 
additional parameters, and the old function pointing towards the new one 
instead. I'm not entirely sure how APIs / ABIs are exposed and consumed 
in C, so I'm not sure if this will fix the issue.


What if.. LOB value reference support was added to AVDictionary, via a 
av_dict_set_lob() function and AVDictionaryEntry->lob field. And anytime 
av_dict_get() is called without a AV_DICT_NO_RESOLVE flag, it would 
simply do a lazy resolve if it lob != NULL and fill in value field (if 
not already resolved, of course). This would allow a LOB aware callers 
to stream it when it is a LOB (use 'value' when not NULL). It should 
even be API/ABI change safe (unless making AVDictionaryEntry bigger 
counts as a break).


Anyway.. just a third option.


Oh, and on a side note: av_dict_get() should _probably_ be changed to 
return a const AVDictionaryEntry * at some point, since it is internal 
and really should never be modified by the caller.


___
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] Question regarding ogg cover art implementation

[Jesse Obic]

On 23/08/2021 12:04 pm, Chad Fraleigh wrote:
Would allocating 16M really be a lot, given typically there wouldn't 
be many of them?


That's something I wanted to get clarification on. I've seen ffmpeg's 
libraries used in embedded hardware / environments with restricted 
memory; however I'm not sure if this is a valid concern in the first place.


If it's not an issue then it would probably be easiest to choose to use 
that option instead.


What if.. LOB value reference support was added to AVDictionary, via a 
av_dict_set_lob() function and AVDictionaryEntry->lob field. And 
anytime av_dict_get() is called without a AV_DICT_NO_RESOLVE flag, it 
would simply do a lazy resolve if it lob != NULL and fill in value 
field (if not already resolved, of course). This would allow a LOB 
aware callers to stream it when it is a LOB (use 'value' when not 
NULL). It should even be API/ABI change safe (unless making 
AVDictionaryEntry bigger counts as a break).


Anyway.. just a third option.


Oh, and on a side note: av_dict_get() should _probably_ be changed to 
return a const AVDictionaryEntry * at some point, since it is internal 
and really should never be modified by the caller.
That's a good point. I'm not sure if it's within the scope of this 
ticket, but I'd love to hear input on it

___
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] Question regarding ogg cover art implementation

[Andreas Rheinhardt]

Jesse Obic:
> Hi,
> 
> First time using a mailing list and (properly) working with C, so please
> forgive me if I've done something wrong.
> 
> I'm looking at implementing https://trac.ffmpeg.org/ticket/4448
> , and I understand what I need to
> do but I'm on the fence about how I should go about doing it.
> 
> For the OGG container, cover art is embedded into the file by adding a
> METADATA_BLOCK_PICTURE tag in the vorbis comment section. The data of
> this tag is a base64 representation of the FLAC embedded image data
> structure, which includes the data of the image itself.
> 
> I looked at how vorbis comments are currently written, and it's lead me
> to `ff_vorbiscomment_write`. It takes in an AVDictionary for metadata,
> and an array of AVChapters for chapter writing. This is where I get a
> bit concerned.
> 
> I see two options as to how I could handle this:
> 
> 
> 1. Place the METADATA_BLOCK_PICTURE tag in the metadata AVDictionary.
> 
> This would be the easiest functionality wise, however it feels like a
> bad idea in my gut because the dictionary would be housing a value that
> is 1.33 * the size of the image(s) being embedded. So for example, if
> you wished to embed a 12 MB image it would require a 16MB malloc which
> doesn't feel right.
> 
> The ogg specification allows for multiple embedded images by specifying
> the same METADATA_BLOCK_PICTURE tag multiple times, which would require
> me to use AV_DICT_MULTIKEY when adding values to the dictionary. I
> couldn't find any examples of using it within the source code for either
> writing or reading (which I will have to handle in oggdec.c as well), so

Isn't reading already supported? See ff_vorbis_comment in
libavformat/oggparsevorbis.c. (These functions use one buffer too much
which could be easily avoided.)

> I'm not sure if other parts of the codebase will handle it well. This is
> probably more paranoia than anything.

Embedded cover arts are exported as streams with the disposition
AV_DISPOSITION_ATTACHED_PIC set; they are not exported as dictionary.

> 
> 2. Change ff_vorbiscomment_write to take in an array of AVStream /
> AVPacket to write it directly to the output IO stream
> 
> As far as I know this would classify as an API/ABI change. However it
> would mean that I don't have to allocate such a huge array upfront, and
> can encode smaller chunks at a time as I write them to the output stream.
> 
> To mitigate it, it could be created as a new function with the
> additional parameters, and the old function pointing towards the new one
> instead. I'm not entirely sure how APIs / ABIs are exposed and consumed
> in C, so I'm not sure if this will fix the issue.
> 

All functions prefixed with "ff_" are internal functions; changing them
does not cause any ABI/API problems.

- 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] Question regarding ogg cover art implementation

[Jesse Obic]

Isn't reading already supported? See ff_vorbis_comment in 
libavformat/oggparsevorbis.c. (These functions use one buffer too much 
which could be easily avoided.)


Ah seems like I missed that. Thanks for pointing that out! Saved me some 
time trying to figure out if I needed to touch that at all.


Regarding the rest of your message, thank you very much for those 
clarifications Andreas. I believe I have enough background knowledge to 
start making something now.


___
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/4] avformat/matroskaenc: Allow to set multiple streams as default

[Andreas Rheinhardt]

Andreas Rheinhardt:
> The Matroska specifications have evolved and now allow to mark
> multiple tracks of the same kind as default (whether this was legal or
> not before was dubious; e.g. mkvmerge disallowed it). Yet when the
> Matroska muxer is set to infer default dispositions if absent, it also
> enforced the now outdated restriction. So update this.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  doc/muxers.texi   | 12 ++--
>  libavformat/matroskaenc.c | 16 ++--
>  tests/ref/fate/matroska-flac-extradata-update |  4 ++--
>  3 files changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 0972bbfd5c..0f8efabab9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1567,12 +1567,12 @@ It influences which tracks players should play by 
> default. The default mode
>  is @samp{infer}.
>  @table @samp
>  @item infer
> -In this mode, for each type of track (audio, video or subtitle), if there is
> -a track with disposition default of this type, then the first such track
> -(i.e. the one with the lowest index) will be marked as default; if no such
> -track exists, the first track of this type will be marked as default instead
> -(if existing). This ensures that the default flag is set in a sensible way 
> even
> -if the input originated from containers that lack the concept of default 
> tracks.
> +Every track with disposition default will have the FlagDefault set.
> +Additionally, for each type of track (audio, video or subtitle), if no track
> +with disposition default of this type exists, then the first track of this 
> type
> +will be marked as default (if existing). This ensures that the default flag
> +is set in a sensible way even if the input originated from containers that
> +lack the concept of default tracks.
>  @item infer_no_subs
>  This mode is the same as infer except that if no subtitle track with
>  disposition default exists, no subtitle track will be marked as default.
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 899a3388cd..e2d9159e2c 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1395,7 +1395,8 @@ static int mkv_write_tracks(AVFormatContext *s)
>  {
>  MatroskaMuxContext *mkv = s->priv_data;
>  AVIOContext *pb = s->pb;
> -int i, ret, video_default_idx, audio_default_idx, subtitle_default_idx;
> +int video_default_idx = -1, audio_default_idx = -1, subtitle_default_idx 
> = -1;
> +int i, ret;
>  
>  if (mkv->nb_attachments == s->nb_streams)
>  return 0;
> @@ -1405,11 +1406,7 @@ static int mkv_write_tracks(AVFormatContext *s)
>  return ret;
>  
>  if (mkv->default_mode != DEFAULT_MODE_PASSTHROUGH) {
> -int video_idx, audio_idx, subtitle_idx;
> -
> -video_idx= video_default_idx=
> -audio_idx= audio_default_idx=
> -subtitle_idx = subtitle_default_idx = -1;
> +int video_idx = -1, audio_idx = -1, subtitle_idx = -1;
>  
>  for (i = s->nb_streams - 1; i >= 0; i--) {
>  AVStream *st = s->streams[i];
> @@ -1435,8 +1432,7 @@ static int mkv_write_tracks(AVFormatContext *s)
>  }
>  for (i = 0; i < s->nb_streams; i++) {
>  AVStream *st = s->streams[i];
> -int is_default = mkv->default_mode == DEFAULT_MODE_PASSTHROUGH ?
> - st->disposition & AV_DISPOSITION_DEFAULT  :
> +int is_default = st->disposition & AV_DISPOSITION_DEFAULT ||
>   i == video_default_idx || i == 
> audio_default_idx ||
>   i == subtitle_default_idx;
>  ret = mkv_write_track(s, mkv, st, &mkv->tracks[i],
> @@ -2823,8 +2819,8 @@ static const AVOption options[] = {
>  { "flipped_raw_rgb", "Raw RGB bitmaps in VFW mode are stored bottom-up", 
> OFFSET(flipped_raw_rgb), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
>  { "write_crc32", "write a CRC32 element inside every Level 1 element", 
> OFFSET(write_crc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS },
>  { "default_mode", "Controls how a track's FlagDefault is inferred", 
> OFFSET(default_mode), AV_OPT_TYPE_INT, { .i64 = DEFAULT_MODE_INFER }, 
> DEFAULT_MODE_INFER, DEFAULT_MODE_PASSTHROUGH, FLAGS, "default_mode" },
> -{ "infer", "For each track type, mark the first track of disposition 
> default as default; if none exists, mark the first track as default.", 0, 
> AV_OPT_TYPE_CONST, { .i64 = DEFAULT_MODE_INFER }, 0, 0, FLAGS, "default_mode" 
> },
> -{ "infer_no_subs", "For each track type, mark the first track of 
> disposition default as default; for audio and video: if none exists, mark the 
> first track as default.", 0, AV_OPT_TYPE_CONST, { .i64 = 
> DEFAULT_MODE_INFER_NO_SUBS }, 0, 0, FLAGS, "default_mode" },
> +{ "infer", "For each track type, mark each track of disposition default 
> as default; if none exists, mark the first track as

Re: [FFmpeg-devel] [PATCH v2 00/10] make QSV works with Intel's oneVPL

[Xiang, Haihao]

On Mon, 2021-08-16 at 15:33 +0800, Haihao Xiang wrote:
> The oneAPI Video Processing Library (oneVPL) is a single interface for
> encode, decode and video processing[1]. oneVPL is a successor to Intel's Media
> SDK (MediaSDK), but removed obsolete features. MediaSDK lifetime comes to an
> end now[2].
> 
> This patchset fixes compiler errors when building FFmpeg against oneVPL and
> uses
> a new way to create MFX session for oneVPL. New features for oneVPL will be
> implemented in other patchset.
> 
> The oneVPL source code:
> https://github.com/oneapi-src/oneVPL
> The oneVPL runtime for new Intel Gen platforms:
> https://github.com/oneapi-src/oneVPL-intel-gpu
> 
> [1] https://spec.oneapi.io/versions/latest/elements/oneVPL/source/index.html
> [2] https://github.com/Intel-Media-SDK/MediaSDK/#media-sdk-support-matrix
> 

Hi Zhong / Mark / Softworkz,

Is there any comment to this new patchset version? This version should not have
any impact to current user if --enable-libmfx option is used. We added --enable-
onevpl option for oneVPL usage but the suffix 'qsv' is still used in codec and
filter, so user needn't change their app or command if they don't use the
obsolete features.

Thanks
Haihao

> Haihao Xiang (10):
>   configure: ensure --enable-libmfx uses libmfx 1.x
>   configure: fix the check for MFX_CODEC_VP9
>   qsv: remove mfx/ prefix from mfx headers
>   qsv: load user plugin for MFX_VERSION < 2.0
>   qsv: build audio related code when MFX_VERSION < 2.0
>   qsvenc: support multi-frame encode when MFX_VERSION < 2.0
>   qsvenc: support MFX_RATECONTROL_LA_EXT when MFX_VERSION < 2.0
>   qsv: support OPAQUE memory when MFX_VERSION < 2.0
>   qsv: use a new method to create mfx session when using the oneVPL SDK
>   configure: add --enable-libvpl option
> 
>  configure|  28 ++-
>  libavcodec/qsv.c | 215 +++---
>  libavcodec/qsv.h |   4 +-
>  libavcodec/qsv_internal.h|   6 +-
>  libavcodec/qsvdec.c  |  15 +-
>  libavcodec/qsvenc.c  |  25 ++-
>  libavcodec/qsvenc.h  |   9 +-
>  libavcodec/qsvenc_h264.c |   3 +-
>  libavcodec/qsvenc_hevc.c |   3 +-
>  libavcodec/qsvenc_jpeg.c |   3 +-
>  libavcodec/qsvenc_mpeg2.c|   3 +-
>  libavcodec/qsvenc_vp9.c  |   3 +-
>  libavfilter/qsvvpp.c | 139 +++-
>  libavfilter/qsvvpp.h |  12 +-
>  libavfilter/vf_deinterlace_qsv.c |  72 ---
>  libavfilter/vf_scale_qsv.c   |  88 
>  libavutil/hwcontext_opencl.c |   2 +-
>  libavutil/hwcontext_qsv.c| 359 ++-
>  libavutil/hwcontext_qsv.h|  18 +-
>  19 files changed, 819 insertions(+), 188 deletions(-)
> 
___
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 00/10] make QSV works with Intel's oneVPL

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Xiang,
> Haihao
> Sent: Monday, 23 August 2021 06:29
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/10] make QSV works with Intel's
> oneVPL
> 
> On Mon, 2021-08-16 at 15:33 +0800, Haihao Xiang wrote:
> > The oneAPI Video Processing Library (oneVPL) is a single interface for
> > encode, decode and video processing[1]. oneVPL is a successor to Intel's
> Media
> > SDK (MediaSDK), but removed obsolete features. MediaSDK lifetime comes to
> an
> > end now[2].
> >
> > This patchset fixes compiler errors when building FFmpeg against oneVPL and
> > uses
> > a new way to create MFX session for oneVPL. New features for oneVPL will be
> > implemented in other patchset.
> >
> > The oneVPL source code:
> > https://github.com/oneapi-src/oneVPL
> > The oneVPL runtime for new Intel Gen platforms:
> > https://github.com/oneapi-src/oneVPL-intel-gpu
> >
> > [1]
> https://spec.oneapi.io/versions/latest/elements/oneVPL/source/index.html
> > [2] https://github.com/Intel-Media-SDK/MediaSDK/#media-sdk-support-matrix
> >
> 
> Hi Zhong / Mark / Softworkz,
> 
> Is there any comment to this new patchset version? This version should not
> have
> any impact to current user if --enable-libmfx option is used. We added --
> enable-
> onevpl option for oneVPL usage but the suffix 'qsv' is still used in codec
> and
> filter, so user needn't change their app or command if they don't use the
> obsolete features.


Hi Haihao,

I'm still struggling to understand this. You are doing a major version bump
to 2.x even there's not a single benefit but features are being removed 
instead.

At this time, I don't see any plausible reason to move away from libmfx.

Kind regards,
softworkz

___
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".