[FFmpeg-devel] [PATCH v2 1/2] lavf: Add general API for IO buffer synchronization.

[Andrey Semashev]

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.