On Wed, Feb 19, 2014 at 10:02 PM, Paul B Mahol <[email protected]> wrote: > On 2/19/14, Carl Eugen Hoyos <[email protected]> wrote: >> Carl Eugen Hoyos <cehoyos@...> writes: >> >>> Robert Krueger <krueger <at> ...> writes: >>> >>> > cat ~/samples/fate/dpx/lighthouse_rgb48.dpx | ./ffmpeg >>> > -f image2pipe -vcodec dpx -i - ~/tmp/fromdpx_pipe2.png >>> >>> > [dpx <at> 0x7fcb21822600] Overread buffer. Invalid header? >>> >>> The image is cut in the middle >> >> Iiuc, the parser reads the file size from the file >> header while the decoder calculates the (minimal >> possible) file size. The value that the parser >> reads from the file header is too small. >> >> I suspect the bug can be fixed by reusing the logic >> to determine the image size also in the parser or >> by ignoring the file size outputting everything until >> the next magic marker. > > There is no bug in parser, bug is in dpx file which do not > conform to the specification. > > FFmpeg dpx encoder is fine. > > ImageMagick sucks.
OK, I didn't know the file was generated using ImageMagick but I see it now. Then it is irrelevant for me and I will ignore this as long as valid dpx files work with this approach. Thank you for the analysis. I don't know what the sample is used for in fate but maybe it's there for testing broken dpx files. It just happend to be there when I was looking for a dpx file to test the image2pipe approach. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
