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