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

[Jan Ekström]

On Mon, Oct 4, 2021 at 12:25 AM Jan Ekström <jeebjp at gmail.com> wrote:
>
> 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.

Also just checked, and AVIOContext::written seems to be this
"bytes_written" already :) Just completely undocumented.

Jan