[FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

[Michael Niedermayer]

On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2016-02-23 20:32:23 +0100, Michael Niedermayer encoded:
> > On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote:
> [...]
> > > > I have an use case with data packets that have the same PTS (which
> > > > makes sense in that specific case). Since I want to fix this issue,
> > > > and dropping the check inconditionally may not be acceptable, I
> > > > propose the following variants:
> > > > 
> > > > * I add an option to drop strict monotonicity checks on data packets
> > > > 
> > > > * I enable a format level capability which disables the strict
> > > >   monotonicity requirement for data packets depending on the format
> > > > 
> > > > What do you find acceptable?
> > 
> 
> > i think its fine to treat data the same as subtitles
> 
> In general, we can assume that makes no sense to have more than one
> packet with the same PTS/DTS for audio or video and for the same
> stream.
> 
> As for subtitles, I'm not sure we should accept that as well, but at
> least in theory I can imagine an use case with multiple packets (and
> thus frames) conveying text information pertaining to the same time
> and stream.  As for data, I think we can safely assume several piece
> of generic data in different packets but with the same timestamp,
> since they are meant to be processed by an automated agent.
> 
> So, while the check makes sense for audio and video, in the case of
> subtitles and data we are in the fuzzy area. In principle, I agree
> with the fact that data and subtitles should be treated in the same
> way, so I propose the following options:
> 
> 1. disable the strict monotonicity check for both data and subtitles
>    inconditionally

yes, do with data what is done with subtitles already IIRC


> 
> 2. add a libavformat muxing option to disable strictness in the
>    timestamps monotonicity check for both data and subtitles
> 
> 3. generalize 2. and provide a libavformat muxing option to disable
>    strictness in the timestamps monotonicity check for some selection
>    of output streams (e.g. using stream specifiers)
> 
> I have no special preference, so I'd leave this decision to the
> libavformat maintainer (which I believe it's still you ;-)).
> 
> In case any of these solutions is not considered acceptable, I need to
> come with an application level solution (but this would mean that
> ffmpeg the tool cannot be used for that).
> -- 
> FFmpeg = Fast and Formidable MultiPurpose Efficient Goblin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160225/0f59d4e6/attachment.sig>