[FFmpeg-devel] [PATCH v2 2/2] ffmpeg: add option -isync

Anton Khirnov anton at khirnov.net
Mon Jul 4 09:29:57 EEST 2022


Quoting Gyan Doshi (2022-07-04 05:47:31)
> 
> 
> On 2022-07-02 03:21 pm, Gyan Doshi wrote:
> >
> >
> > On 2022-07-02 02:12 pm, Anton Khirnov wrote:
> >> Quoting Gyan Doshi (2022-07-01 13:03:04)
> >>>
> >>> On 2022-07-01 03:33 pm, Anton Khirnov wrote:
> >>>> Quoting Gyan Doshi (2022-06-25 10:29:51)
> >>>>> This is a per-file input option that adjusts an input's timestamps
> >>>>> with reference to another input, so that emitted packet timestamps
> >>>>> account for the difference between the start times of the two inputs.
> >>>>>
> >>>>> Typical use case is to sync two or more live inputs such as from 
> >>>>> capture
> >>>>> devices. Both the target and reference input source timestamps 
> >>>>> should be
> >>>>> based on the same clock source.
> >>>> If both streams are using the same clock, then why is any extra
> >>>> synchronization needed?
> >>> Because ffmpeg.c normalizes timestamps by default. We can keep
> >>> timestamps using -copyts, but these inputs are usually preprocessed
> >>> using single-input filters which won't have access to the reference
> >>> inputs,
> >> No idea what you mean by "reference inputs" here.
> >
> > The reference input is the one the target is being synced against. 
> > e.g. in a karaoke session -  the music track from a DAW would be ref 
> > and the user's voice via mic is the target.
> >
> >>> or the merge filters like e.g. amix don't sync by timestamp.
> >> amix does seem to look at timestamps.
> >
> > amix does not *sync* by timestamp. If one input starts at 4 and the 
> > other at 7, the 2nd isn't aligned by timestamp.
> 
> If any further comments or objections, let me know.
> 
> Plan to push set tonight.

Could you please stop constantly threatening to push things when I don't
reply for a day? The traffic on the ML is insane, sometimes I'd like to
work on my own code, and maybe even have a life outside of ffmpeg.

You want to add two new public interfaces, which means we as a project
commit to maintaining them indefinitely. Changing or removing such
things once they are in is a long and arduous process, so they should
not be rushed.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list