On Friday 22 Aug 2003 1:04 pm, Rolf Dubitzky wrote: > On Wednesday 20 August 2003 11:50 pm, Jason Wood wrote: > > 1. The first step I had was therefore converting them to rawdv - not too > > hard but not done via Kdenlive, I used Kino to do this. I missed the fact > > that there appears to be no way to batch-convert files to a new format, > > but then, that's not really what kino is there for. > > ;-) but that what piave is there for. You could probably do this at the > command line with piave_CVS-00-03-devel. Even better, you could just use > the .avi files ;-)
Very true :-) > > - The first thing was sound sync with the video. Rolf has already > > mentioned this is improved in the 0.3.0 branch of piave by using arts > > directly, but it is very annoying trying to watch back your movie and > > "mentally shift" the sound back to where it's supposed to be. > > Yes, this is a problem. mplayer and xine both assume some audio latency > based on experience and allow to in/decrease AV-delay while watching. I > will probably have to do something similar. Maybe we can privide a small > clip with a flap, so you adjust some kind of latency parameter for you > system. Not using artdsp, however, does already help a lot. > > > - I had the same shot filmed at two different camera angles. Syncing up > > the video/sound was relatively straight forward. But damn, the sound > > quality between the cameras was so different it was way too noticable! > > The real solution to this is to have video seperate to sound, so that one > > camera's sound (or an mp3/off/wav file) can be used throughout and the > > other video(s) simply displayed over the top. > > ;-) almost done ;-) the piave version on my laptop can read wav/ogg/mp3 > and ... well, and nothing more, not play anything or re-encode, but I am > currently working on it. I think blending audiotracks together is not too > far away, too. Ok, that's good, so the only thing missing is the support from Kdenlive. That is kind-of in place - there are audio tracks that are currently not used, but could be brought back, and then the VEML will need to be updated to handle video and audio seperately. > > - Because the cameras both had mono sound, the dv files were the same - > > functionality to take sound from either the left or right channel and use > > it for both channels is a must. > > ok. trivial, that can be done. the main problem is probably to invent VEML > to do it. I suppose it depends on if it is done as a special case, or as a piave effect - in which case it is rather that we need the effect framework in place. > > - On the back of this, I missed not being able to fade sound in/out :-) > > well, up to now, there is not a single audio-effect, only some video > effects in various states of bitrot. But since I finished my thesis a few > days ago, and started working on exactly this, I think you can have a > audio-volume-filter pretty soon. BTW, taking audio from one DV file and put > it into the other does workalready, there is just no VEML for it. > > > - video crossfade - for the clips I was editing together, a simple > > crossfade effect would have been quite adequate to make the end result > > much better. > > piave can do this. the effect suffers some minor bitrot. and, more > important, we have no really working VEML definition for effects (and no > GUI ;-) So we need effects , basically :-) > > Things that would have been nice : > > > > - Having sound images in Kdenlive so that you can visually see the > > 'beats' in music, or when somebody starts speaking. This is one thing that I have very little idea as to how to implement. It comes down to ownership - whose job is it to generate the sound waveforms? It's a slightly odd task to as Piave to do, however for Kdenlive to do it, it needs to have the raw audio which only piave has. > > - If piave crashes, it does take a minute or so before a connecion can be > > re-established. Some sort of rotation of port numbers so that a new port > > is tried each time should help remove this problem completely. This does > > not mean that we should stop bug-fixing though!!! :-) > > this just treats the symptom. I just have to look into a network > programming howto. There are two things to it: > 1) Fix the tcp/ip communication and make the socket be freed in case of a > crash > 2) detect when piave and kdenlive are running on the same host and replace > the tcp socket by a unix domain socket. This will improve speed and > especielly reduce latency a lot. This is what XWindows does and can be > done by changing a hand full of source code lines. Ok, that does sound like a good idea. > > - Being able to select in/outpoints works like a dream! > > - The piave in the workspace monitor crashed once or twice , I did not > > lose my project! (There seems to be an issue with long timelines, piave > > inserts <message></message> tags which do not always make the end > > scenelist valid XML. I hope to look into this, since I want to > > rationalize the XML code in Kdenlive at least anyway.) > > - The rendering was nice and fast, and came out exactly as it played > > during the edit. > > That makes me happy ;-) However, it is not too surpizing that it was fast, > since you probably didn't do any real rendering at all. And since piave is > designed by the principle of delayed action, which means that a video or > audio frame in the render tree is only decoded as soon as it is _really_ > necessary to alter the video/audio information. If you don't do anything, > just cut/rearange, the video/audio is not decoded at all. That also means, > that you don't have _any_ kind of quality loss. you can rearange your clips > as often as you like. (at least in DV format) Oh, ok, we need to do something so we can test the rendering speed of piave then :-) > > Right, I'll switch back to the developers hat. Please feel free to > > comment! > > I think I will merge the avi and sound stuff from the devel branch to the > main branch as soon as seperate audio tracks are working. We should try and > get another synchronized kdenlive/piave release, 0.2.4/5 or something. mpeg > support is not something that will work in the next weeks. This will > probably help people testing the stuff. I would also like to supply some > packages. I guess we probably have enough people here to make Mandrake, > RedHat, and debian packages. Since I will be moving to another town to > start a new job at Sep. 1st, I guess maybe we can aim at the first or > second week of Sept. for this, what do you think? I'll post a seperate 'plan of action message' in a minute to give us something to discuss :-) Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk
