On Wed, Aug 27, 2014 at 08:13:24PM -0500, Rodger Combs wrote: > > 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).
possible, yes, i dont know what is best [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
