[FFmpeg-devel] [PATCH v2 1/2] avformat: add AVFormatContext.first_pkt_wallclock
Anton Khirnov
anton at khirnov.net
Mon Jul 4 07:42:46 EEST 2022
Quoting Gyan Doshi (2022-07-02 11:51:49)
>
>
> On 2022-07-02 02:12 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-01 13:07:13)
> >>
> >> On 2022-07-01 03:20 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2022-06-28 08:40:58)
> >>>> On 2022-06-28 10:43 am, Anton Khirnov wrote:
> >>>>> Quoting Gyan Doshi (2022-06-25 10:29:50)
> >>>>>> Stores wallclock time for the first packet received.
> >>>>>> Used for crude sync offset among inputs.
> >>>>>> ---
> >>>>>> doc/APIchanges | 3 +++
> >>>>>> libavformat/avformat.h | 10 ++++++++++
> >>>>>> libavformat/demux.c | 3 +++
> >>>>>> libavformat/options.c | 1 +
> >>>>>> libavformat/version.h | 2 +-
> >>>>>> 5 files changed, 18 insertions(+), 1 deletion(-)
> >>>>> Why should this be in the library? Seems to me this can be just as
> >>>>> easily done by the callers who need it.
> >>>> To not add some extra latency, just like how
> >>>> `use_wallclock_as_timestamps` was implemented inside lavf.
> >>> Where would that extra latency come from?
> >> The interval between its current assigment inside ff_read_packet() and
> >> the chance for assignment in process_input() in ffmpeg.c
> > And why would there be a significant delay there?
>
> With multiple inputs, get_input_packet_mt() will populate each input
> queue in async whereas process_input() will be called on that input at
> best in a round robin fashion depending on choose_output().
So why should this information not be set by get_input_packet_mt() then?
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list