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

[Gyan Doshi <ffmpeg@gyani.pro>]

On 2022-07-04 10:12 am, Anton Khirnov wrote:
> 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?

It can. I wanted to avoid all the latency I could. But I can shift it 
there. Will do.

Regards,
Gyan
_______________________________________________
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".