Re: [FFmpeg-user] OpenEXR input with cropped data window produces black output
As a partial fix I've submitted a patch here: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205267.html That fixes the simple cases. Kevin ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] OpenEXR input with cropped data window produces black output
Hello, FFmpeg EXR decoder, have some trouble with display window != data window And if i remember correctly, if top left doesn't start at 0/0 But the way to manage the display window, is not the same, if data window is bigger than display window or the opposite. I begin to work on this, but not enough time now to finish this patch Martin ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] OpenEXR input with cropped data window produces black output
Answering my own question... I have not tested this but having manually read the code in the git history I'll try code up a fix for my theory: looks like there is a bug in the 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 included line rather than the line after the data window then the code sets the remaining lines to 0 and thus the whole image is over written. Kevin ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] OpenEXR input with cropped data window produces black output
On Tue, Jan 03, 2017 at 11:56:06 +, Kevin Wheatley wrote: > dataWindow (type box2i): (873 318) - (1174 625) > displayWindow (type box2i): (0 0) - (1919 1079) "file" (the "magic" program) kindly reports these as well. > ffmpeg -y -loglevel debug -apply_trc linear -i /tmp/exr_test.%04d.exr > -c:v libx264 /tmp/test.mov > > I end up with a full frame of black, changing EXR compression type > (none, zip 1, PIZ, etc) or data type (16 bit/32 bit) does not make a > difference, nor does switching to mp4 output container, or using mjpeg > as an codec. ffmpeg's exr implementation does seem to have some shortcomings. What is to happen with these windows is described here: https://github.com/openexr/openexr-images/tree/master/DisplayWindow Sample t04.exr has dataWindow: (0 0)-(399 299) displayWindow: (0 0)-(369 279) but ffmpeg chokes on it: [exr @ 0xb8b8dc0] Wrong or missing size information. I expanded ffmpeg's messages a bit: [EXR @ 0xba3f260] Found dataWindow: xmin = 0, ymin = 0, xmax = 399, ymax = 299 [EXR @ 0xba3f260] Found displayWindow: w = 370, h = 280 [exr @ 0xba2fdc0] Wrong or missing size information: w = 370, h = 280, xmin = 0, xmax = 399, ymin = 0, ymax = 299, xdelta = 400 Without digging deeper into ffmpeg's EXR code, I'm not sure it handles those windows properly, according to the quoted link. Moritz ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
