Age | Commit message (Collapse) | Author |
|
`IMB_moviecache` is implemented as a singleton. When destructing the
singleton via `IMB_moviecache_destruct` it will not be created anymore
resulting inusage of unallocated memory and potentional memory
corruption.
When running blender this doesn't happen, but when creating images in
test cases the moviecache should be able to be recreated after it is
destroyed.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13287
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
When scaling down image, users expect to see background, which doesn't
currently happen in VSE. This is because strips use cross blend mode by
default, because alpha over is much slower. Reason is, because any area
of image can be transparent, and therefore it can't have early out
implemented in a way that cross blend mode can.
Flag images rendered by codecs that don't support transparency as fully
opaque and implement a form of early out for alpha over blend mode.
When rendering image stack, 2-input effects are ignored on the
"way down". Alpha over needs rendered overlay image to decide whether it
will use only overlay or background too. Therefore overlay can be
rendered safely before it is used. Image flags can be checked and it can
be freed if needed. Freeing doesn't cause any performance degradation,
because image is always stored in cache.
This feature does not improve blend mode performance. In summary, it
only allowes for having alpha over blend mode on background images
without suffering from lower performance.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D12914
|
|
|
|
Issue was caused by incorrect FFmpeg asynchronous decoding API. In most
cases, decoder returns 1 frame each time it is fed by 1 packet. Here
decoder wanted to return more frames, but our code always expected only
one.
Before sending new packets to decoder, check if there are frames to
receive. If there are, process them, otherwise continue decoding as
usual.
Reviewed By: zeddb, sergey
Differential Revision: https://developer.blender.org/D13079
|
|
Fix own mistake in rB7061d1e39fe
In my attempt to quickly address T92838, along with the original bug, I
made a nonsensical choice to use the limiter lock to guard the check
against the cache item itself. While harmless, it is not necessary and
semantically wrong / potentially confusing to future readers of the code.
Differential Revision: https://developer.blender.org/D13122
|
|
|
|
These null checks were missing in rB0c3b215e7d5456878b155d13440864f49ad1f230.
Differential Revision: https://developer.blender.org/D13157
|
|
A recent change exposed this long-standing race. Simply protect the
MEM_CacheLimiter with its lock now. Additionally, guard against
unmanaging an already destroyed cache handle.
Ref T92740, T92838
|
|
Some compositor tests (e.g. `compositor_color_test`) broke
because of rB0c3b215e7d5456878b155d13440864f49ad1f230.
The issue was a heap-use-after-free bug caused by a missing
call to `MEM_CacheLimiter_unmanage`.
|
|
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
|
|
Caused by using 3D math on 2D vectors, violating memory boundaries.
Use temporary float[3] variable.
|
|
|
|
Commit e1665c3d3190 added math to do 2D affine transformations with 3x3
matrices, but these matrices are also used for 3D transformations.
Remove added functions and use 4x4 matrices for 2D transformation.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12510
|
|
|
|
|
|
|
|
It was using dummy image buffers to indicate if an animation container
could be initialized or not.
Use booleans instead.
|
|
|
|
|
|
|
|
|
|
|
|
Previously this was only loading built-in render passes. Now instead of trying
to load the scene render passes, load whatever passes exist in the cache file.
|
|
|
|
On the blender side this commit fixes importing video files with audio
and video streams that do not share the same start time and duration.
Differential Revision: https://developer.blender.org/D12353
|
|
Oversight in a0912ff5663b950222ef00485a3853bfb6001db4
|
|
Avoids duplicating the image buffer when saving thumbnails.
|
|
Also remove IB_metadata flag from the resulting imbuf as this image
has no meta-data.
|
|
Increase effective resolution of blend preview images from 128x128 to
256x256 for versions saved in the file system thumbnail cache.
See D10491 for details and examples.
Differential Revision: https://developer.blender.org/D10491
Reviewed by Campbell Barton
|
|
Follow up to fix for T89868.
|
|
|
|
We now use a for_each function with callback to iterate through all sequences in the scene.
This has the benefit that we now only loop over the sequences in the scene once.
Before we would loop over them twice and allocate memory to store temporary data.
The allocation of temporary data lead to unintentional memory leaks if the code used returns to exit out of the iteration loop.
The new for_each callback method doesn't allocate any temporary data and only iterates though all sequences once.
Reviewed By: Richard Antalik, Bastien Montagne
Differential Revision: http://developer.blender.org/D12278
|
|
|
|
Previously when loading an thumbnails for an asset the whole file was
read. Reason this was done was perhaps a future idea to load
all thumbnails inside a blendfile in a single go. This was never implemented
and currently unneeded disk and cpu cycles was spend with finding out what
preview to load.
This patch adds an early break when the thumbnail that the caller is
interested in has been found. This improves the thumbnail extraction
when looking into large files.
Reviewed By: mont29
Maniphest Tasks: T90908
Differential Revision: https://developer.blender.org/D12312
|
|
|
|
Bug caused by integer overflow in ffmpeg_generic_seek_workaround().
Function max_ii() was used to limit int_64tvalue.
After fixing the issue there was another issue, where near-infinite loop
was caused by requested_pos being very large and stream being cut in a
way, that it was missing keyframe at beginning.
This was fixed by checking if we are reading beyond file content.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D11888
|
|
The duration and start time for audio strips were not correctly read in
audaspace.
Some video files have a "lead in" section of audio that plays before the
video starts playing back. Before this patch, we would play this lead in
audio at the same time as the video started and thus the audio would not
be in sync anymore.
Now the lead in audio is cut off and the duration should be correctly
calculated with this in mind.
If the audio starts after the video, the audio strip is shifted to
account for this, but it will also lead to cut off audio which might not
be wanted. However we don't have a simple way to solve this at this
point.
Differential Revision: http://developer.blender.org/D11917
|
|
The seek pts was not correctly calculated.
In addition to that we were not seeking in the video pts time base.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11921
|
|
The video duration was not read correctly from the video file.
It would use the global duration of the file which does in some cases
not line up with the actual duration of the video stream.
Now we take the video stream duration and start time into account when
calculating the strip duration.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use C comments for plain text.
|
|
Scaling down images could create images with a width or height of zero.
Clamp at 1 to prevent a crash, also add an assert to scaling functions.
Ref D11956
|
|
Also resolve a crash when when displaying thumbnails, see T89868.
|
|
|