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

[Jan Ekström]

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

Ping? Is this now in a purgatory state due to me not wanting to be the
one to argue for the other options in review?

Jan