[FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output

[Rodger Combs]

> On Thu, Aug 21, 2014 at 02:00:22PM +0200, Hendrik Leppkes wrote:
> > On Thu, Aug 21, 2014 at 1:38 PM, compn <tempn at mi.rr.com <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> wrote:
> > > https://gist.github.com/anonymous/0e26f490ec13d67996fd <https://gist.github.com/anonymous/0e26f490ec13d67996fd>
> > >
> > > commit e94a44543a96b13aa6a23efce2f0378a5479d530
> > > Author: Rodger Combs <rodger.combs at gmail.com <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
> > > Date:   Wed Aug 20 15:38:12 2014 -0700
> > >
> > >     avformat/nullenc: mark null as timestamp-nonstrict
> > >     This avoids unnecessary error messages for null output
> > >
> > > diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
> > > index 7c08c39..58b88a1 100644
> > > --- a/libavformat/nullenc.c
> > > +++ b/libavformat/nullenc.c
> > > @@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
> > >      .audio_codec       = AV_NE(AV_CODEC_ID_PCM_S16BE, AV_CODEC_ID_PCM_S16LE),
> > >      .video_codec       = AV_CODEC_ID_RAWVIDEO,
> > >      .write_packet      = null_write_packet,
> > > -    .flags             = AVFMT_VARIABLE_FPS | AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > > +    .flags             = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS | AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > >  };
> > 
> > There is a lot of other muxers out there that also have NOTIMESTAMPS
> > set, and not this flag.
> > 
> > IMHO the code that complains about invalid timestamps should be
> > adjusted to not do it when NOTIMESTAMPS is set, instead of this.
> 
> maybe but for testing/fate at least we should retain timestamp
> checks, null is used alot for testing if one looks at trac
> iam not sure what is the best thing to do here

How about adding a lavf option? I could imagine a few ways that could be done, but my favorite is to make `AVFMT_NOTIMESTAMPS` imply `AVFMT_TS_NONSTRICT` (on the checking code's end), and add an option to re-enable the error (possibly downgraded to a warning?) even with non-strict encoders. We could also have the option disable the error with strict encoders (but that seems less sensible to me).