On Fri, Jan 06, 2017 at 18:08:44 +0100, Martin Vignali wrote:
> Did you try,all the official display/data window sample ?
I did have a look at a few selected samples, and ffmpeg doesn't seem to
handle them:
http://ffmpeg.org/pipermail/ffmpeg-user/2017-January/034831.html
I'm not sure
No, just this kind.
Behind the images when data = display window, the most common case
OpenEXR file we have, is with a reduced data window that resides
completely inside the display window, though this particular bug would
impact any files where the value of ymax+1 is not equal to the height.
On 1/6/17, Kevin Wheatley wrote:
> The following is a sample EXR that needs the patch to correctly
> process in FFmpeg.
>
> Kevin
>
patch applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hello,
Did you try,all the official display/data window sample ?
I will try to take a look this week end.
Thanks for the sample
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The following is a sample EXR that needs the patch to correctly
process in FFmpeg.
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
looks like there is a bug in commit
1a08758e7c4e14a9ea8d2fef6c33ad411b2d3c40 relating to the handling of
ptr in decode_frame after decode_block is called, before this commit
ptr would have been incremented for each line in the data window, now
after the commit it is left at the start of the first