[FFmpeg-devel] [PATCH] avfilter/src_movie: add various commands

Michael Niedermayer michael at niedermayer.cc
Wed Feb 17 19:07:56 CET 2016


On Wed, Feb 17, 2016 at 05:28:14PM +0100, Hendrik Leppkes wrote:
> On Wed, Feb 17, 2016 at 5:05 PM, Michael Niedermayer
> <michael at 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 <mfcc64 at gmail.com> wrote:
> >>
> >> > On Wed, Feb 17, 2016 at 10:20 PM, wm4 <nfxjfg at googlemail.com> wrote:
> >> > > On Wed, 17 Feb 2016 21:30:20 +0700
> >> > > Muhammad Faiz <mfcc64 at 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.

i think my comment was a bit misunderstood, i did not mean to suggest
that "proper" seek handling is not needed
just that discontinuities already exist and i belive alot more than
10% of the filters handle them fine

yes, some form of flushing is needed for user initiated seeks.


Other seeks like from a edit list (if that is using the same system)
would be better without flush as that would disturb the state of
filters, similarly timestamp discontinuities should not trigger
a full rebuild of the filter graph
that might be off topic though


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20160217/b17591a0/attachment.sig>


More information about the ffmpeg-devel mailing list