On 19/08/2017 20:56, Diego Biurrun wrote:
On Sat, Aug 19, 2017 at 07:28:43PM +0200, Anton Khirnov wrote:
Quoting wm4 (2017-08-18 15:35:49)
On Fri, 18 Aug 2017 15:22:28 +0200
Anton Khirnov <[email protected]> wrote:
Quoting wm4 (2017-08-18 14:44:45)
On Fri, 18 Aug 2017 15:40:32 +0300 (EEST)
Martin Storsjö <[email protected]> wrote:
On Fri, 18 Aug 2017, Anton Khirnov wrote:
Quoting wm4 (2017-08-17 15:01:44)
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
---
doc/APIchanges | 3 +++
libavformat/avio.h | 9 +++++++++
libavformat/avio_internal.h | 8 --------
libavformat/aviobuf.c | 2 +-
libavformat/rawdec.c | 2 +-
libavformat/rtsp.c | 2 +-
libavformat/version.h | 2 +-
7 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 463247f48e..ed90be890d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2017-03-23
API changes, most recent first:
+2016-xx-xx - xxxxxxx - lavf 58.1.0 - avio.h
+ Add avio_read_partial().
+
2017-xx-xx - xxxxxxx - lavu 56.4.0 - imgutils.h
Add av_image_fill_black().
diff --git a/libavformat/avio.h b/libavformat/avio.h
index e65135ed99..f604c4ad41 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -331,6 +331,15 @@ void avio_flush(AVIOContext *s);
*/
int avio_read(AVIOContext *s, unsigned char *buf, int size);
+/**
+ * Read size bytes from AVIOContext into buf. Unlike avio_read(), this is
allowed
+ * to read fewer bytes than requested. The missing bytes can be read in the
next
+ * call. This always tries to read at least 1 byte.
+ * Useful to reduce latency in certain cases.
+ * @return number of bytes read or AVERROR
+ */
+int avio_read_partial(AVIOContext *s, unsigned char *buf, int size);
Maybe this would be a good opportunity to make this size_t
Hmm, not sure how much point there is in that, since all of the
intermediate api (the avio callbacks) still are in int. So I'm wondering
if it's better to change things gradually with a large inconsistency
internally in the avio layer, or just switch it all at once (if needed).
I'd vote the latter.
Well, it's easier to change internals than public API.
In this case I'd prefer a gradual transition.
I'm telling you that makes no sense. int is everywhere in the avio
code, including the central/most used parts of the API, and it won't
help a single bit to change an obscure function to size_t, and for
which the only effect of the change is probably to trigger weird bugs.
Ok, seems I'm in the minority, so I won't press this further.
I'd just suggest considering int64, since 4G is not _that_ insanely huge
and is actually the type we use internally for file sizes/offests.
But if you disagree, I'm fine with either.
FTLIW, I'm for size_t.
I'd rather do that on the next api break. We set a week with enough
people available and replace the usages everywhere in the I/O layer
(and while at it could we spin it off to a separate library?)
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
