On Thu, Feb 20, 2014 at 3:01 PM, Paul B Mahol <[email protected]> wrote: > 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....
OK, if it helps I could generate some dpx samples for fate using Software like Adobe Speedgrade. Just let me know if there is interest in that. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
