Re: [CinCV] change fieldorder, doubling framerate
On Thu, 19 Aug 2010, Gerrit de Jong wrote: In the preferences for playback I found a setting for playback of 16 frames per foot. I presume if I set this to 32 it will give me 50 frames per second, but will it work to for rendering in 50 fps or does it work only for playback? I don't think that's what you want. You have a choice of what units to use for displaying the location in the user interface - for instance, you could display it by minutes and fractional seconds, or by minutes, seconds, and frames. One of the choices is to display it by feet as if you were editing physical film. (I imagine there are people who were trained on physical film editing and are accustomed to thinking in terms of feet.) Because there are different film standards, you can choose which one to simulate by choosing a different number of frames per foot. But that only changes THE NUMBERS YOU SEE ON THE TIMELINE, and even those only if you also choose the feet option for how to display the numbers. The amount of time it really takes to play a clip has nothing to do with the units of measure you select for the display. It's like choosing whether you will weigh something in kilograms or pounds, and then choosing how many grams you will say are in a kilogram. You get different numbers depending on the choices you make, and they will be nonsense if you choose a strange number of grams per kilogram, but nothing actually gets heavier or lighter just because you changed your measurement standard. Sorry I don't have any positive suggestions on the field issues; those are unclear to me, too. But I'm sure changing the frames per foot setting won't help you. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] cinelerra and comercial usage
On Wed, 6 Jan 2010, Marko wrote: I just wanted to ask you if cinelerra can be used for comercial purposes for free Depends what you mean by used for commercial purposes. If you want to have a copy of Cinelerra on your computer and make videos and do commercial things with the videos, yes, that's allowed (at least as far as Cinelerra's license is concerned). If you want to sell copies of Cinelerra for other people to use, that's allowed too, but by doing so you incur certain obligations - in particular, you must allow anyone who receives a copy to redistribute it and to modify it, which implies that they must have access to the source code. If you want to sell binary-only copies and forbid redistribution, or take parts of the Cinelerra software and build them into a commercial product that will not be freely distributable, that's not allowed. -- Matthew Skala msk...@ansuz.sooke.bc.caEmbrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] avi yuv2 render size is huge and no playback plugins
On Sun, 19 Apr 2009, David Morse wrote: The original video from the camera, that you can download at http://www.speakeasy.net/~morse/fan.avi , is pretty high density - only 500k, and gzip can only squeeze a further 2% out of it. It plays in all the movie players you care to name. That file is MJPEG compressed. (Checked by playing it with mplayer.) Once cinelerra loads it and rerenders it, that's when it becomes huge and low-content-density. Its 50x larger than the original: 10,000k, and bzip2 can compress it by a factor of 3, that tells me its not very random, and thus not well-compressed. It looks like 27 frames at 512x384 pixels. At 24 bits per pixel that'd be a little under 16 megabytes. Some minimal compression (run-length encoding for instance) might drop it down to about 10 megabytes. So your AVI file is compressed, as AVI files almost always are, and your Quicktime file is uncompressed or minimally compressed, as Cinelerra-generated Quicktime files often are. So far I'm not hearing anything surprising. If you were really getting a 10-gigabyte file that would be surprising, but I think it's more plausible that you're confused about what a gigabyte is than that you're actually getting that - since you also said 20 times larger!! and that'd only be 10 megabytes, which is reasonable. A gigabyte is a thousand (or 1024, depending...) megabytes. The colour thing is obviously a problem, but that sounds to me like a completely separate issue; I don't think there's anything wrong with the file size. -- Matthew Skala msk...@ansuz.sooke.bc.caEmbrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra won't stop play once started
On Mon, 6 Apr 2009, Daniel Jircik wrote: Preferances Playback Audio Driver = ALSA check tab Stop playback locks up I've asked before, but why is this a configurable option? Is there some population of users out there who want lock-ups? -- Matthew Skala msk...@ansuz.sooke.bc.caEmbrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] xml into .avi or .mov
On Mon, 2 Mar 2009, Thiago Guagliardo Klohn wrote: I'd like to know if it's possible to take a '.xml' video that I have edited and save it in '.avi' or '.mov' simply by using the key save as. I have Cinelerra manual and there it Save as allows you to choose the *name* of the file and only the name. It will always be an XML file. If you save it as .avi, it'll be an XML file with a name ending in .avi. The XML files created by Cinelerra are not videos; they are edit lists, that is, sets of instructions on how to create the video. What you probably want to do instead is render the edit list into a video file with the render command. That will also give you a choice of what name to call it; I strongly suggest that you choose a filename extension matching the format you choose, so choose a name ending in .avi if you're creating an AVI file, and so on. Rendering is a much different operation from saving; it involves actually pulling chunks out of the source files and re-encoding them to create the finished video stream, whereas saving the edit list just saves the list of instructions on how to eventually do the render. Normally you only rarely want to render, because it's time-consuming and may involve a quality loss; while working on your project you just load and save the XML edit lists and then when you're finally finished you render the result. When you watch your project during editing the editor renders parts of it on demand. it the way I want? Is it a bug or a problem because I'm a Kubuntu 7.10 user? Not to be rude, but it sounds to me like a bug or problem because you're a Windows user. The whole thing of file names being inextricably linked to the type of their contents is a Windows aberration; under Linux and most other operating systems, you can give any file any name and if you give it a misleading name (like naming an XML file movie.mov) that's your problem. Save as .avi all you want; it will still *be* an XML file because that is what Cinelerra produces. -- Matthew Skala msk...@ansuz.sooke.bc.caEmbrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] DVD longer than half an hour?
On Sun, 22 Feb 2009, John Detwiler wrote: 3. Standard DVD+R have 4.7 GB capacity, and hold about half an hour of mpg's. My finished project (including 'feature' and 'extras') will be at least 60-90 minutes altogether. DVD+R discs don't hold half an hour of MPEG video. They hold 4.7G, and how much time that is depends entirely on the bit rate. There isn't one standard bit rate that everybody uses. In order to fill a DVD in half an hour you must be using a bit rate of about 20Mbps, which is almost certainly *much* too high. Many decoders won't even operate properly when fed such a high-rate stream; I think the spec sets a maximum of about 10Mbps. Commercially published DVDs routinely fit several hours on a single regular-density 4.7G disc, with bit rates as low as 2Mbps. Try reducing your bit rate by a factor of at least five. Is it possible you're estimating based on the space consumption of uncompressed video, or the output of some kind of camcorder that does some other kind of compression, like DV? -- Matthew Skala msk...@ansuz.sooke.bc.caEmbrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] stop button locks out further rew/play/stop/ff functions
On Sat, 29 Nov 2008, Raffaella Traniello wrote: If you are using ALSA as Audio Driver, make sure you have Stop playback locks up checked in the Settings-Preferences-Playback-Audio Out window. Is this an option that anyone would ever want to have turned off? I've often wondered why it is an option at all. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Realtime or Low Latency Ker-what? - help in choosing a distro
On Thu, 4 Sep 2008, Ichthyostega wrote: throughput, i.e. the bare speed of the system. So, generally it's a tradeoff: do you need maximum speed, or do you need the system to reliably react within a certain timespan? Another point worth emphasizing is that RT kernels are designed for *predictable* latency, possibly even more so than just *low* latency. The average non-RT kernel may be very fast to respond to a given system call 99 times out of 100, but then takes much longer 1% of the time. You can't have that if you're feeding a buffer for audio (or CD burning, or a few other activities); so you need a kernel that will have a fixed upper limit on how long it takes to respond to the call. Even if the upper limit is not such a great response time, being able to guarantee no MORE delay than the limit is useful in planning how often you can afford to make the call. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Gentoo package renamed (cinelerra-cvs - cinelerra)
On Tue, 24 Jun 2008, Stefan de Konink wrote: It is not better, because technically you are using a copyrighted name for something that is not that name. Names cannot be copyrighted. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cinelerra digest, Vol 1 #2261 - 1. thumbnail based renderless editor (xirtus)
On Thu, 22 May 2008, xirtus wrote: HERMAN ROBAK WROTE: He is not referring to proxies (as I understand it), but rather for working with clips as discrete, untrimable units, the way the Thumbnail view in iMovie works... Sounds to me like Herman is spot on. untrimable to me means unfuckupable -and the original media will always be in tact. I have Isn't this just what Cinelerra's existing drag and drop editing mode does? I hate it myself, but it sounds like someone wants it, and we already have it. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Lumierra com and org
On Mon, 25 Feb 2008, Odin Omdal Hørthe wrote: I don't like the name Lumierra nor Luminerra, -- it's the erra-part I don't like. If we'll go that route I would much prefer Luminera, og Lumiera. (Or no r's: Luminea -- but that sounds like a lubricator) I think it'd be nice for the name to be as far away from Cinelerra as possible, but Lumierra has the advantage of sounding like Lumière, as in the Lumière brothers, cinema pioneers. I like that and would vote for Lumierra in preference to any of the other names I've seen suggested so far. Adding an n or removing all the rs breaks that. Removing just one r, for Lumiera, might be best - then it makes the resemblance to Lumière a little stronger and moves it further away from Cinelerra. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] effects
On Sat, 9 Feb 2008 [EMAIL PROTECTED] wrote: DVD-ready MPEG2-PS, single-pass, with multiplexing. I don't understand how I can get it. I need it, because now, I am rendering my editing in AVI-DV, and after, I encode my movies with Avidemux for getting a mpg2 file for my DVD, which is very long (and I also lose image quality). The Bounty is 300 euros. Could you please explain me what a Bounty is... I don't get what it means. Unfortunately, what it means is that that feature does NOT exist; and someone has promised to pay 300 euro if the feature is implemented. That's the meaning of the bounties - they are prizes to be awarded to whoever creates the features. Features on that list are features we wish for, not features we have. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] An Idea for cin3
On Sun, 3 Feb 2008, Thomas King wrote: I be able to redraw all cinelerra icons on svg and I can contribute to cin3 in this way... On attachement an example ( under gpl3 )... Forgive my ignorance again, but shouldn't artwork be released under Creative Commons, or does that matter? There's a lot to be said for keeping all parts of the software under the same license. I'm not sure how well Creative Commons is compatible with GPL3, and the attribution requirements of some Creative Commons licenses, in particular, may be inappropriate for the way icons are used. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Transitions between two loaded files.
On Sat, 2 Feb 2008, Herman Robak wrote: However, that would not suit your usecase. For you, it would be convenient if the transition _ended_ at the edit point. When I'm syncing the transitions to music I normally want the start of the transition to occur on the beat, so I hope that the current behaviour will remain available even if there's an option created for something else. I think what the original poster is missing is that while a transition is occurring, you are really displaying both clips on the screen at once. In effect there are two tracks even if it only shows on the timeline as one, and the clips must overlap. There's no getting around the fact that the source material must include frames past the point where the transition starts. If you try to do transitions from the very end of one clip to the very start of another, then of course you're going to have problems and there's not much the system can really do about it; you're saying Display this clip all the way to the last frame, and then keep displaying it for one second more, but oh no, don't you dare freeze the frame during that time! Is it supposed to create frames from thin air? Automatically reducing the clip's length by the length of the transition to create the overlap may help, but only if you don't care about the overall length of the clip; it would mean that two one-minute clips combine to be 1:59 in length. When doing music sync I *do* care about the overall length, so clipping a second off would be extremely inconvenient. I think it is the usual expected case that the clip you put on the timeline won't be an entire video file up to the last frame - that's not how video editing is normally done. Remember that an edit isn't a file, it's a chunk selected from a file. Normally one would have some extra frames on either side (the director says Lights, camera, action, the clapboard claps, the actors do their thing, the director says cut, and you only use the bit in the middle) and so it shouldn't be the default to expect that the clip will go all the way up to the last frame of the source footage. If things were designed such that transitions went between tracks instead of between edits on the same track, that might make it a lot easier to understand. I think it would mean an architectural change, though. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin-3
On Tue, 29 Jan 2008, Herman Robak wrote: For you an me? Very little. But please realise how irrelevant that is. Potential users and developers think Cinelerra is stuck in the 90s because of its GUI. Users believe the whole application must suck at least as much as its GUI. Developers don't think it's worthwhile to learn about a GUI toolkit that is only used for _one_ application. Bottom line: To many users and coders, Cinelerra doesn't LOOK worthy of their time and effort. For my two cents, the reasons Cinelerra doesn't seem to be worth my time and effort are: - It crashes. - It won't build. - It can't handle DV. - It's not open source. All of those require some qualification, but none of them are directly related to the GUI. Except for a few minor annoyances, I have no real objections to the current GUI and I don't think fixing the GUI should rank above those four points. The people who think making it pretty is a higher priority than making it stable, buildable, work with DV, and open source, are not a group of people I want to join. It crashes - this point has actually improved a lot over the last few years, and it's a big part of the reason I haven't given up on Cinelerra entirely. When I first started using it, which was when it was called Broadcast 2000, it wasn't really usable. Now it's painfully usable, due to the heroic efforts of the community development team. But fixing all segfaults and all hangs should still be top priority. Those kinds of thing are completely unacceptable in a production environment; if I'm doing paid work with a tool I can't afford to be worrying about when it'll next just happen freeze up, how much work I'll lose when that happens, and how much time I'll waste digging back in my backup stack to find the edit list that doesn't trigger the bug. It seems to be largely the GUI's fault that Cinelerra crashes so much - and a big part of it is because a custom set of widgets was used instead of a library - but the problem is behind the scenes, not anything to do with how the GUI looks on screen. It won't build - I should never be told that a needed library is missing when the library in question is already installed on my system; but I have to install new versions of everything just for Cinelerra because it can't look on my system for the libraries I already have installed. Then I have to go through commenting out lines of assembly language because the versions of libraries that Cinelerra needs, won't build properly either without modification - they lack the appropriate conditionals to work with the assembler I have. And so on. Also, I expect software to have a configure script that generates a Makefile that actually works. This point is also one that has improved significantly since the community development effort started; but it would be an absolute dealbreaker for someone who didn't have my considerable C, C++, and assembly-language programming background to customize the build system for my machine in the way that the configure script ought to. It can't handle DV - I don't actually use DV myself, so this isn't directly important to me, but it seems like a significant fraction of the questions we get from new potential users are How do I load/save raw DV files? and How do I record a DV signal from my camcorder? and the answers appear to be You can't, even though it is on the menu. and Use kino instead. respectively. Those clearly aren't acceptable answers, but this situation has persisted for years and I haven't seen a real effort to do anything about it. It's not open source - this may be the most dangerous item on my list, but someone's going to have to say it out loud eventually: Adam Williams has made clear that Cinelerra is HIS project, not OUR project. Although he releases a source package, it's not realistically possible to build from it (I have, kind of, sort of, built from it... but not with a realistic amount of work, and the result kept crashing). It comes with a warning telling you you ought to use the binary instead, and another warning saying there's no warranty even though there is a no-warranty warning built into the GPL already. The GPL isn't good enough for Adam, and Adam's source release is not a real source release. A real source release would be buildable. He's made clear that this situation will not change in the future, that community suggestions and contributions will not be considered or used unless they happen to save him work on things he wanted already, and that nobody but him can ever be a real first-class participant in Cinelerra development. That is not the open-source way. And on the community side, even the people who want to fork the project and make an actually open-source version, still want to call it Cinelerra. As a courtesy to Adam they're going to change the name, but the question isn't What name will we give our project?, it's What euphemism shall we apply to Cinelerra 3 so that
Re: [CinCVS] Re: Cin-3
On Tue, 29 Jan 2008 [EMAIL PROTECTED] wrote: The Name? Cin-3 is a placeholder until we have decided on a new name, then we will do the renaming. Indeed, for all of us there /is/ a tight I don't think the name is really all that important... but I do think that separating from Adam Williams and his project, is important. I want to contribute to an open-source project. I don't want to contribute to a commercial product that calls itself open source but releases code you can't actually use, which seems to describe Cinelerra. That doesn't have to be an insult to or disrespect of Adam and the many valuable things we've gotten from him; but benefiting from his generosity doesn't mean putting him eternally in charge of the open-source video editor he doesn't want to develop. It looks to me like many people involved with this project are not willing to really make it clear that they are doing something separate from Adam and the official Cinelerra. I think a name that didn't resemble Cinelerra would help make that clear, but the mindset (as you mentioned) is what I'm really concerned about and the name is just an indicator of that mindset, not the real point. Honestly, it's depressing how many of the suggestions I've seen are still obviously trying hard to work in as many letters from Cinelerra as possible, and still calling it Can you tell me please what's depressing with that? I think the people suggesting names that sound like Cinelerra aren't willing to really accept and buy into the idea of having a name that isn't Cinelerra, even though Adam asked us not to use the name Cinelerra and there are also good reasons independent of him that the project should want a name other than Cinelerra. It's depressing because these are, nonetheless, the very best people available. If anybody could make this work, it should be the volunteers this project has; but even programmers of this caliber are getting bogged down in a destructively limited view of what they want to do. Even if we often curse Cinelerra, because it crashes or hinders our work by some features being designed in a limited and to simplistic fashion, we should never forget it /is/ an achievement to have a complete editing application which is basically usable for pro work. Would you have started I don't think it's basically usable, and it won't be until there are a lot fewer remember to back up before trying this command and you can't do that warnings necessary. At the moment I think it has to be called alpha code. Also, I have to be able to run it in the first place. If I could expect to be able to get it installed without being a programmer then it might be beta quality; but I can't. This is not about features being missing; it's about features that are there but don't work. It's also about behind-the-scenes issues, like being able to compile and install the software at all. That's barely possible with the existing system - I can sort of do it, but only by checking out a development snapshot and carefully modifying a lot of files that ordinary users should not have to understand, and installing a lot of libraries that I *already* installed and shouldn't have to go through installing again, especially because they're only used to support features I don't need anyway. In fairness: the build and install systems for all Linux video software packages suck. Mplayer is particularly bad. To some degree that may be inevitable given the unique combination of general complexity and intellectual property encumberances that applies to video software. But I think Cinelerra's build system is the worst of the bunch. - Cinelerra can work with uncompressed material, and enables you to work on MPEG material (eg. HDV) as a source format (not a delivery format!) ...and you'd better remember to index the MPEG files with a separate command-line program first, because otherwise it'll load them but they won't actually work. And if you generate MPEG, you can't put it on a DVD because it'll have to be multiplexed first by external utilities. There are design reasons for that limitation (DVD authoring being a complicated task very different from video editing, so we can say it's not part of what the editor is for), but those issues aren't explained anywhere in a form understandable to someone who doesn't already know what multiplexing means. What the newbie sees is I can't make DVDs with Cinelerra. You bet MPEG is not a delivery format; you can't deliver the MPEG you generate with Cinelerra. - Cinelerra gives you *total* control on what is happening with your video data. No wizzard or cheat sheet is patronising you, which is an absolute must for professional work. Agreed. That's a good thing, but I don't think it's relevant to what I was talking about. - Cinelerra has an compositing engine seemlessly integrated into the normal workflow. Together with the automation facility, you can build quite advanced
Re: [CinCVS] Re: Cin-3
On Tue, 29 Jan 2008, Herman Robak wrote: ...and you'd better remember to index the MPEG files with a separate command-line program first, because otherwise it'll load them but they won't actually work. Now, this was remedied quite a long time ago, as Cinelerra actually indexes MPEG files automatically at load time now. It works for me, honest! Which version are you basing your observations on? I'm not sure. It's been a while since I tried to load an MPEG file, so if it now auto-indexes, that's great, and I apologize for the confusion. What I remember was from several years ago, when I wanted to load MPEG files, and it did, but then seeking didn't work, and I had to read a whole lot of unhelpful Web pages before I found out that even though loading an MPEG file causes the file to appear on the timeline, that's actually the wrong way to do it, and you have to use an undocumented command line utility first and load its output instead of the MPEG directly. If that procedure no longer applies, nobody told me. Well, as far as DV is concerned, the _codec_ DV works, if it's in an AVI or Quicktime container. That's what libdv is used for. Raw DV may still be broken. I gave up using containerless DV long ago. I don't have any DV files or equipment. My comments there were based only on the traffic I've seen on this mailing list. It looks to me like How can I use raw (containerless) DV? is pretty high up on the list of most frequently asked questions, and the answer people get is You can't. and I don't think it's a good answer. My guess on one reason people ask this is that maybe they have a lot of raw DV files generated by other software. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] GVFX - Gnu video FX
On Mon, 31 Dec 2007, Florian Cramer wrote: Also note that the GNU name is only used by and for software projects that are official part of the GNU project: ...with the exception of Gnuplot. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering to path containing spaces
On Wed, 19 Dec 2007, Burkhard Plaum wrote: Spaces are perfeclty legal in UNIX filenames. UNIX Software, which doesn't support all legal UNIX filenames, is broken. I agree. The whole thing of having a set of characters that must be avoided in filenames, especially if it's different per application, is very much not the Unix way of doing things. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] silent movie
On Sun, 11 Nov 2007, Z F wrote: I tried to create a text in GIMP and load it in cinelerra and effect was a blurry text. Maybe I did something worng, I do not know. Are there any specific rules to follow when making images in GIMP for movies/cinelerra? Lossy compression, such as JPEG or MPEG, will tend to blur sharp edges. So if you save an image as JPEG that can happen; but if you're compressing the video with MPEG it'll also happen no matter how sharp the original is. I'd suggest using only PNG for still images to be included in videos; it's lossless (unlike JPEG) and it supports full colour (unlike GIF). Be aware that some blurring is inevitable if you're going to compress the video with MPEG, though. It may not show up in the Cinelerra preview, but try viewing your rendered video and see if the titler-created text still looks sharp. There is also a feature called anti-aliasing which deliberately applies a small amount of blur to the edges of text to reduce the jaggies effect noticeable at small font sizes. If Cinelerra is not doing that and GIMP is doing it, then you'll see a difference. You can turn anti-aliasing off in GIMP (it's a check box in the tool options, near where you choose the font), but I'd caution you that that turning it off is probably not a good idea - text usually looks better with it turned on even though it's slightly less sharp. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] silent movie
On Sat, 10 Nov 2007, Z F wrote: I was thinking about making a separate track with the text frames using the title effect, but for title effect to work, it has to be applied to a frame. Do I have to make a black frame myself, or it can be done incide cinelerra? or there is some other better way? I would be inclined to use an image editor like GIMP to create a black frame as a .png file and then just load it in Cinelerra. If my inserted text frames were going to be still, though, I'd probably also create the text in GIMP instead of trying to do it with Cinelerra's titler - the titler effect has always seemed unstable and fiddly to me, and I'd only use it if I needed nice scrolling. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] switching between video tracks while keeping audio in sync
On Thu, 6 Sep 2007, Robert Persson wrote: In Media 100 and Avid this is very easy to do, and in some other editors you can work around it by splitting the main video track (i.e. the one that is in sync with the audio) and trimming it to make a gap, but I can't find a way to split the track. I have tried cutting a chunk out of the track, but when I do this, everything to the right of the cut moves left to fill the gap. I'd suggest using mute. Turn on create keyframes while tweeking[sic], and display mute keyframes, and then you can switch the top track on and off with mute. Where it's turned off, the next track down in the stack will show through. By the way, it should be tweaking. I've only ever seen the word tweeking used in Cinelerra, and to refer to methamphetamine abuse. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Replace was: open Editors
On Thu, 30 Aug 2007, Ed Colmar wrote: I dug through the tutorials and manual last night trying to find this replace command. Can you give me a little more info on how you achieved this, please. I'm struggling with trying to fit video chunks in time with music. After they are placed in time across multiple tracks, how can I replace a chunk and not screw up the entire timeline? It looks like the official name for it is overwrite. In the viewer window, above the transport controls, it's the fourth button on the left, and its use is described here: http://cv.cinelerra.org/docs/cinelerra_cv_manual_en.html#SEC110 -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] open Editors
On Mon, 27 Aug 2007, marquitux caballero wrote: THINGS... oh! and the editing will take 2 or 3 times more... if you edit copying and pasting, maybe cinelerra is faster, but if you edit cuts at the bit of the music, and need to dynamically try different clips in different beats... forget it, download and crack premiere is faster for that user (and cheaper actually). Actually, almost all my editing is of music videos, where I want the cuts to happen on the beats. I go through and mark all the beats (really, every fourth beat in most songs) with labels first, and then it's easy to swap in a different clip and get it the right length. That's why I find drag'n'drop mode so frustrating - I need to change the length of a clip when I move it to a different bar of the song, and I can't do that accurately with drag'n'drop mode. Cinelerra's paradigm of editing based on the time, not on the clips, is what makes it possible to get the beat lined up properly when I switch a clip. My usual routine is to choose a clip in the viewer with in/out points longer than the time I want to fill, arm the track I want to change (if necessary; usually it's the same one I was already working on anyway), select the labels at the start and end of the time I want to fill, do a replace, and then cut off the excess. An easier command sequence based on clips instead of on time would not really be easier at all. I'd end up with a clip the wrong length and fighting with the interface to get it adjusted. That's what usually happens when I accidentally enter drag'n'drop mode. Having a musical beat to synchronize with makes time-based editing all the more important, not more cumbersome. It's not archaic so much as mature; old-style editors worked that way because it was, and remains, a sensible way to work. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] RE: Cinelerra digest, Vol 1 #1879 - 10 msgs
On Mon, 27 Aug 2007, marquitux caballero wrote: keyframing... but still we can`t move 2 or 3 clips together, if we don`t copy and paste silences, and WATCHOUT! the armed tracks must be correct, so if you plan to meve this 2 clips and that 2 clips, WAIT, ARM JUST THOSE TRACKS, copy and paste silences, STOP!, GO ARM THE OTHER TRACKs, and now you How can I move clips? Here is how to move clips. I can't do it any other way. That is true. I can't recommend this software because it lacks basic functionality! -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] RE: Cinelerra digest, Vol 1 #1879 - 10 msgs
On Mon, 27 Aug 2007, marquitux caballero wrote: keyframing... but still we can`t move 2 or 3 clips together, if we don`t copy and paste silences, and WATCHOUT! the armed tracks must be correct, so if you plan to meve this 2 clips and that 2 clips, WAIT, ARM JUST THOSE TRACKS, copy and paste silences, STOP!, GO ARM THE OTHER TRACKs, and now you In more detail: the reason this feature doesn't exist is that in Cinelerra, when you select part of the timeline you are selecting part of the *timeline* - that is, something like from 1:23 to 4:56. You aren't selecting objects on the screen such as edits. So when you cut and paste, you are cutting and pasting whatever is on the timeline during the times you have selected. If you want to edit some tracks while leaving others untouched, that's what the arming and disarming of tracks is for. If you want to move things in several tracks at once to several other tracks, that is a complicated operation because it is a complicated operation: you need to think about what time ranges and what tracks you are moving from and moving to, and communicate those decisions to Cinelerra using the arm/disarm controls. Moving things from track to track requires explicitly selecting time and tracks because those are the things you're operating on. You can't just say move these edits over here because edits are not the things being moved. Edits within a track do not, from a control perspective, have a separate existence independent of the time ranges and tracks in which they exist. This paradigm of editing the tracks and the timeline, not the clips themselves, feels natural to people who are accustomed to editing with tape, because tape works the same way (you edit the tape, not the things on the tape). It apparently doesn't feel natural to people accustomed to editing with Premiere, where clips have an existence of their own and can be selected independently of the time and tracks that contain them. Cinelerra does contain a limited concession to Premiere-like editing in the drag and drop mode, although if it were up to me, we wouldn't have that - I've always found it extremely frustrating and it doesn't fit with the rest of the system. The concept that selection applies to tracks and time, not individual edits, is baked into Cinelerra on a deep level. This is not a minor user interface issue. It's not something that we could change easily if only we stopped being silly and ignoring usability. It's not going to change with anything short of a complete rewrite of the entire package. I also don't think it'll change even *with* a complete rewrite, because changing it would require drastic redesign, and would not provide any benefits that developers consider important. The only benefit of changing selection to work on edits instead of on time and tracks, is that it *might* make the interface more intuitive for *some* Premiere users. I'm not convinced that there are many potential users who would care, nor that the ones who think they would care, would even actually benefit from such a change in the long run anyway. So I really don't believe that this is a problem worth fixing. I don't believe it is a problem at all. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] An alternate proposal: Ctrl-drag to arm
Here's a suggestion that might make the move multiple clips between tracks thing easier for users, without breaking the whole system: what if Ctrl-drag were defined to do both selection and track arming? What I mean is that if you click or drag the mouse with the Ctrl key pressed, the interface would pick up not just the starting and ending points horizontally (time) but also vertically (tracks). As well as setting the selection, it would also arm and disarm tracks as needed so that the armed tracks will be the ones in the range you dragged across. I'm imagining something like the way the Windows and Mac desktops do rectangle selection. As far as I know, Ctrl-drag doesn't have a currently defined meaning in the Cinelerra interface; Shift-drag does, but Ctrl-drag seems to behave like regular drag. I would also define Ctrl-click to be like a zero-length Ctrl-drag; set the playback head to the clicked location and also arm only the track you clicked in. Moving several edits from one set of tracks to another would then go like this: - Ctrl-drag across where the edits are now - Cut - Ctrl-drag across where you want to put them - Paste The arming and disarming would happen automatically. It wouldn't matter which tracks were armed before you started, because the Ctrl-drag would reset that; it would leave the system in a state with the destination tracks armed. This would not excuse the user from knowing what arming and disarming are for; and it would not help when the user wants to cut from or paste to sets of tracks that are not contiguous; but I think it would simplify the most common case for this kind of editing operation. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Keyboard ShortCut referance guide
On Tue, 21 Aug 2007, Kurt Georg Hooss wrote: This would make sense because there are both the r and R commands (record and Render). I'd suggest instead of using letter case to describe the difference, use the actual keystrokes: R for record (the key on the keyboard has an uppercase R on it, never mind that on some internal level it translates to a lowercase r ASCII code) and Shift-R for render. I think that's more consistent with other software documentation. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra productions
On Sun, 12 Aug 2007, Kevin Brosius wrote: See, the problem with large files isn't really the space, it's the bandwidth that downloads will eat up. That costs in dollars (or archive.org is also worth looking into - they have some kind of special program of hosting video files that are of public interest. I don't know the details of how it works. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra productions
On Sun, 12 Aug 2007, Kevin Brosius wrote: Have you considered doing a dvd/cd release on one of the online publishers? You make a small clip available for download, so that people see enough to like or not like your film. Then you point them at the online publisher who will ship them a cd/dvd for $5-15US. I've released a video file through Lulu and generally been pleased: http://www.lulu.com/content/602488 That one is set up to allow free downloads, though I think they require some amount of registration process from downloaders. The Lulu system also allows authors to set up for-a-fee downloads, or CDs or DVDs that people can order for physical delivery. The prices are not super-cheap but basically reasonable. This kind of thing would probably work well for Cinelerra examples and code. The video I link above was made with Cinelerra, but I can't claim it's a wondefully impressive example; it was shot with a Web cam at a low frame rate and is mostly just a talking head. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] region free video?
On Thu, 2 Aug 2007, Yannick Patois wrote: As long as you create unencrypted VOB files (as it seems you are now doing by following the standard procedure), there is no chance your DVD could be zone restricted in any way. There are actually flags in the .IFO files that you could (in theory) set to make a DVD region-restricted, even without encrypting the streams. Of course, it wouldn't be secure - but the encryption and region coding can technically be turned on and off separately. The default for any sensible software will almost certainly be off for both. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] region free video?
On Thu, 2 Aug 2007, Martin Ellison wrote: As far as I know, home-made videos are region-free. It should be an option in the DVD authoring software. I would expect region-free to be the default. In any case, it has more to do with the DVD authoring than the video itself. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra interface questions
On Wed, 1 Aug 2007, Iván Castell wrote: - Another option I'm missing and don't know if it's there, is the ability to link/unlink a video and a audio clip (not the whole video and track, just a You can get a similar effect by arming and disarming tracks. Arm the audio and video you want to keep together, and then you can cut and paste both audio and video and keep them together. There's no automatic way of saying that a particular audio track always goes with a particular video track. - Is there an option to select as premiere does? I mean the selection tools: Range select, Block select, Track Select, multitrack select. I know I can Selections in Cinelerra cover a range of time and all armed tracks - not particular tracks unique to the selection. So it isn't possible to select just parts of some tracks out of a larger set of tracks that are all armed. However, you can achieve a very similar effect by arming and disarming tracks. selection, no the whole track(s). So if you select in the middle of a track it'll move this selection. Which it's the intended behavior but maybe I'm just not used to it ;) If you want to move tracks up and down, arm the ones that will be moved and use the move tracks up/down commands on the menus. Moving tracks from side to side would be meaningless, because all tracks cover all time. If you want to move all the stuff in one track (not the track itself) onto another track, then arm the track you're moving FROM, select and cut the stuff, arm the track you're moving TO, and paste. It may help if you think of the tracks as being like real tracks on a multitrack tape recorder. Moving the tracks isn't possible (what are you going to do, cut and splice the tape LENGTHWISE?) but you can move stuff between tracks. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Can audio be independent of video?
On Tue, 24 Jul 2007, Randolph wrote: Is there a way to make an audio track independent from the time line, so video editing doesn't disturb it? Editing only changes the armed tracks, so you can leave the audio alone by just not arming the audio tracks. Try shift-click on the arm button for a video track to arm just that video track and disarm all others. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Double compression
On Thu, 5 Jul 2007, Pier Luigi Conte wrote: Does it exist a method to don't compress again (during the render phase) an originally already compressed video? Allowing Cinelerra to pass-through frames where possible is a wishlist feature. At the moment, it doesn't exist. You can get that effect with a lot more effort using some other tools instead of Cinelerra, but even in the case where you're just cutting (without doing fancier effects), some recompression is unavoidable because of the way MPEG compression works. The thing is, the MPEG stream contains a few frames called I-frames that are complete in themselves, but most of the frames are B-frames, which are stored by storing the differences between the current frame and nearby I-frames. If your cut eliminates an I-frame, then you MUST recompress the B-frames that depend on it. (Things called P-frames also exist but considering them wouldn't really clarify the discussion.) For example, suppose you have two video streams that look like this: Stream 1: I0 B1 B2 B3 I1 B4 B5 B6 I2... Stream 2: I3 B7 B8 B9 I4 B10 B11 B12 I5... You want to cut from Stream 1 after frame B5, to Stream 2 before frame B8, so as to get this sequence of frames: I0 B1 B2 B3 I1 b4 b5 b8 b9 I4 B10 B11 B12 I5... The problem is that frames B4 and B5 depend on frame I2, which isn't included in your output, and frames B8 and B9 depend on frame I3, which isn't included in your output. (I showed them with lowercase letters to make it clearer). So you have to recompress those frames at least. You've also got an unusually long interval between frames I1 and I4 (I4 is the fifth frame after I1 whereas the original streams had an interval of four), and although that doesn't break any rules in this particular case, there *are* constraints on how long the interval is allowed to be, and it's easy to imagine cases where cutting could violate those constraints and you've have to recompress some I-frames too. There are also long-term bit rate contraints in things like DVDs, which you're allowed to violate for a short time but not for a long time, and in the worst case, cutting together two pieces that are near the limit could push you over and force you to recompress a substantial chunk of video. So avoiding recompression where possible is not just a matter of skip over the recompression code - making such an effort actually work, is a hard problem. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Video Effects and Video Transitions
On Sun, 24 Jun 2007, Jochen Kornitzky wrote: the second clip) or too short (not affecting the first clip, while the transition is in effect)? It's difficult. I'm not certain exactly what behaviour you want, but I've run into problems that seem similar where I'm trying to (for instance) wipe from one clip to another and I want an effect applied to the first clip but not the second - that is applied to ALL of the first clip, even the part that's being wiped. A big part of the problem seems to be that transitions are applied to the footage before effects are processed, where I'd usually prefer to have them applied after effects. I've had some success with putting the two clips on separate tracks, the transition on the top one, and stretching my effects to apply throughout the time of the transition. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] discontinuous automation values at keyframe?
On Sat, 16 Jun 2007, Markus Grabner wrote: Is it possible to define discontinuous automation values at a keyframe? This would be very useful for composing videos from a sequence of still Put keyframes on two consecutive frames. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] DVD render: output quality not so good
On Mon, 11 Jun 2007, Yannick Patois wrote: Most of the texture is lost in all rendered images... Thanks for any suggestion, You seem to be forcing a large GOP size with -g 15 -G 15. That means it's only allowed to emit an I-frame (complete description of a frame) twice per second, and everything else has to be compressed by referring to changes from the I-frames. Since this video contains rapid full-screen motion, the image is totally different from one I-frame to the next, and so you can't compactly describe most of the frames in between in terms of differences from the I-frames; the compressor has to re-describe each frame almost completely anyway. I'd suggest setting a much smaller minimum GOP size, like -g 5, with a maximum bigger than the minimum, so that the compressor can choose GOP sizes instead of being forced to have an I-frame exactly once every 15 frames. Then it can make a better attempt at conserving frame-to-frame information. Two-pass encoding would probably also help, if you're not already doing it. I also wonder if your requirement that the texture be preserved is really reasonable. You've got a complicated pseudorandom texture (looks like Perlin noise, for instance from POV-Ray), which won't compress well at the best of times, and you're trying to change it pretty much completely every single frame. Information theoretic considerations mean that it's just not possible to really do that well, no matter what algorithm or settings you use. You are trying to fit far more than 8600kbps of entropy through an 8600kbps pipe. That's an impossible feat. MPEG compression is dependant on faking it, with a psychovisual model of what human beings can actually see. It preserves the information that is really visible, throws away the rest, and the quality of the output is determined by how well the encoder guesses as to what's visible. It seems like the model is predicting that under these conditions the viewer won't really be able to see your texture, and the thing is, I think the model may actually be *right*. Maybe it would be more clear in a longer sample, but in your one-second clip, I can't focus on the white part firmly enough to be able to see a texture if one were there - it's moving so fast as to be a blur anyway. Can you really see the difference in quality between the compressed and uncompressed versions under actual viewing conditions at full speed? It's easy to spot the difference in still frame grabs, but MPEG cannot, and doesn't attempt to, preserve all details that might be visible with frame grabs. It's meant for moving video. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Still Pictures not exactly in the manual
On Tue, 5 Jun 2007, Randolph wrote: .png extension to .ifo, everything is fine. Then I can load, drag and drop all I want. The manual mentions nothing of this. Why are you renaming any kind of still image file to .ifo? That extension is for DVD metadata; I would strongly suggest that you leave your .jpg files named .jpg and your .png files named .png. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Two camera editing method - howto
On Tue, 5 Jun 2007, Timothy Baldridge wrote: Is this captured from a digital video camera? If so there may be a problem with dropped frames during the capture or with the Cinelerra's playback engine. Otherwise, you're in for fun. Basically, doing any sort of multi-cam with analog cameras is a really bad idea, that is, if you value your sanity. If each video track has its own synced audio track(s) and it's an interview, you could probably just arm both the audio and video tracks, and assemble your interview by cutting and pasting chunks from the appropriate audio along with the video, instead of trying to sync the two video tracks to each other and cut between them. You could even apply a fast crossfade as the default audio transition to smooth out any clicks created by the audio cutting. Syncing between the two video tracks is only necessary if you really need to avoid cutting the audio. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Upgrading wipe plugin
On Mon, 4 Jun 2007, Kevin Brosius wrote: Cool idea. Is there a problem with shape wipe that prevented you from using a new shape wipe mask for vertical wipes? The main issue with shape wipe is simply that it's less convenient - I was in fact using it before I made these changes, but that meant having to create a gradient image, and do more configuration for each use of the transition. The gradient image is quantized to 256 grey levels (so a very slow wipe can't be as smooth) and might have to be made in a different version for each resolution (I'm not sure if shape wipe does automatic scaling of the control image). I'd expect this patch to be a fair bit more CPU-efficient than shape wipe because it's doing a much simpler operation. It's probably faster than the old version of wipe too, because of the use of memcpy. From a usability perspective, a newbie who sees wipe in the list of transitions is going to expect vertical to be one of the things it does, and telling them Oh, you can simulate it by creating a vertical gradient and... is not really an acceptable answer. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Upgrading wipe plugin
I decided to enhance the wipe plugin to do vertical as well as horizonal wipes, and I've a few questions and issues about this code: - I really don't like the indenting style of the existing code. Do I have to follow it, or can I switch to something more readable for the parts I write? - We have a class called BC_Radial for radio buttons. It's probably too late to change it, but that certainly doesn't help understandability of this code. Radio buttons are called that because they function like the station-selection buttons on some old radios; the word radial means extending in rays from a central point and has nothing to do with radio buttons. - Is it safe to use memcpy? If not, is there a similar function I can use? -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Upgrading wipe plugin
Okay, here is a patch implementing my improvements to wipe. If this isn't
the best way to submit patches, let me know what would be.
I'm mimicked the existing code's semantics in that a wipe with a direction
of up means a wipe from the top of the screen down to the bottom. That
seems counterintuitive to me, but it's consistent with the old code's
definition of a wipe with direction left as going from left to right.
Swapping them all would seem more intuitive to me, but might break
existing XML files.
--
Matthew Skala
[EMAIL PROTECTED]Embrace and defend.
http://ansuz.sooke.bc.ca/Index: plugins/wipe/wipe.C
===
--- plugins/wipe/wipe.C (revision 1009)
+++ plugins/wipe/wipe.C (working copy)
@@ -19,46 +19,30 @@
-WipeLeft::WipeLeft(WipeMain *plugin,
+WipeCtlButton::WipeCtlButton(WipeMain *plugin,
WipeWindow *window,
int x,
- int y)
+ int y,
+ int direction,
+ char *caption)
: BC_Radial(x,
y,
- plugin-direction == 0,
- _(Left))
+ plugin-direction == direction,
+ caption)
{
this-plugin = plugin;
this-window = window;
+ this-direction = direction;
}
-int WipeLeft::handle_event()
+int WipeCtlButton::handle_event()
{
- update(1);
- plugin-direction = 0;
- window-right-update(0);
- plugin-send_configure_change();
- return 0;
-}
+ int i;
-WipeRight::WipeRight(WipeMain *plugin,
- WipeWindow *window,
- int x,
- int y)
- : BC_Radial(x,
- y,
- plugin-direction == 1,
- _(Right))
-{
- this-plugin = plugin;
- this-window = window;
-}
-
-int WipeRight::handle_event()
-{
- update(1);
- plugin-direction = 1;
- window-left-update(0);
+ for (i=0;i4;i++) {
+ window-buttons[i]-update(i==this-direction);
+ }
+ plugin-direction = this-direction;
plugin-send_configure_change();
return 0;
}
@@ -66,18 +50,14 @@
-
-
-
-
WipeWindow::WipeWindow(WipeMain *plugin, int x, int y)
: BC_Window(plugin-gui_string,
x,
y,
320,
- 50,
+ 75,
320,
- 50,
+ 75,
0,
0,
1)
@@ -97,15 +77,34 @@
int x = 10, y = 10;
add_subwindow(new BC_Title(x, y, _(Direction:)));
x += 100;
- add_subwindow(left = new WipeLeft(plugin,
+ add_subwindow(buttons[0] = new WipeCtlButton(plugin,
this,
x,
- y));
+ y,
+ 0,
+ _(Left)));
x += 100;
- add_subwindow(right = new WipeRight(plugin,
+ add_subwindow(buttons[1] = new WipeCtlButton(plugin,
this,
x,
- y));
+ y,
+ 1,
+ _(Right)));
+ x -= 100;
+ y += 25;
+ add_subwindow(buttons[2] = new WipeCtlButton(plugin,
+ this,
+ x,
+ y,
+ 2,
+ _(Up)));
+ x += 100;
+ add_subwindow(buttons[3] = new WipeCtlButton(plugin,
+ this,
+ x,
+ y,
+ 3,
+ _(Down)));
show_window();
flush();
}
@@ -202,53 +201,6 @@
-
-#define WIPE(type, components) \
-{ \
- if(direction == 0) \
- { \
- for(int j = 0; j h; j++) \
- { \
- type *in_row = (type*)incoming-get_rows()[j]; \
- type *out_row = (type*)outgoing-get_rows()[j]; \
- int x = incoming-get_w() * \
- PluginClient::get_source_position() / \
- PluginClient::get_total_len(); \
- \
- for(int k = 0; k x; k++) \
- { \
- out_row[k * components + 0] = in_row[k *
components + 0]; \
- out_row[k * components + 1] = in_row[k *
components + 1]; \
- out_row[k * components + 2] = in_row[k *
components + 2]; \
- if(components == 4) out_row[k * components + 3]
= in_row[k * components + 3]; \
- } \
- } \
- } \
- else \
- { \
- for(int j = 0; j h; j++) \
- { \
- type *in_row = (type*)incoming-get_rows()[j]; \
- type *out_row = (type*)outgoing-get_rows()[j]; \
- int x = incoming-get_w() - incoming-get_w() * \
- PluginClient::get_source_position() / \
- PluginClient::get_total_len(); \
- \
- for(int k = x; k w; k++) \
-
[CinCVS] Feature request: vertical wipes/slides
As the subject says. I was actually surprised we don't already have this - but I recently wanted to do a vertical wipe, stuck a wipe between my edits and opened up the configuration dialog, and I found that the only options were left to right and right to left, not top to bottom or bottom to top. The slide, band-wipe, and band-slide transitions seem to have the same limitation to horizontal only. I'm able to fake it with shape-wipe and an appropriate gradient, but it seems like a basic vertical wipe could easily be included in the native wipe transition, and would be welcome. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Length of MPEG2 files
I have an MPEG2 video ES file created by demuxing an NTSC DVD. Some of the frames in it are the result of telecining, but I don't care about that - at this point, I want to treat it as 29.97fps progressive. I'm pretty sure that none of this file is soft-telecine (with 23.976 fps stored in the stream and the DVD player expected to perform the pulldown to generate 29.970). It seems to be a mixture of 29.970 progressive and 29.970 hard telecine. However, I'm not certain of that; I haven't found a good way of testing it. When I try to load the file in Cinelerra, it takes up about 610 seconds on the timeline. That's both if I read the .m2v directly or if I pre-generate a .toc file with mpeg3toc. But all the other software I have that can read .m2v files (namely, transcode and mplayer) report it as being 586 seconds in length. Cinelerra reads it as about 4% longer than the other software. This creates problems because I'm using transcode and custom software to create a visual index of my footage which I'll then use while editing with Cinelerra; I need the frame counts to be the same between the two. When I ripped the DVDs I discarded the audio track because I didn't need it, but I plan to go back and re-rip the audio from this chapter so I can verify its length; that may give me some clue as to how long the video is actually supposed to be. At this point, though, it looks like Cinelerra's MPEG reader is counting frames incorrectly. Is there anything I can do about it? -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Length of MPEG2 files
On Sat, 21 Apr 2007, Scott C. Frase wrote: I've noticed similar things with DVD resolution MPEG2 video, though I am not sure what to do about it. I did some more investigating and found that the .toc file, which consists mostly of 8-byte records, has a few of those records records repeated twice. The number of repeated records in the .toc seems to be pretty close to the number of extra frames Cinelerra sees as compared to my other software. I probably won't be able to try this until I get home tonight (am currently sshed in from work), but I plan to try hacking mpeg3toc to detect when it's about to write a record that duplicates the previous one it wrote, and just not do that. I also determined that Cinelerra's view of the video is already off by several frames before the first point at which mplayer starts complaining about weird telecine settings, so I think I can rule out telecine weirdness as the cause of the issue. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Length of MPEG2 files
On Sun, 22 Apr 2007, Scott C. Frase wrote: Mark, It's actually Matthew or Matt... Thanks for taking the time to investigate this. It will be a big help to get it resolved. Okay, after doing more careful tests, I think I've determined that for a change, it's all the *other* software that's broken, not Cinelerra. Here are my frame counts for the same file containing an MPEG2 Elementary Stream extracted from one chapter of a DVD: mpeg3toc/mpeg3dump: 18309 transcode: 17572 mplayer (default): 18068 mplayer -fps 29.97: 18314 The audio for the same chapter, when extracted and played, takes 610.63 seconds, which at 29.97 frames per second works out to 18300 frames. Cinelerra agrees with mpeg3toc/mpeg3dump. So although none of these match up perfectly, Cinelerra seems to be closest to correct; I think it's the other packages that are at fault. (There go a couple days' worth of CPU time I already spent processing the footage with transcode and mencoder, but sorting this issue out is probably worth it.) Before doing the audio test I experimented with modifying the file libmpeg3/mpeg3vtrack.c, which contains the routine that mpeg3toc uses to record frames in its index. I was able to get a TOC file with frame count very close to transcode's (I didn't write down the exact number) by making it store the previous frame's offset in a static variable and then silently return without recording a new frame, if it were called a second time with the same offset. So it definitely appears that most if not all of the discrepancy comes from some frames being somehow duplicated or read twice. I've also gotten some messages about duplicate frames from mencoder when trying to process this file. So all is clearly not well with the file. Maybe it is at least partly soft-pulldown after all, and different software has different ways of dealing with that. But based on the audio length evidence, I think that these duplicate frames are supposed to be there, and Cinelerra is correctly handling them. I made a clip of the start of the file using dd, which was the only software for clipping it about which I was confident of not changing the format at all. That clip is here: http://ansuz.sooke.bc.ca/temporary/ev-clip.m2v if anyone wants to take a look at it. Grab it soon, because I won't leave it up indefinitely. It's just barely long enough to show clear discrepancies among the software packages, and that also is just long enough to include one of the spots where mplayer complains about telecining and frame rate changes. I don't know if that's a coincidence, or critical to what's going on. Frame counts for the sample clip: mplayer: 241 mplayer -fps 29.970: 244 transcode: 230 mpeg3toc/mpeg3dump: 245 cinelerra: 245 The content is the start of title 1, chapter 2, of ADV Films's North American release of Neon Genesis Evangelion Collection 0:3. By the way, what tools are you using to investigate the toc? (Maybe I can learn something new)? What I did was look at the files with less and try to figure out the format from that. It seems pretty clear that there's a header and then a bunch of 8-byte numbers that increment from zero. Then to look for duplicates I wrote a Perl one-liner. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Video Metadata
On Sun, 20 May 2007, Martin Ellison wrote: Is there a menu I haven't found that allows the title, author, and copyright to be set in our video files? I doubt it. Most video formats lack a standard way of recording that. You might look at tools such as ffmpeg or dvdauthor, which both have options for this. In what format? It's really a format issue more than a software issue. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] gpl headers
On Fri, 2 Feb 2007, muzzol wrote: is not possible to substitute those fonts with free ones? there's lot of free ttf fonts around. There are actually very few *really* free TTF files around. Almost all the free fonts you see are either commercial and distributed in violation of copyright, or different types of shareware distributed under restrictions like personal use only that would violate DFSG. There's also a problem of free replacements for commercial fonts, which don't always have correct metadata - for instance, a file called Helvetica is much more often some kind of Arial derivative, because real Helvetica is jealously guarded by commercial interests. Probably the best source for free TTF fonts is existing free software packages. For instance, if we were interested in Postscript fonts, there's a nice collection of them included with Ghostscript for which somebody else has already done the work of license clearing. I think some X servers may come with really-free TTF fonts. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] gpl headers
On Tue, 30 Jan 2007, muzzol wrote: im sad to see no developers are answering. this is really serious, in fact it could be a GPL license violation and is as simple to resolv as If you're the copyright holder, then your actions can't be GPL violations; you don't need a license for your own work. Just because you intend to put something under the GPL doesn't mean you're REQUIRED to give notice of that intent in a particular form. Furthermore, there's nothing in the GPL saying that it's only valid if mentioned in every source file, and it would make no sense for that to be a requirement for GPL validity because in many cases it would be impossible to comply with. This is, at most, a violation of Ubuntu's policy. However, it's an easily resolved one - let's just put the notice in every source file. Does Ubuntu have a precise definition of exactly what notice they want in every source file? I'm put off if they claim we require what the GPL requires because that's nonsense - the GPL doesn't and can't require any such thing - but at the same time, it's more important to satisfy Ubuntu on this point than to convince them. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] most adequate word
On Mon, 18 Dec 2006, muzzol wrote: and making a little video and i want to express in a formal/serious/powerful moments that supose great advances of the technology/humanity. i use a little clip with neil amstrong steping on the moon and i want to know which of the next words express closely that feeling: - watershed - goal - landmark the whole sentence is (imagine neil amstrong jumping): it's about watershed/goal/landmark I think any of those would be okay. I'd prefer watershed. Your example sentence isn't correct grammer, though. One way to make it work would be to make it more definite: It is a watershed. It is a goal. It is a landmark. and another would be to use a plural: It's about watersheds. It's about goals. It's about landmarks. It can't correctly be about watershed (or goal or landmark) because those are in the grammatical category of common nouns; when used in the singular they need to take a, an, or the. Seeing if I can narrow down the differences: A watershed is a boundary between two things; when you cross it, that's a big change. A goal is the *end* of a process. When you reach it, something is over. I prefer watershed because stepping on the moon shouldn't really be the *end*, it's more like a beginning. A landmark is a reference point; like a watershed it's something in the middle of a journey, but unlike a watershed, the landmark doesn't itself represent any particular change, it only shows that some progress has been made. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ubuntu packages and heroine permission to GPL files
On Wed, 6 Dec 2006, Herman Robak wrote: Not quite. Cinelerra bundles some other libraries that are not Heroine's original work. They are not all GPL-ed. Many distributions will want the app to use the installed libraries instead of bundling its own, too. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Call of cinelerra translators
On Sun, 3 Dec 2006, Alex Fernandez wrote: Can you explain asset as used in the following strings? Show assets, Delete asset from disk, asset to size Resource would be a more translatable equivalent. Show resources, Delete resource from disk. It's worth mentioning, though, that asset *is* the standard technical term used in the business. Changing it to resource in the English version would be a bad idea (confusing to our intended audience) even if the translation of resource is clearer in other languages than the translation of asset. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ubuntu packaging
On Thu, 9 Nov 2006, Holger Levsen wrote: I'm sorry to sound so harsh... but I brought this up two times already in the last 2 months and nobody seems to care. More like lots of people care, but they aren't the ones who are able to do something about it. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 359] New: changing video rate of project changes clip in and out points
On Tue, 7 Nov 2006 [EMAIL PROTECTED] wrote: I did a diff of a simple 5fps xml and a 30fps file, it looks like Cinelerra is not updating the STARTSOURCE and LENGTH values in the clips video track based on the new frame rate. Are those values stored in frames? If so, it seems like a problem because even if they are converted when you change frame rates, there will be an inevitable rounding loss so that you can't change frame rates, change back, and have the clips be unchanged. Since the XML is an ASCII-ish file format anyway, it seems to me that those numbers should be stored in some fixed units, like seconds, with decimals and to precision of less than one audio sample (so that they'll also survive sample-rate changes). -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] merge editing modes
On Fri, 20 Oct 2006, Nicolas wrote: I was too a bit surprised by the change. At first, when moving the cursor on the timeline, I wasn't able to do NOT select a part of the video. All I wanted was to see the flashing insertion point, without any selection. Fortunately, minmax helped me on the IRC, and he advised me to move the insertion point by clicking on the upper part of the main screen, where the time is displayed. I too haven't had much chance to test the change, but this sure doesn't seem like a good thing to me. When I sync things to a audio track, I want to set the insertion point by clicking on or very near the sound waveform. If I have to click on the time bar at the top in order to get a click instead of a drag, that's going to sharply increase the amount of cursing I do while using Cinelerra. And isn't the time bar already pretty much occupied by labels? If it's going to be hard to avoid clicking on a nearby label instead of the point I want, that will also suck. If you just removed drag'n'drop mode entirely, that would be better than this. I almost never use drag'n'drop mode and wouldn't miss it. However, I wouldn't advocate doing that, because I'm aware that some people do like to use drag'n'drop mode. What if instead, the drag'n'drop/normal setting were made less accessible, so that it would be less likely for people to change it without knowing what they're doing? -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Audio Question...
On Wed, 11 Oct 2006, Miha [UTF-8] KitiÄ^M wrote: make a clicking sound just before they record a scene. I suppose if you clap loudly near the mike before you take what you want to take (and make sure that clap of your hands is included in the video), you will be able to synchronize the clap of your hands with the sound track visually That's what I've done in the situations where I wanted to record audio and video with separate devices. I put in a clap at the start and end of each shot in order to be able to correct for speed differences. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] audio levels
On Sat, 30 Sep 2006, Raffaella Traniello wrote: On Internet I learned that we can hear from silence (0 Db) up to over 140 Db (a bomb). So why to set the automation range from -80 to 6? Are these number referred to Db? The dB scale actually measures *ratios*, or differences in loudness, not absolute levels. So it's not really meaningful to say The level of this signal is 10dB; all you can say is that This signal is 10dB above that one. Nonetheless, people do use it to measure absolute levels, and they do that by choosing a specific reference to be 0dB and then describing where everything else is in relation to that reference. For actual sounds in the physical world, the usual zero point is chosen as the softest sound a typical human can hear. That's 0dB (more correctly 0dBA - the A indicates that we're using this scale). Louder sounds are like 20dBA for whispering, 60dBA for typical spoken conversation, or your example of 140dBA for a bomb going off. Note that 0dBA is *not* truly silence; it's just the softest sound audible to human hearing. But electrical signals are usually measured on a scale where 0dB is taken to be the loudest sound the system can reproduce accurately. In normal use, typical signal levels will be slightly below that, with peaks going slightly above. You will get distortion as you go above 0dB signal levels. On level meters there's a red zone on the scale to warn you about that. Depending on the user's volume setting, 0dB on the electrical level meter might be 60dBA or 80dBA or 20dBA or whatever. One issue with digital is that in most cases the top of the power scale is a hard limit - once your signal's 16-bit sample values get to +32768 you simply *cannot* go to +32769. As a result, the clipping distortion you get when you drive a digital system past its maximum tends to sound especially annoying, and you have to be really careful not to do that too often. Analog systems tend to degrade more gracefully, so that you can push them above 0dB on the level meter with audible, but not annoying, distortion. A similar effect is part of why some people fetishize vacuum-tube analog amplifiers: the way they distort at excessive signal levels is claimed to be better-sounding than the way transistor-based amplifiers do. Electrical equipment displays a phenomenon called the noise floor, which means that there is *always* some amount of noise measurable even when there is no signal. You can never have true silence. The noise floor might be 80 or 100dB below the 0dB mark on your level meter; it depends very much on the quality of the equipment, with better equipment having a lower noise floor. With 16-bit linear digital samples, there are theoretical reasons that the noise floor can't be any lower than about -98dB. So it makes no sense to have volumes adjustable below that. In Cinelerra, there is a configuration setting for how low you want the level meters to go. What numbers have I to write if I want silence when the white fade line is at the bottom margin of the track and a slightly too loud sound when the line is at the top margin? The defaults should be like that already. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] dv grabbing (off topic)
On Sat, 23 Sep 2006, Nicolas wrote: Well, you're lucky. Because on my system, if I launch a CPU consuming task, the burning process can stops for some 1/10th of a second. Make sure the interrupt-unmask flag is set for your hard drives; see man hdparm. On many systems it is not the default (because it can, rarely, be dangerous) but your system will effectively lock up for a fraction of a second every time a large disk access occurs, if this flag is not set. It's pretty much a necessity for activities like DVD burning. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] about starting over...
On Mon, 31 Jul 2006, Dimitrios wrote: In other words, we keep the current interface and just add a lighter version along with it. All advanced features will only exist in the Expert Interface while all the Basic Interface will have only the simple features for working on simple projects. I don't think the interface is the problem; I think stability is the problem. And if we're capable of offering a choice of Would you like crashing or non-crashing?, why bother making that a choice? -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Free media positioning in track?
On Fri, 21 Jul 2006, Stefan de Konink wrote: Is it possible to move a track around in the 'arrow' mode instead with the mouse moving the track with the keyboard frame by frame. I want to lipsync individual recordings. But it is kinda hard doing it with a mouse, play to check, and move it a bit around again. What I'd really like to see would be keystrokes for move this edit a frame earlier and ...a frame later that would work during playback, from the compositor. Then I could modify timing for lip sync, and play and replay to see that it works, all from the keyboard without switching windows. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Free media positioning in track?
On Sat, 22 Jul 2006, Pierre Marc Dumuid wrote: What I'd really like to see would be keystrokes for move this edit a frame earlier and ...a frame later that would work during playback, Try pressing the keys on the Num Pad and see what they do (1 4 especially) I'm talking about changing the edit, not moving the playback head. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra v2.1 has been Released
On Thu, 6 Jul 2006, Dimitrios wrote: features to their drivers. Sure, their drivers aren't open source (and anyone working for a similar organization very well understands why) but who really cares, I care. Anyone working for a similar organization very well understands why is not an excuse I consider acceptable. That same statement could be used to justify almost anything. I'm not sure how relevant this kind of philosophical discussion really is to the topic of this mailing list, but given that we're an open source project ourselves, I think there's some room for keeping in mind the reasons for what we're doing. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Revision n° 799: compilation error
On Thu, 25 May 2006, Andraz Tori wrote: this mailing list is getting crowded, maybe we should split -dev part to its own? My opinion is that before doing that, we should stop having all Bugzilla traffic automatically forwarded to the mailing list. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] understanding chained tracks
On Wed, 8 Feb 2006, Andraz Tori wrote: The concept comes from audio... where there are many situations in stereo, where you want to apply the same effects with the same keyframes to both tracks at the same time, without managing keyframes for every track separately. The same could be used for video tracks when you are combining some material in multitrack and want to fix all the material in the same way (apply the same color correction for example...) no matter which track the material is in... But then what happens to the data from the shared track? As far as I can tell, when you use a shared track, it doesn't just apply the same plugins... it also composites one track into the other. I have yet to read a clear description of where the data actually goes, let alone why it's useful. Sharing just the plugins (like, share a track to automatically share all its plugins) would make sense to me. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Strange masks moving
On Sat, 4 Feb 2006, Nicolas wrote: It worked. I would have preferred to be able to use the 1 and 4 keys of the compositor, since that would have avoid me going from the main window to the main compositor on each frame. But as I said, that worked, The 1 and 4 keys should still be usable... you just have to pay close attention to what direction you're moving, and understand that the cursor is *between* frames, not *on* a frame. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Head between frames
On Sat, 4 Feb 2006, Herman Robak wrote: is *between* frames, not *on* a frame. Is there a justification for this somewhat odd behaviour? Is it more logical? More usable (I think not!) Easier to program? I think it has to do with the idea that the playback head is positioned on a sample rather than on a frame. When you say move ahead one frame, you aren't actually moving to the next frame; you are moving ahead an amount of time equal to the length of one frame, and seeing what happens during that time. When you change direction, you end up replaying the same frame twice. I imagine the original developer of Cinelerra thought that was more logical. Now, we generally edit with align playback head to frames turned on, and in that environment, this behaviour sure is confusing. Before trying to change it, I think we should try to figure out how other editors handle this issue. I'm not sure it's trivial to know exactly what the right behaviour is. I've changed the title of this message because I'm pretty sure the masks moving issue was actually about Edit keyframes while tweaking being turned off, not this. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
