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-requ...@ffmpeg.org with subject "unsubscribe".
