Well, putting aside it just doesn't feel right to begin with to let such important information unspecified, as I was saying it's all a precarious matter of resolutions.
Just try to render some teeny-weeny video, and you'll see it's the bt.709 color matrix now to be screwing it.
What are the downsides of the flags I posted? They do seem to work in standalone. Are those h264 exclusive also? On the other hand it seems h264 is de-facto standard for light on hardware/size video.
After effects, just like "top notch" video players, has this heuristics that choose the color space based on the HD resolution and thinks it's rec.709 even though ffmpeg targets 601 for everything by default.
Other rendering software may actually properly flag the video stream, or even if they don't they may dynamically convert the color space based on the output dimensions (especially if they target professional scenarios that may closely tie with TV work)
This is also what out_color_matrix does, "matching the conventions" expected for unflagged videos.
But since the video is still untagged (and ffmpeg also doesn't have this questionable inputs guess game from the last century) when imported it will be assumed to be rec.601, in turn shifting colors again.
(standalone ffmpeg of course produces the same results of blender that uses it)
p.s. take note browsers are quite the can of worms, and you better use some legit video player to discuss this issue
Browsers are cans of worms by their nature. Mentioned those just for context.
Sat, Jan 15
Fri, Jan 14
Wed, Jan 12
Mon, Jan 10
Sat, Jan 8
Fri, Jan 7
Thu, Jan 6
Wed, Jan 5
T86952: Heap Buffer Overflow when viewing dds thumbnails in the file browser. I would think is also related, as it involves a Heap Buffer overflow in the dds flipping function.
I had trouble finding this so I added it to the Images & Movies project, and created a Known Issue column there.
Tue, Jan 4
In addition, some dimensions such as x=844193 and y=6364 are such that bottomf wraps around and then passes topf, resulting in bottomf > topf which may look safe. During the loop, however, bottomf will eventually be decremented to fall below topf and once again trigger the fault.
The proposed fix is useful, but insufficient.
T94629 has been filed. I am indeed fuzzing the blender codebase, as a hobby exercise. I don't think any particular support is needed - my output is bug reports and possibly patches.
@Albin Eldstål-Ahrens (eldstal) Yes, file a separate issue for that and yes I can confirm the issue too and your analysis. It looks like you're doing a fuzzing exercise here. I can't speak for the project as a whole but I'm not sure what kind of support we can provide for such an endeavor. It might be best to run this by some folks over on https://blender.chat/channel/blender-coders first to see what can be done here.
It's an integer overflow in IMB_flipy at rotate.c:71.
I haven't had time to figure out the exact cause yet, but the following HDR image still manages to cause an out-of-bounds read (in IMB_flipy()) even with the above patch applied: