On Sat, Oct 02, 2021 at 02:42:52PM +0300, Jan Ekström wrote: > On Sat, Oct 2, 2021 at 1:32 PM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > > > On Sun, Sep 26, 2021 at 06:48:18PM +0300, Jan Ekström wrote: > > > Such a field can be seen as generally useful in cases where the > > > API user is not implementing custom AVIO callbacks, but still would > > > like to know if data is being read even if AVPackets are not being > > > returned. > > > --- > > > Originally I thought about making an accessor for the private field, to > > > not grow the public struct's size (and have a duplicate field, as well > > > as making sure the value was read-only). But an objection was raised > > > that such accessors should be refrained from as they unnecessarily > > > filled the function symbol space or so. Together with the objection, a > > > proposal of making it a field on the public struct that was only written > > > to was proposed. > > > > > > This patch follows that proposal. > > > > > > doc/APIchanges | 3 +++ > > > libavformat/avio.h | 5 +++++ > > > libavformat/aviobuf.c | 2 ++ > > > libavformat/version.h | 2 +- > > > 4 files changed, 11 insertions(+), 1 deletion(-) > > > > There are 3 statistics, read, write and seek > > shouldnt all 3 be provided to the user? > > > > thx > > > > I added one which I have seen actually utilized by at least one API > client, and then others could be added as per responses. > > That is why I pinged, as I had not received any responses - either > positive or negative. >
> Writing I can see a use for, seek I am not as sure of. But if you > believe all of them should be exposed I am fine with that. seek is timeconsuming especially if its over a network due to latency. So for example if suddenly the number of seeks changes that could be interresting. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
signature.asc
Description: PGP signature
_______________________________________________ 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".
