Bug#420231: ffmpeg needs trickery to read from pile of pipes

[Ian Jackson]

Package: ffmpeg
Version: 0.cvs20060823-8
Severity: wishlist

I am trying to encode a video stream using ffmpeg (or indeed
ffmpeg2theora).  The input data to be encoded comes from a series of
netpbm runes, one small shell scriptlet per frame.

Ideally I would like to use the `image2pipe' format but this has a
critical bug which AFAICT renders it unuseable.  See my other report.

Instead I provide ffmpeg with a directory full of named pipes, for use
by -f image2.  However, there are two problems:

1. ffmpeg opens and then closes many prospective files right at the
start, apparently trying to figure out which files exist so it knows
how many frames there are.  There is no need to open the files at this
stage - stat() or access() would be the right calls to use.

2. When it actually starts encoding, ffmpeg lseeks each file right
after opening it, apparently trying to find out its length.  This is
not necessary: in particular, we know that it's not supposed to be
necessary at all (or at least it's unnecessary for many frame image
formats) because the image2pipe format is supposed to be able to
achieve the same thing.

I observed these behaviours in strace.  I solved my problem with a
subterfugue trick, which makes it seem to ffmpeg that these things are
all plain seekable files even though in fact they're pipes which are
opened and written to by the data provider in order.  This is
obviously less than ideal.

Ian.