[FFmpeg-devel] [PATCH] avformat/mux: skip parameter and pts checks for data muxer

[Hendrik Leppkes]

On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
> >
> >
> > On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> > >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> > >>  mux.c |    9 ++++++++-
> > >>  1 file changed, 8 insertions(+), 1 deletion(-)
> > >>d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46  0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
> > >> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
> > >>From: Gyan Doshi <ffmpeg at gyani.pro>
> > >>Date: Fri, 26 Apr 2019 18:31:33 +0530
> > >>Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
> > >>
> > >>Allows to dump a malformed stream for external inspection or repair.
> > >>---
> > >>  libavformat/mux.c | 9 ++++++++-
> > >>  1 file changed, 8 insertions(+), 1 deletion(-)
> > >>
> > >>diff --git a/libavformat/mux.c b/libavformat/mux.c
> > >>index 83fe1de78f..3699b572f2 100644
> > >>--- a/libavformat/mux.c
> > >>+++ b/libavformat/mux.c
> > >>@@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >>          goto fail;
> > >>      }
> > >>+    if (!strcmp(of->name, "data"))
> > >>+        goto bypass;
> > >>+
> > >>      for (i = 0; i < s->nb_streams; i++) {
> > >>          st  = s->streams[i];
> > >>          par = st->codecpar;
> > >>@@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >>          av_dict_set(&s->metadata, e->key, NULL, 0);
> > >>      }
> > >>+bypass:
> > >I think this skips a bit more than what would make sense
> > >(for example priv_data allocation but thats not the only odd thing)
> > >
> > >also iam not sure this is the ideal approuch.
> > >I mean "I want to dump inavlid data in a data muxer for debug"
> > >that seems a potentially valid request for other muxers too
> > >like the image muxer producing individual files per frame and
> > >so on
> > What would be the ideal approach?
>
> I guess the ideal approuch would be to allow the developer who needs
> this to override the check when the muxer in use can actually saftely
> mux it without the specific check.
> There are for example muxers which would not function properly with
> backward going dts or something like that
>

We already have a variety of flags in place, like if a muxer doesn't
care for timestamps at all, flag it AVFMT_NOTIMESTAMPS, and have code
that checks timestamps check for this flag. Checks based on muxer
names seem generally always wrong.

- Hendrik