Re: [FFmpeg-devel] [PATCH v2 1/2] avformat: add AVFormatContext.first_pkt_wallclock

[Anton Khirnov <anton@khirnov.net>]

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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".