On 9/28/16, Priebe, Jason <jpri...@cbcnewmedia.com> wrote: > On 9/23/16, Paul B Mahol <one...@gmail.com> wrote: > >> On 9/27/16, Priebe, Jason <jpri...@cbcnewmedia.com> wrote: >> > On 9/23/16, Paul B Mahol <one...@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.
Using avformat/avcodec calls to decode input from named pipe into AVFrame. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel