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

[Jan Ekström]

On Mon, Oct 4, 2021 at 1:06 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Mon, Oct 04, 2021 at 12:25:26AM +0300, Jan Ekström 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:
>
> Assume a network protocol, TCP, UDP, HTTP, RT*P whatever
> how do you tune the buffer sizes ?
> Can the number of seeks be used ?
> or from a different point of view, if there are alot of seeks should
> a user app try to increase the buffer sizes ?
>
> maybe iam missing something but when playing a not perfectly interleaved file
> over the network the buffer size should be what makes the difference between
> that working or not working
> ideally a user app shouldnt need to mess with this, of course and these values
> should all be automagically adjusted
>
> If a user app fails to get packets in realtime over the network, it would
> fail to play that stream. Some user apps could display a warning message to
> the user about it.
> If now the user app has access to the number of seeks it could be more
> specific in the warning to the user.
> "Unable to play network is maybe too slow"
> "Unable to play buffer is maybe too small or file is poorly interleaved"
> ...
>
> Maybe iam just seeing all this from the wrong side i dunno but to me it seems
> usefull to a user app to have access to the number of seeks and these seem
> non contrived use cases to me ... Ive gotten random point to nowhere
> warnings about playback issues and restarting the computer obviously that
> never was the issue.
>
> thx
>

OK, I think this is now focusing on the wrong point, sorry.

I think it's just better for me to note that I am not the best person
to post (and thus be the one to argue for the usefulness in reviews if
someone asks why I am bringing those private entries that were once
removed back to the public struct) of those other entries.

Jan