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 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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
