[FFmpeg-devel] [PATCH 1/3] libavformat: add "capture:" protocol
timothy.ty.lee at gmail.com
Mon Apr 3 12:10:42 EEST 2017
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.
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
>> 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.
>> + * 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
>> +#include <fcntl.h>
>> +#if HAVE_IO_H
>> +#include <io.h>
>> +#if HAVE_UNISTD_H
>> +#include <unistd.h>
>> +#include <sys/stat.h>
>> +#include <stdlib.h>
>> +#include "os_support.h"
>> +#include "url.h"
>> +#ifndef O_BINARY
>> +# define O_BINARY 0
> 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.
Thank you for your suggestion. I will look into the possibility of
using AVIO URL to implement the capture protocol instead.
More information about the ffmpeg-devel