On 2/20/14, Robert Krueger <[email protected]> wrote: > 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.
The sample is made before dpx encoder existed in ffmpeg.... > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
