On Wed, 17 Feb 2016 17:05:18 +0100 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 Please explain why such a corner case means the common case can't be handled properly. (That aside, mpeg can show a lot of behavior that libavfilter can't handle.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
