Sivu saatavilla vain englanninkielisenä.
Peter Schlaile (schlaile)
Total Commits : 382
Trunk Commits : 376
Branch Commits : 6
First Commit : February 5, 2006
Latest Commit : April 14, 2013
Commits by Date
|Date||Number of Commits|
Favourite Trunk Files
Trunk File Changes
April 14, 2013, 13:44 (GMT)
== FFMPEG / Canon DSLR footage workaround ==
The latest ffmpeg versions include a workaround to deal with a certain
pecularity in Canon DSLR footage: instead of decoding pictures with the
proper resolution of 1920x1080 they decode it with 1920x1088 and add a
black bar at the bottom.
Needless to say, that this screws up things in a lot of areas within blender
(proxy indices, mask animations etc.)
Since all blender versions besides Linux x86 32bit seem still to include
older ffmpeg versions which still contain this bug, this patch adds
a workaround for older versions until we have all versions on all platforms
up to date.
See also: http://git.libav.org/?p=libav.git;a=commit;h=30f515091c323da59c0f1b533703dedca2f4b95d
February 27, 2013, 00:04 (GMT)
== Sequencer ==
This fixes the placement code of new files added to the sequencer timeline.
The old code tried to guess the strip position from the current mouse
Annoying effect: if you add a new strip using the menu, especially if the
file editor pops up, the strip ends up in nowheres land (most likely around
track 40, frame -200).
New behaviour: strips are always placed at cfra, which is the
sequencer equivalent to the 3D cursor (and that's where new objects in
3D editing end up).
Bonus feature: we try our best to guess the right track by finding the
nearest strip by type.
The patch was inspired by
] VSE: Add Strip on Current Frame
Thanks to venomgfx for the idea!
February 17, 2013, 22:13 (GMT)
== Sequencer ==
Made my last fix a little bit faster and more elegant by not playing around
with seq->tmp (only reseting it to NULL, like the old code).
February 17, 2013, 21:44 (GMT)
== Sequencer ==
This fixes a bug in sequencer cut tool:
* if you cut two strips of the same name class (MVI_XXXX.MOV and MVI_XXXX.001)
the two new generated strips will end up with the same name.
(easy test case: add a MOV file with it's accompanying audio track to the
timeline and then cut both strips at once into two pieces)
* visible problem: your animation data will get messed up on the way, since
the animation system doesn't know, which strip it should assign the
Problem was caused by generating a new list of sequences within the
Since dupli_seq() can't see the members of the new list of sequences, it
won't be able to assign unique names in all cases.
February 10, 2013, 21:01 (GMT)
] [video sequence editor] Offset and crop of strips are wrong
Applied patch by jehan after confirming the issue.
Thanks for the patch!
December 2, 2012, 15:15 (GMT)
== FFMPEG ==
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)
September 7, 2012, 21:41 (GMT)
== FFMPEG ==
This fixes [#32399
] VSE doesn't show last 3 frames of Quicktime movie.
Some decoders store frames internally until EOF.
So one has to feed the decoding engine with empty packets after EOF
until all frames could be extracted properly.
August 12, 2012, 15:59 (GMT)
== Inpaint Node ==
Fixed several small (stupid) issues with the inpaint node:
* on pixel order building, some ranges got wrong and origin was considered
* the convolution kernel didn't consider all pixels (+1,0),(-1,0),(0,1) and (0-1)
were omited, leading to suboptimal results (sometimes even black areas)
* alpha channel is now only affected an areas considered by inpaint.
That's only important, if you choose low iteration counts.
July 29, 2012, 15:48 (GMT)
== compositor ==
This adds an inpaint node to blender.
In case, you don't know, inpainting does this:http://en.wikipedia.org/wiki/Inpainting
It's use cases in blender are
* wire removal
* green screen background reconstruction
The node isn't tile based (for fundamental reasons), but very fast,
since it first builds a manhatten distance map and after that performs
color convolution only on the edges.
That's something, one should probably add also to the dilate node (in
step mode) to make it perform a lot better for dilate iterations greater
It will bring it's computing time from O(n^3) down to O(n^2).
Take a look here for the details: http://ostermiller.org/dilate_and_erode.html
May 27, 2012, 20:57 (GMT)
MiikaHweb - Blender SVN Statistics v1.34