| Age | Commit message (Collapse) | Author |
|---|
|
This was a regression in svn rev52718 caused by the fact that we can not
free packet fun until we've finished all manipulation with decoded frame
since frame and packet could share same pointers.
For now restored old behavior of next_packet which seems to be well
tested and better not do bigger refactoring here so close to release.
Memory leak fixed by that revision was fixed by calling av_free_packet
just before avcodec_decode_video2 in cases we're at the end of file.
Tested with valgrind and could not see any memory leaks in ffmpeg
area.
|
|
|
|
This fixes a memory leak caused by the last packet on stream EOF not freed.
(Memory leak occurs on ffmpeg heap managed by av_malloc / av_free, so it is
invisible to Blender)
Also: clean up the code a little bit (anim->next_packet was never really used,
so could be moved into a local variable)
|
|
|
|
the type of an argument (uintptr_t??)
The struct member is an unsigned int, not a pointer, so it is mysterious why the orignal code cast it to an uintptr_t.
I changed the code to cast it to an unsigned long so that it matches the format.
|
|
|
|
Avoid using IMB_flipy from image save callback. It will use a bit more
memory but wold be thread-safe.
|
|
|
|
Also fixed crash using --debug-ffmpeg caused by BLI_vsnprintf modifies
va_list -- need to create copy of list if this list is gonna to be reused.
|
|
platforms.
|
|
|
|
|
|
In this case we can not validate OCIO configuration and the only way
to fix such issues is to add NULL-pointer checks..
|
|
add a check for duplicates in BlenderLib()m, if 0'd now.
|
|
unused arg to move_to_layer_invoke()
|
|
The new node that outputs multilayer was using longer names than default.
Caused old code that truncated pass names to 11 chars to fail on loading exr.
This was an old limit in openexr - but that got fixed long ago.
On todo: check current openexr name lenghts, and all code in Blender that
defines pass/layer names.
|
|
There was incorrect formula applied on color components, used the same
as gimp uses. It makes image looking nicer in blender, however it's
still not 100% correct. Seems lots of software are handling profiles
from jpeg file nicely. But that's another topic.
|
|
also initialize bmesh-bevel settings struct to zero to avoid possible uninitialized memory later.
|
|
from blenlib
|
|
|
|
without audaspace.
|
|
|
|
|
|
free_main().
|
|
|
|
|
|
Use IMB_testiffname to check whether file could be handled by ImBuf or
whether it should be handled by anim routines.
It solves the issue when file without extension is used for movie clip.
|
|
|
|
files since its done throughout the code in some places.
|
|
listing.
also remove logImageLib.c - empty file.
|
|
|
|
|
|
|
|
|
|
|
|
not do correct partial updates, now it remembers if the opengl texture is a
non-color data texture or not and takes that into account for the update.
Also includes some renaming ncd => is_data for consistency with color space
terminology used elsewhere.
|
|
|
|
when saving, rather we flip the compressed texture during load. The code used
here comes from the chromium O3D project:
http://src.chromium.org/chrome/trunk/o3d/core/cross/bitmap_dds.cc
Also made it only load compressed for power-of-two resolution images, it doesn't
seem to work for other resolutions, just falls back to non-compressed then.
|
|
after adding compressed DDS texture loading.
DDS images can be flipped compared to the Blender standard, however we do not
unflip them because we also don't flip compressed textures. If we would flip
those we'd need to uncompress, flip and recompress them, and so losing the
speed benefit that you get from using them. Users are expected to save DDS
image in OpenGL compatible format.
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
when tree is being executed. This could lead to nor initialized color space
for the image.
Solved by insuring image buffer is loaded before checking for whether color
conversion is needed.
|
|
than normal
There was a missing byte buffer linearization for shader nodes.
Also fixed incorrect image input color space refresh when image is packed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Patch by Julien Enche, thanks!
From the patch comment:
It allows Blender to load:
- 1, 8, 10, 12 and 16 bits files. For 10 and 12 bits files, packed or
filled type A/B are supported.
- RGB, Log, Luma and YCbCr colorspaces.
- Big and little endian storage.
- Multi-elements (planar) storage.
It allows Blender to save :
- 8, 10, 12 and 16 bits file. For 10 and 12 bits files, the most used
type A padding is used.
- RGB and Log colorspaces (Cineon can only be saved in Log colorspace).
For Log colorspace, the common default values are used for gamma,
reference black and reference white (respectively 1.7, 95 and 685 for
10 bits files).
- Saved DPX/Cineon files now match the viewer.
Some files won't load (mostly because I haven't seen any of them):
- Compressed files
- 32 and 64 bits files
- Image orientation information are not taken in account. Here too,
I haven't seen any file that was not top-bottom/left-right oriented.
|
|
also left bmesh decimator on in previous commit.
|
