[Libav-user] Does the image2 demuxer work with a custom AVIOContext?

[Robert Krüger]

On Thu, Feb 20, 2014 at 3:01 PM, Paul B Mahol <onemda at gmail.com> wrote:
> On 2/20/14, Robert Krueger <krueger at lesspain.de> wrote:
>> On Wed, Feb 19, 2014 at 10:02 PM, Paul B Mahol <onemda at gmail.com> wrote:
>>> On 2/19/14, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>>>> Carl Eugen Hoyos <cehoyos at ...> 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.