[FFmpeg-devel] imagepipe filter (was [PATCH] avfilter: add dynoverlay filter.)

[Priebe, Jason]

On 9/23/16, Paul B Mahol <onemda at gmail.com> wrote:

> On 9/27/16, Priebe, Jason <jpriebe at cbcnewmedia.com> wrote:
> > On 9/23/16, Paul B Mahol <onemda at gmail.com> wrote:
> >
> > - it uses a slightly inelegant technique to read the images; it writes
> >   the image data to a temp file so it can call ff_load_image().  I didn't
> >   see a function that can load an image directly from an in-memory byte
> > array.
> 
> AVFrame stores all decoded data from image. Using temp files is ridicculous.

I do store the *decoded* image in an AVFrame.  I only use the temp file
when I finish reading the *encoded* image from the named pipe -- I
write to a temp file, hand that off to ff_load_image(), and once the
image has been decoded, I destroy the temp file.

Like I said, I don't see any way to decode an in-memory encoded
image (PNG, JPG, etc.) with the existing function calls.  I only
see ff_load_image(), which takes a filename.

I think that trying to decode a PNG out of an in-memory buffer would
require refactoring inside of files like libavformat/utils.c, which
would require a deeper understanding of the internals than I have.

If there's a better way to decode these still images without using
an intermediate temp file, please point me to it, and I'll make the
change.

> > - Portability - I'm worried this is the big one.  mkfifo isn't readily
> >   available on Windows without compatibility libraries, and even then,
> >   I'm not sure whether they would work the same way they do under *nix.
> >   Generally speaking, how does the ffmpeg team tackle cross-platform
> >   issues like this?
> 
> IIRC named pipes are available for Windows.

I think you are right -- the *concept* of named pipes exists in
Windows, but the mkfifo() call doesn't create them.  You have
to use calls like CreateNamedPipe() and ConnectNamedPipe().

It looks like there is some windows compatibility code for handling
standard file open() calls in libavutil/file_open.c, so I suppose
that something like that could be built for named pipes (maybe one
call that creates and opens the named pipe, with conditional calls
for *nix and Windows?)

This is way outside my wheelhouse -- I don't even have a Windows
build environment.  But if it's a show-stopper, then I can slog
my way through it. 

Jason Priebe
CBC New Media