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
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
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
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
This reverts commit rB3a48147b8ab92, and fixes the issues with linking
etc.
Change compared to previous buggy commit (rBf8d219dfd4c31) is that
new `BlendFileReadReports` reports are now passed to the lowest level
function generating the `FileData` (`filedata_new()`), which ensures
(and asserts) that all code using it does have a valid non-NULL pointer
to a `BlendFileReadReport` data.
Sorry for the noise, it's always when you think a change is trivial and
do not test it well enough that you end up doing those kind of
mistakes...
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
If the last decoded frame had the same timestamp as the GOP current
packet, then we would skip over this frame when fast forwarding and we
would seek until the end of the file.
This would could only be triggered reliably in single threaded mode.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11601
On the Windows platform there will be some errors printed to the
console if the user's thumbnail cache folder doesn't already exist.
While creating those folders there is an attempt to do so multiple
times and so we get errors when trying to create when exists. This
is caused by paths that have hard-coded forward slashes, which causes
our path processing routines to not work correctly. This patch defines
those paths using platform-varying separator characters.
Differential Revision: https://developer.blender.org/D11505
Reviewed by Brecht Van Lommel
Scanline processor did its own heurestic what didn't scale well when
having a multiple cores. In stead of using our own code this patch will
leave it to TBB to determine how to split the scanlines over the
available threads.
Performance of the IMB_transform before this change was 0.002123s, with
this change 0.001601s. This change increases performance in other areas
as well including color management conversions.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D11578
ffmpeg_generic_seek_workaround did work properly and our start pts
calculation was wrong.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11562
