On 12/3/18 3:43 PM, Nicolas George wrote:
Andrey Semashev (2018-12-03):
This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.
The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op.
---
libavformat/avio.c | 7 +++++++
libavformat/avio.h | 16 ++++++++++++++++
libavformat/aviobuf.c | 17 +++++++++++++++++
libavformat/url.h | 12 ++++++++++++
4 files changed, 52 insertions(+)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..19413ac586 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
return size;
}
+int ffurl_sync(URLContext *h)
+{
+ if (h->prot->url_sync)
+ return h->prot->url_sync(h);
+ return 0;
I think it should be an error, probably ENOSUP. Otherwise, the
application will assume it was done.
I don't think this would be useful to users. I mean, the application can
already check whether the operations is supported or not by inspecting
url_sync. When the application doesn't care (which, I think, will be the
majority of cases), they will treat ENOTSUP the same way as a success,
so it only adds more burden to test for this error code.
I could use some separate "success" code for the "not supported" result,
if there is one. Is there?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
