On 9/27/16, Priebe, Jason <jpri...@cbcnewmedia.com> wrote: > On 9/23/16, Paul B Mahol <one...@gmail.com> wrote: > >> Named pipe approach would implement video source which would read images >> from named pipe. It would read from named pipe until it decodes single >> frame >> and then would use that frame as input to next filter, for example >> overlay filter. >> >> If it encounters EOF in named pipe it would not abort but would instead >> keep >> sending last frame it got, for example completely transparent frame. >> >> If it suddenly get more data from pipe it would update its internal >> frame and output it as input to next filter in chain. >> >> So command would look like this: >> >> imagepipe=named_pipe:rate=30[o],[0:v][o]overlay=x=0:y=0 ... >> >> And than in another terminal, you would use commands like this: >> >> cat random_image.format > named_pipe > > Paul: this is a really good idea (when you first mentioned pipes, I > thought you meant to use pipes as a standard ffmpeg input, which doesn't > really work in the way I'm trying to make it work here). But a purpose- > built filter that reads from a pipe is another story. > > I built an imagepipe filter that I'd like to submit as a patch, but > I have some questions before I do that: > > - it outputs YUVA420P. Does it need to output other pixel formats to > be accepted?
Not neccessary if adding other formats is easy. > > - 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'm not 100% sure how to write the test. I added a block=1 option to > the filter so that it will block on each frame to read in an image from > the pipe; this is designed for testing only (normally, you want > non-blocking > reads). But I don't know how to leverage FATE to build a test that > runs ffmpeg and also in another process, writes files to the pipe. I > think I can do it if I add a new function to fate-run.sh, but I don't know > if that is discouraged. Test can be added later. > > - 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
