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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
