On 12/6/18 9:29 PM, Nicolas George wrote:
Andrey Semashev (2018-12-04):
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.
Users can distinguish this case from the successful completion by the result
code AVIO_SYNC_NOT_SUPPORTED, which is also considered a successful result
(i.e. >0).
---
  libavformat/avio.c    |  7 +++++++
  libavformat/avio.h    | 33 +++++++++++++++++++++++++++++++++
  libavformat/aviobuf.c | 17 +++++++++++++++++
  libavformat/url.h     | 13 +++++++++++++
  4 files changed, 70 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..662d4ed971 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 AVIO_SYNC_NOT_SUPPORTED;
+}
+
  int ffurl_get_file_handle(URLContext *h)
  {
      if (!h || !h->prot || !h->prot->url_get_file_handle)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..403ee0fc7b 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -349,6 +349,15 @@ typedef struct AVIOContext {
       * Try to buffer at least this amount of data before flushing it
       */
      int min_packet_size;
+
+    /**
+     * A callback for synchronizing buffers with the media state.
+     *
+     * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
+     *         the operation is not supported and ignored, an AVERROR < 0
+     *         on error.
+     */
+    int (*sync)(void *opaque);
  } AVIOContext;
/**
@@ -586,6 +595,30 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
av_printf_format(2, 3);
   */
  void avio_flush(AVIOContext *s);

+/**
+ * Indicates that the sync operation has been carried out successfully
+ */
+#define AVIO_SYNC_SUCCESS 0
+
+/**
+ * Indicates that the sync operation is not supported by the underlying
+ * resource and has been ignored
+ */
+#define AVIO_SYNC_NOT_SUPPORTED 1

I must say, I really do not like this version at all. ENOTSUP feels like
a much more consistent solution.

Could you provide an example where ENOTSUP (i.e. the error code) would make more sense for a sync operation, as opposed to AVIO_SYNC_NOT_SUPPORTED (i.e. the success code)?

I have used this API internally in an application for a few years, and I never wanted to distinguish the "not supported" case from "success", let alone specifically handle it as an error. I have further patches to extend this functionality in ffmpeg and the intention there is similar - in no case I want the "not supported" case to be an error.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to