Re: [Bf-committers] Blender
Hi! Lip syncing and spoken would be left to a text to speech engine which is also able to sing, using a string for the speech and another for the lips. If you have such an engine, please contribute to the scientific scene, because such a thing doesn't exist yet in perfection that you could let it sing or even use it for multiple different realistic voices for a movie or game. Last but not least, the music, which I directly compose in Blender and use when needed for the speech pitch as well in order to make it sing. Sure, that's easily possible, you just have to hire at least 10 audio developers to work on this fulltime for at least two years, to get a basically usable DAW out of it... Will this be possible? Why not also add a browser rendering engine and a whole kernel to blender so that you can run BlenderOS directly when your PC starts? Now to be reallistic: Such an eierlegende Wollmilchsau [1] won't ever exist, but there are other applications that work perfectly with blender and does it really matter whether they are one executable or multiple ones? For the audio stuff you want: blender supports Jack and the included Transport mechanism, so it works perfectly with professional open source audio applications such as Ardour for example. Regards [1] http://www.dict.cc/?s=eierlegende or http://dict.leo.org/ende?search=eierlegende ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi! Sorry for the late reply, but I had no internet for 3 days. Lars: The problem is that the Data API in blender doesn't have such mutexes and as such isn't thread safe, I guess making blender thread safe in this way, requires a GSoC project or even more on its own. Knapp: This is not about interpolation ;-) And why it's not readable? Imagine a thread accesses a pointer while another thread deletes that memory?! Brett: This doesn't change anything regarding the data access. Sergey: Well yes, the question is whether the main thread can do such a preprocessing. At least the cache can be updated with the current frame value once it's reached so that the value is correct at least the second time you playback after a change (not doing changes between first and second playback for sure). Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi guys! There's a serious problem with the way how animation works in regard to audio. The main problem is, that the animation system pushes the output, so it sets the data, renders a frame, advances to next frame (setting the data there) and renders again and so on, this works pretty good for video. But it doesn't work with audio, especially as audio has a very high temporal resolution (48000 eg. samples per second) compared to video (eg 25 frames per second) and moreover for audio the output device pulls the data, instead of the animation system pushing it, so the other way round. I talked to Martin (Poirier) and Joshua (Leung) and even we three together cannot think up a nice solution for the problem, maybe some genious mind here on the list who is more into the animation code than I am has a really nice idea. Here are specific problems in detail: * Subsample Accuracy: To avoid stair steps as we currently have in volume animation. * Multi Threading: Audio runs in a separate thread. * Speed: The access mechanism has to be realtime capable! * Asynchronous access: Audio playback is ahead of video playback normally (buffering the samples, feeding them to the output device). The first point can be solved easily with a proper interpolation if you have two nearby samples, one in the past, one in the future, so this basically requires the animation data to be cached/buffered somehow or at least asynchronous accessible. As the cached data also solves points 3 and 4 it's pretty obvious that we need the data cached, we had that conclusion already. Questionable is now how to get the cache? One obvious solution is to require the user to bake it, but this heavily impacts how easy the system can be used and as we also already concluded this is a really ugly solution. Better is the automatic caching which leads us to the problem point 2 multi threading. I don't know if it's possible to cache in the main thread? I bet not. And as long as blenders (animation) data isn't accessible multithreaded we still have no solution for the problem. So now your help is needed. Any ideas? If not I'll have to do the baking solution to finish the project. Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Am 2011-04-25 08:26, schrieb Sergey I. Sharybin: So, question is: do we want to support more codecs (ogg, vorbis, teora, vpx, dirac, schro) and have 8mb bigger Blender binary as we've got now? Ogg, vorbis and theora are definitely needed as they are in the output file formats and codecs and commonly used codecs in the FOSS world. For the others I'm fine if we don't support them, but I'm not the video guy here, just audio. Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Hi! We should definitely update the one for static linking to the linux release. Most distributions so far don't have libav in their standard repositories yet, so most distros and devs will still link against ffmpeg, also there's no libav build for win64 yet so we'll have to wait for that too if we want to switch completely to libav. But as long as we maintain our code so that it's possible to link against both versions I don't see too much problems (at least not more than we're used to have with ffmpeg...) supporting both. So back to the version we should use for the linux release: I'd really like to try libav. Although I didn't try it out yet (because my distro doesn't have any packages yet), I got a good impression of libav when I joined both IRC channels #ffmpeg and #libav when trying to find a workaround for a bug [1] and got really useful help in #libav. But in the end it doesn't really matter at the moment and the future will show which project survives. I think other questions are more interesting, lately someone came up in IRC with switching ffmpeg output to a CLI interface, though that would leave the decoding with ffmpeg as it is now. Another possibility would be to switch to gstreamer, but here some say it might be too big a dependency. Regards [1] http://projects.blender.org/tracker/index.php?func=detailaid=26990group_id=9atid=498 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Am 2011-04-24 11:15, schrieb Sergey Kurdakov: just to make it more correct http://win32.libav.org/win64/ Awesome! I've only looked here: http://libav.org/download.html where you can only find win32 binaries. Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Hi, I've marked those with NO mostly sure that they are not needed and could be disabled. The others marked with NO? are at least not used for encoding but disabling them would disable some input formats. Question is if we really need to support everything?! Regards Am 2011-04-24 22:04, schrieb Sergey I. Sharybin: ./configure \ --cc=gcc -Wl,--as-needed \ --extra-ldflags=-pthread -static-libgcc \ --prefix=/opt/ffmpeg \ --enable-static \ --enable-avfilter \ --enable-vdpau \ === NO === --enable-bzlib \ === NO === --enable-libgsm \ === NO? === --enable-libschroedinger \ === NO? === --enable-libspeex \ === NO? === --enable-libtheora \ --enable-libvorbis \ --enable-pthreads \ --enable-zlib \ === NO === --enable-libvpx \ === NO? === --disable-stripping \ --enable-runtime-cpudetect \ --enable-vaapi \ === NO === --enable-libopenjpeg \ --enable-libfaac \ --enable-nonfree \ --enable-gpl \ --enable-postproc \ === NO === --enable-x11grab \ === NO === --enable-libdirac \ === NO? === --enable-libmp3lame \ --enable-librtmp \ === NO? === --enable-libx264 \ --enable-libxvid \ --enable-libopencore-amrnb \ === NO? === --enable-version3 \ --enable-libopencore-amrwb \ === NO? === --enable-version3 \ === TWICE? === --enable-libdc1394 === NO === ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Audio GSoC
Hi! I'd like to apply for a google summer of code project again this year, but this time directly for audio stuff. You can find my current proposal in the wiki [1]. I think it's important to not have audio improvements as title, but have a real target, in this case 3D audio. Campbell also came up with the idea to improving lip sync, which would be also possible, I for example found some papers [2], [3], [4], that would enable blender to have some auto-lip-sync (for sure manually editable too). This project would target on improving the lip sync workflow with blender. Before I write a proposal for the lip sync project I'd like to know your opinion about it and if it's prefered over 3D audio. Also if there're any other audio features you'd like blender to have, just answer here! Regards, neXyon [1] http://wiki.blender.org/index.php/User:NeXyon/GSoC2011/Proposals [2] http://www.lmr.khm.de/files/pdf/speech_berlin.pdf [3] http://scribblethink.org/Work/lipsync91/lipsync91.pdf [4] http://jan-schulze.de/file_download/14/Diplomarbeit.pdf ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Python API Documentation
Hi all! During my GSoC project which I just merged, I implemented a new Python API documentation system that uses templating and gets documentation out of several different sources to unify them then by writing out Sphinx .rst files that can then be used to build an html or latex documentation with sphinx-build. The problem (in my eyes) we have is the many different locations of documentation we have at the moment, if you look at source/blender/python/doc/sphinx_doc_gen.py you'll find out that it gets the documentation from three different places: * bpy.types and bpy.operators are generated using the rna_info module * the bge modules are handwritten rst files * the other currently online modules are generated using the python docstrings * there are still some modules like bgl that still aren't in the online documentation yet Now there should be a unified solution and I have two possible solutions: 1) Have all documentation as docstrings: Advantages: * Docstrings can be read in the interactive console * The documentation can be kept very near to the code Disadvantages: * They blow up binary size as for C modules all docstrings are in the binary * They are not as easy to maintain and edit by dedicated documenters that are no blender coders with svn access 2) Have a database with a nice structure to store docs Advantages: * Easy to edit for everybody, there could be a web interface to edit docs directly * Lower binary size Disadvantages: * No docstrings, so no direct documentation in the interpreter, although the help function could be overwritten to retrieve the docs from the DB * Documentation and code are seperated, extra validation is needed to check completeness of the docs Let the discussion begin. :) Regards, neXyon ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Advice on fixing bad merges (Shaders GSoC)
Hey, I had exactly the same problem last summer! What I did then in the end is merging by hand when I was allowed to merge my branch to trunk. That wasn't too much a problem as most files were new and in a separate directory (audaspace). Since then I'm poking Ton to update the svn server, because a new version as you said resolves the problem. I hope this other case helps speeding up this a little. Regards, Jörg Am 30.07.2010 08:07 schrieb Mitchell Stokes moguri...@gmail.com: Hello devs, I'm looking for a bit of advice. A couple of days ago, my mentor and I realized that some of the merges earlier in the project were done poorly, which is now starting to cause some issues. I'm thinking the best way to resolve this is to diff against the trunk and clean up the resulting diff to only have my changes. Then, from there, rebranch from trunk and apply the diff to the new branch. Thoughts on this? Also, another thing to consider: I believe newer versions of SVN are much better at merging. For example, I don't think a revision range needs to be specified (this is where problems showed up in my branch). I know there was some talk about upgrading to a newer version of Subversion (1.4.3 is quite ancient). Is anything happening to this end? Thank you, Mitchell Stokes (Moguri) ___ 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] Large sequencer cleanup
Hi Peter! I haven't tried out your patch yet, but the improvements sound really nice! The sequencer definitely needs some love. About the grandma understanding the code, there's one thing that's pretty confusing: all that startofs, anim_startofs, startdisp, startstill attributes, all with end instead of start also and length and so on. So it would be nice to drop some (most) of these attributes from the structs to the least minimum and calculate the dropped ones on the fly (as far as I have noticed calc_sequence and calc_sequence_display are called so often that the attributes can definitely be calculated when they're needed without getting a real performance loss). And then it would be nice to have a clear documentation what value/function returns what at some place (wiki?). As part of that recode of cfra to float I wonder if it would be better to change cfra to a time value that holds seconds? I guess that's a general discussion topic that can even be considered for the whole blender code. Well it's just a quick idea, I have no clue what problems could arise from that. One more thing is if you could have a look at the drawseqwave function in sequencer_draw.c, you see there that sound_read_sound_buffer is called and everytime a quite huge buffer is alloced and freed again. Although that's only done for sounds where the raw PCM samples are already loaded into RAM it's quite slow and makes it nearly impossible to use with even one music strip of 3 minutes length, so I wondered if you would be as kind as to add a caching mechanism here too. Regards, neXyon Hi, the last three days, I cleaned up / rewrote large parts of the sequencer code, to accomplish the following things: * make cfra a float internally to enable sub-frame precision rendering with speed effects and make the code a lot clearer * remove the whole TStripelem mumbo jumbo (is necessary, since cfra is a float now, right?) * replacing it with a hashtable based caching system * thereby dropping memory usage of the sequencer to a fraction of it's current usage (80 MB without using any caches to approximately 5 MB on a 3 hour timeline) * thereby making the cache limitor drop the full imbufs (no more clicking on refresh from time to time anymore) * thereby make cutting a lot snappier, since freeing up the imbufs is just about dropping the contents of the current hashtable and not traversing really large arrays of null pointers... * prepare the code for multi-core usage (threaded rendering is disabled right now, but the old code was limited to two cores anyways, because of this TStripElem hell) * and: make the code so easy to understand, that your grandma will get hold of it (hopefully) I did some test editing, nothing crashes, no memory leaks, everything seems happy, but: can I commit or should I wait some days to let Blender 2.53 settle? Patch is here for reference: http://peter.schlaile.de/blender/seq_cache_rewrite.diff Only thing missing is frame blending in Movie and Image strips on speed effect input (which is still largely broken, so most people won't really notice...) This will come back shortly as an option for Movie and Image strips. (Which will be able to adapt to different frame rates directly for free on the way, since, cfra is now a float :) ...) 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
Re: [Bf-committers] meeting minutes - June 13, 2010
Tom M wrote: Joerg Mueller feels .blend file reading: ipo-curve conversion code should be moved, he suggests the following patch: http://www.pasteall.org/13752/diff Talked to Aligorith now in IRC, he's fine with the patch, Campbell too, if nobody else has concerns about this (Brecht? Ton?) I'll commit this at the end of the week. Regards, Jörg ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] neXyon's GSoC 2010 proposals
Hi there! I've had some ideas and quite liked some of the ideas other people told me, so I've set up some drafts of proposals for GSoC 2010 of projects that I'd really like to do. They are 7 proposals all together. So far I've not detailed them very much as I don't see much sense in working on a proposal that won't get accepted/will get low priority. I personally can't and won't rate those proposals. That's the job of the mentors, so I'm asking you: How would you rate these proposals? And what details would you like to have added? http://wiki.blender.org/index.php/User:NeXyon/GSoC2010 Regards, Jörg ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Audio stuff!
Hi there! The next bigger audio commit has been done, where I've worked on quite a lot of things again and now I have some things to discuss. a) New Sequencer Audio. The biggest part of it is the rewrite of the sequencer audio code. Audio is now not updated on every frame change, but every time the frame jumps, so if playing back with to low framerate, audio will not stutter as before, but just continue playing with the result that it's not in sync anymore. To keep audio up to date there are 3 functions to be called: sound_stop_scene, sound_play_scene and sound_seek_scene. The later does the scrubbing too (play sound on frame change when not currently playing back). It does the scrubbing when there is currently no playback and scrubbing is enabled. I currently ask if there is playback via if(CTX_wm_screen(C)-animtimer); I wonder if there is a better way to do this? b) FFMPEG I've enabled ogg, theora and vorbis now to check if there are bugs reported about that not working, because it was disabled in code with a simple note that it is not working... I've got it working here now after wasting a lot of time with ffmpeg. I've also added wav, matroska and mp3 as new formats and flac as new codec. Flac is NOT working for me and I have no idea why, already asked in #ffmpeg in irc, but nobody has been able to help me yet. The problem is that avcodec_encode_audio returns 0. Is anyone able to tell me what's wrong or to fix it? Moreover you can now choose mp3 and wav formats for encoding audio only, as well as None as video codec (which results in only audio being encoded as well), but there's a problem when hitting the animation button: blender is still rendering the images = wasting a hell lot of time, because they are not used. Brecht told me where the rendering can be disabled, but I don't want to touch that code. Someone more experienced with that part of blender might be as kind as to disable the rendering when it's not needed! While meeting we also discussed that ffmpeg in extern can now be removed. If someone is willing to do that and update the scons configuration, feel free to do so! If you are doing so, please remove WITH_BF_OGG as well, as it only en-/disables the ogg support of ffmpeg in extern... c) Sound Wave Drawing Yeah, the wave drawing in the sequencer is back for cached sounds (which is the same as RAM sounds in 2.4x). Two points here: Number on is: There might be another colour used. And number two: For long strips the drawing is pretty slow, so one might add a user setting to en-/disable the drawing of the sound wave. Both tasks sound like perfect tasks for new blender developers. :-) That's it for now, let the discussion begin. Regards! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Solution for the Linux audio problems with OpenAL
Hi! After a lot of investigation I now finally have a solution. This weekend I came up with a workaround trying to use ALSA definitely with OpenAL before using the default backend. Unfortunately that works for some and bugs for others, same is true if I'd try Pulse backend first. The reason behind this is, that there are actually two bugs. 1. There has been a bug in OpenAL soft with the Pulse backend. 2. A bug in the pulse alsa plugin. The thing that routes applications playing to ALSA to pulse. (Just to let pulse then later play through ALSA again ... I know... it's stupid) Well, today OpenAL 1.11 has been released and that one solves bug number 1, as well as bug number 2, as it now uses pulse by default if it runs (bug number 2 would now only happen if the users having pulse would configure OpenAL to definitely use ALSA...). So the solution is to link the official blender version to OpenAL soft 1.11, either statically or if possible dynamically, supplying the lib and a script that makes sure blender uses the lib. That has to be done by the linux plattform maintainers/official builders. I removed the workaround and will now close all bugs in the tracker related to this, though people having pulse will continue to have problems with pre 1.11 OpenAL. CC? Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
