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@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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
