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

Michael Niedermayer michael at niedermayer.cc
Fri Feb 26 01:52:47 CET 2016


On Thu, Feb 25, 2016 at 07:02:31PM +0100, Stefano Sabatini wrote:
> On date Thursday 2016-02-25 13:41:02 +0100, Michael Niedermayer encoded:
> > On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
> [...]
> > > 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
> 
> See attached patch.
> 
> [...]
> -- 
> FFmpeg = Fiendish and Fierce Mastering Political Empowered Geisha

>  mux.c |    1 +
>  1 file changed, 1 insertion(+)
> 28a1647f5cd7b49f6fe439777af61241adf5c19f  0001-lavf-mux-do-not-fail-in-case-of-non-strictly-monoton.patch
> From 0996189555f4a2402b396801da318b4ffcfb1a13 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini <stefasab at gmail.com>
> Date: Thu, 17 Dec 2015 20:51:42 +0100
> Subject: [PATCH] lavf/mux: do not fail in case of non strictly monotonically
>  increasing DTS values for data packets
> 
> Consistent with what we already do with subtitles since ac08c5c0adcb7f2f9b5ea3eb473d1c2b9659aab2.

LGTM

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20160226/e39de995/attachment.sig>


More information about the ffmpeg-devel mailing list