[FFmpeg-devel] [PATCH v3] ffmpeg: add option -isync

[Hendrik Leppkes]

On Sat, Jul 9, 2022 at 9:56 PM Gyan Doshi <ffmpeg at gyani.pro> wrote:
>
>
>
> On 2022-07-10 01:13 am, Paul B Mahol wrote:
> > On Sat, Jul 9, 2022 at 8:28 PM Gyan Doshi <ffmpeg at gyani.pro> wrote:
> >
> >>
> >> On 2022-07-08 09:26 am, Gyan Doshi wrote:
> >>>
> >>> On 2022-07-07 03:11 pm, Anton Khirnov wrote:
> >>>> Quoting Gyan Doshi (2022-07-04 18:29:12)
> >>>>> 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 not all inputs have timestamps, the wallclock times at the time of
> >>>>> reception of inputs shall be used. FFmpeg must have been compiled with
> >>>>> thread support for this last case.
> >>>> I'm wondering if simply using the other input's InputFile.ts_offset
> >>>> wouldn't achieve the same effect with much less complexity.
> >>> That's what I initially did. But since the code can also use two other
> >>> sources for start times (start_time_realtime, first_pkt_wallclock),
> >>> those intervals may not exactly match the difference between
> >>> fmctx->start_times so I use a generic calculation.
> >> Plan to push on Monday, if no further changes. 5.1 is to be cut soon.
> >>
> >>
> > Why big rush, its not so critical.
>
> Patch was first sent on 22nd June. Only one reviewer asked for changes.
>

It does however not seem like that reviewer has ultimately signed off, did he?
Lack of response for a day does not make previous objections just go away.

- Hendrik