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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20211004/32ff07fe/attachment.sig>