[FFmpeg-devel] [PATCH 1/3] libavformat: add "capture:" protocol

[Timothy Lee]

On 04/03/2017 06:35 PM, Nicolas George wrote:
> Hi. Thanks for the patch.
>
> Le quartidi 14 germinal, an CCXXV, Timothy Lee a écrit :
>> Capture is an input stream capture protocol that dumps the input stream to a
>> file.  The default name of the output file is "capture.dat", but it can be
>> changed using the "capture_file" option.
>>
>> capture.c borrows heavily from cache.c.
> Can you explain more precisely how and why? Borrowing code often means
> features could be merged or should be more clearly separated, depending
> on cases.

Hi Nicolas,

Thanks for your quick reply.  Regarding the almost direct copy of code 
from cache.c, I previously submitted a patch on 31 March that adds a 
"cache_file" option to the cache protocol.  It was intended to allow a 
specifically named cache file to serve as a dump of the input stream.

Michael Niedermayer explained that his intention was to maintain a 
caching system that was more consistent with how a browser's cache 
works, and my changes to the cache protocol was not appropriate.

Hence my attempt to duplicate the code from cache.c and use it for the 
capture protocol.

>> ---
>>   libavformat/Makefile    |   1 +
>>   libavformat/capture.c   | 321 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   libavformat/protocols.c |   1 +
>>   3 files changed, 323 insertions(+)
>>   create mode 100644 libavformat/capture.c
> I think the documentation and ChangeLog patches should be merged with
> this one.
OK.
>> + * Copyright (c) 2017 Timothy Lee
> If the file "borrows heavily", then copyright is owed.
Understood.  If I end up using cache.c, then I'll amend the copyright to 
reflect that.
>> +#include <fcntl.h>
>> +#if HAVE_IO_H
>> +#include <io.h>
>> +#endif
>> +#if HAVE_UNISTD_H
>> +#include <unistd.h>
>> +#endif
>> +#include <sys/stat.h>
>> +#include <stdlib.h>
>> +#include "os_support.h"
>> +#include "url.h"
>> +
>> +#ifndef O_BINARY
>> +#   define O_BINARY 0
>> +#endif
> Do you have any particular reason to use a direct file access for the
> capture file instead of relying on an AVIO URL?
> These are only preliminary comments. Pending explanations on the
> relation with cache:, I have not yet looked at the global logic.
> Regards,
Thank you for your suggestion.  I will look into the possibility of 
using AVIO URL to implement the capture protocol instead.

Timothy Lee