On Wed, Feb 17, 2016 at 11:28 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Wed, Feb 17, 2016 at 5:05 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: >> On Wed, Feb 17, 2016 at 04:58:31PM +0100, wm4 wrote: >>> On Wed, 17 Feb 2016 22:55:47 +0700 >>> Muhammad Faiz <mfc...@gmail.com> wrote: >>> >>> > On Wed, Feb 17, 2016 at 10:20 PM, wm4 <nfx...@googlemail.com> wrote: >>> > > On Wed, 17 Feb 2016 21:30:20 +0700 >>> > > Muhammad Faiz <mfc...@gmail.com> wrote: >> [...] >>> > > >>> > > Possibly it happens to work for you because there are no filters with >>> > > much buffering and you didn't try video. >>> > > >>> > I don't mean that it will be supported by all filters. On filters with >>> > much buffering, probably there will be huge delay between seek command >>> > and their new output pts (It is tolerable). On filters which assume linear >>> > pts, probably it will fail. >>> >>> How is that even a reasonable argument? >>> >>> libavfilter already has enough "works in maybe 10% of all cases" >>> solutions. >> >> mpeg* can contain discontinuities in the timestamps already without >> any seeking >> > > Just because there could be discontinuities in some formats doesn't > mean there should be no proper handling of seeking and flushing. > A seek requires a flush on all components involved, thats just the > most basic logic.
The most common case when seek without flush is that the output pts response to seek will be delayed. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
