[CinCV] Announcement from Michael Collins (the new registrant of cinelerra.org)
** Michael Collins asked me to forward this to the list ** To all Cinelerra List members: March 8, 2014 We intend to rebuild the user list and efforts through the establishment of a collaborative network on a new site design oriented towards modern development collaboration and messaging methods. If you have anything you wish to do with Cinelerra in the near and planned future, let us know: l...@cinelerra.org Please feel free to contact me through this e-mail or through a new list being established to be merged with the old list. My direct e-mail is michael.coll...@cinelerra.org Yes, my methods are for communication is a little different, but, I am open and willing to listen and to collaborate. So, if you have any ideas about tools, UI, networking, kernel coding, marketing, sales, user support, developer support, web site, or anything you can think of and is important to you, let me know. My direct e-mail is michael.coll...@cinelerra.org Thanks Mike Collins skype is michaelalancollins2 google is michaelalancollins ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
Re: [CinCV] Sincere thanks and GIT Repo links needed
(cc-ing to sender, as the mailing list can lag several days!) På Wed, 05 Mar 2014 17:31:30 +0100, skrev MGV-AV Linux i...@bandshed.net: Hi, I realize that CinelerraCV is in a real state of flux right now and there is so much to do and too few to do it. My sincere thanks to Christian, Raffa, Rebecca, Herman, Bhikkhu and any others I have missed doing their best to pitch in and help. :-) I can't seem to get working GIT URLS to either Monty or Einar's branches and would very much like to build and help test them. Can you get to this? http://git.cinelerra-cv.org/gitweb?p=einar/cinelerra.git;a=summary Monty's branch in particular gives me all kinds of weird GIT authorization errors. You mean the one hosted on xiph.org? http://git.xiph.org/?p=users/xiphmont/cinelerraCV.git;a=summary If nobody has time to fix them on the site itselfI would appreciate someone replying to this email with current working links. Sincere thanks, Glen MacArthur - AV Linux Maintainer If you need some hand-holding you may hail the #cinelerra IRC channel of the Freenode network. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
Re: [CinCV] wtf old cinelerra.org
På Sun, 02 Mar 2014 12:25:39 +0100, skrev Christian Thaeter c...@pipapo.org: Who holds cinelerra.org now? adam? It's Michael Collins. I got an e-mail from him yesterday. I think he wants to help. I'll tell you more when I know more. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
[CinCV] New domain: cinelerra-cv.org
(The list server keeps bouncing e-mails from Raffaella, so I'm resending this, hoping it won't bounce my e-mail...) Date: Wed, 15 Jan 2014 23:01:18 +0100 From: Raffaella Traniello raffaella.tranie...@g-raffa.eu To: Mailinglist for Cinelerra, the community version cinelerra@skolelinux.no Copy (Cc): broadc...@earthling.net Subject: New domain: cinelerra-cv.org Hi! Since it was difficult to restore the cinelerra.org domain (now in a limbo: expired but not yet available), I followed Richard's suggestion and registered a new domain: cinelerra-cv.org. I think this domain is more representative of the community version and it mimes exactly the package name. Some consequences are: - We have a lot of links to fix - cinelerra.org will become available in a month or two and could be used for the original project at HV, in case Adam is interested. I'd be happy to pay and maintain this domain too. Ciao! Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
[CinCV] Have you had problems posting to the mailing list lately? Please tell me!
** Have you had problems posting to the mailing list lately? Hi, I'm Herman Robak, the CinCV mailing list moderator. Since December last year, the cinelerra at skolelinux.no mailing list has been hosted at a new server, and mail delivery to the list has been ... erratic. :-( Some subscribers complained or asked if there was something wrong early on. I suspect many more tried, but did not get through. Apparently it has not gotten better. If you have had any problems getting through to the mailing list this year, please tell me about them, briefly. If you got bounces or error messages, please summarise them to me. Send it to my personal e-mail address, not to the list, please! My email address is herman.robak at gmail.com. Every e-mail I receive about this problem before the end of this month (August 2013), I will reply to. Usually within a day. Failing that, you may send a memo to me on the Freenode IRC network. My nick there is hermanr. -- Herman Robak herman.robak at gmail.com ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
[CinCV] The mailinglist went down in December. Should be back up again now.
The migration of the CinCV mailing list to another server had some ... issues. It's supposed to be back up again now, but there may be some glitches still... The list info has moved to lists.skolelinux.no: https://lists.skolelinux.org/listinfo/cinelerra -- Herman Robak List moderator, for ten years soon. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://lists.skolelinux.org/listinfo/cinelerra
Re: [CinCV] Cannot solve this problem
På Wed, 21 Nov 2012 13:41:20 +0100, skrev Basil Chupin blchu...@iinet.net.au: On 21/11/12 23:12, Basil Chupin wrote: [ and applied the 'Grandma's Fix', Using the Graphical User Interface - WinFF, and then followed the instructions given there to convert the mpg file - ie, used Cinelerra intermediate formats and Select DNxHD as Preset. When I do that I get the following error message: Sorry about that. I didn't realise that the graphic would not be accepted here. However, the error message can be seen here: http://susepaste.org/25335932 720x576 DNxHD won't work, that's right. DNxHD is a very constrained codec. It only accepts two resolutions: 1280x720 and 1920x1080, and only combined with a fixed set of framerates and bitrates. Beware! I think there is a typo error or two in this table: http://www.itbroadcastanddigitalcinema.com/ffmpeg_howto.html#Encoding_VC-3 -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Video/Audi sync problem. Can anyone please help?
På Thu, 15 Nov 2012 05:07:42 +0100, skrev Basil Chupin blchu...@iinet.net.au: On 15/11/12 02:59, Herman Robak wrote: As far as I have understood, Audio Offset is for _calibration_, and nudge is for _correction_. Thanks for the response, Herman. Yep. As I mentioned to Einar, I wonder why it afflicts Cinelerra when all my tv programs, videos are all in perfect sync - or, at least, so close to being perfect that any difference is not noticeable. I don't know. Maybe Cinelerra has bugs that the other don't have. Calibration is per computer/installation, and correction is per project/format/track/clip. Now, if only there was a way to reliably calibrate audio/video synchronisation on a computer! I'd like a cheap gizmo, let's call it a Synchrophone, that has a simple microphone and a fast rate low-res sensor (one monochrome pixel might do). I like this idea! :-) Like a clapperboard but only in the form of software. You sound like someone who knows something so can you explain this, please :-) . Uh-oh... In the Cinelerra manual, page 23, instructions are given on how to calculate the audio offset. The part which really has me confused is this: Play the timeline from 0 and watch to see if the gradient effect starts exactly when the audio starts. It's a good idea to not use video and audio _files_, but rather use generated sound and video, eliminating codecs and file I/O. But it's still hard to align audio with video like that. The offset is supposed to be constant, not proportional with playback speed, so you can't check it at 1/4 speed. When exactly does the audio start - is it when the audio level meter appears on the right-hand side of the Compositor window or when the actual *sound* is heard (to match the appearance of the synthesiser)? When the sound is heard, obviously. Synchronising sound with another sound is easier, and can be FAR more accurate. Do you have a monitor that hums loudly when the screen is bright? Or some way to bleed analogue video (VGA could do, HDMI or DVI less likely) signals into one of the audio output channels? Wild idea: Covering everything but Cinelerra's audio meters with black windows, so quiet audio results in little or no screen buzz. a) Does the buzz sound like a pre-echo? Audio is too late! b) Does the buzz come like an echo? Audio is too early! c) Do the audio and the buzz seem in phase? Bingo! This could be used BOTH for the one-off Audio Offset calibration, and for the asset-by-asset nudge. (Hm, if this is workable, it might be worthy a test suite...) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Video/Audi sync problem. Can anyone please help?
På Thu, 15 Nov 2012 16:21:31 +0100, skrev Monty Montgomery xiphm...@gmail.com: (Hm, if this is workable, it might be worthy a test suite...) There's a reason for the historical CLACK! Action! Yeah, but then they had optical sound-on-film, so you could _see_ the clack peak on the soundtrack. Or you could run the audio slooowly through the player, back and forth, until you had homed in on the clack. Then you could set a crayon mark at that point. Same procedure with the film strip. You can't do that when you try to measure the offsets between audio and video outputs from the computer. The offset may be short enough to be hard to gauge manually, yet large enough to be disturbing. And you can't work around that by playing back and forth at low speed. Any significant offset will be detrimental when you line up audio and video manually, or try to correct synch drift in Cinelerra. It's like doing colour correction wearing tinted sunglasses. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Video/Audi sync problem. Can anyone please help?
På Wed, 14 Nov 2012 16:16:52 +0100, skrev Tom Judge tvju...@gmail.com: If my understanding of things is as I just mentioned then the use of the Audio Offset is a waste of time and one should simply edit a file with Audio Offset = 0.000 Not quite... and only use the Nudge facility to synchronise video/audio. Yes. Am I misunderstanding things? As far as I have understood, Audio Offset is for _calibration_,and nudge is for _correction_.Calibration is per computer/installation, and correction isper project/format/track/clip.Now, if only there was a way to reliably calibrate audio/videosynchronisation on a computer! I'd like a cheap gizmo, let'scall it a Synchrophone, that has a simple microphone and a fastrate low-res sensor (one monochrome pixel might do). It would plug into a stereo jack, with sound from the mic going to one channel, and "sound" from the "eye" going to the other.The host application would send flashes to the screen and clicksto the audio, and locate the matching peaks in the signals fromthe Synchrophone. If they are out of phase, that phase shiftis the Audio Offset.That gizmo has to be _one_ device, and if it's analog it wouldnot incur the timebase jitter due to buffering. The stereoinput is supposed to have all channels in phase lockstep, orelse stereophiles would complain loudly. ;-)Well, this was just me daydreaming. Maybe a project for a rainy day, maybe...-- Herman Robak
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 14:27:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: ... and presenting 0.0 as black and 1.0 as white internally is totally out of the question? No. :-) However, if black is 0.0, then super black would be negative, and hilarity ensues. So we have to make up our minds about what headroom and toeroom are for, how to use them, and how to represent them. With your proposed studio swing mapping most compositing and filtering operations have to scale and bias to work right. E.g. black + black + black will be a shade of gray, unless a bias is subtracted. Yup. I was suggesting it as something of a path of least resistance. For the record, we already have this problem with studio swing. After some reconsideration, I realised that the kind of black we are talking about here is black level black. Not the matemathical black hole kind of black. The black level isn't zero luma. It is below perceptible luma. And if you add three just below perceptible lights, you DO get something brighter than pitch black. This may or may not be what you want. My point is that the accumulation of noise or fog when you add several black level signals is the most faithful representation. Because unless they are synthetical, they will not be crushed/clipped blacks, but a noise floor. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 14:27:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: ... and presenting 0.0 as black and 1.0 as white internally is totally out of the question? No. :-) There is more. I can't see we have adressed what kind of black and what kind of white. * Aquisition medium black and white ? (e.g. from max density in the film emulsion to a clear base) * Display black and white ? (e.g. the monitor's brightness range) * Scene referred ? (From black hole to supernova, if you have bits to burn.) HDR computer graphics can be scene referred, and film scans will likely be media referred. They can be easily represented in full range inside the program, but at display time they have to be remapped to a range that the screen can manage. This remapping is typically lossy, often very much so. You don't want to do it at import time. Well, for some workflows you DO want that. But not as the default, right? This is getting hairy. Should Cinelerra have two modes or workflows; one for conformed video editing, and one for high tonal fidelity grading and compositing? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 05:43:49 +0100, skrev Monty Montgomery xiphm...@gmail.com: The real rub in all of this, and the impetus for getting me thinking to start with, is filter operations using colorspaces with singularities at black (like HSV). When you don't know where black is, any HSV operations are wrong at best and useless at worst. Gamma manipulation is also completely wrong when you don't know your black and white points. ... and presenting 0.0 as black and 1.0 as white internally is totally out of the question? With your proposed studio swing mapping most compositing and filtering operations have to scale and bias to work right. E.g. black + black + black will be a shade of gray, unless a bias is subtracted. I don't do any film at all, so that's part of why I was asking :-) Given that it sounds like digital cinema has all gone to log curves, if I'm going to use an assumed pipeline space, it sounds like it has to be linear light :-( ...how do log colorspaces handle color mixing? I suppose it is always converted to 16 bit linear, or linear float first. 2) Also making the pipeline a single assumed internal colorspace. It could be linear, log, gamma, whatever; we're in float, they're all equivalent. The rub here would be conversions; in some ways choosing linear is the most extreme choice because it means lots of reconversion (lossless reconversion, but burned CPU nonetheless). How much is a lot? One conversion entering the pipeline, and another exiting the pipeline? Perhaps the better idea is to be able to choose the pipeline working colorspace, the way we currently choose the pipeline pixelformat. The dilemmas just won't end, will they? :-/ -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 16:54:15 +0100, skrev Keith Gudger ke...@sploids.com: I hope this isn't off topic, but for those of us still using SD formats, we need YUV and not RGB. I tried RGBA for a while, but I always got artifacts, so I went back to YUV. No artifacts. RGB8, I presume? The artifacts may be due to lossy and buggy conversion between YUV8 and RGB8 in Cinelerra. RGB FLOAT will not suffer from that. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 14:27:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: How much is a lot? One conversion entering the pipeline, and another exiting the pipeline? Any color filters that expect to operate on R'G'B' rather than RGB. I think in most cases, these operations only work on R'G'B' to avoid the additional conversion, but there are probably at least a few that really do want the gamma space. They'd have to convert. I suppose linear light is the native space of many (most?) common operations. Blurring and resampling/scaling will get funny shifts in brightness if they operate on non-linear samples, for example. So maybe there is a lot of conversion going on already, and using linear light could _reduce_ that? Or, a lot of conversion _should_ have been going on, and we see wonky and imprecise results because they are missing? Just speculating... -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra vs Cinelerra-CV
På Mon, 05 Nov 2012 14:02:17 +0100, skrev Basil Chupin blchu...@iinet.net.au: The CV is being developed day-by-day and is always ahead, in one way, of the heroinewarrier (v4.4) because hw only takes from CV what it considers to be relevant to it aims. Nope. CinHV used to be "upstream", which CinCV _followed_,by merging with CinHV's releases. CinHV has progressed fastermost of the time between those merges.And CinCV broke off with upstream after CinHV 4.0, becausemerging became hard. Since then CinCV must have fallenbehind quite considerably, though I have not tested CinHVlately to see how big the difference is.-- Herman Robak
Re: [CinCV] Color handling
På Sun, 04 Nov 2012 03:26:51 +0100, skrev Monty Montgomery xiphm...@gmail.com: Note that although I'm suggesting a mandatory RGBA space, I'm also suggesting standard studio-swing levels (16-240 with head/toeroom). Full-swing imports will be mapped to the restricted range. In floating point terms that would mean 0.07-0.93, right? Having 0.07 as the black point and 0.93 as the white point. Now what about formats whose white point is far below the max value, like some higher depth formats? What is the most, like, do-what-I-mean course of action there? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Sun, 04 Nov 2012 12:54:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: Now what about formats whose white point is far below the max value, like some higher depth formats? The higher-depth formats I know of (and I'm asking because I'm sure there are ones I don't know of) still define swing in terms of the 8 bit range, and just tack on additional bits. The TV-oriented video formats do. http://www.avsforum.com/t/1432394/do-hd-studio-cameras-use-studio-swing-pixel-mapping But then there are cinema-oriented formats,like Digital Intermediates and such. http://www.reduser.net/forum/printthread.php?t=2714pp=10page=310 What is the most, like, do-what-I-mean course of action there? If there are in fact multiple possible studio swings in common use, it may be necessary to allow the user to define the pipeline swing. Are there? There is 10-bit log, where the white point may be around 700, rather than 940. If you hardcode the white level to 93% those images will look dull out of the box. But then again, they are usually supposed to go through colour grading to look right. But which parts of Cinelerra have to be aware of the intended black-to-white range? Could the black and white points simply be display and export settings? I suppose a fancy colour correction plugin would need to know those levels, so they ought to be exposed in the API, though. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Animating in Cinelerra ( was: thanks to g-raffa)
På Thu, 13 Sep 2012 14:43:24 +0200, skrev Robert Lee robert@gmx.net: hello, what linux programm would you use for animations? what works good with cinelerra? For stopmotion, there is LinuxStopmotion: http://linuxstopmotion.org/ -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Animating in Cinelerra ( was: thanks to g-raffa)
På Thu, 13 Sep 2012 17:56:50 +0200, skrev Graham Evans g...@karricountry.com.au: LinuxStopmotion is sounding like an awesome upgrade onthe only real Linux tool of any worth in that area. I will be playing with that one soon and can't wait. LinuxStopmotion is the program Stopmotion of yore. It has gotten a bit long in the tooth, but luckily Tim Band has churned out quite a few bugfix patches lately, making LinuxStopmotion more dependable, eventually. (We haven't made a new release yet) A major rewrite is due, though, once we have a stable bugfix release out. I want more speed and performance, caching, pre-loading, using TurboJPEG and OpenGL/GLSL, sophisticated scheduling... It ain't done until it plays sequences of huge DSLR(*) JPEGs (say, 18 megapixels) at 12 fps or better, along with a smooth scrolling thumbnail timeline. I think of thumbnails as small proxies and proxies as large thumbnails; they may be interchangeable. We'll see. *) Maybe RAWs, too, but 12fps will be pushing it... -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] MTS / Canon AVCHD in Cinelerra
På Sun, 02 Sep 2012 09:57:03 +0200, skrev James Moe ji...@sohnen-moe.com: On 09/01/2012 12:06 PM, Herman Robak wrote: I explained my workflow in this archive http://www.mail-archive.com/cinelerra@skolelinux.no/msg13210.html The link is broken. That link works like a charm in my web browser. could it be a configuration problem on your side? I do not understand how it might be. I am using Firefox. It fails in Chrome and Opera as well. The 404 seems a very clear response, complete with a nifty graphic of an empty file cabinet. Somehow, somewhere, the link most likely gets mangled, so that the ASCII string we see in our e-mail clients is not the same as you give to your web browser (URL) or to your shell (command line). A line break may have snuck into the command lines (because they were long, and thus line-wrapped) and weird characters (like the @) may have been escaped twice. I'm just suggesting here... -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] MTS / Canon AVCHD in Cinelerra
På Sat, 01 Sep 2012 20:10:46 +0200, skrev James Moe ji...@sohnen-moe.com: On 08/31/2012 02:34 PM, felix wrote: I explained my workflow in this archive http://www.mail-archive.com/cinelerra@skolelinux.no/msg13210.html The link is broken. That link works like a charm in my web browser. Brokenness seems like a recurring theme for you; could it be a configuration problem on your side? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Dark / contrasted prepared MJPEG videos
På Tue, 10 Jul 2012 21:10:38 +0200, skrev Nicolas Ecarnot nico...@ecarnot.net: Le 28/06/2012 12:11, Nicolas Ecarnot a écrit : Hi, Following the advices here : http://www.g-raffa.eu/Cinelerra/HOWTO/get_media_ready.html I'm converting with ffmpeg / avconv my input media files to MJPEG files. No obvious quality loss occurs, but they result in darker videos - dark enough to be noticed. In fact, they are getting darker and/or more contrasted. ... But when I'm converting, here is what I notice in avconv/ffmpeg output: Incompatible pixel format 'yuv420p' for codec 'mjpeg', auto-selecting format 'yuvj420p' This happens only on video that have this yuv420p pix format. How do I have to understand that? ... I'm sorry to insist on that point, but according to every doc I read related to cinelerra, everyone seems to advice to convert to MJPEG. This format sounds great to nle software, but I can't figure it out how I can manage this contrast problem. I'm not clear about whether the fault is on my source files, or a limitation of the MJPEG format, or a limitation of the converter (ffmpeg/avconv). I'm sure many of you have a well established workflow and you can't live with this issue, so maybe your video source formats don't bother you the way I'm bothered... It does bother me, for what it is worth. I think the problem is due to different luma range (MJPEG is full range; 0-255) and chroma sample alignment. I'd guess that the contrast range is first stretched, then truncated, leading to higher contrast _and_ some crushed blacks and clipped highlights. What to do? Find some other intermediate or proxy format. I'd suggest DNxHD for intermediates and intra-only low-bitrate h.264 for proxies. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra and jack
På Sun, 17 Jun 2012 14:02:45 +0200, skrev Orm Finnendahl o.finnend...@inm.mh-freiburg.de: Hello, sorry if this has been brought up before: Are there any plans to implement jack support into Cinelerra? It's not on a roadmap that I know of, but it is on my personal near-term TODO, for what it is worth. Our music school offers a new degree in scoring for film. Neat! I'm dabbling with scoring in Rosegarden myself ... http://www.nuug.no/pub/herman/misc/really_slavic.mp3 ... and synching Rosegarden and Cinelerra with Jack Transport is a usecase of a certain interest to me. The electronic studio heavily relies on linux machines using open source software. Cinelerra could be a real alternative to Sequoia, Premiere Final Cut or Vegas, but for this, professional audio support is mandatory (which in the linux world means jack and jack_transport). Indeed. Using the jack and jack-transport API is fairly easy (I've done that for other applications) so I can't imagine the implementation is a major deal comparing it to the awesome features already present in Cinelerra. Are you volunteering? :-) Or looking for collaborators? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra and jack
På Sun, 17 Jun 2012 20:16:37 +0200, skrev Lorenzo Sutton lorenzofsut...@gmail.com: Hi, On 17/06/12 14:02, Orm Finnendahl wrote: Hello, sorry if this has been brought up before: Are there any plans to implement jack support into Cinelerra? Our music school offers a new degree in scoring for film. The electronic studio heavily relies on linux machines using open source software. Cinelerra could be a real alternative to Sequoia, Premiere Final Cut or Vegas, but for this, professional audio support is mandatory (which in the linux world means jack and jack_transport). You might like to look into xjadeo [1], it's a neat video player with jack_transport support. I have used xjadeo. :-) The lead developer presented work on integrating video editing directly into Ardour at recent LAC 2012 [2]. Yep, I saw that one. I've met Robin a few times. Meanwhile, in my humble opinion, if you're accustomed tojack_transport you'll love xjadeo meaning you can use itwith Ardour, Rosegarden... even Pd. I want more. ;-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra and jack
På Sun, 17 Jun 2012 20:52:10 +0200, skrev Herman Robak her...@skolelinux.no: På Sun, 17 Jun 2012 20:16:37 +0200, skrev Lorenzo Sutton lorenzofsut...@gmail.com: Hi, On 17/06/12 14:02, Orm Finnendahl wrote: Hello, sorry if this has been brought up before: Are there any plans to implement jack support into Cinelerra? Our music school offers a new degree in scoring for film. The electronic studio heavily relies on linux machines using open source software. Cinelerra could be a real alternative to Sequoia, Premiere Final Cut or Vegas, but for this, professional audio support is mandatory (which in the linux world means jack and jack_transport). You might like to look into xjadeo [1], it's a neat video player with jack_transport support. I have used xjadeo. :-) I was a little too quick; you weren't replying to me, but to the thread starter. Sorry about that. :-) Anyhow, how is the interest for Jack integration for Cinelerra? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Development of Cinelerra CV
På Fri, 08 Jun 2012 10:08:23 +0200, skrev cin467-i...@yahoo.de cin467-i...@yahoo.de: Hello, I would like to ask about the further development of Cinelerra CV? Does developers working on a new version of Cinelerra CV at the moment? Not at the moment. One of the contributors is working on some rather invasive rewrites, and has done so for a long time. But we have not gathered a new list of low hanging fruit to be picked, and rolled into the next minor release. I would like to ask about a roadmap of Cinelerra CV becauseI would like to start deeper with Cinelerra. How deep? (That's a very open question, on purpose ;-) ) Perhaps I could help testing or so. Are you the Ordnung muss sein type? Our testing would benefit from more of that attitude. Over the last weeks I learned that I am spend a lot of time reporting bugsand so on for commercial video editing products. So I thought I could do this better for open source products like Cinelerra CV. You will find that responses like I have that problem, too or here is a workaround are far more frequent than I'll fix that! CinCV is dormant, as far as active development goes. It has a quite big community, so it won't die outright any time soon. But it ought to get out of bed ... What are your needs, as a potential Cinelerra user? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Development of Cinelerra CV
På Fri, 08 Jun 2012 19:21:15 +0200, skrev cin467-i...@yahoo.de cin467-i...@yahoo.de: Many thanks for your answer. Not at the moment. One of the contributors is working on some rather invasive rewrites, and has done so for a long time. But we have not gathered a new list of low hanging fruit to be picked, and rolled into the next minor release. That sounds very good. :-) For a regular user that would sound rather disappointing. On the other hand, if you are seeking oppurtunities, it may sound promising. You will find that responses like I have that problem, too or here is a workaround are far more frequent than I'll fix that! That is true. Perhaps there are only to few people able to fix things because of the lack of programming skills. I have the luck to be able to program in C and some C++. But that was always a hobby. However I will freshup my progamming skills and will hopefully in some time be able to look at the source code of Cinelerra too. Perhaps my skills will never fit to support the development but we will see. You may be able to fix some technical bugs (see below) yourself then, after you have dug through Cinelerra's source code a few times. What are your needs, as a potential Cinelerra user? I only want Cinelerra to do the things right. When there is a function than it should work like expected. As an example: I want to make an export in another windows video editing program. I set all settings to mpeg and 16:9. I got an mpeg file but the file is 4:3. That are the things that makes me unhappy. Aaawww. I have seen that aspect ratio is handled for only a few formats during rendering. Ogg/Theora, raw DV, and oddly enough the YUV4MPEG pipe output. And the aspect ratio logic is rather hackish where it exists at all. Before you even consider fixing that, do read up on the quirks of pixel aspect ratio, display aspect ratio, active area and overscan. Many, MANY get it wrong. And you are expected to interoperate with some of them, or be told that YOU are wrong. http://lipas.uwasa.fi/~f76998/video/conversion/#faq So far I read Cinelerra has it problems too but these are known and there are workarounds. So I do not try to go to the codec jungle. I convert my video files to uncompressed RGB and work than with these files. I am not sure if that works everys time but until now that is very fast during playback and very fast during export on my computer. Harddrives are big and cheap so I can work in that way. If I have done all my editing I export all to uncompressed RGB and use than other tools to convert the material. Such workarounds slow down the workflow. Particulary so with HD video. If you're not editing a movie, but a newsclip or something else with a tight deadline, slowness is baaad. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Your message to Cinelerra awaits moderator approval
På Sat, 02 Jun 2012 02:00:43 +0200, skrev Murray Strome wmstr...@yahoo.com: My E-Mail was hijacked -- I did NOT send this message!!! Aaawww, that SUCKS! I have received bounces from e-mails sent in my name, too, once every blue moon. It's fraud, and in a perfect world those spammers would be put behind bars. :-( Let's hope it was a one-off, or I'll have to put your e-mail address on manual moderation, for the common good. --- On Thu, 5/31/12, cinelerra-ad...@skolelinux.no cinelerra-ad...@skolelinux.no wrote: From: cinelerra-ad...@skolelinux.no cinelerra-ad...@skolelinux.no Subject: Your message to Cinelerra awaits moderator approval To: wmstr...@yahoo.com Received: Thursday, May 31, 2012, 7:46 PM Your mail to 'Cinelerra' with the subject Hi Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Luckily this spammer was lazy or greedy (or both) and did not bother putting the mailing list's address in the To: header. That has a high spammyness factor, hence the bounce. Brace yourself for more grief; your e-mail address has been scooped up by some crooks, and may be re-used on a random(ish) basis. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Your message to Cinelerra awaits moderator approval
På Sat, 02 Jun 2012 12:46:35 +0200, skrev Herman Robak her...@skolelinux.no: På Sat, 02 Jun 2012 02:00:43 +0200, skrev Murray Strome wmstr...@yahoo.com: My E-Mail was hijacked -- I did NOT send this message!!! Aaawww, that SUCKS! I have received bounces from e-mails sent in my name, too, once every blue moon. It's fraud, and in a perfect world those spammers would be put behind bars. :-( Bah! Clicking Reply doesn't always do the expected; my reply was intended for Murray, not the mailing list! I'm sorry! (Note to self: Double-check the To: field before sending!) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** Meeting reminder: Developer IRC meeting today, Sunday May 6th, at 16.00 UTC in #cinelerra
It's the first Sunday in the month, so there will be a developer meeting on the IRC channel #cinelerra on the Freenode IRC network. The meeting begins at 16.00 UTC, that's 6 PM in middle Europe (summer time) and in the morning in the Americas. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** Reminder: Developer IRC meeting tomorrow on #cinelerra, at 16:00 UTC
This is a reminder about the next developer IRC meeting, at April the 1st (yes, really!) at 16:00 UTC. The meeting takes place in the channel #cinelerra on the Freenode IRC network, as usual. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: g-raffa.eu still down
På Wed, 28 Mar 2012 08:37:31 +0200, skrev Einar Rünkaru eina...@smail.ee: Still down. Google-ing, found easily various sites like: http://vimeo.com/raffatraniello but g-raffa.eu is Firefox can't establish a connection to the server at g-raffa.eu. And this time with Tor browser, Hopefully nothing serious. World is beautiful because of there are people like her, and you folks at Cinelerra. I won't worry yet, but I will pray just the same. Nameservers do not resolve the name g-raffa.eu. Mails do no reach her, I haven't seen her on irc. May be she travels. Her gmail address works. She has Internet connection, but the server g-raffa.eu went down, and so did her e-mail account there. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra plays mute on pulseaudio
På Thu, 22 Mar 2012 17:38:56 +0100, skrev Einar Rünkaru eina...@smail.ee: I would propose writing a pulseaudio driver, instead of patching the old ALSA driver. That would fix the problem in the right place. It could be fairly low hanging fruit. Write a patch. I am ready to review. Will do, later. It just moved further down on my TODO list, once pulseaudio turned out to be a non-issue. It will be a simple side-task to adding Jack support, which I also would like to do. Some time. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra plays mute on pulseaudio
På Wed, 21 Mar 2012 19:47:06 +0100, skrev Miroslav Rovis m.ro...@inet.hr: To Cinelerra developers that looked into this, Einar, and Raffa! There's an update. Another developer is quite confident that the ball is in your yard, dear respected Cinelerra developers. I believe you are right. I peeked at audioesound.C, and it looked quite simple, less than 200 lines of code. Much less than the ALSA output driver. I would propose writing a pulseaudio driver, instead of patching the old ALSA driver. That would fix the problem in the right place. It could be fairly low hanging fruit. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Thu, 26 Jan 2012 14:40:55 +0100, skrev feli felixadandena...@hotmail.com: Le 2012-01-25 06:08, Herman Robak a écrit : På Tue, 24 Jan 2012 15:21:37 +0100, skrev felix felixadandena...@hotmail.com: I was also wandering how I can share this plugin modification so that it can be commented/further modified. If the diff is no more than a few hundred lines long, you may attach it to a post to this mailing list. Otherwise, we have both a bug tracker and a Git mob repository where patches can be submitted. Well, my modification to the blur plugin does not remove any functionality because I added three check marks, Y, U, V, to the gui so that if you have a YUV color space you can blur each of the YUV channel like in the original plugins, using the same effects and calculations. the difference is that you can blur the RGB channels and if you are in a RGB color space you can blur the YUV channel. If you blur the same channels as your color model there is no lossy color conversion, however if you blur a channel from an other color space that the one of your project or both (R and Y for instance), then there are lossy color conversion. My tests yesterday showed that even _one_ conversion is visibly lossy: The gradient effect becomes striped in YUV8 mode. The gradient is generated, so it does not process input pixels. Hence, there is only one colour model conversion, the _output_. Your feature will add _two_ (optional) conversions; one on the input and one on the output. The blurring of the input may help, though. However, conversion in FLOAT looks pretty smooth. It can't be technically lossless, but it seems perceptually lossless, which is our main concern here. Doesn't blur work with floats in the inner loops anyway? And it works on a temporary buffer, since it needs two passes, to you don't have to stick to the same component size as the input and output. What I'm suggesting is: Don't do the YUV-RGB conversions in 8bit. Always do them in FLOAT. Cinelerra has functions for that; they are called in the YUV effect plugin. You probably have to move the conversions closer to the inner loop to do this. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Sun, 04 Mar 2012 11:34:05 +0100, skrev Herman Robak her...@skolelinux.no: However, conversion in FLOAT looks pretty smooth. It can't be technically lossless, but it seems perceptually lossless, which is our main concern here. Doesn't blur work with floats in the inner loops anyway? And it works on a temporary buffer, since it needs two passes, to you don't have to stick to the same component size as the input and output. No, not that easy. The processing macro uses a _cast_ to float: http://cinelerra.org/devcorner/doxy/svn_2.1_r1056/html/blur_8C-source.html#l00383 ... but the buffer is in the native format. What I'm suggesting is: Don't do the YUV-RGB conversions in 8bit. Always do them in FLOAT. Cinelerra has functions for that; they are called in the YUV effect plugin. You probably have to move the conversions closer to the inner loop to do this. I still think it's worth pursuing, though it may not be as low hanging fruit as I thought. Linked below is the YUV effect's processing macro. If the colour format is YUV, then use_yuv is true, and the short block is run. Otherwise, the longer block with a conversion from RGB to YUV first, and a conversion back to YUV at the end: http://cinelerra.org/devcorner/doxy/svn_2.1_r1056/html/yuv_8C-source.html#l00289 -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Sun, 04 Mar 2012 11:55:49 +0100, skrev Herman Robak her...@skolelinux.no: Linked below is the YUV effect's processing macro. If the colour format is YUV, then use_yuv is true, and the short block is run. Otherwise, the longer block with a conversion from RGB to YUV first, and a conversion back to YUV at the end: errr, back you _RGB_ at the end! Need. more. coffee! http://cinelerra.org/devcorner/doxy/svn_2.1_r1056/html/yuv_8C-source.html#l00289 -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Yuv, RGB8 and RGB FLOAT comparison; subtle and not so subtle artifacts
I have promised to produce some test images. Seeing is believing. First, a PAL-sized PNG, showing a linear gradient made with Cinelerra's gradient video effect plugin. This PNG was rendered with the colour format set to YUV. It looks quite smooth, but it isn't. Next, a PAL-sized PNG of the same gradient rendered with RGB8 as the colour format. This is pretty smooth. Then a 2x enlarged region, with a 4x contrast stretch, showing FLOAT, YUV, RGB8, FLOAT side by side. You can see the difference now, right? ;-) Why is the Gradient effect so much poorer in YUV mode than in RGB8? It's because the gradient is generated in RGB colour, then converted to YUV (if necessary). And the conversion is lossy, especially when the colour depth is just 8 bits. In FLOAT mode, the YUV-RGB conversion is perceptually lossless, as far as I have been able to see. More aggressive and through testing remains, though. I'm sure you can squeeze out some artifacts if you yank up the saturation, contrast or sharpness really hard. If you combine effects that are YUV-native and RGB-native, you can only get decent quality in RGB FLOAT mode. In the 8-bit modes the image will suffer considerable loss and artifacts. -- Herman Robakattachment: gt2_gradient_only-yuv8.pngattachment: gt2_gradient_only-rgb8.pngattachment: gt2_gradient_only-stack-mid_2x.png
Re: [CinCV] ** Meeting reminder, and agenda ** Devel IRC meeting tomorrow, Sunday, at 16.00 UTC
På Sat, 03 Mar 2012 21:49:11 +0100, skrev Herman Robak her...@skolelinux.no: Last meeting we came up with several topics that we deferred to next meeting, the one we're having tomorrow: * Figure out what the default keyframe is, what's wrong with it, and what it should be changed to. * YUV - RGB conversion and quantisation/rounding errors, and RGB(A) FLOAT bugs and issues. * Test patterns and diff images showing colour space conversion errors/noise. (Tests: see my previous posts today. Diff images: none yet.) * Spam filtering and wishlist items for the Trac (bugs.cinelerra.org) (May have to be postponed again, since Raffaella can't attend) * Miscellaneous: The alpha blending bug patch that came in today, some user requests/suggestions, various ... Aaand, status updates for bug #967, if there are any: http://bugs.cinelerra.org/ticket/967 ImageLists not played back correctly -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Alpha Transparency Bug - FIXED
På Sat, 03 Mar 2012 01:18:27 +0100, skrev Craig Shelley cr...@microtron.org.uk: Hello Everyone, I've often noticed Cinelerra incorrectly overlays layers with alpha transparency. The main issue I see is transparent areas of the bottom track getting incorrectly rendered when overlaid with partially transparent sections from tracks above. ... After some deep debugging, I've tracked this issue down to the method used by Cinelerra to optimise the rendering of the bottom layer. Cinelerra seems to render the bottom layer using TRANSFER_REPLACE mode, which does make sense as there are no layers beneath it. Good work! Please let me know if you need any more info, patch files etc.. Yes please; more patches to the compositing pipeline in general. :-) For example correctly working alpha blending in RGB FLOAT mode, if you can figure it out. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Colour correction, quantisation/rounding errors and display; some findings.
I'm late with my homework for tomorrow's meeting, so I'm giving you a quick summary of what I have come up with so far. The hue/saturation effect has bad quantisation artifacts when the colour model is YUV and the sliders are set to anything but unity. I have attached a test project to demonstrate the banding noise; it's glaringly obvious when you view it at 200% size. There is another concern bugging me: LCD displays with lacking colour depth. I get banding artifacts no matter what on my LCD monitor when I display synthetic gradients that are free from noise and dithering. (like in my testcase) I'll compare with my CRT monitor, and see what difference it makes. -- Herman Robak?xml version=1.0? EDL VERSION=2.1CVxiphmont PROJECT_PATH=/home/herman/Devel/Cinelerra/ColourTests/gradient_test.xml LOCALSESSION IN_POINT=-1 LOOP_PLAYBACK=0 LOOP_START=3.2002e+00 LOOP_END=6.3603e+00 OUT_POINT=-1 SELECTION_START=3.4399e+00 SELECTION_END=3.4399e+00 CLIP_TITLE=Program CLIP_NOTES=Hello world FOLDER=Clips TRACK_START=0 VIEW_START=0 ZOOM_SAMPLE=512 ZOOMY=64 ZOOM_TRACK=64 PREVIEW_START=0 PREVIEW_END=5 RED=9.972510e-01 GREEN=1.002075e+00 BLUE=9.965255e-01 AUTOGROUPTYPE_AUDIO_FADE_MIN=-80 AUTOGROUPTYPE_AUDIO_FADE_MAX=6 AUTOGROUPTYPE_VIDEO_FADE_MIN=0 AUTOGROUPTYPE_VIDEO_FADE_MAX=100 AUTOGROUPTYPE_ZOOM_MIN=1.00e-03 AUTOGROUPTYPE_ZOOM_MAX=4 AUTOGROUPTYPE_X_MIN=-100 AUTOGROUPTYPE_X_MAX=100 AUTOGROUPTYPE_Y_MIN=-100 AUTOGROUPTYPE_Y_MAX=100/LOCALSESSION SESSION ASSETLIST_FORMAT=1 ASSET_COLUMN0=100 ASSET_COLUMN1=100 SHOW_MUTE=0 SHOW_CAMERA_X=0 SHOW_CAMERA_Y=0 SHOW_CAMERA_Z=0 SHOW_PROJECTOR_X=0 SHOW_PROJECTOR_Y=0 SHOW_PROJECTOR_Z=0 SHOW_FADE=0 SHOW_PAN=0 SHOW_MODE=0 SHOW_MASK=135623208 SHOW_TRANSITIONS=1 SHOW_PLUGINS=1 AUTO_KEYFRAMES=1 AUTOS_FOLLOW_EDITS=1 BRENDER_START=0 CROP_X1=0 CROP_Y1=0 CROP_X2=320 CROP_Y2=240 CURRENT_FOLDER=Video Effects CURSOR_ON_FRAMES=1 CWINDOW_DEST=0 CWINDOW_MASK=0 CWINDOW_METER=1 CWINDOW_OPERATION=0 CWINDOW_SCROLLBARS=0 CWINDOW_XSCROLL=4294966395 CWINDOW_YSCROLL=4294965901 CWINDOW_ZOOM=2.50e-01 DEFAULT_ATRANSITION=Crossfade DEFAULT_VTRANSITION=BandWipe DEFAULT_TRANSITION_LENGTH=5.e-01 EDITING_MODE=1 FOLDERLIST_FORMAT=1 HIGHLIGHTED_TRACK=0 LABELS_FOLLOW_EDITS=1 MPEG4_DEBLOCK=1 PLUGINS_FOLLOW_EDITS=1 PLAYBACK_PRELOAD=0 SAFE_REGIONS=1 SHOW_ASSETS=1 SHOW_TITLES=1 TEST_PLAYBACK_EDITS=1 TIME_FORMAT=1 TIMECODE_OFFSET_0=0 TIMECODE_OFFSET_1=0 TIMECODE_OFFSET_2=0 TIMECODE_OFFSET_3=0 NUDGE_SECONDS=1 TOOL_WINDOW=1 VWINDOW_METER=1 VWINDOW_FOLDER= VWINDOW_SOURCE=4294967295 VWINDOW_ZOOM=1 DECODE_SUBTITLES=0 subtitle_number=0/SESSION VIDEO INTERPOLATION_TYPE=1 INTERPOLATE_RAW=1 WHITE_BALANCE_RAW=1 COLORMODEL=YUV-8 Bit INTERLACE_MODE=NOTINTERLACED CHANNELS=1 VCHANNEL_X_0=0 VCHANNEL_Y_0=0 FRAMERATE=25 FRAMES_PER_FOOT=16 OUTPUTW=720 OUTPUTH=576 ASPECTW=5 ASPECTH=4/VIDEO AUDIO SAMPLERATE=48000 CHANNELS=2 ACHANNEL_ANGLE_0=180 ACHANNEL_ANGLE_1=0/AUDIO FOLDERClips/FOLDER FOLDERMedia/FOLDER ASSETS /ASSETS LABELS /LABELS TRACK RECORD=1 NUDGE=0 PLAY=1 GANG=1 DRAW=1 EXPAND=1 TRACK_W=720 TRACK_H=576 TYPE=VIDEO TITLEVideo 1/TITLE EDITS EDIT STARTSOURCE=0 CHANNEL=0 LENGTH=125/EDIT /EDITS MUTEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MUTEAUTOS CAMERA_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_X CAMERA_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Y CAMERA_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Z PROJECTOR_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_X PROJECTOR_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Y PROJECTOR_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Z FADEAUTOS AUTO POSITION=0 VALUE=100 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /FADEAUTOS MODEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MODEAUTOS MASKAUTOS AUTO MODE=1 VALUE=100 FEATHER=0 APPLY_BEFORE_PLUGINS=0 POSITION=0 /AUTO /MASKAUTOS PLUGINSET RECORD=1 PLUGIN LENGTH=125 TYPE=1 TITLE=Gradient IN/INOUT/OUTSHOW/SHOWON/ON KEYFRAME POSITION=0 DEFAULT=1GRADIENT ANGLE=5.3793191909790039e-06 IN_RADIUS=20 OUT_RADIUS=8.007629394531e+01 IN_R=255 IN_G=127 IN_B=127 IN_A=255 OUT_R=0 OUT_G=0 OUT_B=0 OUT_A=255 SHAPE=0 RATE=0 CENTER_X=9.3859649122807014e+01 CENTER_Y=5.1500e+01/GRADIENT/KEYFRAME /PLUGIN PLUGIN LENGTH=0 TYPE=0 TITLE= IN/INOUT/OUTON/ON KEYFRAME POSITION=0 DEFAULT=1/KEYFRAME /PLUGIN /PLUGINSET PLUGINSET RECORD=1 PLUGIN LENGTH=125 TYPE=1 TITLE=Hue saturation IN/INOUT/OUTSHOW/SHOWON/ON KEYFRAME POSITION=0 DEFAULT=1HUESATURATION HUE=1.937151e-07 SATURATION=-7.450581e-08
Re: [CinCV] Colour correction, quantisation/rounding errors and display; some findings.
På Sat, 03 Mar 2012 12:46:28 +0100, skrev Herman Robak her...@skolelinux.no: The hue/saturation effect has bad quantisation artifacts when the colour model is YUV and the sliders are set to anything but unity. I have attached a test project to demonstrate the banding noise; it's glaringly obvious when you view it at 200% size. The YUV effect plugin fares better, in YUV mode. And even better(er) in RGB FLOAT mode, though it doesn't look perfect here(*) In RGB mode it suffers from a weird glitch when the colours get really hot: A bright yellow band comes wiping down from the top! Some clipping/clamping failure, I guess... I have attached another test project file, this time with the YUV effect. The gradient is the same as in the Hue/Saturation effect test. There is another concern bugging me: LCD displays with lacking colour depth. *) The result in RGB FLOAT mode may have been immaculate before my LCD monitor reduced the gradient to series of conspicuous horizontal bands. ;-( -- Herman Robak?xml version=1.0? EDL VERSION=2.1CVxiphmont PROJECT_PATH=/home/herman/Devel/Cinelerra/ColourTests/gradient_test2.xml LOCALSESSION IN_POINT=-1 LOOP_PLAYBACK=0 LOOP_START=3.2002e+00 LOOP_END=6.3603e+00 OUT_POINT=-1 SELECTION_START=4.7998e+00 SELECTION_END=4.7998e+00 CLIP_TITLE=Program CLIP_NOTES=Hello world FOLDER=Clips TRACK_START=0 VIEW_START=37 ZOOM_SAMPLE=512 ZOOMY=64 ZOOM_TRACK=64 PREVIEW_START=0 PREVIEW_END=5 RED=9.972510e-01 GREEN=1.002075e+00 BLUE=9.965255e-01 AUTOGROUPTYPE_AUDIO_FADE_MIN=-80 AUTOGROUPTYPE_AUDIO_FADE_MAX=6 AUTOGROUPTYPE_VIDEO_FADE_MIN=0 AUTOGROUPTYPE_VIDEO_FADE_MAX=100 AUTOGROUPTYPE_ZOOM_MIN=1.00e-03 AUTOGROUPTYPE_ZOOM_MAX=4 AUTOGROUPTYPE_X_MIN=-100 AUTOGROUPTYPE_X_MAX=100 AUTOGROUPTYPE_Y_MIN=-100 AUTOGROUPTYPE_Y_MAX=100/LOCALSESSION SESSION ASSETLIST_FORMAT=1 ASSET_COLUMN0=100 ASSET_COLUMN1=100 SHOW_MUTE=0 SHOW_CAMERA_X=0 SHOW_CAMERA_Y=0 SHOW_CAMERA_Z=0 SHOW_PROJECTOR_X=0 SHOW_PROJECTOR_Y=0 SHOW_PROJECTOR_Z=0 SHOW_FADE=0 SHOW_PAN=0 SHOW_MODE=0 SHOW_MASK=135623208 SHOW_TRANSITIONS=1 SHOW_PLUGINS=1 AUTO_KEYFRAMES=1 AUTOS_FOLLOW_EDITS=1 BRENDER_START=0 CROP_X1=0 CROP_Y1=0 CROP_X2=320 CROP_Y2=240 CURRENT_FOLDER=Video Effects CURSOR_ON_FRAMES=1 CWINDOW_DEST=0 CWINDOW_MASK=0 CWINDOW_METER=1 CWINDOW_OPERATION=0 CWINDOW_SCROLLBARS=0 CWINDOW_XSCROLL=4294966395 CWINDOW_YSCROLL=4294965901 CWINDOW_ZOOM=2.50e-01 DEFAULT_ATRANSITION=Crossfade DEFAULT_VTRANSITION=BandWipe DEFAULT_TRANSITION_LENGTH=5.e-01 EDITING_MODE=1 FOLDERLIST_FORMAT=1 HIGHLIGHTED_TRACK=0 LABELS_FOLLOW_EDITS=1 MPEG4_DEBLOCK=1 PLUGINS_FOLLOW_EDITS=1 PLAYBACK_PRELOAD=0 SAFE_REGIONS=1 SHOW_ASSETS=1 SHOW_TITLES=1 TEST_PLAYBACK_EDITS=1 TIME_FORMAT=1 TIMECODE_OFFSET_0=0 TIMECODE_OFFSET_1=0 TIMECODE_OFFSET_2=0 TIMECODE_OFFSET_3=0 NUDGE_SECONDS=1 TOOL_WINDOW=1 VWINDOW_METER=1 VWINDOW_FOLDER= VWINDOW_SOURCE=4294967295 VWINDOW_ZOOM=1 DECODE_SUBTITLES=0 subtitle_number=0/SESSION VIDEO INTERPOLATION_TYPE=1 INTERPOLATE_RAW=1 WHITE_BALANCE_RAW=1 COLORMODEL=YUV-8 Bit INTERLACE_MODE=NOTINTERLACED CHANNELS=1 VCHANNEL_X_0=0 VCHANNEL_Y_0=0 FRAMERATE=25 FRAMES_PER_FOOT=16 OUTPUTW=720 OUTPUTH=576 ASPECTW=5 ASPECTH=4/VIDEO AUDIO SAMPLERATE=48000 CHANNELS=2 ACHANNEL_ANGLE_0=180 ACHANNEL_ANGLE_1=0/AUDIO FOLDERClips/FOLDER FOLDERMedia/FOLDER ASSETS /ASSETS LABELS /LABELS TRACK RECORD=1 NUDGE=0 PLAY=1 GANG=1 DRAW=1 EXPAND=1 TRACK_W=720 TRACK_H=576 TYPE=VIDEO TITLEVideo 1/TITLE EDITS EDIT STARTSOURCE=0 CHANNEL=0 LENGTH=125/EDIT /EDITS MUTEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MUTEAUTOS CAMERA_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_X CAMERA_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Y CAMERA_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Z PROJECTOR_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_X PROJECTOR_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Y PROJECTOR_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Z FADEAUTOS AUTO POSITION=0 VALUE=100 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /FADEAUTOS MODEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MODEAUTOS MASKAUTOS AUTO MODE=1 VALUE=100 FEATHER=0 APPLY_BEFORE_PLUGINS=0 POSITION=0 /AUTO /MASKAUTOS PLUGINSET RECORD=1 PLUGIN LENGTH=125 TYPE=1 TITLE=Gradient IN/INOUT/OUTON/ON KEYFRAME POSITION=0 DEFAULT=1GRADIENT ANGLE=5.3793191909790039e-06 IN_RADIUS=20 OUT_RADIUS=8.007629394531e+01 IN_R=255 IN_G=127 IN_B=127 IN_A=255 OUT_R=0 OUT_G=0 OUT_B=0 OUT_A=255 SHAPE=0 RATE=0 CENTER_X=9.3859649122807014e+01 CENTER_Y
Re: [CinCV] Colour correction, quantisation/rounding errors and display; some findings.
På Sat, 03 Mar 2012 13:07:16 +0100, skrev Herman Robak her...@skolelinux.no: The YUV effect plugin fares better, in YUV mode. And even better(er) in RGB FLOAT mode, though it doesn't look perfect here(*) You may see it more clearly in the selftest I'm attaching here, where I have added another video track on the top with the same gradient, and the overlay mode set to subtract. FLOAT RGB looks best, and RGB looks broken. -- Herman Robak?xml version=1.0? EDL VERSION=2.1CVxiphmont PROJECT_PATH=/home/herman/Devel/Cinelerra/ColourTests/gradient_selftest.xml LOCALSESSION IN_POINT=-1 LOOP_PLAYBACK=0 LOOP_START=3.2002e+00 LOOP_END=6.3603e+00 OUT_POINT=-1 SELECTION_START=5 SELECTION_END=5 CLIP_TITLE=Program CLIP_NOTES=Hello world FOLDER=Clips TRACK_START=0 VIEW_START=35 ZOOM_SAMPLE=512 ZOOMY=64 ZOOM_TRACK=64 PREVIEW_START=0 PREVIEW_END=5 RED=9.972510e-01 GREEN=1.002075e+00 BLUE=9.965255e-01 AUTOGROUPTYPE_AUDIO_FADE_MIN=-80 AUTOGROUPTYPE_AUDIO_FADE_MAX=6 AUTOGROUPTYPE_VIDEO_FADE_MIN=0 AUTOGROUPTYPE_VIDEO_FADE_MAX=100 AUTOGROUPTYPE_ZOOM_MIN=1.00e-03 AUTOGROUPTYPE_ZOOM_MAX=4 AUTOGROUPTYPE_X_MIN=-100 AUTOGROUPTYPE_X_MAX=100 AUTOGROUPTYPE_Y_MIN=-100 AUTOGROUPTYPE_Y_MAX=100/LOCALSESSION SESSION ASSETLIST_FORMAT=1 ASSET_COLUMN0=100 ASSET_COLUMN1=100 SHOW_MUTE=0 SHOW_CAMERA_X=0 SHOW_CAMERA_Y=0 SHOW_CAMERA_Z=0 SHOW_PROJECTOR_X=0 SHOW_PROJECTOR_Y=0 SHOW_PROJECTOR_Z=0 SHOW_FADE=0 SHOW_PAN=0 SHOW_MODE=0 SHOW_MASK=135623208 SHOW_TRANSITIONS=1 SHOW_PLUGINS=1 AUTO_KEYFRAMES=0 AUTOS_FOLLOW_EDITS=1 BRENDER_START=0 CROP_X1=0 CROP_Y1=0 CROP_X2=320 CROP_Y2=240 CURRENT_FOLDER=Video Effects CURSOR_ON_FRAMES=1 CWINDOW_DEST=0 CWINDOW_MASK=0 CWINDOW_METER=1 CWINDOW_OPERATION=0 CWINDOW_SCROLLBARS=0 CWINDOW_XSCROLL=4294966395 CWINDOW_YSCROLL=4294965901 CWINDOW_ZOOM=2.50e-01 DEFAULT_ATRANSITION=Crossfade DEFAULT_VTRANSITION=BandWipe DEFAULT_TRANSITION_LENGTH=5.e-01 EDITING_MODE=1 FOLDERLIST_FORMAT=1 HIGHLIGHTED_TRACK=0 LABELS_FOLLOW_EDITS=1 MPEG4_DEBLOCK=1 PLUGINS_FOLLOW_EDITS=1 PLAYBACK_PRELOAD=0 SAFE_REGIONS=1 SHOW_ASSETS=1 SHOW_TITLES=1 TEST_PLAYBACK_EDITS=1 TIME_FORMAT=1 TIMECODE_OFFSET_0=0 TIMECODE_OFFSET_1=0 TIMECODE_OFFSET_2=0 TIMECODE_OFFSET_3=0 NUDGE_SECONDS=1 TOOL_WINDOW=1 VWINDOW_METER=1 VWINDOW_FOLDER= VWINDOW_SOURCE=4294967295 VWINDOW_ZOOM=1 DECODE_SUBTITLES=0 subtitle_number=0/SESSION VIDEO INTERPOLATION_TYPE=1 INTERPOLATE_RAW=1 WHITE_BALANCE_RAW=1 COLORMODEL=YUV-8 Bit INTERLACE_MODE=NOTINTERLACED CHANNELS=1 VCHANNEL_X_0=0 VCHANNEL_Y_0=0 FRAMERATE=25 FRAMES_PER_FOOT=16 OUTPUTW=720 OUTPUTH=576 ASPECTW=5 ASPECTH=4/VIDEO AUDIO SAMPLERATE=48000 CHANNELS=2 ACHANNEL_ANGLE_0=180 ACHANNEL_ANGLE_1=0/AUDIO FOLDERClips/FOLDER FOLDERMedia/FOLDER ASSETS /ASSETS LABELS /LABELS TRACK RECORD=1 NUDGE=0 PLAY=1 GANG=1 DRAW=1 EXPAND=1 TRACK_W=720 TRACK_H=576 TYPE=VIDEO TITLEVideo 2/TITLE EDITS EDIT STARTSOURCE=0 CHANNEL=0 LENGTH=125/EDIT /EDITS MUTEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MUTEAUTOS CAMERA_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_X CAMERA_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Y CAMERA_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Z PROJECTOR_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_X PROJECTOR_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Y PROJECTOR_Z AUTO POSITION=0 VALUE=1 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /PROJECTOR_Z FADEAUTOS AUTO POSITION=0 VALUE=100 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /FADEAUTOS MODEAUTOS AUTO POSITION=0 VALUE=2/AUTO /MODEAUTOS MASKAUTOS AUTO MODE=1 VALUE=100 FEATHER=0 APPLY_BEFORE_PLUGINS=0 POSITION=0 /AUTO /MASKAUTOS PLUGINSET RECORD=1 PLUGIN LENGTH=125 TYPE=1 TITLE=Gradient IN/INOUT/OUTON/ON KEYFRAME POSITION=0 DEFAULT=1GRADIENT ANGLE=0 IN_RADIUS=20 OUT_RADIUS=80 IN_R=255 IN_G=127 IN_B=127 IN_A=255 OUT_R=0 OUT_G=0 OUT_B=0 OUT_A=255 SHAPE=0 RATE=0 CENTER_X=9.3859649122807014e+01 CENTER_Y=5.1500e+01/GRADIENT/KEYFRAME /PLUGIN PLUGIN LENGTH=0 TYPE=0 TITLE= IN/INOUT/OUTON/ON KEYFRAME POSITION=0 DEFAULT=1/KEYFRAME /PLUGIN /PLUGINSET /TRACK TRACK RECORD=1 NUDGE=0 PLAY=1 GANG=1 DRAW=1 EXPAND=1 TRACK_W=720 TRACK_H=576 TYPE=VIDEO TITLEVideo 1/TITLE EDITS EDIT STARTSOURCE=0 CHANNEL=0 LENGTH=125/EDIT /EDITS MUTEAUTOS AUTO POSITION=0 VALUE=0/AUTO /MUTEAUTOS CAMERA_X AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_X CAMERA_Y AUTO POSITION=0 VALUE=0 CONTROL_IN_VALUE=0 CONTROL_OUT_VALUE=0 CONTROL_IN_POSITION=0 CONTROL_OUT_POSITION=0/AUTO /CAMERA_Y CAMERA_Z AUTO
[CinCV] ** Meeting reminder, and agenda ** Devel IRC meeting tomorrow, Sunday, at 16.00 UTC
Last meeting we came up with several topics that we deferred to next meeting, the one we're having tomorrow: * Figure out what the default keyframe is, what's wrong with it, and what it should be changed to. * YUV - RGB conversion and quantisation/rounding errors, and RGB(A) FLOAT bugs and issues. * Test patterns and diff images showing colour space conversion errors/noise. (Tests: see my previous posts today. Diff images: none yet.) * Spam filtering and wishlist items for the Trac (bugs.cinelerra.org) (May have to be postponed again, since Raffaella can't attend) * Miscellaneous: The alpha blending bug patch that came in today, some user requests/suggestions, various ... -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** Devel meeting reminder ** Next meeting is on Sunday, the 4th of March, at 16.00 UTC
There will be a developer meeting on IRC on Sunday this week-end, the usual time and place. Time: 16.00 UTC Place: #cinelerra @ Freenode The hot topic on the agenda will be colour model conversion(*) and colour correction in Cinelerra: What bugs are there, how grave are they, how can they be easily and precisely measured, and some measurement results. I had hoped to be have some demonstrations and measurements to show off before posting this reminder, but alas, I have not. I intend to have some done before the meeting, though. *) http://www.fourcc.org/fccyvrgb.php -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Capture from different ports
På Wed, 29 Feb 2012 16:25:20 +0100, skrev Bhikkhu Mettavihari tv.li...@gmail.com: Hi from Sri Lanka The world is changing so fast that it is very difficult to follow I find it now difficult to find a laptop with firewire to capture my data on Sony cameras now come with 1. DV output (firewire) 2. SDI output 3. HDMI output I have used kino to capture my videos with for at least the past 5 years Everything is fine. My problem is now: Can Kino capture from SDI output or HDMI output ? I know I should have looked at the source code before writing this... ...but I am 99% sure that Kino is DV only, through ieee1394 and USB. I am interested in SDI and HDMI myself, not so much for ingestion to an editor, but rather for live mixing, as a successor to DV in dvswitch(*) HD video is no longer an exception, it is becoming the norm. *) http://dvswitch.alioth.debian.org/wiki/ -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] ** Devel meeting reminder ** Next meeting is on Sunday, the 4th of March, at 16.00 UTC
På Wed, 29 Feb 2012 19:57:54 +0100, skrev Rafael Diniz raf...@riseup.net: ffmpeg has some very optimized color conversion routines! Actually, I would prefer to study the topic with fresh eyes, before we look into other implementations. ffmpeg's routines may be excellent, but I would like to know how to review their code for correctness and quality all the same. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] [OPENVIDEO] Linux Stopmotion community
På Mon, 27 Feb 2012 16:21:52 +0100, skrev flavio soares qazav...@gmail.com: Hey, Raffa, One of the automation scripts I've done for Apertus reads all the JPEG images from a folder* and creates a reference file to them (exactly like img2list would do, only it automates this process) so that they can be read as movies by Cinelerra. Does that help you in any way? I'm just about to document them - probably around next week - so if it can be useful for animation, just let me know! =) Thanks. :-) I have already written a Cinelerra file list export for Stopmotion, in C++, integrated in Stopmotion. My Cinelerra export groups scenes into individual file lists, with a separate sub-folder for each scene. It works, minus a bugfix or two. I will commit it to the LinuxStopmotion git repo soonish (may take a week, or a month ...) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] [OPENVIDEO] Linux Stopmotion community
På Sat, 25 Feb 2012 22:03:43 +0100, skrev Raffaella Traniello raffaella.tranie...@g-raffa.eu: Ciao! You might be interested to know that Stopmotion, the application for grabbing the frames of an animation, has now its own community. Please, visit the Linux Stopmotion brand new website at: http://linuxstopmotion.org I think the most interesting features we are working on are: - capture from DSLR camera So far, a prototype Ghoto-based grabber is implemented, as a command line tool. It takes about 10 previews per second, and stores each of them to the same file, until it gets killed. Right now I'm rewriting it as a library (.so file instead of a stand-alone executable) that captures to RAM, not to a file, and returns a pointer to the image data. Should be quite a bit faster. It requires some rewriting of Stopmotion, to support dynamic loading of capture libraries. - export to Cinelerra framelist Already written. A couple of bugfixes remain. (Not committed to git yet) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 24 Jan 2012 15:21:37 +0100, skrev felix felixadandena...@hotmail.com: Hi all Thanks for the comments, this is a very interesting discussion. In the mean time I've make some modification to the blur plugin so that if your color model is YUV, it coverts YVU to RBG before running the blur engine and then convert RGB to YUV the output frame. I used the YUV plugin as a basis for the conversion algorithm because YUV does the conversion (start at line 320 of yuv.C, conversion is performed by the functions in plugincolors in plugins/colors). This introduces a dilemma: You are removing functionality in favour of consistency. What about the users (*raising my hand*) who do prefer to soften the chroma and the luma separately? Besides, according to Monty, Cinelerra already performs more colour conversions than it ought to, under the hood. The OpenGL plugin engine attempts to aggregate effects; treating a chain of effects as one combined effect. I think the same could be done with colour formats, avoiding a few noisy conversions. This is no longer low hanging fruit, I know ... As of now I still have issues with the float RGBA color space,but I hope that I'll be able to fix this. There are two issues that I know of: * Wrong handling of the alpha channel (missing or wrong scaling from the 8-bit int to the 0.0-1.0 float range) * Some special-casing in the display pipeline going wrong. (Only pass-through works for video, transformed video comes out black) I was also wandering how I can share this plugin modification so that it can be commented/further modified. If the diff is no more than a few hundred lines long, you may attach it to a post to this mailing list. Otherwise, we have both a bug tracker and a Git mob repository where patches can be submitted. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Sun, 22 Jan 2012 11:02:35 +0100, skrev Michal Fapso michal.fa...@gmail.com: Thanks for your comments, Hermann. It seems to me that using only float RGBA color model would be quite a good solution. Plugins would become simpler and should behave coherently for any videos and precision should be also fine. Indeed. However, Float RGBA is buggy, at least in my builds. I can import Float formats like OpenEXR, and do HDR colour correction on them in Cinelerra. But 8-bit images and videos come out black as soon as I apply any effect or adjustment. I have not figured out why yet. The drawback I see here is that float would require 4-times morememory than YUVA 8 bits per channel. Also computation would beprobably slower for floats. And all this extra precision is applied to the same old coarse 8-bit gamma-encoded data, without any prior smoothing. Same with the half-resolution colour data, which _could_ have been processed as separate image planes, halving the number of pixels per frame. Naïvely upscaled images introduce false information, like aliasing, banding, artificial noise. High-precision effects need pristine input to work well. Either untransformed pixel data, or very well filtered and precisely transformed data. The latter is expensive (slow!) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Wed, 18 Jan 2012 18:50:29 +0100, skrev felix felixadandena...@hotmail.com: Hi While following this thread and experimenting on my own, I stumble on something... When I apply the inverse video plugin, I dont get the same result if my project's color model is RGB or YUV. It seems as if the plugin simply reverse each channel without considering if the color model is RGB or YUV. If your color model is RGB then the plugin work right and each chanel/color is inverted. However if your color model is YUV then the first channel is Y and it get inverted if you select the invert R. Finally if you invert all three channel RGB you get the same result whether your color model is YUV or RGB. It's the same with the Blur effect. The effect is applied to the components you choose. There are either three or four of them, and alpha is the fourth. The lazy fix would be to detect the colour format, and switch the labels in the plugin's settings window. Quite often the behaviour you described is exactly what you would want. Or not? I would like to hear your opinions on this. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 11:53:47 +0100, skrev Michal Fapso michal.fa...@gmail.com: Hi everyone, when I apply a Hue saturation effect in Cinelerra and increase the saturation, it creates color artifacts. When I increase saturation in Avidemux, it looks well. Here is an example. Look at the sky near the sea level. There are blue artifacts which are not present in the Avidemux case: Cinelerra: http://www.fit.vutbr.cz/~ifapso/download/cinelerra_hue_artifacts.png That red line above the track suggests that you have background rendering turned on, right? Cinelerra renders to a sequence of JPEGs. Maybe what you see is JPEG artifacts (rather bad ones, I might add ...) Try turning background rendering off. Avidemux: http://www.fit.vutbr.cz/~ifapso/download/avidemux_hue_ok.png Here is the video (10MB): http://www.fit.vutbr.cz/~ifapso/download/MVI_2230.MOV Is that the original? Because I get different blocking artifacts here than on your screenshot. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 18:45:29 +0100, skrev Michal Fapso michal.fa...@gmail.com: Thanks for your reply, Herman. Yes, the background rendering was on, but it is exactly the same when I turn that off. Is that the original? Because I get different blocking artifacts here than on your screenshot. Yes, it is the original video. You mean you inserted it to Cinelerra's timeline, added the saturation effect and pushed saturation up and saw different artifacts? Yes. However, I notice that the brightness or gamma differs, too. The picture was brighter in my compositor window than in your screenshot of Cinelerra, but your screenshot of Avidemux was _much_ brighter. Could be a gamma setting thing; is the paused picture worse than during playback? Do you use X11, X11-XV or OpenGL as display driver? Could you send me your screenshot? I did not make a screenshot, but compared side by side. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 18:35:57 +0100, skrev Herman Robak her...@skolelinux.no: På Tue, 17 Jan 2012 11:53:47 +0100, skrev Michal Fapso michal.fa...@gmail.com: ... Here is the video (10MB): http://www.fit.vutbr.cz/~ifapso/download/MVI_2230.MOV Is that the original? Because I get different blocking artifacts here than on your screenshot. Now I found how to get the same artifacts: Setting the Hue to -0.00! If I adjust the Hue with the mouse to the middle, unity, I only get 0.00, and the colours are right. If I adjust the Hue with the keyboard to the middle zero value, I get -0.00. Minus zero. And I see blocks with bluish tint that are not there on any other Hue setting. I'd call that a bug. Probably quite easy to fix, too! :-) Can you confirm? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 20:32:38 +0100, skrev Michal Fapso michal.fa...@gmail.com: I am not able to set Hue to -0.0, but when I just moved a bit the hue slider, the blue artifacts disappeared! And now there are no artifacts evein with Hue=0.0! So basically, I cannot make it to show those artifacts now :o) However, there is still another kind of block artifacts in the sky: http://www.fit.vutbr.cz/~ifapso/download/cinelerra_vs_avidemux_block_artifacts.png That could be due to lacking chroma interpolation. As far as I know, Cinelerra upscales 4:2:0 video to 4:4:4 simply by nearest neighbour; repeating each colour pixel 2x2 times. Such blocky 2x2 colour pixels will give the colour macroblocks really sharp edges, which will stand out like mach bands when you raise the colour contrast (i.e. the saturation). Avidemux apparently filters the chroma properly, avoiding this. You may try a workaround: Apply a blur effect _before_ the hue/saturation effect, and make sure your colour format is YUV(A), not RGB(A). Enable only blur of G and B (which means U and V, since you are in YUV mode), and set the blur radius to 3. It helps quite a lot, and since the luma is left alone, the result is still sharp. I still see a lot of flickering blocks in the top of the image, though. Maybe Avidemux has a dynamic deblocker enabled, too? Anyhow, your MJPEG video is _very_ blocky! Try upping the bitrate a few notches. PS! Hm, I'd suggest setting the blur radius to 8, or 16 even! The colour signal isn't exactly crisp in the first place. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 21:26:51 +0100, skrev Herman Robak her...@skolelinux.no: I still see a lot of flickering blocks in the top of the image, though. Maybe Avidemux has a dynamic deblocker enabled, too? Nah, Avidemux' output flickered pretty badly near the top, too. Blocky, blocky! Higher bitrate, if you please! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 22:42:01 +0100, skrev Michal Fapso michal.fa...@gmail.com: Thanks for your hints, Herman! I use that down-scaled video only as a proxy. When I set up the project, I render the final video from 1920x1080p videos. The original 1080p clips were recorded on Canon 600D with Magic Lantern, bitrate was set to 0.7x to save some disk space: Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p, 1920x1088, 30516 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc How are the results if you process the original video the same way in Cinelerra and Avidemux? Do you still get blocky and flickering video? When I tried your trick with blurring the U and V channels, it helps with the block artifacts a bit, but it is still not as good as avidemux and when I set the blur radius too high, color from small spots like the yellow from sea-marks vanishes :o( There is quite a bit of luma blockiness, too. I doubt the camera original is as blocky as the proxy, by far. I really like the output of avidemux for both 640x360 and 1920x1080 videos. As we already have noticed, Avidemux appears to do more than only raise the colour saturation. But what? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 22:42:01 +0100, skrev Michal Fapso michal.fa...@gmail.com: Thanks for your hints, Herman! I use that down-scaled video only as a proxy. When I set up the project, I render the final video from 1920x1080p videos. The original 1080p clips were recorded on Canon 600D with Magic Lantern, bitrate was set to 0.7x to save some disk space: Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p, 1920x1088, 30516 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc When I tried your trick with blurring the U and V channels, it helps with the block artifacts a bit, but it is still not as good as avidemux and when I set the blur radius too high, color from small spots like the yellow from sea-marks vanishes :o( If you use the YUV effect instead of Hue/Sat, then a blur of 3 px will do just fine. In fact, it looks passable without chroma blur. I really like the output of avidemux for both 640x360 and 1920x1080 videos. Is anybody able to improve the code for 4:2:0 - 4:4:4 conversion in Cinelerra? Never mind that. The Hue/Saturation effect must have some severe rounding errors. Just try using the YUV effect instead, and see for yourself: Keep Y at 1.0 (unity) and raise U and V by the same amount. I get a much cleaner result here, on par with Avidemux. I think it looks good with Y+10 and U,V + 40. .oO(Those colour adjustment effects really do need some scrutiny ...) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color correction artifacts
På Tue, 17 Jan 2012 23:49:07 +0100, skrev Michal Fapso michal.fa...@gmail.com: How are the results if you process the original video the same way in Cinelerra and Avidemux? Do you still get blocky and flickering video? Here is the original from camera (50MB): http://www.fit.vutbr.cz/~ifapso/download/MVI_2230_1080p.MOV There is blocking noise in that video, too. Particulary near the top of the image, where the image _should_ be smooth. My experience with DSLRs is that a hand-held camera and moderately complex scenes cause noticeable compression artifacts. So I would _not_ have turned down the bitrate, if I were you. Just sayin' :- -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Improved UI...
På Fri, 30 Dec 2011 22:56:04 +0100, skrev Stefan de Konink ste...@konink.de: Op 30-12-11 22:35, Ichthyostega schreef: Yet still, there is also a lot of fun in actually getting things done, maybe the hard way, and probably that's what keeps us going. So, if I would like to make any of the discussed ideas myself. Is then the motto: just make them then come asking for help? Or is there currently an outline how to integrate such thing? No, and I think writing a reasonably complete integration HOWTO for Cinelerra would be a heavy task. Too heavy in the short term. But I liked the suggestions you made on Tuesday (quote): Herman: For the benefit of proxy editing, AND multi-angle DVDs, AND 3D video, I think support for multi-track video would be neat. Track folding or hiding would enhance the usability, and track grouping/locking would be even more critical. Can it be done? Stefan: To do this properly also multiple preview windows would be 'required' to do anything useful, Some form of A-B editing not yet present is Cinelerra. Maybe the first target could be: - create a player that gives a visual preview (in a lower resolution) of all video-tracks (This could then branch off to a zillion different use cases including linear editing) Next target: - Allow audio tracks to be (hard) attached to videotracks - Allow interactive manipulation of the videotracks given the tracks are playing, or in a paused state, where visual feedback results in alignment. (Tackles: 3D/Multiangle/Synchronisation) - Allow video tracks to be (hard) attached as a group of tracks - Create an intermediate representation so a multi track could be folded You are suggesting new functionality in terms of building blocks, enabling further additions and extensions in the future, in theory. Now, if we could agree on a short list at tomorrow's meeting; that is, which building blocks to prototype first, we could get from theory to practice pretty soon. We may even start that discussion right now, on the mailing list, as a preparation to the IRC meeting. :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Improved UI...
På Fri, 30 Dec 2011 22:35:34 +0100, skrev Ichthyostega p...@ichthyostega.de: Am 30.12.2011 19:42, schrieb Stefan de Konink: Is the above really what you observe in 'daily life', because as I told you before, I would love to work on stuff, but without any serious 'we are ready to get people in to do real work and end with something that they can actually use', I feel quite stock. Geesh! Everyone wants focus, pragmatism and real stuff and so on. No one wants just to toy around. Its always the others toying around.. Good intentions aren't the problem Easy now! :-) Are you suggesting we need some perception management? (I'm not protesting, for what it's worth) For example: I'm now for weeks thinking about coding a simple videosynchronisation program, because none of the programs I work with to do my video editing is able to give me the ability to do frame synchronisation in a way that is easy. Indeed it is only an afternoon work... Nice example. I don't hesitate to believe you that you'll be able to code up something in an afternoon. That's what we call a prototype Then you'll experiment a bit with it and find yourself several days long nailing bugs or fighting against some buggy driver or library. Hm, so if prototyping is like having sex, then developing is like having children? Considering the declining birth rates, that mental image worries me. I think we DO need some perception management. (At least I do ...) Don't get me wrong; I think you are right. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Meeting reminder: Dev meeting on #cinelerra (IRC, Freenode) Sunday 1st of January, 2012.
As usual, there will be a developer IRC meeting at the first Sunday of the month. The next meeting will be on the first day of 2012, which is a holiday in some countries (mine included). Date: January the 1st, 2012 Time: 16.00 UTC We will discuss candidate tasks for a Google Summer of Code project. Some old candidates are here: http://cinelerra.org/soc.php Some comments: Personally, I think ffv1 is a better choice for a lossless codec than HuffYUV. Especially for intermediate renders, since it supports several colour formats, e.g. 4:2:0. Colour format conversions are expensive and lossy. For the benefit of proxy editing, AND multi-angle DVDs, AND 3D video, I think support for multi-track video would be neat. Track folding or hiding would enhance the usability, and track grouping/locking would be even more critical. Can it be done? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Your message to Cinelerra awaits moderator approval
På Sun, 20 Nov 2011 15:56:01 +0100, skrev Leandro Martins conspro...@gmail.com: How do I add myself to the list? If it's just a matter of asking through this e-mail, please add me. Thanks a lot! You can subscribe yourself through the mailing list's web interface: https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra You don't have to re-post your question about feature films edited in Cinelerra; I let that one through now. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] How to get same video properties on multiple tracs?
På Mon, 14 Nov 2011 07:44:15 +0100, skrev Hannu Vuolasaho vuo...@msn.com: I have been wondering how do I do this. I have three different videos from same scene from three different camera. The footage is taken so cameras are in row and see little bit each others view. I want to get same video properties to side tracks as the center on has. So that color and light are pretty much same in all tracks. So that I can just pan and zoom the wide view. Is there any automation available for this task? At least I couldn't figure out it. It wold be so nice if I was able to say Cinelerra: Look the upper track's left side of video and compare it this track's right side and adjust this track's properties so that they are same. Let me see if I understood this right: Do you want a pseudo-panorama video stitched together from three videos, with colour/brightness adjustment near the edges to conceal the seams? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] How to get same video properties on multiple tracs?
På Mon, 14 Nov 2011 20:26:26 +0100, skrev Hannu Vuolasaho vuo...@msn.com: Let me see if I understood this right: Do you want a pseudo-panorama video stitched together from three videos, with colour/brightness adjustment near the edges to conceal the seams? Exactly. Looks like quite heavy computing and andpanoramic video stitching hadn't much hits in google :( Making a panorama stitching plugin by way of shared tracks or rerouting would be, um, an interesting challenge. However, if you want to solve this problem _soon_, my suggestion would be using existing panorama tools. Some of the tools can do batch processing; UI-less conversion of still images into synthetic panoramas. So what you can do is converting those three videos into three series of still images, and batch-processing them, three by three, resulting in one series of super-wide images. Cinelerra can import wide videos or image sequences just fine. You will need disk space and time, for sure. ;-) Anyhow, this isn't exactly what you would want (or not what I would want, if I was doing this). For the result to look like actual panning, the perspective has to be transformed along with the simulated panning. This is doable within Cinelerra, using the perspecitve plugin, but tedious. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Can't change playing range in Cinelerra
På Fri, 11 Nov 2011 14:21:08 +0100, skrev Aleksey Medvedev medvez...@gmail.com: Hi! There are one small problem I have. I can't change playing range in the program (( There are two green lines in main window and when I pressing play button it plays range only between them. I've tried all possible combinations and shortcuts, but it doesn't changing.. (( So your loop range is stuck on? I suppose you set it to loop, right? Shift+l is the shortcut to turn it on and off. Have you tried the menu: Settings|Looping Range ? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] capture video from webcam
På Fri, 07 Oct 2011 22:52:26 +0200, skrev Edouard Chalaron e.chala...@xtra.co.nz: The use of it ? controlling imports or scans(like I do) with a vectorscope I am starting a hack of the invert plugin to work onscanned negative films. This is what it can be used for. What kind of camera/scanner do you scan the film with? I'm kinda curious as to how it is done, and what hardware is needed. (I could get hold of an Arri and some footage) What is your workflow, exactly? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** Reminder: Developer IRC meeting in #cinelerra today, at 16.00 UTC
Short notice, I know... Today it's the first Sunday of the month again, so there will be a developer IRC meeting in the #cinelerra channel on the Freenode IRC network, at 16.00 UTC, as usual. Topic: Is version 2.2 ready now? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Building on OSX and App Bundle
På Tue, 27 Sep 2011 15:50:31 +0200, skrev Michael Fisher mfishe...@gmail.com: Hello There, I'd like to first introduce myself. My name is Michael Fisher. I am a programmer, web developer, video/photo artist, and musician. An avid linux user (gentoo is my favorite). Cool! I would like to start helping with development of Cinelerra. I saw the news post *October 16, 2004* *Cinelerra on Mac OS X!* Adrian Prantl builds and runs Cinelerra on Darwin (with screenshots)http://stud3.tuwien.ac.at/%7Ee0025274/cinelerra/Cinelerra_on_Darwin.html. And decided to give it a shot. This is a broken link by the way. I couldn't actually get Adrian's latest patch from 2008 to let me build, so I mixed and matched his stuff with my own and am able to build the latest Git master on my 64 bit mac (10.6.8). Unlike Adrian, I chose to build all dependencies by hand. The reason being is that Macports/Fink install X11. This really isn't necesary because Cinelerra will build with the X11 SDK and libs provided by Apple. To aid in some of the heavy lifting, I went setup a gtk-osx build environment using jhbuild and then went from there. Since i'm using jhbuild it was fairly simple to create the Application bundle. The Application Bundle works without having to install any third party libraries. I haven't actually tested on another 'non-development' machine, but it should work just fine for OSX = 10.6 users. Do give it a try. I'd really like to continue on and see if I can reinvent the Linux specific code for Mac. A big (among many others) item to fix would have to be audio support. My first inclination is to create a JackAudio driver for cinelerra which in theory should work just fine on OSX to. Jack support would indeed be interesting. I use Rosegarden (a score editor) quite a lot, and it can share transport controls with other jack-enabled apps. Currently, I can use xjadeo to cue a video in synch with Rosegarden, and it would be awesome to have the same ability with Cinelerra. Besides, I think the audio subsystem needs some careful scrutiny, to figure out synch and latency issues, and hopefully solve them elegantly. I didn't attach a path because I still need to go through and fine tune it and make my changes more presentable. Since code would have to undergo some major changes, I'm wondering if I should just fork the cinelerra-cv/master to an osx and go from there. I wanted to first contact the mailing list here and get some advice from Core Developers before I just go and do whatever. Aside from working on an OSX port, I'd like to also help out wherever else needed. How deep are you ready to go? ;-) Some of us hang around on the #cinelerra IRC channel on the Freenode network. You may pop in and say hello some time. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** Reminder: Developer IRC meeting in #cinelerra, on Sunday the 4th, at 16.00 UTC
** Reminder: Developer IRC meeting in #cinelerra, on Sunday the 4th, at 16.00 UTC ** The monthly developer meeting in the IRC channel #cinelerra on the Freenode network is just round the corner: on Sunday the 4th of September, starting at 16.00 UTC. The agenda will largely repeat last meeting's agenda. One new item: * Finalising the policy document for the new official git repository. CinelerraCV 2.2 is even more imminent now, so bugfixes and features for v2.2 will be highly relevant for this meeting! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] request for plugin / negative C41 to reversal
På Sat, 20 Aug 2011 01:02:02 +0200, skrev Edouard Chalaron e.chala...@xtra.co.nz: Hi Herman I just checked the output it says 16 bits not 8. Not sure what you mean by the debugging ... do you mean the RGBA float in Cinelerra is buggy ?? Yes. Clearly RGBA FLOAT is broken. RGB FLOAT (no alpha) can be used with OpenEXR files, using the Gamma effect to yank the brightness and contrast down into the displayable range. How about changing the RGB output in the script for exr ?I understand Cinelerra is working fine with EXR Yeah, apart from the need to aggressively adjust the whitepoint and the gamma (using Cinelerra's Gamma video effect) to get anything resembling a real picture. As for the LUT this is what I want to achieve witha new plugin based on this script. Did you have a look at the new version ? negfix8 ? Nope. I'm not fluent in ImageMagick at all, and I am quite new to pixel transformation math, too. And there is no instant gratification in it for me: I don't have any negative scans at hand to try this out on. it can actually create a profile you can apply to a serie of frames. Unless I grab the flags from the EDL, create a profile for each of them,do a bash script based on frame numbers. But that would be outsidecinelerra and way more data to manage. What is the aim? A high-quality grading tool, or a real-time preview with almost correct colours? As far as I can tell, and as far as I have been told, Cinelerra in its current state isn't quite up to high quality grading. So personally, I would go for a speedy and coarse adjustment effect, for working quickly on rough cuts. Having it to work would be such a bonus gosh .. It would shorten your workflow, for sure. :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] request for plugin / negative C41 to reversal
På Fri, 19 Aug 2011 02:54:59 +0200, skrev E Chalaron e.chala...@xtra.co.nz: Hello all As you probably know I am always looking for solutions to scan negative films either in super 8 or in 16mm. So my main problem is to convert a C41 film colors to reversal and it's not as simple as just inverting, far from it. The orange bias must removed first (RGBs are 235,172,121). Have you tried using the histogram effect for that? It can adjust the response curve for each colour channel. (It happens to be a colour curve tool, too) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] request for plugin / negative C41 to reversal
På Fri, 19 Aug 2011 23:16:44 +0200, skrev Edouard Chalaron e.chala...@xtra.co.nz: Hi Herman Yes this is what I am usually doing, but results are nowhere close to this script,maybe what I need is an improved version of the histogram, with possibility ofcalculating a profile curve etc not too sure yet. The histogram seems limited to 8bit, unlike the Gamma effect that can actually adjust full range RGB FLOAT, even though the GUI suggests otherwise. That did come handy when I wanted to see an OpenEXR image displayed in a sane way in Cinelerra's compositor. Is there an API for creating video effects ? I vaguely remember that Yeah, in a way. Here is a guideline: http://cinelerra.org/docs/split_manual_en/cinelerra_cv_manual_en_23.html#SEC331 It's not super-hard. The convention of putting the business part of the plugin into a big #define macro isn't pretty, but there are compactness and performance reasons for doing so. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] request for plugin / negative C41 to reversal
På Fri, 19 Aug 2011 23:16:44 +0200, skrev Edouard Chalaron e.chala...@xtra.co.nz: Hi Herman Yes this is what I am usually doing, but results are nowhere close tothis script, maybe what I need is an improved version of the histogram,with possibility of calculating a profile curve etc not too sure yet. It looks like the script outputs 8-bit RGB. Quality film compositing should rather be done in Cinelerra's RGB(A) FLOAT colour format. But that needs some debugging, it seems ;-( Besides, two log() operations per pixel?! No wonder it takes a second each frame! You'd better fill up some look-up tables first, and use them, since there will be far less unique pixel values than there will be pixels in a frame. And SIMD optimisation will probably be worthwhile, too (MMX, SSE, etc.) Is there an API for creating video effects ? I vaguely remember that. I have dabbled with video plugin writing, and the most advanced effect that I got working properly was a random noise effect. It was fast enough for HDV video. A simpler effect was a YUV sepia toner (RGB is much harder and slower). I even did some rudimentary SIMD (via gcc's builtins), and it did speed things up a bit. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Last minute reminder: Extra dev meeting today, at 16.00 UTC. xiphmont (Monty) will attend.
We scheduled an extra developer meeting at a time that Monty would be able to attend, to discuss his experimental fixes, and how they could be merged into an upcoming CinelerraCV release. The meeting is today, at 16.00 UTC, in the #cinelerra IRC channel. The topics may get rather technical; about codecs, pixel formats, colour models, scaling functions, etc. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Reminder: Developer IRC meeting on August the 7th, 16.00 UTC
The next developer IRC meeting is in four days, on Sunday the seventh of August, 16.00 UTC, in the channel #cinelerra at Freenode. Among this meeting's topics: * Our roadmap, and the imminent release of Cinelerra-CV v2.2 http://bugs.cinelerra.org/query?group=statusmilestone=Release+of+2.2 * Setting up and maintaining an official git repository for Cinelerra-CV that packagers can pull stable releases from. The roadmap collects only some of the intetersting patches that were posted here on the Mailing list. Please, help us to make the collection more complete. There will be yet another IRC meeting one week later, where Monty (xiphmont) will attend. It is scheduled for Sunday the 14th, 16.00 UTC. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Colour spaces, dynamic range and lossy format conversions (Was: Cinelerra digest, Vol 1 #3211)
På Sun, 17 Jul 2011 07:41:18 +0200, skrev mohan manu mohan...@gmail.com: Hi, I have done shooting of my children movie with my canon 550d camera which records in h.264 50mbps bitrate vbr mov format. And have done editing with proxy files which were mjpeg codec for faster response in cinelerra. And next for grading those footages i have exported as tiff sequence removing all proxy files and workflow is going on nice. I have some doubt regarding the quality of the footages. Have you seen something with your naked eyes that gave you doubts? The big thing is my camera records at YUV color space with full video range i.e, 0-255. I choose 8bit RGB as my editing colorspace format. While i import these footages does cinelerra consider it as full range color HD footage? or does it takes on 16-235 video range? I think that is handled by the codec, i.e. the codec scales, truncates or clamps the range. But I'm not sure how, when (or if?!) that happens in Cinelerra. And does cinelerra do good job at converting YUV to RGB? I have not tested that. Monty may have some insights to share on that. Another workflow i am thinking of is converting all my original footage using 5DtoRGB which converts to RGB Huff uncompressed codec and the converter maintains full color range and does good YUV to RGB color conversion. I'm looking into DNxHD as a proxy and intermediate codec. It looks promising on my laptop. The low bitrate 36Mb/s quality can play faster than full framerate, and the high bitrate 185Mb/s quality _almost_ plays smoothly, and has visually transparent quality. Fast forward and backward and aggressive seeking are pleasantly responsive, even for the 185Mb/s version. http://www.itbroadcastanddigitalcinema.com/ffmpeg_howto.html http://www.slashcam.com/EN/info/DNxHD-with-ffmpeg-or-mencoder-under-Ubuntu-434741.html Mind you, it doesn't accept 1920x1088, the native video resolution of my Canon EOS 7D, so I have to tell ffmpeg to scale or crop it to 1920x1080: ffmpeg -i input file -b 185M -s 1920x1080 -vcodec dnxhd -acodec copy output file -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Hello
På Sat, 09 Jul 2011 14:12:17 +0200, skrev abegail benson abegai...@att.net: Hello! how are you! hope you are fine and in perfect condition. No, I'm pretty peeved that I pressed 'a', when I should just have pressed Enter to discard your spam post to this mailing list! Sorry, folks! Nothing to see here, just a slip of my fingers. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Reminder, with caveat: Developer IRC meeting on #cinelerra at 16.00 UTC today
Today is the day for the monthly IRC meeting, in the #cinelerra IRC channel on the Freenode network. The meeting will begin at 16.00 UTC ... IF ... I have a usable Internet connection around that time (I will be on a train) or if Raffaella has gotten online by that time. If you see neither raffa nor hermanr in the #cinelerra channel, hang around for a while. She may be late, and I may have lost the connection. See you! (maybe, hopefully...) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Reminder: Developer IRC meeting on Sunday, July the 3rd, at 1600 UTC.
The coming Sunday, July the 3rd, there will be a developer meeting on the IRC channel #cinelerra on the Freenode IRC network. The meeting starts at 16.00 UTC. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] CinelerraCV 2.1.5 back in AV Linux 5.0
På Mon, 27 Jun 2011 21:09:45 +0200, skrev Nicola Ferralis feran...@hotmail.com: I am concerned by the lack of response to my question. As it is, I don't think AV Linux is compliant to the GPL license, since no source is available and the web pages expressively says that AV Linux is a non-GPL Linux derivative. IANAL, but I expect the developers to provide a clue to my concern, regarding the compliance to GPL. This is my personal opinion, but I think that if not compliant, Cinelerra-CV should not advertise in the cinelerra.org website a distro in plain violation of GPL. I am looking forward to an explanation. From Glen MacArthur (the AV Linux Maintainer that started this thread) or from those doing the updating of cinelerra.org? If I had an answer, I would happily speak on behalf of the latter. But I don't think I have enough information to answer, and I hope the people behind AV Linux will comment to enlighten us. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] (Late) reminder: Monthly IRC meeting today, at 16.00 UTC.
Yes, there will be a developer meeting today, at 16.00 Greenwitch time. That's less than three and a half hours away, so it's a pretty dang short notice, for those of you who haven't lurked on IRC, or figured out the schedule. Anyhow, we will get together on #cinelerra at the Freenode IRC network, as usual, since it's the first Sunday in the month. See you there! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Highlights from last Sunday's developer meeting on IRC.
On Sun, 13 Mar 2011 09:18:58 +0100, Ichthyostega p...@ichthyostega.de wrote: Herman Robak schrieb: Planned: An Apt repository will be set up and maintained at cinelerra.org. Assigned to Herman and Raffaella. Hi Herman, funny coincidence -- today I did just that for Lumiera: configuring an Apt repository; I choose a setup of middle complexity level (not the simple version 'dump all in one directory' and not the full-blown DB backed distribution-scale online repository). Anyway. if what I've found out and set up might be of some help for creating an Apt repository for Cinelerra, I'd be glad to share more infos I think it would be of some help. :-) What's the URL to the repository? What steps did you follow to create it? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: [CinCV] Cinelerra på Ubuntu 10.10?
On Sat, 12 Mar 2011 13:36:17 +0100, Chris Nørve blackoutw...@gmail.com wrote: Hei. Jeg lurte på om dere kunne lage en repository eller .deb pakke fil for ubuntu 10.10? Hi. I wondered if you could make a repository or .deb package file for Ubuntu 10.10? Jeg så at det var en for 8.04 men den funket ikke for meg. I saw that there was one for 8.04 but that didn't work for me. Det er dessuten litt trøyt at dere har repos for så gamle versjoner fremfor de nye. Besides, it's quite beyond reasonable that you have repositories for so old versions, rather than the new ones. Jeg prøvde også repoen for Debian men den funka heller ikke. Please fiks dette. I also tried the repo for Debian, but that did not work either. Please fix this. We're working on it, Chris. If it's not straightened out in a week, you may nag again! :-) By the way, you wrote to a mailing list, and most of the subscribers are not Scandinavian. So please write in English. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Highlights from last Sunday's developer meeting on IRC.
1. Sorting out release versioning. Planned: Source tarballs will be made for each numbered release. An Apt repository will be set up and maintained at cinelerra.org. - Assigned to Herman and Raffaella. j6t's Git repository will be the hub, pretty much as before. 2. Systematic regression testing and self-tests Planned: A comprehensive testsuite. - Assigned to Herman 3. New users need reasonable defaults. In progress: a) Hard-coding some defaults that we agreed were better. b) Make a timezone to TV standard mapping (PAL or NTSC), to automatically choose PAL or NTSC as the default resolution. - Assigned to Einar 4. Merging in ichthyo's bezier patch - Assigned to Raffaella 5. Output formats Planned: Extensive research! Overlaps with (2), the testsuite. To be revisited at the next meeting on April 3rd. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] ** REMINDER: Developer meeting on IRC, tomorrow, at 14.00 UTC. **
What needs doing? Join us tomorrow at #cinelerra on the Freenode IRC network! There will be a developer meeting at 14.00 UTC (that's GMT, the timezone they use in Britain) Agenda here: http://cinelerra.org/docs/wiki/doku.php?id=meetingagenda Short agenda; it's the first developer IRC meeting, so it is pretty open. Welcome! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra roadmap
On Mon, 21 Feb 2011 18:04:31 +0100, Nicola Ferralis feran...@hotmail.com wrote: Thanks, Herman. I'd like to suggest an alternative, more dynamic way of versioning Cinelerra. Instead of having patches committed in trunk and at some point (which is not described anywhere) do a 2.1.x release, what about using the Google Chrome/Chromium approach to have a fast pace versioning? Basically every time a patch is applied, there would be a version bump (maybe not immediate, but after some time of testing). I don't think browsers and video editors are quite comparable. For most users, browsers are consumer tools: They use them to pull stuff from the net, to get information or entertainment. Using the browser as a content _editor_ is indeed possible with current browsers, but it's not perceived as highly reliable yet. Editing video is a time-consuming task. Since Cinelerra is a high-end oriented editor/compositor, users may spend days or weeks on a single project. If an upgrade breaks such a project, it's a huge deal for the user. There won't be an easy work-around, like press reload, or load it in another browser. However, we have to get versioning straightened out, for sure. Release snapshots should be published as properly named .tgz archives, and tagged in Git. (This will be one of the topics on the upcoming developer meeting in five days: Sunday March 6th, at 14.00 UTC, in the #cinelerra IRC channel. More on that in a separate e-mail.) Cinelerra's project files should get a version number added to them, so that version-specific work-arounds can be applied, if needed. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Developer meeting, Sunday the 6th of March, 14.00 UTC
There will be a developer meeting in the #cinelerra IRC channel next Sunday, at 14.00 UTC (that's GMT). That's 3 PM in most of Western Europe, and early in the morning in the Americas. Points for the agenda: http://cinelerra.org/docs/wiki/doku.php?id=what_needs_doing -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra roadmap
On Tue, 15 Feb 2011 06:03:46 +0100, Nicola Ferralis feran...@hotmail.com wrote: In the past few weeks, there has been a very interesting discussion in this forum about the long term future of Cinelerra. This discussion made me wonder if a short-term roadmap of Cinelerra really exists. In particular I wonder if there is any set decision for a version 2.1.7 (and 2.1.8, 2.2, etc)? No, I don't think there is any off-list coordinated planning going on to write a roadmap for the next release(s). Not yet, anyway. I'd like to hear some thoughts about this. As the maintainer of the Cinelerra-ppa for Ubuntu, I wonder if instead of syncing only official releases, I should instead sync with git every time a commit is pushed. In this latter case, I would think a bump in version should be adopted. Good points for the agenda of the not-yet-scheduled developer meeting. :-) It's been too long since I wrote what needs doing, without any progress report or any meetings or published TODOs. Readers are getting impatient. Not good. Why? Well, the webmistress got very busy with other film/video related stuff, and I got occupied learning Cinelerra plugin programming, and other unrelated stuff. Besides, it's winter up here. So there has been too little worth reporting, but we're not dead yet. ;-) Anyhow, I don't feel _quite_ ready to lead a long march to a Next Gen Cinelerra, yet. And I do think some firm and competent leadership would be a Good Thing. I am ready to start scrathing my own itches, and fix some other users' woes if they happen to be related to mine, as a start, using the cinelerra.org DocuWiki as a kind of blog to tell about it. It's too early to say which wishes any of the coding contributors will be able or willing to fulfill. I only promise that there will be _some_ activity within the next few days. Best wishes! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] I uninstalled Cinelerre from my Linux Ubuntu computer and the download site doesn't respond
On Fri, 04 Feb 2011 12:39:04 +0100, rbthorne...@netzero.net rbthorne...@netzero.net wrote: I uninstalled Cinelerre from my Linux Ubuntu computer and the download site doesn't respond This one... https://launchpad.net/~cinelerra-ppa ...or this one... http://akirad.cinelerra.org/ ? Sir/Ma'am, Where do I find a download site for Cinelerra; I'm using Linux Ubuntu on an Eight-Virtues Linux computer. http://akirad.cinelerra.org/ is abandoned, try https://launchpad.net/~cinelerra-ppa. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Performance targets: How fast is good enough, and on what hardware?
Cinelerra can edit video in the TV resolutions (PAL and NTSC) of yore on typical affordable hardware. An old laptop will do, if the screen isn't too small. But new cameras, real cameras, not cell phones, tend to record HD video. That's 1280x720 or 1920x1080, two or four times as many pixels as good old SD. Fairly new computers can play that in a video player, but what about Cinelerra? On my 2x2 CPU 2 GHz Opteron computer, browsing HDV and DSLR footage in Cinelerra is a bit unresponsive. Forward playback at normal speed can be smooth without dropped frames, at the very best. Scrubbing (dragging back and forth on the timeline) is pretty sluggish. Backward playback gives a very low framerate, and doulbe speed forward is jerky, too. I'll call my user experience, as described above, minimum: * Forward playback without dropped frames * Scrubbing at least 2 frames per second, with less than 0.5 second lag * Backward playback somewhat working Here is what I would consider nice and snappy: * Forward playback without dropped frames, even accross edits * Double speed forward playback at full framerate (at least!) * Normal speed backward playback without skipping frames * Double speed backward with smooth movement (no jumps or jerks) * Seeking/scrubbing with at least half the native framerate * Full rate forward playback of _two_ layered video tracks * Full rate forward playback with one effect applied. DV satisfies nice and snappy, whereas the HD formats of my cameras barely qualifies for minimum. The AVCHD performance is not even minimum. (Yes, Cinelerra built from Monty's git handles AVCHD :-) Conclusion: For a good user experience and workflow on current, affordable hardware, Cinelerra will need some kind of proxy format to deal with AVCHD, HDV and DSLRs' h.264 footage. I write proxy, not intermediate, because I think the final rendering should use the original video files as its source. The rendering goes only forward, and can take its sweet time. Editing goes back and forth at the user's whim. It should be fast and responsive, always! If you feel that you have something to add, go ahead! :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] What needs doing, and how do we do it? (was: cinelerra fork)
On Fri, 28 Jan 2011 23:17:03 +0100, flavio qazav...@gmail.com wrote: Still on the functionality issue, one thing that may or may not be easy to do, but would help a lot is to create shortcuts to toggle between the copy and paste and drag and drop editing modes. How about [Shift]? It would make even more sense if Drag-n-Drop was the default mode. Pressing [Shift] to drag-select is an old, established and _expected_ convention, after all. Every now and then, when I use dn'd, only the video is draggedand the audio just stays there, so I do most of my editing using cn'p. That's bugworthy. Having a lock between a group of tracks, like the audio and the video, has been mentioned and requested before. IMHO, audio tracks should be locked to the video at import time. Staying in synch is the expected. However, there will be exceptions and dilemmas: What if a locked audio track is not armed? Cinelerra would have to show the user that there is a conflict, and give a hint about the solution, in a _very_ clear and obvious way. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] What needs doing, and how do we do it? (was: cinelerra fork)
On Fri, 28 Jan 2011 14:22:51 +0100, Rebecca beccato...@hotmail.com wrote: In terms of things I think Cinelerra needs to improve on – Interface I don’t actually think this is a really big deal.Sure a more attractive interface would be a bonus, but honestly I thinka reskin on the level of what Cinecutie did is adequate. I agree. At least in the short term. And that is pretty low hanging fruit. Transitions I come down firmly on the side of not transitioning between tracksby default – I like the way transitions are displayed now. It would be nice if they could be “dragged” to increase or decreaselength rather than right-clicking and manually assigning a length, There is another snag with transitions: They are applied _before_ the effects. If you have applied some different colour and contrast effects to scene A and scene B, then add a transition between them, then scene A will snap to raw and uncorrected when the transitions starts. Making transitons post-effect would likely be a rather invasive change. But it's the only way to make grading and transitions in one pass, with acceptable results. Functionality Finally, but probably most importantly, some words on generalfunctionality. I am actually pretty happy overall with Cinelerraand its capabilities. I think the most glaring absence is thenested sequences feature – Yes! It's direly needed for larger projects. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] What needs doing, and how do we do it? (was: cinelerra fork)
On Fri, 28 Jan 2011 18:39:02 +0100, august aug...@alien.mur.at wrote: I've used cinelerra for years ( more than 10) now Wow, a really early adopter! (Or was that Broadcast2000?) and just recently switched to KDenlive. Cinelerra has been left to rot this past year it seems. I don't use effects (except for color balance) and have very few demands on a video editor. It should just cut tracks one after the other and be able to add sound on separate tracks. However, to do even that, I have to transcode 3 times. Clearly unacceptable for anything but truly oddball formats. Cinelerra must become(*) able to import aquisition formats du jour, and that includes AVCHD. If scrubbing and seeking is too crappy with those formats, it must create a suitable proxy _itself_, and use that for editing (not for rendering, which is sequential, and not realtime). Also, reasonable output formats in high demand need to be there, and just work. Maybe asking for built-in DVD authoring is a bit much, but rendering muxed MPEG-PS in _one pass_ isn't too much to ask. Just to mention one example... I'm willing to work on that. I don't know how, but I'm sufficiently irked to disregard that minor shortcoming for a while... *) and remain able to load/render mainstream formats That means some development and testing effort from time to time. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] What needs doing, and how do we do it? (was: cinelerra fork)
Hi, everyone. I'm Herman Robak, the moderator of this mailing list. 8 years ago, I suggested forking Cinelerra in a post to the web forum on Cinelerra's Sourceforge site. The result was the Community Version, a branch of Cinelerra hosted at the same server as skolelinux.no. To make a long story short: I was involved with the formation of Skolelinux, now a sub-project of Debian-Edu. We saw a need for a _usable_ and capable video editor that schools could use. Free Software for Linux, of course. :-) So I used Skolelinux' server to host the CVS repository we set up. The web page and the repository(ies) has since moved to their own server, but the mailing list is still hosted by Linpro, with the same name as in 2003. During the first year of CinCV, the pace of progress was good, and the attitude was quite ambitious and optimistic. Fast forward to 2010, when the activity is on the rise again. Lumiera is still several years out, and we need something good in the meantime. I don't see any other strong candidates than Cinelerra, really. So what needs doing? ** An agenda, some kind of schedule, and a place to maintain it. I suggest a corner of the Documentation Wiki at cinelerra.org (Maybe frequent IRC meetings, too) * A modest makeover of the GUI's look and feel. That can be started right away, focusing on low hanging fruit * A dig through the pile of old bugs, to find repeat offenders, typical annoyances, and hopefully some underlying causes. * A performance review (like, framerate and responsiveness) for typical loads (DV, HDV, DSLR footage, multiple tracks) and various hardware. * Setting some performance targets: By profiling Cinelerra's resource use, and comparing with other applications, find out where and how Cinelerra _should_ perform better. This will require some effort from programmers. (By should I mean can be done rather than expected) ** People with the time, skills and ambition to do the above. What is currently going on? Some development here and there in various git repositories. Preparations for a makeover of the cinelerra.org site, and preparations for automatic builds and packaging (nightly builds, pulled from git.) A word of advice: Have computers do the tedious and repetetive work, like building, packaging and simple tests! We need the manpower for other things. Who's in? Developers, testers, designers, tutorial writers, videographers, editors, sound recordists, anyone and everyone! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] cinelerra fork.
On Wed, 26 Jan 2011 16:02:36 +0100, yosepkey yosep...@gmail.com wrote: Anyone know of a fork of cinelerra. If I knew, I'd make one. Anyone interested? What kind of fork, and what for? You may consider the one which is hosted at cinelerra.org (community version 2.1.5) a fork of the upstream, which is hosted at http://heroinewarrior.com/cinelerra.php By the way, you may join the IRC channel #cinelerra at Freenode for a chat. I'm hanging out there right now. :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Fwd: Jerky movements in rendered movies
Interlace mode TFF Here comes the problem: when I load the mpg files in Cinelerra resources window and move them to the viewer window they don't play back correctly. This particular scene is a bridge with cars passing by at high speed. At a certain moment cars suddenly jump back and forth. . I rendered the whole movie in Cinelerra with my own created Use Pipe: ffmpeg -f yuv4mpegpipe -i - -y -target pal-dvd -flags +ilme+ildct -f mpeg2video % to a m2v file with YUV4MPEG Stream format (since the supplied ffmpeg pipe with -ilme -ildct -hq does not work in the ffmpeg version I have). This m2v file contains the errors described when played in any player. I checked the original MOD, the original MOD file renamed to mpg and modcopied mpg file in all players I have, like Avidemux, Totem, VLC, Mplayer and Xine. I could not find any playback defect in any file. My questions: 1 What could have gone wrong with Cinelerra showing corrupt images? It is supposed to leave resource files untouched and just make a road book from which file to take which frames. 2. Is there some setting I've done wrong? 3. Is there something I can improve on the ffmpeg options? 4. If someone wants to investigate the raw material I can send or post it somewhere. Please provide instructions. In the mean time I did various tests on multiple computers, multiple versions of Cinelerra but there is no improvement. I'm hesitant to redo the whole movie in e.g. Kdenlive as it contains over 700 scenes. I would really appreciate your help. Yours Sincerely, Sape -- Herman Robak
[CinCV] Shutting down cinelerra-commits, as it has been idle for a couple of years.
After we transitioned from Subversion to Git, the cinelerra-commits mailing list became inactive. I'm shutting it down. The web archive is still up. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
