Re: [Bf-committers] Adding 360 Video Tools to VSE
Hi all, I've written a first version of a design document on the wiki: https://wiki.blender.org/index.php/User:LSutic/Blender_360_Effects The development process tells me to "Do the actual coding :)" now, but I kind of suspect I should wait for feedback on the design doc first... /LS ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Adding 360 Video Tools to VSE
Hi all, I have been experimenting with 360 video and Blender, and have developed two effect strips for the VSE that I think could be useful. I would like to take this to the next step in the development process, which is to write a wiki page with the project proposal. I'd like to have a wiki account. The code as it is right now (but of course this is something that I expect to change): https://bitbucket.org/leo_sutic/blender/branch/blender-360-video A blog post I made about the tools, showing examples: https://monochrome.sutic.nu/2018/02/14/360-video-with-blender.html /LS ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fwd: Copyright violation distributing faac binaries together with GPL software
Ton, libavcodec *is* FFmpeg. (Or part of it, anyway.) The problem that is claimed is that libfaac is included in Blender's version of libavcodec that is distributed with Blender 2.49. The solution is to compile FFmpeg / libavcodec without libfaac. (Throwing out x264 is not an option, as libfaac has more problems than just being GPL-incompatible) It should be a build config change and that's it - but someone has to build a new distribution. Then we should be OK. SVN is down fot the moment, so I haven't been able to look at the 2.49 source to figure out where the change needs to be made. We lose the ability to encode sound using AAC, but nothing more. Could you run this past Carl Hoyos and see if I got this thing right? See here for some others who have run into the same issue: https://bugs.launchpad.net/ubuntu/+source/faac/+bug/374900 http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-October/006221.html Also look here for a libfaac license change (?): http://faac.cvs.sourceforge.net/viewvc/faac/faac/libfaac/tns.c?r1=1.8r2=1.9 Here's the libfaac license, for reference: BEGIN LIBFAAC LICENCE __ COPYRIGHTS FAAC is based on the ISO MPEG-4 reference code. For this base code the following license applies: ** This software module was originally developed by FirstName LastName (CompanyName) and edited by FirstName LastName (CompanyName) FirstName LastName (CompanyName) in the course of development of the MPEG-2 NBC/MPEG-4 Audio standard ISO/IEC 13818-7, 14496-1,2 and 3. This software module is an implementation of a part of one or more MPEG-2 NBC/MPEG-4 Audio tools as specified by the MPEG-2 NBC/MPEG-4 Audio standard. ISO/IEC gives users of the MPEG-2 NBC/MPEG-4 Audio standards free license to this software module or modifications thereof for use in hardware or software products claiming conformance to the MPEG-2 NBC/ MPEG-4 Audio standards. Those intending to use this software module in hardware or software products are advised that this use may infringe existing patents. The original developer of this software module and his/her company, the subsequent editors and their companies, and ISO/IEC have no liability for use of this software module or modifications thereof in an implementation. Copyright is not released for non MPEG-2 NBC/MPEG-4 Audio conforming products. The original developer retains full right to use the code for his/her own purpose, assign or donate the code to a third party and to inhibit third party from using the code for non MPEG-2 NBC/MPEG-4 Audio conforming products. This copyright notice must be included in all copies or derivative works. Copyright (c) 1997. ** For the changes made for the FAAC project the GNU Library General Public License (LGPL), version 2 1991 applies. For the changes the following statement applies: ** FAAC - Freeware Advanced Audio Coder Copyright (C) 2001 M. Bakker This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ** Please note that the use of this software may require the payment of patent royalties. You need to consider this issue before you start building derivative works. We are not warranting or indemnifying you in any way for patent royalities! YOU ARE SOLELY RESPONSIBLE FOR YOUR OWN ACTIONS! END LIBFAAC LICENCE -- /LS On 2011-01-06 17:41, Ton Roosendaal wrote: Hi devs, Please advise. I recall libavcodec is quite old already, and probably obsolete mostly because of FFmpg? -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands Begin forwarded message: From: Carl Eugen Hoyos Date: 6 January, 2011 17:15:37 GMT+01:00 To: foundat...@blender.org Subject: Copyright violation distributing faac binaries together with GPL software Hi! I am an FFmpeg developer and I just found out that Blender binaries are distributed
Re: [Bf-committers] Fwd: Copyright violation distributing faac binaries together with GPL software
Carl and everyone else, I've done some checking of the FFmpeg integration in Blender 2.49b. I came up with the following: I can confirm that the default configuration for compiling FFmpeg into Blender has --enable-gpl set and no --enable-nonfree. So it *ought* to be all right. It is linked against libfaad, but I find no trace of libfaac in the dll. For example, the string faac: codec init failed is in the dll, but that's from libfaad (libfaad.c), which does not link to libfaac, as far as I know. In libfaac.c, the FFmpeg interface to libfaac, are the strings wrong libfaac version and libfaac AAC (Advanced Audio Codec), neither of which can be found in avcodec-52.dll. Unless these strings are stored somewhere else, shouldn't they be present if libfaac.o is linked in? I am really unfamiliar with the FFmpeg codebase, so I don't know what the significance of the above is. Carl, could you give me some guidance as to what to look for to confirm the existence / absence of libfaac code in the dll? Basically, what did you see? /LS On 2011-01-06 17:41, Ton Roosendaal wrote: Hi devs, Please advise. I recall libavcodec is quite old already, and probably obsolete mostly because of FFmpg? -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands Begin forwarded message: From: Carl Eugen Hoyos Date: 6 January, 2011 17:15:37 GMT+01:00 To: foundat...@blender.org Subject: Copyright violation distributing faac binaries together with GPL software Hi! I am an FFmpeg developer and I just found out that Blender binaries are distributed containing GPL'd versions of libavcodec linked against non-free software (this is a copyright violation). I don't know where to report this (should I open a bug report?), so I write to the only email adress I easily found on the web-site. I downloaded blender-2.49b-windows, it contains libavcodec.dll, a binary distribution of libavcodec. The dll contains code from x264, making it GPL (and not LGPL). It also contains code from the libfaac project. Originally, libfaac claimed to be free software (under the LGPL), but unfortunately, this was never true: libfaac is (and always has been) proprietary software. Since you cannot fulfill the requirements of the GPL for libfaac, you cannot distribute a GPL'd version of libavcodec with libfaac support enabled. Please remove it from your download page / update your libavcodec version. Thank you, Carl Eugen Hoyos ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fwd: Copyright violation distributing faac binaries together with GPL software
No probs, dude. Regarding the 2.56 version - right now we have a libavcodec dll binary checked into SVN - there is no source code in the blender tree: https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows/ffmpeg/lib/ (We have ffmpeg binaries for other platforms checked in as well) I think it would be trivial to get a source package checked in there as well. The corresponding source tarball is here: http://ffmpeg.arrozcru.org/autobuilds/ffmpeg/sources/ffmpeg-r22941-swscale-r31050.tar.bz2 I don't have commit access, so I'm leaving this to someone who does now. Anyone? /LS On Fri, Jan 7, 2011 at 2:38 AM, Carl Eugen Hoyos c...@hoyos.ws wrote: Hi! Sorry for the noise! Your analysis is absolutely correct, given that I am the one hunting real FFmpeg license violators, I should really know better! libavcodec.dll shipped with Blender 2.49b was NOT linked against libfaac, there is absolutely nothing wrong with the dll (license-wise, since it is quite old, I fear there are a few known bugs in it)! Note that there may be another problem, http://download.blender.org/release//Blender2.56abeta/blender-2.56a-beta-windows32.zip contains libavcodec, but the source package http://download.blender.org/source/blender-2.56-beta.tar.gz may be missing FFmpeg sources (probably because you removed FFmpeg from your source tree, iiuc), Am I right or am I again missing something? Thank you for reacting so quickly (I wish the real license violators would be so fast!), and please excuse me again for making wrong assumptions! Carl Eugen PS: The reason I went to your forum today (and believed I saw the wrong information there that Blender uses libfaac) is this bug report that claims a problem using libavcodec: http://roundup.ffmpeg.org/issue2485 If anybody knows which posts in the blender's bugtracker user chaos means, I can try to help (although I am very bad in using libavcodec outside of FFmpeg/MPlayer). I didn't find anything remotely similar, but perhaps you know what he is talking about. On Fri, 7 Jan 2011, Leo Sutic wrote: Carl and everyone else, I've done some checking of the FFmpeg integration in Blender 2.49b. I came up with the following: I can confirm that the default configuration for compiling FFmpeg into Blender has --enable-gpl set and no --enable-nonfree. So it *ought* to be all right. It is linked against libfaad, but I find no trace of libfaac in the dll. For example, the string faac: codec init failed is in the dll, but that's from libfaad (libfaad.c), which does not link to libfaac, as far as I know. In libfaac.c, the FFmpeg interface to libfaac, are the strings wrong libfaac version and libfaac AAC (Advanced Audio Codec), neither of which can be found in avcodec-52.dll. Unless these strings are stored somewhere else, shouldn't they be present if libfaac.o is linked in? I am really unfamiliar with the FFmpeg codebase, so I don't know what the significance of the above is. Carl, could you give me some guidance as to what to look for to confirm the existence / absence of libfaac code in the dll? Basically, what did you see? /LS On 2011-01-06 17:41, Ton Roosendaal wrote: Hi devs, Please advise. I recall libavcodec is quite old already, and probably obsolete mostly because of FFmpg? -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands Begin forwarded message: From: Carl Eugen Hoyos Date: 6 January, 2011 17:15:37 GMT+01:00 To: foundat...@blender.org Subject: Copyright violation distributing faac binaries together with GPL software Hi! I am an FFmpeg developer and I just found out that Blender binaries are distributed containing GPL'd versions of libavcodec linked against non-free software (this is a copyright violation). I don't know where to report this (should I open a bug report?), so I write to the only email adress I easily found on the web-site. I downloaded blender-2.49b-windows, it contains libavcodec.dll, a binary distribution of libavcodec. The dll contains code from x264, making it GPL (and not LGPL). It also contains code from the libfaac project. Originally, libfaac claimed to be free software (under the LGPL), but unfortunately, this was never true: libfaac is (and always has been) proprietary software. Since you cannot fulfill the requirements of the GPL for libfaac, you cannot distribute a GPL'd version of libavcodec with libfaac support enabled. Please remove it from your download page / update your libavcodec version. Thank you, Carl Eugen Hoyos ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org
Re: [Bf-committers] Have you seen this?? How to improve Blender
Now that is slick. /LS On 2010-11-26 11:13, Steren wrote: I saw a link posted by Andrew showing a first online prorotype of the home page : http://69.164.205.151/blender/ On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani prashant.soh...@gmail.comwrote: Well.. I am reviving this old thread.. The points raised in the presentation were very valid; I think it's high time we act on some of them. Has anybody a ready new home page for blender.org? If not, I volunteer to redesign the homepage of Blender and any other parts that may be wanting a complete overhaul. I have reasonably good skills in web development. (I am just done with an exceptionally heavy semester, and have a month's holiday ahead of me.) And of course, anybody else willing to volunteer, is welcome as well :) I'll create my own version on my website, and I'll post the link(s) in a new thread.. people may comment on it etc. In the meanwhile, let's start brainstorming about what we can do about the other points raised in the same presentation. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
Hi Peter,
you raise some very good points, and I'll have to go back to the drawing
board for a moment.
For example: How do you play a movie backwards? Not easy with a
next()-style interface.
It's going to take a little while, though, because the next() style
interface makes some other things like image stabilization and object
tracking much easier.
One question, though:
map_vse_frame_to_cfra() is *really* a non-trivial function!
How? Isn't it just a fcurve.evaluate (frame)? Or is it the speed control
strips that make it non-trivial?
/LS
On 2010-11-26 10:25, Peter Schlaile wrote:
Hi Leo,
Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:
Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.
If I may modify your code a little:
class scene_iterator : public iterator {
public:
Frame next () {
// fcurves go in map_vse_frame_to_cfra
float cfra = map_vse_frame_to_cfra (nextFrame);
setup_render(cfra);
++nextFrame;
return render();
}
int nextFrame;
}
and again, that doesn't work with fcurves and gets really nasty
with stacked speed effects.
map_vse_frame_to_cfra() is *really* a non-trivial function!
VSE only sees a sequence of discrete frames
uhm, why is that exactly the case? In fact, currently it renders
internally with floats.
- which is precisely what its domain model should look like,
because video editing is about time-discrete sequences, not continuous.
again, why? The point behind making cfra continous was, that the *input*
strip can make it's best afford to do inter-frame interpolation or do
in-between rendering.
It depends heavily on the *input* strip, how that is done best.
So: no, I *strongly* disagree with your opinion, that the VSE sees a
sequence of discrete frames. In fact, it doesn't!
The Blender scene is a continuous simulation - having a float cfra
makes sense, because time is continuous there. In the VSE the domain
objects are discrete in time. Having a float cfra makes no sense.
as stated above, I disagree.
Which brings me to the point: what was the sense in dropping the random
access interface again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.
uhm, you always will need a fetch() and a seek() function, so where
exactly does your idea make things simpler?
Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.
uhm, as stated above, next() isn't really defined in your sense.
You can define a version, that does CFRA + 1 if you like. If that is
really helpfull is another question.
In fact, the next cfra for a given track will be defined by the topmost
speed effect fcurve and then calculated down the stack. That won't break
your initial idea of changing the order in which frame calculation takes
place, it only reflects the fact, that next() isn't that easy to calculate
if you do retiming in a creative way.
So: yes, next() won't be easy to calculate in advance for a given track,
but yes: that is a fundamental problem, if we allow stacked retiming with
curves. Even if you do retiming with simple factors, you will run into the
problem, that if the user speeds up a track with say a factor of 100 you
probably don't want to blend *all* input frames into the output frame but
limit the sampling to say 10 inbetween frames. (That's the way Blender
2.49 does it and Blender 2.5 will do it soon using the new SeqRenderData
parameters.)
Cheers,
Peter
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] S-DNA and Changes
Hi all, I've now started to dig into the codebase - and the VSE in particular. The workings seem fairly straightforward, but as far as changing things I must ask your advice. The problem is the S-DNA representation of the VSE data. The structures used in the VSE, and also written to the blend file, are strongly coupled to the current workings of the VSE. Not an unsurmountable obstacle, but something which requires extra care when changing things. So, my question is this: How has this been handled historically? I can't be the first one to run into this. For the sake of argument: Suppose I want to make really big changes to the VSE - should I... 1. Write a VSE 2 and create all-new structures? 2. Create some kind of compatibility loader or data import filter that converts the old data to the new, as far as possible? That is, we read old and new formats, but only write new format. 3. Convert the old structs to the new in-memory? That is, we read and write the old format, maybe with some back-compatible changes, but use a new format internally? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Status of C++
All, thanks for the advice. I have no problem following those recommendations. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Documenting the VSE
Hello, after digging into the VSE, I couldn't help bu notice that the documentation is a bit terse. I was thinking about submitting some patches consisting of doxygen docs for parts of it - mostly concerning its external interface and connection to the pipeline.c code. Is now a good time to do so, or is that module up for serious reworking? Or is it your experience that code comments end up obsolete and wrong really fast in Blender? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
Hi Peter, thank you for your feedback on the SDNA. You bring up some very good points, let me try to address them quickly: On 2010-11-25 19:45, Peter Schlaile wrote: Or, to put it another way: please show a case to me, that *doesn't* work, with a simple background builder job system, I thought about that yesterday, actually, because it seemed such a simple solution. But let's consider the background builder job itself. In principle, there is nothing that can't be factored out as a background builder job. I mean, I can do anything I want in an external program and then just place the end result in Blender. But then I have to build a UI for my stabilization program, and the whole purpose of doing any work on Blender was to put my stabilization algorithms there in order to have a nice UI. By nice I mean to be able to combine video effects in the VSE much like I can combine nodes in the compositor. I want to be able to apply stabilization, interpolation, etc. by stacking effect strips. Combinatorial power, I think it is called. This means that the background builder job ends up being more or less a render in anything but name. It needs access to the same data as a render - output from previous effect strips. That's why I need to involve the main rendering pipeline. I wish I didn't have to. The implications of your track rendering idea is - scary. Either you end up with a non-realtime system (since you have to calculate optical flow information on the fly in some way, which is, to my knowledge, not possible with current hardware) or you have to render everything to disk - always. I, as a user, want to have control over my diskspace (which is very valuable, since my timelines are 3 hours long, and rendering every intermediate result to disk is *impossible*!). Correct, it is impossible. You've asked this once before (way back), I replied in: http://lists.blender.org/pipermail/bf-committers/2010-September/028825.html and you thought: that sounds indeed usefull http://lists.blender.org/pipermail/bf-committers/2010-September/028826.html Short-short summary: The system need not do it the naive way and write out every frame. We can also optimize away a lot frames being held concurrently in memory by using smart algorithms. The current state of the prototype code is that *nothing* is being written to disk, and it never renders more frames than absolutely needed. Eventually I might need to include the option of writing out some things to disk but I consider that a last resort, and only for operations that the user *knows* will cost a lot of disk. This, however, is not a consequence of the strip-wise rendering algorithm itself, but of the processing we want to do. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
On 2010-11-25 21:54, Peter Schlaile wrote: Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) I decided against that due to the complications it resulted in - mostly because it became very difficult to get all frames to align in time when round-off errors may affect the float cfra parameter depending on how it was calculated. (It was also difficult for movie clip sources, again due to rounding errors, where you could end up on the wrong frame.) It was easier to just pretend, in the VSE, that each sequence was continuous, but sampled at a fixed rate. (So the frame rate should really be a field rate.) That way, the only time we risk that the frames don't line up is when we do framerate conversion - and everyone kinda expects them to not line up then. So what I have instead is that each sequence (strip) has an individual rate. That way I could slow down or speed up a sequence by altering the frame rate. An effect strip can then do motion interpolation or timelapse to convert the base sequence to the desired output framerate. So the renderer might have a float frame number, but the VSE only ever sees integer frame numbers. I'm just guessing regarding the float cfra parameter: Is it for motion blur? Then, for example, with output frame rate at 24fps: Strip 1: Movie clip, 60fps. Must be converted to output frame rate. Strip 2: Converts strip 1 to the output frame rate, 24 fps, by combining frames in strip 1. Strip 3: Movie clip 24 fps. Can be used as-is. Strip 4: Gamma cross 13 Strip 5: Blender scene, motion blur, 24fps with simulated shutter at 60fps. As far as the VSE is concerned, the output of this strip is 24fps. Strip 6: Combine 5 and 4 using alpha in 5. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
On 2010-11-25 23:40, Peter Schlaile wrote: Hi Leo, Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) I decided against that due to the complications it resulted in - mostly because it became very difficult to get all frames to align in time when round-off errors may affect the float cfra parameter depending on how it was calculated. (It was also difficult for movie clip sources, again due to rounding errors, where you could end up on the wrong frame.) It was easier to just pretend, in the VSE, that each sequence was continuous, but sampled at a fixed rate. (So the frame rate should really be a field rate.) That way, the only time we risk that the frames don't line up is when we do framerate conversion - and everyone kinda expects them to not line up then. uhm, ouch. OK, do it differently, tell the next()-iterator the absolute next-cfra not the increment, but please make it a float, because... I'm just guessing regarding the float cfra parameter: Is it for motion blur? ... it's not about motion blur, it's about retiming. If CFRA is float, you can retime a scene strip afterwards and have it render subframe precision frames (read: extrem slowdowns), which are done the real way, not using fake interpolation. Ah, ok. I'd still try to stick with integer frames and a parameterless next(). Allowing the client to specify the advance in the next() method makes it too much of a random-access method (there is no guarantee that the advance is to the next frame, which is the whole purpose of the iterator interface). I'd do it this way: Suppose we have a scene where we want normal speed for frames 1-10, an extreme slowdown for 11-12 and normal speed from 13-20. Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE. Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output framerate. This strip covers frames 11-211 in the VSE. Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE. When the sequencer renders this, the next() for strip 1 and 3 will advance one scene-frame. The next() for strip 2 will advance 0.01 frames. That way, the VSE code only ever sees integer frames (although it does see different frame rates), and we can guarantee machine precision in the slowdown frame number calculation. The renderer, however, sees the fractional frames - but this is hidden behind the scene strip's code. (This also enables us to take a scene that was designed for 24p and render it at 60p with everything lining up properly.) Would this take care of the issue? I realize that we suddenly have a VSE cfra and a Scene cfra, but if you're going to have retiming through the VSE, then you already got that. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
On 2010-11-26 00:28, Peter Schlaile wrote:
Hi Leo,
Ah, ok.
I'd still try to stick with integer frames and a parameterless next().
Allowing the client to specify the advance in the next() method makes it
too much of a random-access method (there is no guarantee that the
advance is to the next frame, which is the whole purpose of the
iterator interface).
I'd do it this way:
Suppose we have a scene where we want normal speed for frames 1-10, an
extreme slowdown for 11-12 and normal speed from 13-20.
Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
framerate. This strip covers frames 11-211 in the VSE.
Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.
sorry, that won't work. One can retime using fcurves.
Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:
Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.
If I may modify your code a little:
class scene_iterator : public iterator {
public:
Frame next () {
// fcurves go in map_vse_frame_to_cfra
float cfra = map_vse_frame_to_cfra (nextFrame);
setup_render(cfra);
++nextFrame;
return render();
}
int nextFrame;
}
VSE only sees a sequence of discrete frames - which is precisely what
its domain model should look like, because video editing is about
time-discrete sequences, not continuous. The Blender scene is a
continuous simulation - having a float cfra makes sense, because time is
continuous there. In the VSE the domain objects are discrete in time.
Having a float cfra makes no sense.
Which brings me to the point: what was the sense in dropping the random
access interface again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.
Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.
/LS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 2010-11-26 00:40, Lorenzo Pierfederici wrote: Maya is in a way a very open software: stable APIs for plugins, lots of documentation and examples, good support. You can build amazing stuff around it Seems like you got your solution right there. Why aren't you just going with Maya? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
A lot of the discussion has centered around integrating Blender in a production system based on proprietary software. I'd like to bring up the following two points: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. (...) However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. I really think the problems brought up in this discussion are best solved by being smarter about how the integration is handled. (It is possible to integrate GPL programs in a proprietary system, if not, we'd really have problems.) It's a lot easier than doing a wholesale re-licensing of the code - something which, as far as I can see, completely lacks support among the main contributors; and furthermore would not solve anything, as the interface required in section 0 of the LGPL isn't defined by Blender. Unless the interface is clearly defined (no, header files don't count - they define internal interfaces, not necessarily library interfaces; consider linux - it has many headers, but only some are considered OK to use in proprietary code). /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
I just want to raise a point somewhat related to the GPL: A closed source API must be both stable and a stable ABI, a GPL API need not. In order for closed source plugins to work reasonably well, the parts of Blender they interface with must be stable, both in the sense that the functions work the same, but also in the sense that the data structures being passed across remain binary layout compatible - otherwise the plugin won't link against blender, or won't work. Maintaining a stable programming interface that is binary compatible with previous versions is a serious undertaking and cost; but essential if one is to support closed-source code. If I remember correctly, the Linux kernel only allows GPL drivers partly because maintaining a stable driver ABI is such a huge cost. libc can be LGPL, because it is such a very, very stable specification. My suggestion would be to keep Blender as-is, and let those who want to distribute closed-source plugins write and maintain their own GPL-to-non-GPL shim. (Think about it: since Blender Foundation doesn't own the copyrights to the code, it is in exactly the same situation as everyone else as far as the GPL is concerned - if BF can write such a shim, so can everyone else.) That way: 1. the workload ends up where it should be - let those who want to interface figure out the legal and technical problems 2. the shim can be customized to the needs of the closed source code and updated as needed /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
I've been prototyping and testing strip-wise rendering. In case anyone wants to know what the state of the work is right now: http://monochrome.sutic.nu/2010/11/15/sequence-rendering.html The short version: Just prototyping right now. Image stabilization etc. works great. Working on getting efficient caching. Peter: Unfortunately I won't be at the Blender conference. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Status of C++
I've looked in a lot of places and Googled, but haven't found any answer: What is the status of C++ in Blender? Should I just take a hint from the fact that it is almost all written in C, or is that an artifact of it being 15 years old? I know that it isn't the easiest language out there, but std::vector is kinda nice, and basic single inheritance, too. I have no problem with C, but that syntactic sugar of C++ is sweet in small doses. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Status of C++
I wasn't really asking for an opinion of C++, I was asking what the community had decided, if anything, in regards to use of the language. C++ is already in Blender (GHOST, Audaspace, etc.), so it's not like I have to try to push it in: It's already there. But I need to know just what the deal with it is. /LS On 2010-11-15 21:57, Wolfgang Draxinger wrote: Am Mon, 15 Nov 2010 21:49:20 +0100 schrieb Leo Sutic leo.su...@gmail.com: I know that it isn't the easiest language out there, but std::vector is kinda nice, and basic single inheritance, too. I have no problem with C, but that syntactic sugar of C++ is sweet in small doses. Please for all gods sake, please don't try to push C++ into Blender. It's a horrible language. This so called syntactic sugar creates more problems than it solves. C is an extremly versatile and powerfull language. And if you know how to use it allows for much more OOP than ever possible in C++. You may want to polish up your C++ knowledge: http://yosefk.com/c++fqa/ Wolfgang ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
Peter, I've read through the plugin proposal you wrote way back, and I find no real issue with it. Why wasn't it implemented? Was it just lack of resources, or am I missing something? (Also, I am prototyping a strip-wise renderer, but that's another story.) /LS On 2010-10-05 23:18, Dan Eicher wrote: On Tue, Oct 5, 2010 at 1:45 AM, Peter Schlaile pe...@schlaile.de wrote: ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
This is one of those questions that end up being decided by case law. The issue is what is an aggregate and what is a modified version. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation It is tricky to define where the line between these is drawn, as much of it depends on the nature of the connection between the Blender-part and the external part. If public APIs are used on both sides, then it comes closer to aggregation. If private APIs are used, closer to modified version. I had this same discussion with the authors of JBoss, an EJB Server, a while back. There, too, one could write plugins for the server. The end result was that as long as the plugin only used public APIs (Java standards), you could do anything you wanted. /LS On 2010-10-06 06:56, Dan Eicher wrote: As long as myDLL didn't link to or rely on any gpl'd code there's nothing anyone can say about how people use it -- except for the copyright owner of course. Bundling (distributing it and blender in the same 'package') is probably not an option though. The bottom line is that we consider everything you can create in Blender as 'data', including Blender scripts. But when you extend Blender with other facilities you have to follow the regulations of the GPL. ...snip... The divider is If the script runs in the Blender Interpretor. When the script calls code not running in the Blender Interpretor you are making bindings to other facilities, and the regular GNU GPL rules apply. Hmm... so one can only make calls to gpl compatible code if they want to distribute a script that runs in blender's interpreter? That doesn't sound right. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
On 2010-10-01 23:41, Dan Eicher wrote: On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile pe...@schlaile.de wrote: Hi, I have libplugin (http://libplugin.sourceforge.net/intro.html) working in blender. Well, extensions and join-points at least, still haven't ported over the (semi-)current plugin systems to use it. When I say 'working' I mean on linux building with cmake BTW, probably be a chore to get windows going since it brings a couple extra libs into blenderdom. in fact, it doesn't look like the way, a plugin system for blender should work IMHO. We are not aiming at *replacing* core functionality, but providing a clean way, to add certain types of filters / effect tracks etc. It's really just a wrapper around the .so/.dll symbol fetching functions plus some 'object abstraction' at its core, Yes, but it's quite different from what we're trying to do here. Libplugin assumes that the application has extension points where plugins can be added. Each extension point can have, if I understand the docs and illustrations right, *one* plugin; since the function pointer that is the extension point can only point to one place. We need for each extension point to have more than one plugin, and to be able to identify and select between them at runtime. Libplugin has more in common with aspects than plugins. Sorry if I got it wrong. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
Hi Peter, On 2010-09-28 20:39, Peter Schlaile wrote: Hi Leo, Looking at the code for the VSE it appears solid, but not very modular, nor suitable for effects that need access to more than the current frame. Since the tools I have fall into that category ? the anti-shake, for example, needs to compute the optical flow for each pair of frames ? it is currently near-impossible to port them over in a way that would give a good user experience or remain modular enough to be maintainable. Problem is: the idea behind the VSE is, that it should try to do most / all things in realtime. That doesn't alter the fact, that we need optical flow, so my idea was: add a optical flow builder, similar to the proxy builder in 2.49 and link the generated optical flow files to the strips. That makes it possible to: a) use optical flow files generated by other software (like icarus tracker) b) use optical flow information from scene files or even Open EXR-files (I'd think, the vector pass together with the Z-pass could be used for that) c) let the optical flow information be calculated in the background, when none is available and reuse it later for realtime display. I view optical flow much like an alpha channel - it is something that goes with the image data. Certainly we could use flow data from external sources, but more about this below. for each frame: for each strip: render composite gets turned into: for each strip: for each frame: render composite I don't really know, how you want to do that in realtime. But maybe I got you wrong. Reading your comments, yes, I think I must have failed to explain what I was trying to. Of course, we will only ever render those frames that are absolutely necessary to produce the requested output frames. We will also cache intermediate and final results. If you want to display one arbitrary frame in the middle of a Sequencer Editing, what exactly does your code actually do? Short answer: Ignoring caching for the sake of argument, we render that frame and its dependent frames. Nothing more. Let me illustrate the difference. Suppose we have two strips, A and B, both being movie clips (a.avi and b.avi, for example), that are composited to produce the final output. Case 1: Render a single frame, say frame 10. Here both methods work the same. We render: 1. A 10 2. B 10 3. Final output frame from A 10 and B 10 Case 2: Render multiple frames, say frames 10-20. This is where it gets different. Currently, we'd render: 1. A 10 2. B 10 3. Final 10 4. A 11 5. B 11 6. Final 11 ... n-2. A 20 n-1. B 20 n. Final 20 I want to invert that so we render: 1. A 10 2. A 11 3. A 12 ... 10. A 20 11. B 10 12. B 11 ... 20. B 20 21. Final 10 22. Final 11 ... 30. Final 20 Now, suppose we have one thousand strips with one thousand frames each to render. In this case, rendering one million frames and then producing final output from them would be crazy. So I would also allow the system to break up the processing into smaller chunks. Using the same example as above, we could: 1. Render A10-A15 2. Render B10-B15 3. Render Final 10-Final 15 4. Render A16-A20 5. Render B16-B20 6. Render Final 16-Final 20 Of course, we could use a chunk size of 1 and then we'd be back to the way things work today, but having larger chunk sizes allows us to amortize a fixed chunk cost over several output frames. For example, when computing optical flow, you need two frames to produce OF for one frame. That's twice the amount of frames. But to produce OF for two frames, you need just three input frames, not four. For ten OF frames, you need eleven input frames. In general, to produce N output frames, you need N+1 input frames. That cost for that final frame is amortized over the other N frames, so we want N, the chunk size, to be as big as possible. I hope that explains what I want to do. My understanding of your idea is currently: I'd have to render everything from the beginning and that sounds, uhm, slw? :) Yeah, that would suck. But we don't have to do that any more than we do now. That is, not at all. So what is the real gain with the kind of processing that I propose? Your render/bake pass solves one problem - it gives the plugin access to more than the current frame. But it also introduces problems: 1. Every time a parameter is changed, the bake/render must re-run. 2. When it runs, it processes, as you say, the entire strip. 3. So you: a. don't get any real-time processing. b. can't split the processing over several nodes in the render farm. What I propose is basically that we allow the render/bake to process arbitrary parts of the strip, and we provide a way for the r/b process to specify the minimum it needs to process in order to produce the requested chunk of baked data. Then we can 1. Split it over several nodes. 2. Run it in real
Re: [Bf-committers] VSE Strip-Wise Rendering
Hi Peter, thanks for the link to the plugin proposal. Any other pointers to work already done would be greatly appreciated. I'll drop back to working on bugs in the 2.5 beta for now. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
