On Mon, Oct 4, 2021 at 1:06 AM Michael Niedermayer <mich...@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 > > <mich...@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 > > > > <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
