Re: [CinCV] Weird keyframe problems during rendering -- SOLVED
Richard Rasker schrieb: >> I'm trying to help one of my Linux users with a rather frustrating >> problem: Basically, Cinelerra handles keyframes just fine during >> preview, but behaves erratically when rendering. > OK, I went over & checked things out, and it turns out to be related > to the track overlay mode (normal/additive/etcetera). The first two > tracks were set to additive, but the third one (where the problems > occurred) was set to normal. When trying to create a cross-fade from > the second to the third track, the fade-out of the second track > overlaps the fade-in of the third track -- but with the third track > in "normal" overlay mode, this latter track is only displayed when > the clip in the second track has completely ended. Setting the third > track overlay mode to additive as well solved the problem. Hi Richard, this sounds familiar! That specific problem has biten me several times. Basically, something in the handling of Alpha in conjunction with some colour models got broken with the step to Cinelerra 2.1. (It worked OK with Cinelerra 2). Basically, when you use additive overlay mode combined with dissolve transitions, *both* tracks need to be in additive mode. I've tried to figure out what goes wrong, but the relevant part of the engine code is quite large; and because of the multiple colour models combined with multiple overlay modes (not to mention the openGL support hacked in all over the place) it is a huge task even to figure out what's going on and how it "should" be. My guess at that time was that fixing this bug properly (which means to *prove* you haven't broken anything else) would require at least a man month of work; thus I gave up and used the workaround. > It still seems a bit weird though -- this user has created dozens of > Cinelerra projects, with literally hundreds of crossfades between > different tracks, but this is the first time he encountered this > problem. Talking from own experience: the problem is tricky and if you don't know where to look, it may take some time to realise that something is going wrong here. Especially: did you know that you can *keyframe* the overlay mode? Yeah, that's a very powerful and usable feature of Cinelerra, but if you've turned the "automatic keyframes" on and at the same time the "show mode keyframes" off, then you might well accidentally add dozens of overlay mode keyframes all over the timeline without noticing it. Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] donation of apple hardware for cinelerra darwin port
Rafael Diniz schrieb: > I'd ask if someone is still interested in a cinelerra darwin port. > Any news from the lumiera front? Not hardware is the limiting factor. We need people willing to participate on a long-term base, in order for a darwin port to happen. In this respect, the situation is the same for cinelerra and lumiera. Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] EDL Specification
Daniel Steinberg schrieb: > Is there any documentation describing the full EDL (XML) syntax that > Cinelerra parses? rather not... Cinelerra uses an "homebrew" XML parser and the parsing / outputting is scattered over various places; mostly the objects to be loaded or saved contain the code to parse themselves. Anyway, it's pretty much straightforward to figure out. Use a simple project with 1 media and one clip in the timeline and look at the generated XML. project session viewer-window (nested session with assets and EDL) assets EDL tracks clips pluginsets automation (just quoting from memory, maybe inaccurate) hope that helps Cheers Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Lumiera Engine
Am Mittwoch, den 16.04.2008, 11:59 -0400 schrieb Roland: The idea is interesting for a start. Do you think it is possible? ie : > plays many hdv videos for example? > Hi Roland, just to explain Christian's Idea a bit: the videoplayer will use the same backend code as Lumiera, and it creates a similar situation as we expect to have in the App: there you may have background rendering going on, maybe another render job running, and at the same time you may want to watch a video in the viewer and scrub through the composer/timeline (which will fetch background-rendered frames and maybe some additional frames). Building a videoplayer allowes to do stress-tests on the backend code, which needs to get all this frame-fetching and delivering right and performant. The focus is not so much on the I/O throughput, which, of course much depends on your hardware and underlying system. For example, playing several HDV videos in paralel requires that your disk/IO/system can get quite a lot of data in very fast. Further, it requires that you have a lot of processing power "on board" for doing the decoding. But, /assumed you do have theses capabilities/, the goal is to write code able to deal with organizing all those video frames efficiently -- and this is what the video player test app is aiming at. Cheers, Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] lumiera
Am Dienstag, den 08.04.2008, 02:58 +0200 schrieb Frans de Boer: > Okay, i understood before that the CV-Cinelerra team was working on a > new (bottom-up) cinelerra-CV version since it is obvious that if you > have to resort to an option to "restore from backup" that the product > must me fundamentally flawed anyhow... > ... but the main question might be: why is the original HV project so flawed? Well, it is often difficult to pose the question "why?" -- often those things manifest out of circumstances. For example: if we talk of "bad leadership": there never was the intention of "leadership" at all. Just Someone(tm) wrote code usable for editing video, realeased it under the GPL and other people checking in those releses into SVN and collecting bug reports And suddenly, there is something like "the Cinelerra-CV community" If you are interested, you may have a look at an old polemic text I wrote last year in the time we had those discussions finally leading to the start of coding at what is now called "Lumiera". http://pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra_woes > Apart of the many crashes, CV-Cinelerra (v 2.1) does offer many of the > things I expect from a professional Video Editor. it does has it's > excentric ways compared to MainActor/Adobe Premiere, but still deliver > AND because it uses XML files to create EDL files, it can be - in > theory - portable to other editors as well. Yes, I want to stress the point that indeed you can do professional work with Cinelerra. Cinelerra isn't a "pile of crap" or "broken". No, it basically works, allowes you to do quite advanced things and deliver hight quailty. > My only hope sofare is that the new piece of code can handle the > CV-Cinelerra V2 XML files too. I have already restarted projects three > times - Adobe Premiere (win32) -> MainActor (linux) -> CV-Cinelerra I can asure you: importing Cinelerra Sessions is on the agenda. There may be some rough edges, because we won't have an identical replacement for each and every plugin Cinelerra provides, but my guess is, it won't be too complicated to get in the clips, masks, camera/projector and basic things like color correction, blur. But note, as matters are now, this is just a guess how it may be when we have a working edit+render core and are able to load and store sessinos. Btw, we have not yet decided anything on what the native session format for Lumiera will be, but it is designed in a way that we will have one (or several?) storage backends For me personally, the fact Cinelerra stores it's sessions in XML was one of the most important features for getting larger projects done smoothly (including checking the XML into SVN or GIT and being able to do scripted manipulations on parts or the whole project). Depending on the quality of our scripting interface the situation may be different for Lumiera though. cheers, Hermann Vosseler (aka "Ichthyo") ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin3 naming
Am Dienstag, den 26.02.2008, 17:17 -0800 schrieb [EMAIL PROTECTED]: > I'd like to offer to do some focus testing of the proposed names, > once they are narrowed down to the to 6-10 or so. Hello Jay, thanks for your offer. I think it's not the right moment for wasting any efforts on such things now. > The new Cin3 can do for NLEs what Firefox did for browsers. Please excuse me for putting this so direct, but this statement is not correct. The new App /could indeed/ do interesting things in the far future, /if/ we manage to do our work right and keep the focus of the project. Right now, there /is/ no "new Cin3". Regarding the focus: We should not be concerned about people's opinions or try to impress some Apple company, rather our main concern should be to build an application that really works and works correct and reliable, is up to the state-of-art, maybe does some things better compared with "the average video editing app". And, very important, we should care for good usability in the core application area, which is editing film (feature, video, documentary, independent, news items, artwork projects, ...). We wanted the community to be involved in finding a name. This community is right here. We got lots of interesting name proposals, now we are about to narrow down the selection and remove any names we devs utterly dislike. We'll finish the name game with a poll. There is no need to be objective or use scientific methods for picking the name, because it simply reflects what we (both the community and the devs) prefer right now at the moment. Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Quick Start Guide
Am Dienstag, den 12.02.2008, 21:45 +0200 schrieb Dirk Uys: I am interested in getting involved with the development of the new > version of cinelerra! I am a C++ developer, but I know a fair amount > of C. Hello Dirk, you are welcome! > What I would really like to know, is there some web page or document > that contains all knowledge/ideas/guidelines about cin3 to this date? We have quite some infos scattered on various levels -- I mean from rather abstract to practical and low-level. The project "home" is currently on Christian Thaeter's "pipawiki" http://pipapo.org/pipawiki/Cinelerra3 Besides this wiki, the Core of our project is contained in the GIT repositories. Within this tree, you'll find a directory with some TiddlyWikis containing the design- and technical documentation. You can browse the GIT trees at: http://pipapo.org/gitweb Currently, my GIT is the most up-to date http://pipapo.org/gitweb?p=cinelerra3/ichthyo;a=summary I put together some snapshots (of the mentioned design TiddlyWikis and a Doxygen run) on my webpage at http://ichthyostega.de/cin3/ You may want to have a look at our project meetings on IRC http://ichthyostega.de/cin3/wiki/index.html#IRC-Transcripts If you are interested how things started out, you'll find a polemic I wrote about the old source base, some conclusions and a first preliminary project plan at http://pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3 NOTE: this pages are from last summer. At this time, we thought to rather do a partial rework the old source base. But by now we are a complete rewrite and will soon have a new Name different from "Cinelerra3" The project is in a early stage and things are much in flux. Please feel free to ask more questions. We don't have a complete Architecture overview or Roadmap yet, but it is clear that the new app. will have three Layers: - Backend (written in C, ask Christian Thaeter for details <[EMAIL PROTECTED]>) - Proc-Layer (written in C++, ask myself for more details <[EMAIL PROTECTED]>) - GUI. (no maintainer yet, only some brainstorming) Cheers, Hermann Vosseler (aka. "Ichthyo") ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] codec for youtube?
> On Tue, 12 Feb 2008 15:19:32 +0100, marquitux caballero > > why don´t you LISTEN? maybe having 2k or 4k is for not many users, but > > FLV and 3GP EXISTS, so if you plan to make a PROFESSIONAL tool, why not > > to listen what the people say? Am Dienstag, den 12.02.2008, 15:58 +0100 schrieb Herman Robak: Mentioning 2k and 4k here is a straw man argument, since hardly anyone > on the list has ever mentioned it. A youtube output/upload option was > actually on the "needs doing" list > And now, Marquitux, I ask _you_ to listen: > ! while I agree fully with Herman, I want to add the following: Marquitux, you are shouting all the time "why don't you LISTEN"...? Marquitux, we talked on irc, you expressed your experiences in great detail in several mails, we found out that we share similar frustrating experiences with the current cinelerra. We stated several times that this was one of the motivations to start the "Cin-3" (or-what-else- it-will-be-named) effort. You did GUI mockups, we saved them as a reference for later when we are able to make use of them. What else do you want? that someone says "Pofff" and a shiny new magical application emerges out of the blue?? >From reading this ML you can see, that we are coding (yes, we are actually coding), that we have developer meetings, that we conduct a GUI debate and discuss features clearly geared towards a professional workflow -- but you can see as well that we didn't reach the point where we could make a GUI draft, so basically, if you are demanding that this or that feature needs to be "built in", your perception is correct: no one is LISTENING, because such arguments are beyond our focus: There is the current Cinelerra. Several of us have tried quite some time to build in some desperately needed features. It is doable, but requires unproportional efforts. We did an analysis and drew our conclusions. We'll care *first* for building a *engine* which will put us in the situation to implement all those esperately needed features (which we are well aware off) with reasonable efforts. And to make it absolutely clear: Marquitux, we value your contributions and we will need your judgement and your feedback very much at some time in the future! Cheers Hermann Vosseler (aka "Ichthyo") ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] User Interface CONCEPTS mockup.
Am Mittwoch, den 06.02.2008, 21:02 +0100 schrieb Christian Thaeter: > The tracks in a timeline represent a tree, to make it a full graph one > just needs to 'wire' signals between this tracks. > > AkhiL mase some drawing some time ago: > http://img81.imageshack.us/img81/6916/cin3proposaldrawingbn3.png ... >This ui is imo far more intuitive and nearer to the current approach > then a node editor and uses screen estate much better. Hi Christian, I understood Richard's proposal such that the node editors are only an optional view the user could open when (s)he wants to delve into the details how nodes are wired. So, both aproaches could be combined: in the Timeline-Windows you just atach clips, effects etc. to each other and place them on tracks Hermann V. PS: and of course, Tracks form a tree, that's important :-) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Totally dumb question
Am Mittwoch, den 06.02.2008, 13:48 -0600 schrieb Timothy Baldridge: Cin3 actually has development going on? Just look at the news history > on the main page, and the forums. It's vaporware. > > And yeah, I've been keeping tabs on it since '03. > Timothy, for your info: "Cin3" is the new project everyone is just searching a new name for. And yeah, it has development going on :-P cheers, Hermann V ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] User Interface CONCEPTS mockup.
Am Mittwoch, den 06.02.2008, 09:02 +0100 schrieb Richard Spindler:
> I've made a little Picture about how I think the User Interface of a
> yet to be named Video Editor could be presented.
>
> http://propirate.net/oracle/zipfiles/UI-concepts-CineTris.png
> cehteh, ichthyo, do you think that the backend could be used with
> such a frontend?
Hi Richard,
the structure displayed in your drawing is to a large degree identical to the
"high level model" I am currently developing in the Proc-Layer (middle Layer
of the application). Besides, our design incorporates a Builder, which creates
a uniform network of render nodes which will be implemented/driven by the
backend.
But the intention is to rather shield the user from the low level model while
presenting him a view of the high level model.
So, largely, you can take it as agreement. In the following I'll concentrate on
differences in deail or on things I do a bit more flexible than in your
proposal:
*Tracks and Busses*: in the Proc-Layer, material on one track can
connetct to several different Busses. I want to ged rid of this
often very limiting "leftover" from the old analogue hardware,
where each track corresponds to one reading/writing head and
thus to one bus. Even in the simplest case, for me a "Clip"
containts a video and an stereo audio stream and thus makes
connection to two busses simulatnously.
*Tracks are a Tree*: Tracks are nested right from start. You can
attach properties on every level. Most important property of course
is the output bus connection, further properties are layer ordering,
sound PAN position, MIDI instrument/channel asignments. Each Clip
searches the next-applicable properties he needs. (Here the rule-based
aproach comes into play, but from users view, this is not immediatly
obivious, because the application will come with a set of pretty much
conventional rules).
*One or multiple Timelines?*: The Proc-Layer has N distinct EDLs in
the Session. Each EDL is a collection of objects placed in some way, but
from users view it can appear as an separate timeline. Obviously each
timeline can either be anchored at an absolute time or just use relative
coordinates (it doesn't make any difference). An EDL can be placed in
the form of a meta-clip in another EDL -- that's similar to the
"sub-timeline" in your drawing.
*basic building block = Pipeline*: We are using various names for the
same concept: Node Graph, Bus, Scratch Bus in your drawing, "Port" in
my design and implementation. I am trying to find a grippy name for this
entity all the time, an currently I am geared to call it just "Pipeline".
Other opinions or proposals? Some facts to further the discussion:
- remember it's the high level model. Its an abstraction the user works
with. You can expect this "Pipeline" to be translated into a chain of
connected nodes in the low-level model, but it is not identical to
this chain.
- each clip is built round a Pipeline, containing the effects directly
attached to the clip. At the source end, it will be connected either
to a source reader + Codec, or recieve input from some other Pipeline.
- we have global Pipelines ("Busses") forming a matrix similar to the
mixer strips of a sound mixing console. As said, we can have
attachement points to these global Pipelines at various levels in
the tree of tracks, and in several EDLs simultanously, so each global
pipeline can recieve input from different and varying sources.
- an EDL which is a meta-clip can be configured either to connect
to the global Pipelines directly, or it can connect to the local
Pipeline of the meta-clip, where we could attach further effects
and transitions. This configuration can even be mixed: e.g. route
the sound directly but send the video through the meta-clip
*limit the Pipelines to linear chains?*: I want to hear your opinion
about limiting the individual pipeline to a strictly linear chain of
nodes! The only exception would be "send nodes", which can make
arbitrary conections to the input side of other Pipelines. The rationale
is code simplicity. Having a tree or even network within each Pipeline
makes building, addressing, processing and managing much more complicated
without providing anything you could not get similar by connecting a
"send node" or the exit point of a Pipeline to another Pipeline (which
could be a global one, or just appear as clip somewhere in some EDL
and thus add even the possiblility of changing the config
in a time varying fashion).
> There is no central notion of the camera/projector Model, which I think
> could be added anywhere in the Graphs as a Node with an unlimited Number
> of inputs.
Agreed, I am following the same line of thought. Besides, I plan to
make the default configuration rules such as to insert a "camera" node
in case the source resolution is different of what can be derived for
the Clip-Pipeline and similarily to insert a "projector" node automatically
when the desired output
[CinCVS] Vote for a Name for a new NLE
Am Mittwoch, den 06.02.2008, 07:53 +0100 schrieb Richard Spindler: The Following Names were the "preferred" choices on the wikipage at > How to vote? Make an "X" in the Box before the name, and send this > mail back to the list. > > [x] VeriteCV > Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Default settings and presets also need some love.
Am Dienstag, den 05.02.2008, 22:47 +0100 schrieb Raffaella Traniello: > I'd add: > * Audio fade (and meters?) set to -40.0 to 6.0 Hello all, oh yes, this reminds me of some unfinished work. Indeed Audio faders and meter need to be -96dB to +6dB, because that's the dynamic range of 16bit PCM. (24bit has even -124dB) Pierre Dumuid discovered this misconception quite a while ago. Now this brings us to a quite complicated issue, the usage of dynamic range. While for much "everyday work" you won't use more then -20dB (and even apply a compresor to the sound to squeeze it into this limited range, so it sounds "good" on your car radio), for quality oriented work you certainly use all the dynamic range. Now, (as Pierre pointed out correctly at that time), if we just change the effective "default dynamic range" of cinelerra, this will change the meaning of the audio fade curves in quite a dramatic manner and -- whats most important -- this affects opening old sessions created with cinelerra's former (misguided) understanding of the dynamic range ending at -40dB. Cinelerra had/has the habit to just switch off the sound when reaching -40dB. On consumer grade Boxes this may seem fine, but when using Studio Monitors, you can hear a quite annoying "Click" at the start and end of /every/ fade and crossfade. But, on the other hand, would we change this "switch of at -40dB" behaviour, all sound tracks of all old sessions wouldn't be longer silent at places were the original author of these sessions intended them to be silent. Again, not noticeable on small PC speakers, quite noticeable on stuido speakers. Not, at the same time (two years ago) I was working on the "bezier patch" which improves the handling of the smooth fade (and camera+projector) curves quite to some degree. This was one of my attemts to fix/supply some features needed badly for more inclined work with cinelerra. (And as you all know, we learned the lession that wanting to repaire seemingly localized issiues quickly turns into a major undertaking -- finally this led us to where we are now with "Cin3") Pierre at that time helped me much to tidy up the bezier patch, split it up into parts so that it could be, at least partially accepted without breaking mergeability. This process created some tension, because I wanted to improve the source base and Pierre cared much more for staying alligned with upstream. Anyways, in the course of this we found out, that using the functionality I built into my patch (which we at that time expected to go "in" in some way) would also nicely solve the "96db" Problem, because it would allow us to set a new artificial interpolation node at -40dB while allow to retain the slope and curvature of the fade line the original author intended. Thus Pierre's partial patch for this problem was waiting on the inclusion of my patch, but the latter first costed much time, then came Cinelerra 2.1, I ported over my patch but Pierre then had already started to work on his thesis -- and I and my friends are using my privately patched Cinelerra version ever since (and doing sound mixing in Ardour anyways, so the click isn't a problem). Well -- I really don't know how to proceed with this issue now... cheers Hermann V. PS: Pierre Dumuid also did the patch to have separate zoom ranges for the video/audio fade and the projector and camera, which resolves most of the handling problems connected with this -96dB range limit. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Interlacing, DVD
Am Dienstag, den 05.02.2008, 11:09 -0500 schrieb Aaron Newcomb: > ffmpeg -vcodec copy -acodec copy -r 25 -aspect 16:9 -i NAME.mov OUTPUTNAME.mov > > > > (this sets 25fps, the aspect ratio, and marks the video as interlaced) > > > I am not sure that this is true. The -deinterlace option in ffmpeg > will deinterlace video, but if the video you are starting with is > already deinterlaced I don't think ffmpeg with automatically add > interlacing. I am not sure if that is what you mean by this comment or > not. Aaron, you are absolutely right, I just copied this cmdline, but indeed it doesn't help at all with the original Problem, because the "-i" switch just means "input file" (silly me!) cheers, Hermann V. PS:: Btw, Raffa's original problem was: in spite of the video /data/ being rendered correct (i.e. in this case *interlaced*), the header of the created video doesn't contain the right flags, so the DVD player thought it was progressive and presented it that way, giving the well known artifacts. Raffa could verify in VLC (by explicitly choosing the somewhat hidden option "deinterlace/linear") that the video data indeed was correct (interlaced) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra 2 Tasks for Designer/Artists and casual Users:
Richard Spindler schrieb: > > > Example of poor Metapher: "Albert Einstein" for "Sharpen". Am Dienstag, den 05.02.2008, 18:02 +0100 schrieb Burkhard Plaum: I thought the same, but when looking at the "Unsharp" effect > and it's icon I laughed a lot. > me to, but, indeed this rather proves the point Richard wanted to make originally. The so called "unsharp" effect is the well known "unsharp mask", which is much more than a "soft" or "blur" filter. (In many cases you use it to /sharpen/ images) Its one of the most fundamental working tools and certainly nees a more grippy Icon. cheers, Hermann PS: in "Cin3" you will be able to organize Effects in subfolders, and save your grouping in the session, of course ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Tuning Video Playback
Am Dienstag, den 29.01.2008, 23:58 +0100 schrieb Terje J. Hanssen: > My available homePC w/Cinelerra on openSUSE 10.2 is an old, less > powerful K7 w/ATI Rage128RF graphical card, SB0312 Audigy LS (modern) > audio card, 512MB memory and a sliced 80GB Maxtor-5T060H6 hard disk. > > 3) VLC > Opens the file in a wrong 4:3 aspect window. > . > Is it possible to get VLC to open the file in a correct 16:9 window, and > preferably scale it to fit the display width? > Hello Terje, I did succeed to get the aspect right with VLC only by using the ~/.vlc/vlcrc file. VLC has configurable optionions for starting in Full screen mode and for preselecting a given aspect ratio and deinterlace method (and much more). You can either change these values via GUI and then safe the settings, or you can hand edit the vlcrc file (it's quite well commented but has tons of options). (As usual, being a hacker, I just have a shellscript somewhere and an assortment of vlcrc files for various setups (playing DVD, playing HDV, playing DV). I didn't do much research, but for me VLC was the /only/ media player capable to display the 1080i HDV footage correct, i.e. with increased framerate, so it looks as smooth as on an external interlaced monitor. You need the deinterlace method "linear" (doing linear interpolation of the missing lines, gives a slightly blurred look) or "bob". The other deinterlace methods have the usual 25Hz flicker (which many people praise as "real film look"). I saw smooth HDV playback with VLC in this setup on some Celeron Laptops (about 2 GHz + nvidia proprietary driver), but probably this will be to much for your machine. But maybe it works with the downscale you mention. Have you setup VLC to use the XV output? PS: VLC does the same smoth playback for normal DV interlaced material, but of course, here the usual artifacts are much more noticeable) Cheers, Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What is the Best Project Practice
Am Dienstag, den 29.01.2008, 23:03 +0100 schrieb Terje J. Hanssen: Loaded one of my listed video files (dv02.dv). Then it arised > automatically on the time line and in the Media map in the Resources > window. Created a working directory (mkdir /home/terje/cin) and tried > File>Save as /home/terje/cin/cintest1_dv02 > However, I couldn't find this file afterwards, just another "related" > file cin.xml in my home directory /home/terje. Shouldn't the first file > be created and why the latter? > I also tried just File>Save without any change. > Hi Terje, yup, there seems to be some inconsistency in the handling of the File Save dialog. (Can't verify it, because at work atm) > Is the above mentioned "Session.XML" a fictive file name or the real > file name? > In your case, the Session-XML file obviously got the name "cin.xml". (so, Session.xml was just an example) > cin.xml contained the real file path to where dv02.dv is located. > yes, because it contains all you did within your session. You can start cinelerra from prompt by "cinelerra cin.xml" to re-open this session. For me, this is the default procedure to fire up cinelerra on an alredy existing session. I started Cinelerra again. At first there was nothing on the timeline or > in the Media map. Tried File>Load Backup and the dv02 file arised on the > timeline and in the Media map. > In the "Open File" dialog box, there is a dropdown at the bottom to define the "replacement stategy" (I don't recall the exact wording). Because you can choose to add/insert material in an existing session, replace your session with the new content or just create new resources in the "Media" folder. You need "replace current session" if you want to open an existing session from within the application, and you I find it best to use "create new resources only" if I want to add new media files to an existing project. > Where are these listed "video file pointers" possibly located and how > to reset the list when starting a new project? - technically they are located within the Session xml file - you get new Media entries by loading media, but using "create new resources only" - you can remove them by right click on an entry and "remove from project" To create a new project, fire up cinelerra, choose project format, then use "save as", select as file type "XML" and a name. Then at least you should get your XML file somewhere (ha ha ha). You can move it to the right place and copy or rename it as you like, cinelerra won't bother (but when moving to another directory it can't find any resources by relative path, of course) If I recall right, you even can fire up cinelerra with an not-yet existing XML name to create a new session in the current directory (?) Cheers, Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] "Cin-3"
Am Dienstag, den 29.01.2008, 21:27 +0100 schrieb Richard Spindler: 2008/1/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > You should note though that the individual render node *must not* hold > > any time varying data because of thread safety. Any data will be passed > > in as "frames" (video, audio, control data) with the individual "pull" > > calls for rendering. The render network is shared, and the backend needs > > complete freedom for pulling rendered frames as it sees fit. > > Problems to keep in Mind: Richard, obviously you didn't get my point... > * Requiring Plugins to provide random access to frames is nice in theory, but > in > practice, many iterative Video Filters exist and produce nice Visuals. I wasn't talking about "theory" but pointed out, that in our current design the render nodes themselves are stateless, and get a context passed in. If we find that we need to support sequential processing, then this has to be organized via the context... > * Complete Separation of UI and Plugins is nice in theory, but in practice, > you might want to attach additional UI relevant data to an Effect. Again, I wasn't talking about "theory" but pointed out we need to accomodate for pasing some opaque data owned by the upper layers... Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] "Cin-3"
Christian Thaeter schrieb: > > I'd rather separate plugin rendering functionality, parameter passing > > and the gui. > Am Dienstag, den 29.01.2008, 19:11 +0100 schrieb Burkhard Plaum: > IMO GUI and rendering can (and should) be separated. But > - parameters are affected by the GUI > - rendering is affected by parameters > - parameters can change during rendering > > For rendering we already concluded to use gavl to pass data arround, I > > didn't yet checked if gavl has some provisions for passing > > metadata/parameters along, if not, this might be a nice feature someday. > > For passing additional data, you have 2 options: > ... Hi Burkhard, you are right, parameters can be tricky, because the different layers of the app need to cooperate. For the middle layer I used up to now interfaces "Param" and "ParamProvider". (Postponed any details for now). ParamProvider will be implemented by a automation data source while rendering and will be implemented by some connector to the GUI layer while setting up plugin instances. In our current design, the middle layer has the job to set up all connections (but never cares about the actual data types passed, as long as it can figure out what connections to make) and the render nodes never to any checks or configuration tests while rendering... You should note though that the individual render node *must not* hold any time varying data because of thread safety. Any data will be passed in as "frames" (video, audio, control data) with the individual "pull" calls for rendering. The render network is shared, and the backend needs complete freedom for pulling rendered frames as it sees fit. > If it turns out, that one priv pointer isn't enough, I can add a priv2 > pointer :) gavl never touches these anyway. this is fine because the other layers will for sure have some opaque data to pass along here too (and it wouldn't be wise to define everything to the last bit now before even kowing what the upper layers will need) > > Distributed plugins which just do the work on a renderfarm will just > > work, the GUI is only needed for the front node where the user sits. ...and this includes marshalling parameter/automation data over the network. The middle layer will be able to work in a "headless"/scripted setup too, including all editing operations. cheers, Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: "Cin-3"
Hi Matt, your post contains some points about "mindset" I want to respond to -- especially with regards to "Cin-3" The Project? Some days ago you saw the first quasi-official mention on the ML. It is just emerging as a project, and it /will/ be a project separate from Cinelerra. It started out by some devs worrying about the state of Cinelerra-2 project and code base. We first tried the "patching and repairing" aproach, then the "rework some subsystem and bring in a new spirit" aproach and -- now it evolves into a separate project. Note: I don't blame anyone, I just say, this is what happened. 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 connection to Cinelerra, because we are part of the community, use it for our editing work (and will continue to do so). Moreover, some hint in the name connecting it to "Cinema", "Film", "Video", "NLE" and "Linux" seems to be a good idea to start with. ( and it should be female :-P ) > 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 > "Cinelerra 3" in the discussion of what official name to give it. It's > clear that in people's minds, it *is* Cinelerra 3, and the result of the > naming discussion won't change how it's thought of. Can you tell me please what's depressing with that? 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 such a ambitious project 10 years ago from scratch? - Cinelerra can work with uncompressed material, and enables you to work on MPEG material (eg. HDV) as a source format (not a delivery format!) - 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. - Cinelerra has an compositing engine seemlessly integrated into the normal workflow. Together with the automation facility, you can build quite advanced processing chains "right in there" out of basic building blocks (including the "pull" principle for rendering) I don't want to loose this power and I don't want to change the fundamental approach with regards to this points, and I don't see any reason to be ashamed of following this route. I understand, that from a users POV, you may not find much "killer features" in our new project to start with. We even postponed GUI discussions. We just want to unleash the power by removing obstacles. The developer may note though, that this isn't possible without reconsidering, reworking or even building from scratch almost all core parts of the application, because the problems Cinelerra is suffering from are not like "things" laying around and waiting to be spotted and removed. By following this route we will be able to build some real advanced features on top of it later on, to make it really open for all sorts of extensions and to provide the guidance features and safe presets Cinelerra is lacking, without the danger of limiting advancedd uses. Cheers Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] HDV workflow questions
Hi flavio,
at the moment, I'm at work and can have just a quick glance at the
problem. Seemingly the two attached xml files are identical with
respect to the semantics (the python script changes the order of
the attributes, but this doesn't matter in xml).
I've made the necessary changes manually with a text editor
and attached this manually modified xml. Can you please check
if this now uses the proxy clip for you?
I did the following:
(1) at the bottom, in your video track, change
FILE SRC="cam_flavio2.avi"
to be:
FILE SRC="cam_flavio.toc"
(2)
in the same video track, apply a scale=2.0 to the camera automation default
keyframe:
changed to be:
Am Mittwoch, den 21.11.2007, 11:25 -0200 schrieb flavio:
> Right, all that to say that the script worked when I modified that,
> but I'm not sure if it really really worked because
> I'm sending both files atached and this was the output I had:
>
> [EMAIL PROTECTED]:/mnt/hdb1/flavio/temp/seychelles no mis$ ./proxychange.py
> 01_teste_proxy.xml -from 'proxyfiles/(\w+)\.avi' -to 'hdv/\1.toc'
>
> ['./proxychange.py', '01_teste_proxy.xml', '-from',
> 'proxyfiles/(\\w+)\\.avi', '-to', 'hdv/\\1.toc']
> read session 01_teste_proxy.xml
> transform args={'doAudio': False, 'regExp': <_sre.SRE_Pattern object at
> 0xb7e07e20>, 'scale':
>
> 0.5, 'template': 'o', 'doVideo': True}
>
there seems to be an error already in the documentation. The "GNU getopt"
library I use for command proccessing accepts either short
options with one dash or long options with two dashes.
Here, the script seems to interpret the "-from" as option "-f" with
parameter value "rom", which it obviousely can't find in your session
- and thus the script doesn't change anything :-)
In your second command line, there is a single, unbalanced double quote
at the end, and because of this, your shell prints the ">" in the next
line and expects further input.
Given your session file, I would guess the commandline should be rather
as follows:
./proxychange.py 01_teste_proxy.xml --from 'cam_flavio2.avi' --to
'cam_flavio.toc' --scale 2.0
The example in the documentation uses a "regular expression match" to
do an automated transfroming with several different media files, where
the original media reside in subfolder "proxyfiles/" and the target
media reside in subfolder "hdv/". In the above command line for your
session file, I gave you a simple search-and-replace...
My apologies for all the hassle! I would be much more happy, if we
could just code a simple dialog box into cinelerra and the App would
handle all those details internally
cheers,
Hermann
01_teste_proxy.modified-manually.xml
Description: Binary data
Re: [CinCVS] HDV workflow questions
Hi Flavio,
the whole thing with the python script is just a quick-n-dirty hack to
get some sort of "proxy editing". I wrote it to be able to handle a larger
project in HDV, since Cinelerra doesn't support proxy editing natively.
Basically it just automates some search-and-replace I did
first using a text editor.
Since I am a coder, I considered to build it into Cinelerra itself of
course, but soon realized (again) this would be a major pain, because
Cinelerra internally hasn't anything like a component model, extension
points or similar "architectural stuff". Well, that's another story
(and you probably noted the "Cinelerra-3" project Cehteh and I started
to rework some internal parts of Cinelerra to improve on this situation).
So, to explain this workaround with the python script:
- you create proxy clips from your footage (using some external app)
- you load the proxy clips into your Cinelerra session as well, so
for every Media you have an full res entry and a proxy entry within
the same session.
- at the bottom of every Cinelerra Session XML is a section, which
contains your actual video and audio tracks and the clips on them.
Each of this clips referes to some media entry /by name/
- so, basically all we have to do, is to exchange this reference link,
i.e. replace the name of the proxy media the name of the full
res media in every clip on your video tracks.
- now, because the proxy clips are smaller than the full res clips,
some means to enlarge the proxy clips when displaying them would
be nice. I used the camera automation for this. And to help with
it, we have the "--scale" parameter in the script.
Am Montag, den 19.11.2007, 13:37 -0200 schrieb flavio:
>, making the XML that has been generated by cinelerra point to the
>original
>HDV clips and to a HDV project. The python script whose link is at the manual
>would then do this last part, of changing the XML and creating a backup of the
>original XML file.
>
generally speaking this is correct, but note: the script doesn't create
new media entries for proxy/or full res media. It works only, if you
have already loaded fullres and proxy version of every media into your
session.
> [EMAIL PROTECTED]:~/Desktop/testes hdv$ ./proxychange.py cinelerra.xml -from
> `proxyfiles/(\w+)\.avi` -to `hdv/\1.toc`
> bash: command substitution: line 1: syntax error near unexpected token `\w+'
>
> bash: command substitution: line 1: `proxyfiles/(\w+)\.avi'
> bash: hdv/1.toc: Arquivo ou diretório não encontrado
>
what makes me suspicious here is the fact that your shell ("bash") has
anything to say here. Did you really use single quotes to enclose the
"--from" and the "--to" parameters? It is best to use single quotes
to prevent your shell from expanding or substituting anything here,
because we just want to pass on the regular expression patterns
unmodified to the script.
> Minidom wird gehackt
you see, I should really clean up the script and remove my german
debugging messages... :-P
...
> read session cinelerra.xml
...
> File "xml/dom/expatbuilder.py", line 207, in parseFile
> xml.parsers.expat.ExpatError: not well-formed (invalid token): line 17,
> column 99
>
This just tells us that the XML parser (Expat) called by the python script
bails out. He can't parse the Session file, because it is not 100% legal XML.
This is a notorious problem; cinlelerra uses a homebrew XML parser internally
and understands its own session files just fine in spite of them beeing not 100%
legal XML, but modern library parsers are quite picky (and it is a good idea to
be
pedantic with XML). Last summer, I made a patch to fix some of the often
encountered errors in cinelerra's XML, but obviousely there are still more
of them to discover :-)
So, please look in line 17, column 99 of your session XML what's there!
Sometimes it's some character encoding problem, sometimes its a missing
closing tag or missing quotes.
> This part is not working but I could eventually edit the XML manually. I
> tried
> using the program meld to see the differences between a HDV and a DV project
> files to see where I would have to change them in case I had to.
Basically, thats a good idea. Knowing what's going on is helpfull for
using this hack altogether.
Make a simple new Session, load just 1 HDV media and the corresponding
proxy media. Delete everything but 1 single video track and place one
single clip on this track. Save it and look at it in the text editor
to understand the structure. You should find your video track at the
bottom, and you should see how it referes to the media entry
Cheers,
Hermann Vosseler
(aka "Ichthyo")
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Am Montag, den 12.11.2007, 20:08 + schrieb mark carter: I'm wondering to what extent you think extern libs might help (hopefully > the answer is "a lot"). > yes, I think so, it will greatly help reducing the overall size of "cinelerra > code" I'm presuming that Cinelerra grew up in a world > where there was a paucity of such libraries - so had to do a lot of > things itself. When I looked at the code that does the reading, I > couldn't help thinking that "there's too much of it", and appears to be > handling a lot of stuff that I might expect an external library to deal > with. .. > my judgement too... Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Am Montag, den 12.11.2007, 19:08 + schrieb mark carter: , but some people > argue against git and in favour of svn, claiming that the whole idea of > priviliged checkin is not such a bad idea. > Obviously, some people don't seem to get the point with GIT: It is up to /you/ to define your policies as you see fit, and GIT will support it :-) If someone wants "privileged checkins", this just tanslates to arranging for one specific branch at one GIT repo to represent the "privileged truth", so every merge to this branch will be a privileged checkin... Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
2007/11/12, mark carter <[EMAIL PROTECTED]>: > > ... As you guys will no doubt be aware, I had created some > > patches for Ficl, and left cinelerra alone for some time. When I tried > > to apply the patches to a later version, there were quite a few > > conflicts. Backed up from my other (limited) experiences with revision > > control systems, I came to the conclusion that conflicts arise really > > fast. Mergability is a real problem. I guess Linus must be some kind of God. > Am Montag, den 12.11.2007, 17:25 +0100 schrieb Richard Spindler: I think this depends on the project, most code in Linux are propably > device drivers, that can be developed independently without > interfering with others. > Yes, it depends much on how the code is organized. In the current Cinelerra codebase, you get mergability problems very fast, as soon as you try to "rework" anything, as opposed to just patch small changes into existing structure. So anything that is not so small, localized or trivial as to be accepted into trunk very fast, is strongly discouraged. In my oppinion /this/ is the root of the problem which looks from users view as if "developers don't care for users needs". Ideally, a sourcebase should be decomposed into several, not-so-strongly coupled subsystems, and every coupling should be made explicit via interfaces. Then, for example, if you start your-favorate-new-feature project as a new subsystem, maybe needing this and that addition to other interfaces, and you get distracted and come back a half year later, all you have to check in order to get up-and-running again, is for modifications to the interfaces you used... cheers, Hermann Vosseler PS: and you can take it for granted that we try to get into this direction with our cin3 work... ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build SVN version on 64bits PC - error in libavcodec inside ffmpeg
Am Sonntag, den 17.06.2007, 11:28 +0100 schrieb J.P. Casainho: On the last 2 days, I tried to build Cinelerra on my new 64bits system, one > Core 2 Duo from Intel. > > I always got this error: "/usr/bin/ld: > ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): relocation > R_X86_64_32 against `a local symbol' can not be used when making a shared > object; recompile with -fPIC > ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o) ..." > > I tried with option "--with-external-ffmpeg", but got another error later :-( > > Hello, yes, thats a very common problem on 64bit systems. See my other mail "Compiling problems, Debian, AMD64, -fPIC" some weeks ago (with a patch). Base line is: obviosely, generating PositionIndependentCode for a thing like Cinelerra doesn't make much sense, thus the inclination to compile with -fpic. BUT, you link against lots of system libs, which are commonly build with -fPIC (because thats just what PIC is for, shareing lib objects in memory...). So for practical reasons you want to compile *everything* as PIC, and to be successfull, you need to make the small change to the internal ffmpeg subdirectory, otherwhise you won't ever be able to link. > Note: I already build several times on my old i386... and I did build the > same > version in my this new system, but, in a Linux Ubuntu i386 version instead of > the 64bits version. > does this mean you are on a debian or ubuntu system? Then you could check out my "private" debian/ubuntu package which I setup last week. I would be glad if someone tested it, so please tell me if interested. Cheers, Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SoC 2007
Il giorno mer, 07/03/2007 alle 01.36 +0100, Andraž Tori ha scritto: > > On Wed, 2007-03-07 at 01:21 +0100, giskard wrote: > > > hello, > > > > > > it's a long time i don't contribute to cinelerra,but i'm always > > > interested in it. > > > > > > Yesterday i wondered why cinelerra cannot be part of SoC 2007 (SoC as > > > in Summer of Code a project sponsored by google) > > > > Why not, we could... Kiberpipa can be mentoring organisation, and myself > > and JohannJohanneses Sixt and maybe someone else as mentors... but the final > > decision is on google... > > > > > I have some ideas, but for most of them i can't be the mentor (maybe for > > > all). > > > > > > 1) write a GUI in gtk2 > > > > this is wy beyond SoC project > > > > > 2) re-write cinelerra-cv as a modular program > > > > I was thinking about smaller scale projects... > > > > > we have to decide if partecipate or not to SoC 2007. > > > > i am all for it > > Am Mittwoch, den 07.03.2007, 17:34 +0100 schrieb giskard: > ok! cool ! > i will start reading SoC docs, Johannes (and * project guys) do you are ok? > > > > Yesterday i wondered why cinelerra cannot be part of SoC 2007 (SoC as > > > in Summer of Code a project sponsored by google) > > > > Why not, we could... Kiberpipa can be mentoring organisation, and myself > > and JohannJohanneses Sixt and maybe someone else as mentors... but the final > > decision is on google... > > > > > I have some ideas, but for most of them i can't be the mentor (maybe for > > > all). Il giorno mer, 07/03/2007 alle 01.36 +0100, Andraž Tori ha scritto: > > I was thinking about smaller scale projects... > > hello Andraž, hello giskard, what's with handling interlaced internally? wouldn't this be a "smaller" project? Somthing along the following lines: - you have e.g. 50i material - you swith the project framerate up from 25fps to 50fps - any 50i clips now "emit" 50 frames per second while doing some clever interpolation - all the rest (all plugins, transistions, masks, keyframes, the whole video pipeline need not be modified) - you render your project immediately into a pipeline with 50fps and handle the re-assembling to the final delivery format externally Cheers, Hermann V. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
Am Mittwoch, den 07.03.2007, 10:20 +0100 schrieb Christian Thaeter: Finally I found some time to look at some cinelerra bugs. Cinelerra use > quite some own things.. > I believe the code complexity could be lowered by replacing some > things with standard or defacto-standard libs rather fixing the problems ... Hello Christian, I am much in favour of the cleanups you propose, indeed, many aspects of cinelerra source are hard to work with... but, as I see it, the main problem is: will such changes be accepted "upstream"?? If not, we will end up with a de-facto code fork. (I state this without intending any pun or hostility). /If/ we wanted a completely forked "Community-Cinelerra", we would need much more dev manpower Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] external firewire drive
Am Montag, den 16.10.2006, 17:40 -0400 schrieb Wesley T Allen: And I was leery of Maxtor and Seagate because I've had drives from both die on > me - but samsung? Really? Wow, the world changes > > Wes > ...I am using 10 Samsung HDD about 2 years now and without any probs. This drives are really silent and (other than my Maxtors) never failed. Of course, things can change rapidly -- it could as well happen that you get crap if you buy Samsung today, you know only if you try :-) Speed? I can playback HDV MPEG-TS stored on them in vlc without problems via USB 2. In Cinelerra I get about 20fps playback (without any transitions, effects etc of course) on a AMD 64 X2 machine. Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Bezier automation
Am Mittwoch, den 23.08.2006, 21:41 +0200 schrieb Nicolas: > OK. So, if I open a "made with the patched version" project with the > "normal" 836 version, only the way the input and output points are > displayed would be changed, wouldn't they? > exactly > Your patch is *REALLY* important for me. That's because I work on a long > video which will contains around 1000 keyframes. same for me > However, that project is a "long term" project. It'll be finish in > around 2 months, but I have to be able to edit it again in some years. Same for me, also a "long term" project. I'm determined to use the patch myself and I will try to get it into the official codebase, if this is possible. So you can count on me! Cheers, Hermann, Munich, Germany ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Bezier automation
Am Mittwoch, den 23.08.2006, 20:31 +0200 schrieb Nicolas: Could you please explain the syntax to apply the patch? I'm not familiar > at all with that command... > > Hello Nicolas, patching is simple, you just feed the patch to stdin of the patch command. The only complication is the "-p" parameter, which ist necessary in almost all cases. Its purpose is, that the patch command can find the target files it has to patch on /your/ system. As a reference, it usess the paths and filenames provided in the patch file, but it removes a prefix from each given path before it tries to find the target file on your system. There are examples in the manpage, but -- actually in this case, it is simple (I just wrote the explanation because I never like people doing things "blind" without them knowing at least a bit of what is happening) OK. You have the *.zip file containing the patch. 1. go to the root directory of your cinelerra source tree (i.e. the directory containing the cinelerra/ guicast/ plugins/ and debian/ dirs) 2. unpack the zip from there: unzip bezier_patch-1hiv20060818.patch.zip as a result, it should place the four new png files into the plugin/suv/data etc... dirs and it should unpack the patch itself in the root of the source tree. 3. apply the patch with patch -p 0 < bezier_patch-1hiv20060818.patch he should report just that he is patching some source files, but no errors and no additional questions. If something fails at this point, then please mail me again! 4. build and install You wrote : > > One final word to the compatibility ... > ... > if you afterwards open a session file edited with the patched > > Cinelerra in a old version of Cinelerra, your control points will > > again show up in the old (strange) way, but with their horizontal > > position reset to zero, i.e. they will show up exactly above and below > > the corresponging automation node. > > Does that mean the curves will be transformed into straight lines? > No, the curvature of the line is retained, only the display of the control points is messed up slightly. The explanation why this is the case is given in the manual section you cited: the way it is implemented in cinelerra, the /horizontal/ position of the control point is irrelevant, only the vertical position matters. > BTW, it's written in the official Cinelerra manual : > ... > While the input control and the output control can be > > moved horizontally as well as vertically, the horizontal movement is > > purely for legibility and isn't used in the curve value. > that's fine! I wasn't aware of this section in the manual. I always draged the keyframes horizontally and expected the curve to change, as I would expect it from a full-fledged implementation of bezier curves, and it seemed to change something (actualliy it didn't) an so I felt betrayed and got angry. This is, why I made this fact explicit in my patch: there you can only drag the points vertical. There is another reason why I changed this: if you can drag the control point horizontally as you like and this has really no effect (as it is in cinelerra up to now), the so called "tangent property" of bezier curves is completely messed up. This tangent property means, that the line from the node to the control point is at the same time the tangent on the smooth curve in this node, i.e. the slope of the curve at this side of the node. > This my English isn't very good, I miss the point... > please tell me, if I express myself too complicated. I'm not a native speaker as well, and (worse) I studied math some long time ago :-) and thus tend to express myself overly complicated at times ;-) Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] same problem - libquicktimehv/ libfaad/ libfaac
Am Mittwoch, den 16.08.2006, 20:48 +0200 schrieb Valentina Messeri: hi Kristin :) > > maybe changing your marillat repositories frm etch to sid can help ... Hi Vale, Hi Kristin, ...I don't think it is necessay to go to sid. I think, it's only the new address "debian-multimedia", so I would propose to try first deb http://www.debian-multimedia.org etch main (I myself got it from debian-multimedia etch) Ciao Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] same problem - libquicktimehv/ libfaad/ libfaac
Hello Kristin, yes, it seems to make sense: your Apt simply doesn't know where to get the libfaac0 package cinelerra requires. He knows only the official released version 1.24-0 which he can get from the old url of Christian Marillat's unofficial multimedia Repository. But Marillat is always moving from server to server, and now uses the new name "debian-multimedia" and got some additional mirrors. I guess, the old sites are no longe up to date (and will vanish at some point). See at http://debian-multimedia.org/ At the page bottom, there is a lot of deb-Urls and even a page with mirrors. Do you know how to add a repository to your Apt configuration (sources.list)? hope this helps Hermann PS: you can see by the output on my system, that I myself got the package from one of the new mirrors... ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Fixing the faders and automation lines
Hi Leo, Hi Pierre,
the last weeks, I spent quite some time on implementing a patch for an
issue closely related to this. So, I think it's great you want to
participate, and maybe we can join forces or at least I could assist
in understanding the code involved in rendering and manipulation of
the automation curves. :-)
To recap, I am in the middle of a large editing project and bound to
use the automation feature rather heavily, and I found it quite
cumbersome to use. It is nice we can have fades and pans, but given
professional needs, I found myself hand-editing the tangent of
almost every automation node, because some of the behaviour of them
is annoying at least. So I started a patch to improve handling of
bezier automation curves. See the Threads called "Bezier curve
alternative?" and "Bezier automation" about a month ago.
Meanwhile, I got interrupted by two sound recording jobs I had to
do, but today my patch is »almost done« and just needs some
polishing. Last week on irc, Johannes Sixt asked me if I could
port it over immediately to Cinelerra 2.1, so I didn't publish
anything new. But, of course, if there is interest, I could
produce a patch based on the "latest Version of Cin 2.0-CV"
(which is r836 in Subversion, IIRC), before the merging up
to Cinelerra 2.1 started.
Pierre Dumuid wrote:
> What really annoys me is at the moment, the ranges of the all
> automation curves (that control floating point variables) are
> currently shared, (i.e. the range for an audio track, typically need
> values from -80 to 6 dB), projector / camera zoom ranges are ALWAYS
> positive, and generally go from .0001 to 10, and projector / camera
> translation control are generally of the order of -1024 to 1024
> (depending on your image size).
...
> This I consider is the most annoying feature about automation curves
> and the one that should be tackled first. My proposed solution is as
> follows:
...
> dropdown text boxbutton
> [type] [ -100 to 100][log/lin]
>
> With this idea, each curve is of a type (zoom, translation,
> audiofade), and the range used on the track depends on the type.
I completely agree with you this is very annoying behaviour; basically
it hinders gaining any profit of the fact that several overlay curves
are sharing the same screen real estate: most of the time their scales
don't match and we are forced to display only one curve at a time.
But I'm rather sceptical if your poposal will make things better. Having
to navigate with the mouse down to the statusbar and selecting a type
and entering Values into the text box can be cumbersome as well.
Even the current solution seems more steamlined: We have the "overlays"
window with checkboxes for every overlay type and we have keybindings
for toggeling the most common curves. And we have the ALT-f key, which
even works in conjunction with the current selection in a track, i.e.
it bases the new automation vertical zoom range on the current visible
curves within the selection of the first armed track.
Pierre Dumuid wrote:
> I do want to say, that I currently LOVE the ability to manually set
> the limits of the ranges by typing the values in.
Absolutely. This is a strength of Cinelerra not to be sacrified.
E.g in ardour, the current value of an automation node or segment
is shown as a hint while dragging, and the values are quantized to
0.1dB. Getting a segment constant to say exactly to -6dB can be
quite a challenge...
Leo germani wrote:
> Plan A:
> Build Ardour-like automation tracks: it means you would have,
> on the left panel, the option to show or hide the automation tracks
> of your choice, wich would be subTracks of the track you are working
> in. On this track all you see is the automation line of the selected
> automation (fade, CameraX, etc...). You would be able to see one or
> as many automation tracks as you like at a time. I think this is the
> best way cause also opens the door for, later on, someone add all the
> effects to this. For example, the PluginKey frames could migrate to
> the automatinoLine style. So I could automate, lets say, the HUE
> parameter of the Color Balance effect.
And we should add, the handling of the mouse wheel in conjunction
with SHIFT, ALT and CTRL is very nicely done in ardour.
But, without wanting to dilute your proposal in any way, we should note
this approach gets cumbersome rather quickly at larger projects. Given a
typical Session (classical music, medium sized orchestra, some singers),
I find myself soon scrolling up and down through tons of automation
tracks, either beeing forced to orient myself all the time ("what the
heck is the track I'm currently in here), or forced to decode which
parameter of which plugin to select and to show and hide, beeing rather
distracted from listening and working with the sound altogether.
What I am dreaming of would be sort of "View Combinations"
(similar to the free combinations of stops found on large pipe organs):
They would be freely configurable and c
[CinCVS] Re: Bezier automation
Hi Andraz, just missed you on irc. :-( The Alt-thing I can do, shouldn't be difficult and just in there where I am mucking around all the time... I don't know what to say as far as "factor 2" is concerned. My goal of course was to get things as simple as possible, from a programmers POV :-) But the state cinelerra is in (I mean with no real "up-to-date stable version" compatibility between versions is also a value. > - the changing should also be available in the "?" window >in the compositor don't quite understand you: what changing do you mean: the changing of node tangent mode (smooth-linear-free)? For camera and projector auto only? bye Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Any recommended x86_64 distribution for using cinelerra?
> On Tue, 6 Jun 2006 11:16:56 +0200 "Helge Nert" <[EMAIL PROTECTED]> wrote: >>I have had huge problems getting cinelerra to work on my FC4 x86_64 >>platform. > Dimitrios wrote: > I'm still learning cinelerra, but i haven't had any problems related to the > distribution. I'm using Fedora Core 5 x86_64 with the latest RPM packages of > cinelerra published by freshrpms.net (which handles all dependencies). > Hello, ever considered to have a look at Debian? Since last fall, when I built up my new system for sound and video editing at home, I am a big fan of the way Debain manages packages, building and debendencies. OK, RedHat, SuSE and the like are RPM based systems and if you know one, you can handle all. Debian is different, so there are some things new and to be learned. For my PC, I started with http://64studio.com/ a distro specially designed for music and multimedia work on 64 bit platforms, which is based on Debian/testing. For Cinelerra there are Debian packages provided rather frequently, as the source tree in SVN is almost a complete debian package. Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: projector y motion with interlaced dv footage
Alec Robertson wrote: > I have NTSC DV footage for which ... > I can use the projector y-motion to center the subject vertically ... > But, I noticed that when I then do a frames to fields that the interlacing > order changes between successive fields. This is as one would expect ... > Is there a way to preserve the interlacing under such conditions? Hi Alec, as far as I can see, there is no easy workaround. (We encountered the same problem in our project). You can take two different approaches: 1) if it's clear that the final product will be progressive (e.g. if you plan to make a movie for internet distribution with low bandwidth), than you can throw away the additional information contained in your interlaced footage by applying a deinterlacer and working on the deinterlaced material. 2) if you want to preserve the interlacing (e.g. if you want to watch the final result on a tv screen) and you want the effect in high quality, then the only way doing soin cinelerra is to extract the fields to separate frames with doubled frame rate, i.e. you render your footage with fields to frames effect to a intermediate movie clip with doubled frame rate. Then you apply your pan/mask/whatever effect in a separate cinelerra session which runs with doubled frame rate and finally you reintegrate your processed footage by using the frames to fields effect. hope this helps, Hermann PS: Note that "progressive" was sort of a buzzword in the last years. This doesn't mean that progressive is "always better", only under certain circumstances :-) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Cinelerra with shared Libs
Eddy Nigg (StartCom Ltd.) wrote: > Current Cinlerra version 2.0 can't be compiled on FC5, and may patches > have to be applied to various libraries (Faac, Faad, Libdv etc). I did > not got to the point yet to compile cinelerra itself, because I would > prefer that it would be linked to the system libraries and not the libs > provided in the cinlerra package. I wonder, if there are a few tips for > doing that, before I kneel into this and do it by ourself. Hi, supposedly you are refering to the "official" Heroine version of cinelerra 2.0 from october 2005. You may want to have a look at the "unofficial" community version at http://cvs.cinelerra.org/ , because this one is to be compiled and linked against the system libs (and besides the recent versions have much improved stability and some nice productivity enhancements as well). Regards Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Cinelerra generating files that ffmpeg can't read
valentina messeri wrote: > avi or mov, are container, but dv, afaic, is a lossless > codecalthough tiff is "losslesser" no way > dv is lossy, IIRC, somewhat similar to M-JPEG, where every frame is compressed seperately, in contrast to MPEG, which treats groups of frames... yuv is lossles, of course :-) Other examples for really lossles formats are OpenEXR, PNG sequence, ... But if the original footage has been shot on DV, it /is/ compressed alredy, and so, in most cases, a "slight lossy" format like DV or M-JPEG (with high quality setting) deliveres just fine quality. Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: Cinelerra under debian testing
Piotr Legiecki wrote: > But wonder if I can make clean (not to force > dependency problems with packages) cinelerra install under etch? It > should be not very complicated (just one force-overwrite on the > libmpeg3hv_1%3a2.0.0-1svn20060213_i386.deb): > basically it is not very difficult. Ok, you need some "unofficial" repository, like "marrilat" or "debian unofficial" IIRC. At the moment things seem to be a bit complicated with etch. (I am using "64Studio" and "DeMuDi", both based on debian testing) Currently, we can't install the simplest things as there are some required libs (notably form kde) still not in testing. So at the moment, you either have to fiddle with Apt-Pins and use unstable or need to be patient. > Is it stable enough to use it without frustration? stability has been largely improved in last time. Im using it heavily and generally didn't entcounter any serious problems. Of course, cinelerra has the habbit of simply crashing when you do something obvious silly, it never bothers the poor haunted power user with spurious mesage boxes or step-by-step-recovery wizards :-) But there is a reliable auto backup feature (importand: the really first thing you need to do after restart after a crash ist "load backup" form file menu) With respect to frustration I can't promise you anything. As with most any pro software, you probably get lots of frustrating experiences if you think a "normal" application should behave as if it was microsoft word. You should really read the manual completely and try to understand what's written there. Cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: understanding chained tracks
Andraz Tori wrote: > For changing the order of overlays, you could use overlay plugin... Hi Andra, as you are mentioning it Yesterday, I didn't manage to get any visible result by this plugin, but I couldn't figure out what exctly it is doing (even by poking into the source :-( ) - do I need always to share this plugin between exactly two tracks? - what does the setting "ouput to top/bottom" mean? - what happens with the original output of the tracks? maybe you could give me a hint? thanks, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] understanding chained tracks
> On Wed, 8 Feb 2006, Andraz Tori wrote: >>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... > [EMAIL PROTECTED] wrote: > 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. this was one of the points that puzzled me. Because this feature seems to combine several things, i.e sharing the plugins in "backwards direction" and at the same time sending the output in "forward direction" from track A to B. This seems a bit limiting, but there are workarounds: - if I am not interested in the "plugin and mask sharing", I can mute the "source track" (track A) and only use the overlaid output on B - if I am not interested in the shared output then I can hide it by using the normal track overlay: lets assume, track A is below and track B is above. If the overlay mode of track B is set to "normal" or to "replace", it will cover and thus hide the redirected output of track A (because it is calculated later and the redirected output is overlaied first, when calculating the data of track A -- did I guess this explanation right?) cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: understanding chained tracks
> On sre, 2006-02-08 at 20:15 +0100, [EMAIL PROTECTED] wrote: > I am somewhat puzzled by the behaviour of "chained tracks" ... 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... > Hi Andra, Ah, I see, this makes perfectly sense. Chained tracks seem to be an advanced feature overloded with several possible uses - sharing a processing chain on different material - deriving and overlaying different versions of the same source footage - accumulating several masks from different tracks - changing the order overlays are output to differ from the order of the tracks further possibilities? cheers, Hermann ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] understanding chained tracks
Hi all, currently, I am exploring cinelerra's features (we are at the start of a large editing project). I am somewhat puzzled by the behaviour of "chained tracks" (is this the right term) when doing compositional work. Maybe someone can confirm if I did grasp the following correctly? My understanding is that I can use this feature in a chain of plugins on a track in order to derive a partially modified version of this track and overlay this on another track. A possible use (I am thinking off at the moment) would be, to blur and tint the image near the border of a mask (where the border of the mask is heavily automated with keyframes). Lets asume, we have the source footage in track "A". I can then select and chose a shared track (context menu of the track or "change.." in the context menu of a plugin placed alredy in track A). So I can select "track B" and get the display as if adding another plugin to track A. I can even reorder this "track B" with other plugins like -- say "flip". Everything nice so far. At this point, the contents of track A as processed in the plugin chain up to the point where the "track B" entry is inserted, appear overlaid in track B, according to the overlay mode of track B (e.g. "additive"). This ist what I would expect. BUT, at the same moment there is a "strange backlash": all plugins as well as the mask of track B gets inserted into the processing chain of track A. (at exactly the point where the "track B" entry sits) E.g. if I add a "color balance" to track B and use this to color track B heavily green, track A gets colored the same way. Is this intended behaviour? What is the rationale of such behaviour? OK I can get away by muting track A, but I like to understand the idea behind... Btw: I am still using the heroine 2.0 version of cinelerra (but I plan to try out the newest svn as soon as I get some time) cheers, Hermann Vosseler ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
