Official blender builds from blender.org support MP3. (checked with 2.75).
If you don't use official builds, codec support depends on the version
of ffmpeg in use.
On Thu, Jul 2, 2015 at 3:49 PM, Jeffrey wrote:
> Some of the issues with these media formats is the licensing on the
> format itself
Some of the issues with these media formats is the licensing on the
format itself. For example, you want MP3 support, but using MP3 requires
licensing from a company to use it. Blender is strictly in the GPL
branch of open source licenses (see more here:
https://www.blender.org/about/license/)
I use blender for video editing because for a free software it can do a
lot. The only problem I have run across is it's supports for video codecs
and audio codecs. The biggest being it does not support MP3. If blender
were to allow for more common codecs, I believe it could be taken seriously
as a
Woops, we forgot to update the branch to RELEASE stage. One liner fix, but
needs re-compilation.
New branch revision is c6b042be9ef3e0a46a52dde2c06cc570bfbe66cc.
On Wed, Jul 1, 2015 at 12:19 PM, Sergey Sharybin
wrote:
> Hey everyone,
>
> We'are finally ready for the final 2.75 release!
>
> Info
it's not so crucial to have atm, but nice to solve it still.
We can reformulate out usage of atomic_cas and make it return non-zero if
value changed, which would simply mean we need to update non-OSX versions?
Other thing is that update_maximum() from guardedalloc is not really atomic
as well, th
Ah yes indeed, thanks!
Also, now in the 'cas' case on OSX, we have this code:
uint64_t init_val = *v;
OSAtomicCompareAndSwap64((int64_t)old, (int64_t)_new, (int64_t *)v);
return init_val;
(because OSX has no primitive returning original value of 'v').
As far as I can see, this op
Hey everyone,
We'are finally ready for the final 2.75 release!
Information for platform maintainers:
- Branch: blender-v2.75-release
- Branch hash: cb1777d3b6b37670c3522791d7b36c58029cf58d
- Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc
- Addons hash: 45b1e42fffd550b4250f953a1933892c913b
"InterlockedExchangeAdd(p, x) + x" works exactly the same as "
__sync_add_and_fetch(p, x)", no need to use asm.
On Wed, Jul 1, 2015 at 9:53 AM, Bastien Montagne wrote:
> So, trying to hunt an strange issue with Windows scons builds of
> filebrowser work, I found that our attomic operations (defin
So, trying to hunt an strange issue with Windows scons builds of
filebrowser work, I found that our attomic operations (defined in
intern/atomic/atomci_ops.h) do not return the same things on MSVC than
with other OS/compilers.
With GCC & co we use `__sync_add_and_fetch`, on OSX, `OSAtomicAdd64`
