`IMB_remakemipmap` may 'shrink' the mipmap list without actually freeing
anything, so we need to check all possible levels in `imb_freemipmapImBuf`
to avoid memory leaks, not only those currently used.
Seems to be rounding error. Hopefully new code handles the error fixed back in
SVN revision 28901 and still have proper frame number for Hjalti.
What could possibly go wrong here..
Some of these check that dimensions match before running code that
assumes they do match.
For imb_stereo3d_write_anaglyph I *assume* this change reflects the
intended behavior. Before it was always grabbing alpha from buffer 0.
Found with PVS-Studio T48917
This reverts commit f12204196f.
Campbell, sorry. have to revert this for the time being.
We've missed some very important bits, such as:
- FFmpeg is usually linked against OpenJPEG
- OIIO needs OpenJPEG as well.
For FFmpeg issues we can either disable OpenJPEG there (since
we don't really use it), or bump FFmpeg to version 3.1.1 which
can use either of OpenJPEG 1.5 or 2.1.
For OIIO we do need OpenJPEG support (otherwise Cycles will
not be able to use j2k/j2c textures) and currently there is
NO solution to make OIIO working with OpenJPEG 2.1.
According to Matthias Fauconneau (aka mfv) Larry is working
on the patch to get OIIO work with OpenJPEG 2.1, but it'll
take some time still.
I've tried to look into support of some sort of build system
flag and do ifdefs, but it all becomes quite nasty, especially
with bundled OpenJPEG bumped to 2.1.
Surely such an update is something we'll have to apply to
but at this exact moment it causes quite some pain for all
developers.
Suggest to wait for until OIIO supports OpenJPEG 2.1 and then
go with the updates for real.
Just avoid some unneeded initialization functions when the threaded
processor is simple enough to only depend on current chunk start
scanline and number of scanlines.
White the config itself could be loaded this way, lookup tables can not. Additionally,
that's not really clear how to solve the issue with search path which is multi-byte
only in the API.
Reverting for further investigation.
This reverts commit ab4307aa08.
Something weird, seems some buffers _might_ be shared between codec context
and frame, which is quite weird. Could be a bug in FFmpeg or could be wrong
API usage somewhere else..
In fact, some areas in FFmpeg might require alignment up to 32, so now we
make temporary conversion in an aligned frame. We only do this if width is
not aligned to 32.
This is a bit annoying, but FFmpeg can't deal with unaligned arrays in some
cases. There seems to be an easy workaround with using SWS_ACCURATE_RND flag
which should be harmless since we don't really scaling frames, but only
using sws_scale to change color space.
Additionally, this is what VLC is also using.
This is an alternative to passing a copy callback which is some times inconvenient.
Instead the caller can write to the key - needed when the key is duplicated memory.
Allows for minor optimization in ghash/gset use.
Also add BLI_gset_ensure_p_ex
The idea now is to have FFmpeg/OIIO headers listed after
the system ones. This is because FFmpeg/OIIO might define
some constants with the same name as the ones from math.h.
FFmpeg/OIIO has ifdef around defines, but math.h doesn't
check whether constants were already defined or not, which
causes some noisy warnings.
While it's not something we'll be using for the official release,
it's nice to support new libraries at least on "it compiles" level,
so it's not that many frustrated developers around.
Nexyon, please have a look into Audaspace changes :)
CLAMP was conflicting between Common.h and BLI_utildefines.h
Ideally we would use macro from BLI, but it's a bit involved change
to make it working with C++, will keep it for later.
D1751, remove this library since its quite a specific - only supports an older version of this codec.
Also ffmpeg has added support for recent versions of the codec.
The idea is to use known number of frames in the stream when possible
instead of trying to deduct it from a stream duration and time base,
which could potentially give some rounding errors.
This, i.e., solves quicktime encoded files from animators to open
just fine in sequencer.
Another report done by the main Nieve guy (aka venomgfx)
Title actually tells it all, it is rather simple function which totally makes
sense to be inlined.
This gives up to 5% of speedup when updating scopes for a large image.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1310
This patch aims at providing multiple compression modes for TIFF output,
particularly uncompressed mode.
At this moment have None, Deflate, LZW and Pack Bits modes been integrated,
mimicking The GIMP export modes (except JPEG mode, which returned encoding
errors).
More modes could be added if needed.
Default remains Deflate.
Reviewers: campbellbarton, mont29, sergey
Differential Revision: https://developer.blender.org/D1709
Screenshot ignored errors, some render code printed 'Saved' without checking for failure.
note: errno is now cleared from IMB_saveiff so all callers don't need to.
