[FFmpeg-devel] [PATCH] Add av_file_get_size() and av_file_read(), replace cmdutils.h:read_file().
Fri Dec 3 18:43:46 CET 2010
On Fri, Dec 03, 2010 at 05:15:44PM +0100, Stefano Sabatini wrote:
> On date Thursday 2010-12-02 02:32:30 +0100, Michael Niedermayer encoded:
> > > +/**
> > > + * Read the file with name filename, and put its content in a newly
> > > + * allocated 0-terminated buffer. If filename references a link, the
> > > + * content of the linked file is read.
> > > + *
> > > + * @param bufptr location where pointer to buffer is returned
> > > + * @param size location where size of buffer is returned
> > > + * @param log_ctx context used for logging
> > > + * @return 0 in case of success, a negative value corresponding to an
> > > + * AVERROR error code in case of failure
> > > + */
> > > +int av_file_read(const char *filename, char **bufptr, size_t *size, void *log_ctx);
> > this API is crap.
> > at a minimunm it should support memory mapped files on platforms supporting them
> We could have a:
> int av_file_get(const char *filename, size_t *size, void *log_ctx);
> (alternative name: av_file_open())
> which returns the filedes and the size performing the boring checks,
> then the application may suck the content in a buffer or using mmap()
> access. Would be this acceptable?
its worse in every respect, and still doenst support mmap
what i was thinking of:
@param **bufptr The file content, can be a allocated buffer or access through mmap
fd=av_file_map(const char *filename, uint8_t **bufptr, size_t *size, int access_rights, void *log_ctx);
av_file_unmap(int fd, uint8_t *bufptr, size_t size);
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel