[FFmpeg-devel] [PATCH] avformat/avio{, buf}: introduce public AVIOContext::bytes_read

[Jan Ekström]

On Sat, Oct 2, 2021 at 2:51 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> 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
> > <michael at 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

I would prefer to add fields which were noted as specifically private
and then cleaned up when there are actual API client users that would
see them as useful, or if there are clear use cases where they'd be
useful. I have seen the read bytes statistic actually being utilized
by an API client with a comment:

// This is fully intentional - there is no other way to get this
// information (not even by custom I/O, because the connection reuse
// mechanism by the HLS demuxer would get disabled)

(note: not sure if that any more holds true)

Also I double-checked and the write statistic was in counts, not
bytes. So that I see as generally less useful than something like
"bytes_written" if such were to exist.

Jan