Re: [CinCVS] Keyboard ShortCut referance guide
On Sun, 2007-08-19 at 23:13 +0200, Jay wrote: i am sending a small image file thate makes an easy graphical referance for the keyboard shortcuts Nice image, Jay!:-) It is worth being inserted in the Manual. I noticed you used some wordings slightly different from the ones used by the Manual. Could it be possible that you (or me) make them match? Do you have a Spanish version too? Is it translatable to other languages? What do you think? Ciao Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [Bulk] Re: [CinCVS] help converting .ogg to .mpg
Christian Einfeldt wrote: hi Thanks for this suggestion! But a few questions: On 8/20/07, *Aaron Newcomb* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ffmpeg -i file.ogg file.mp3 Why did you leave out -o ? For example, why not: ffmpeg -i flie.ogg -o file.mpg? Becouse thats how ffmpeg works. Also, someone else suggested that I do this: ffmpeg -i mansour.ogg -target pal-dvd mansour.mpg This will give full frame DVD. The source is though normally not a full frame. Consider. ffmpeg -i file.ogg -target pal-dvd -s 352x288 file.mpg ffmpeg -i file.ogg -target pal-dvd -s 352x576 -aspect 16:9 file.mpg Remember that the ITU-Rec 601 spesifies that the viewable screen is 702 px wide. So the 4:3 og 16:9 is on pal 702x576. Consider therefor croping the source on the side, if there are black lines. This will give you better compression. ffmpeg -i file.ogg -target pal-dvd -cropleft 8 -cropright 8 -s 704x576 -qmin 6 file.mpg ffmpeg -i file.ogg -target ntsc-dvd -cropleft 8 -cropright 8 -s 704x480 -qmin 6 file.mpg The qmin prevents unnecessary runaway bandwidth usage. (goes in to VBR when q=6, prevents padding, 6 is a LOW number) Again, I am noticing that there is no -o here. Why is that? Also, I am in the US, and I am primarily interested in distributing this film via the Internet Archive and YouTube. I guess that we could re-render for PAL and NTSC later. You should render what the source is closest to. If it's from a NTSC source (eg 320x240,15fps), use NTSC. Thanks again everyone for the suggestions! :-) -- Mike Menk ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Keyboard ShortCut referance guide
I agree that suggestive wording is important. So if you don't mind, i'd like to propose a few pedantic changes: 1. instead of PlayBack use Backwards. Paradoxically, playback means play forward in time. 2. instead of RwndFast use FastBackwards. Rewinding is done with tapes, and especially during fast rewinding, one cannot usually see what is on the tape. 3. instead of Marker, use Label to fit the l key, and instead of Load, use Open to fit the o key. Furthermore, I wonder wether we should pay attention to the case sensitivity of cinelerra's commands, e.g. use o instead of O where o is needed. This would make sense because there are both the r and R commands (record and Render). It would however require quite a lot of rewriting... :-( georg On Tuesday, 21. August 2007 12:47:12 Raffaella Traniello wrote: On Sun, 2007-08-19 at 23:13 +0200, Jay wrote: i am sending a small image file thate makes an easy graphical referance for the keyboard shortcuts Nice image, Jay!:-) It is worth being inserted in the Manual. I noticed you used some wordings slightly different from the ones used by the Manual. Could it be possible that you (or me) make them match? Do you have a Spanish version too? Is it translatable to other languages? What do you think? Ciao Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- dr.k.g.hooss schoepfung wandel wissenschaftliche medienberatung breite strasse 6-8, d-23617 luebeck www.schoepfung-und-wandel.de ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] linux fund
I just found this, potentially damning, fineprint: The current criteria is that the projects have to have a substantial user base (over 10,000 users) and they should be significant for the future in some way. How would we know or prove such a thing? It seems like a big number. I wonder if Blender would pass on this criteria? Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] linux fund
http://www.linuxfund.org LinuxFund is looking for a few more good projects to fund. Our criteria is pretty simple at this point: Open Source and used by thousands of people. Take a look at the projects we're currently funding and if you have a candidate please send the nomination to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. Please include contact information and in 200 words or so, tell us why you think this is a great candidate for us to support. I'm not sure the likelihood that cinelerra (or cinelerra 3 ??) would get some funding. Or how such money would be spent. But that application process sounds pretty easy. I have applied for grants before and I have never heard of it being that easy. Past projects they funded which have a passing resemblance to cinelerra were: Jahshaka, Film gimp, and Simple DirectMedia Layer. Blender received money last year I was wondering whether libcinelerra might be a project worth seeking funding for - or for the entire (proposed) cinelerra3 project. Or money for Adam. Or money for someone to tackle the backlog of bugs. I think of those 3 graces libcinelerra might have the necessary sex appeal (does it for me!). Would it be better for it to have an explanatory name as in *Simple DirectMedia Layer *project? The marketing dogma these days recommends names that describe... That's a tangent anyway - but the api could have a new name and the NLE built on top could still be cinelerra. Anyway off that tangent and back to the funding: Does anyone else think this is worth following up? Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 440] segfault when rendering to ogg
http://bugs.cinelerra.org/show_bug.cgi?id=440 --- Comment #5 from [EMAIL PROTECTED] 2007-08-21 16:43 +2 --- I can reproduce this bug. 1. Load an ordinary camcorder clip (.mov from dvgrab). 2. Render it to OGG Theora/Vorbis with Replace existing project as insertion strategy. 3. The green progress bar shows the rendering progressing up to the end. 4. Cin crashes. All the insertion strategies that load the file after rendering make Cin crash. Only Insert nothing strategy doesn't cause the crash and produces a rendered file. If you load this rendered file, Cin crashes. To me this looks just a consequence of the OGG bug. Cin can't load OGG Theora/Vorbis files. Not via Load files... nor via Render. Actually, if I keep trying, I can successfully load an OGG Theora/Vorbis file (after 5-10 attempts). Once loaded, that file is stable and can be played. Following attempts to load the same file will show the bug again; the file will be loaded only after 5-10 attempts. If this project is saved, the XML containing the .ogg file opens as dreamed (10 times out of 10). Similarly, if I keep trying, I can successfully render (with any loading insertion strategy) an OGG Theora/Vorbis file (after 5-10 attempts). I think this bug is related to bug 412 Loading an ogg/vorbis file crashes Cinelerra. I see no difference in the behaviour of OGG Vorbis audio files and OGG Theora/Vorbis video files. My Cinelerra rev.1015 lives on Ubuntu Feisty. Good bye Raffaella -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Keyboard ShortCut referance guide
On Tue, 21 Aug 2007, Kurt Georg Hooss wrote: This would make sense because there are both the r and R commands (record and Render). I'd suggest instead of using letter case to describe the difference, use the actual keystrokes: R for record (the key on the keyboard has an uppercase R on it, never mind that on some internal level it translates to a lowercase r ASCII code) and Shift-R for render. I think that's more consistent with other software documentation. -- Matthew Skala [EMAIL PROTECTED]Embrace and defend. http://ansuz.sooke.bc.ca/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [Bulk] Re: [CinCVS] help converting .ogg to .mpg
Hi, Thanks Michael Eric for this nicely detailed reply! On 8/21/07, Michael Eric Menk [EMAIL PROTECTED] wrote: Christian Einfeldt wrote: hi Thanks for this suggestion! But a few questions: On 8/20/07, *Aaron Newcomb* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ffmpeg -i file.ogg file.mp3 Why did you leave out -o ? For example, why not: ffmpeg -i flie.ogg -o file.mpg? Becouse thats how ffmpeg works. Also, someone else suggested that I do this: ffmpeg -i mansour.ogg -target pal-dvd mansour.mpg This will give full frame DVD. The source is though normally not a full frame. Consider. ffmpeg -i file.ogg -target pal-dvd -s 352x288 file.mpg ffmpeg -i file.ogg -target pal-dvd -s 352x576 -aspect 16:9 file.mpg Remember that the ITU-Rec 601 spesifies that the viewable screen is 702 px wide. So the 4:3 og 16:9 is on pal 702x576. Consider therefor croping the source on the side, if there are black lines. This will give you better compression. ffmpeg -i file.ogg -target pal-dvd -cropleft 8 -cropright 8 -s 704x576 -qmin 6 file.mpg ffmpeg -i file.ogg -target ntsc-dvd -cropleft 8 -cropright 8 -s 704x480 -qmin 6 file.mpg The qmin prevents unnecessary runaway bandwidth usage. (goes in to VBR when q=6, prevents padding, 6 is a LOW number) Again, I am noticing that there is no -o here. Why is that? Also, I am in the US, and I am primarily interested in distributing this film via the Internet Archive and YouTube. I guess that we could re-render for PAL and NTSC later. You should render what the source is closest to. If it's from a NTSC source (eg 320x240,15fps), use NTSC. Thanks again everyone for the suggestions! :-) -- Mike Menk ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- Christian Einfeldt, Producer, The Digital Tipping Point
Re: [CinCVS] libcinelerra3
Interesting thoughts, Richard. While I do think that Cinelerra could use a deal of refactoring and general cleaning up, I very much agree that a completely new base is not necessary. A lot of work has been put into what's already here, and it would be a shame to lose it. Your three suggestions --particularly 1 and 2- are absolutely precise; a quality deinterlacer and a decent color grading solution are the primary lackings in open source video software. I've particularly been missing SyntheticAperature since making my switch to Linux. I've managed to rig a basic 3-way color corrector in Blender's compositor, though the workflow is absolutely horrific. Anyway, I work professionally in film and video and have a fair amount of experience with various color correction tools --SyntheticAperature, NUKE, IFX Piranha- so if anyone's up for the task of implementing an open source color correction app/plugin, I would be thrilled to provide my thoughts and experience on how such tools work. Several months ago actually, I wrote a very general spec for a 3way cc: http://fouressence.net/3way/DescriptiveLanguage.pdf If interest starts to pick up on this topic, I'll be thrilled to delve more deeply into the workings of color correction tools. Thanks Richard for bringing these points up. Definitely worth some thought. -=Derek Hi, I just read through these plans for an API to the cinelerra functionality, and I'd like to share my views a little. First of all, I do believe that everyone should hack whatever he wants to, as long as he does it for fun. ;-) Ok, now what I don't like. In my opinion there are already plenty of options for doing scripted or programmatical video editing. I remember that I did that a long time ago using shell and imagemagick. And even today, I find it fairly easy to hack up simple video tools using libquicktime and gavl. I agree though that this might require a little creativity and programming experience, but I guess you'd need that too for any vision of libcinelerra. So a duplication of efforts here IMHO. On the other hand I do like to imitate and recreate other peoples software too, so if you feel you can make a difference, go ahead and do it. :-) On the other hand, I do have a couple of ideas that I feel would not only make a difference, but could be fun too. This is just I list of random stuff that I think is missing in the free and open source video editing space, and that would be useful to a number of projects, including, but not limited to cinelerra. 1) Image-based Autodetection for Interlaced Video and 3:2-Pull-Down Sources. required Skills: C or C++ Image Processing and Analysis Algorithms Tasks: create a simple set of libs and commandline tools for the purpose named above, in a fashion that they can be reused by a number of diverse open-source video-editing and conversion applications. Why: While converting between different formats is use case that is widely implemented in the open source space, there are limited tools for professional formats, that is formats used by people how produce media contrary to consuming media. Interlaced And Telecined Video is such a category that is mostly neglected by common tools, and even if implemented there are plenty of occasions where users could screw up, so strong autodetection features would certainly be useful. especially because not all devices and formats apply flags media files to specify exactly what kind of source is used. (Example: Camcorders exporting 24p as Telecine, or distingishing between 25i and 25p DV-Files) 2) Color Corrector Reverse Engineering: required Skills: Solid Understanding of Color Correction and LUTs Access to various Color Grading Apps Knows how to use test images and histograms to conclude from UI-Interaction to color computation. No Programming required. Tasks: Use, analyse and document commen User-Interfaces and commerzial tools, with the aim to recreate the user interface, to make it easier for users to switch to other tools and platforms. Remember: The algorithms for color transformations are mostly trivial, it's the more advanced user interface that provides access to these features. Imagine if you would combine a selection of different cinellera plugins for brightness, gamma, colors, saturization into a single plugin with an interface using colorwheels and all the stuff the windows-kids like. 3) Interoperability Engineering: required Skills: Experience with SDKs and Plugin-Development on Popular Commercial NLE Software C/C++ Tasks: Port Plugins and Technology developed in the Tasks above as Open-Source and Free Software to other Platforms, Applications and Plugin-Specifications, to promote Interoperability, Free Software, and to help people switch to Free Software by giving them a preview on the available Technology. And to promote the idea and friendliness of Free Software in Communities around
Re: [CinCVS] Fancy Titles HowTo
great! thanks. I have been looking for that. On 8/21/07, Jonas Wulff [EMAIL PROTECTED] wrote: ctrl-left click on your keyframes in the timeline -- first you'll get the left, then with a second click on the keyframe you'll get the right handle to tune how the curve looks like (and, in this case, to make it a straight line). On Tue, 21 Aug 2007 14:06:23 -0400 Aaron Newcomb [EMAIL PROTECTED] wrote: bezier handles? where are these bezier handles you speak of? On 8/21/07, Jonas Wulff [EMAIL PROTECTED] wrote: Another thing about professional credits is that their scrolling speed is usually constant, so one should make sure to use the bezier handles to prevent motion 'fade-in/-out'. Just to mention. Good idea to use OO! Jonas On Tue, 21 Aug 2007 09:59:16 +1200 David McNab [EMAIL PROTECTED] wrote: Hi all, After struggling with the limitations of the 'Title' plugin, I just tried out an idea for getting more professional-looking scrolling credits working in Cin (came to me when I was drifting off to sleep last night). Straightforward process, using 100% open source tools and a simple 3-step procedure. I've written it up as an HTML 'HOWTO' page and stuck it up at: www.freenet.org.nz/misc/cintitles The page includes links to all the demo files involved. For basic scrolling animation of formatted titles, it's way easier than doing it in Flash (eek! proprietary!), converting and importing into Cin. Enjoy! Cheers David ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- Thanks, Aaron Newcomb http://www.thesourceshow.org http://www.opennewsshow.org ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
On 2007-08-19 18:41, Kevin Brosius wrote: On 2007-08-19 10:50, Graham Evans wrote: ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(fdct_mmx.o): could not read symbols: Bad value did not look into it but must be a change after my patch from earlier this year. j I'm pretty sure I can help with this one - by reposting a patch posted earlier by Hermann (easier than tracking down and constructing a useful link). Around the time of cinelerra svn 1000 I switched from fedora to debian sid and couldn't compile cinelerra anymore. My distro is debian sid pure 64 on an amd64smp/openGL system. I was having all sorts of fpic and ffmpeg problems exactly like the one above. Hermann had a patch which only changed one line in a makefile and that fixed all my problems. It looks like this patch has not been committed. Perhaps it will help you (attached). I'm not sure why this patch is not committed - perhaps there is some uncertainty whether it is sound for all build systems. With this patch I have been building all recent svn versions up to svn 1017 without any compile flags. best of luck and please send in any feedback which might help this patch get evaluated. Thanks Graham, I suspect no one knew the full impact of this change. I think it will fix my build problem also. Does anyone have a system that builds without -fPIC on a 64 bit platform (either amd64 or Intel?) I think that is the only case that may break with the change. I don't see any results for this case, although there are some comments that fPIC should not be needed in all cases. Well, this has been a long and somewhat painful investigation. :) I can answer why the original patch is not or should not be committed as is, Graham. It breaks 32 bit intel/amd platform builds. I've extended it and will commit a change that should work on all intel/amd 32 and 64 bit systems. Please let me know if anyone sees trouble with builds afterwards. The short version, is that ffmpeg/libavcodec in our tree needs -prefer-non-pic for 32 bit platforms, but not 64 bit (on the platforms I tested and for the people who reported in this thread.) If you disable PIC completely on 64 bit platforms, you will normally fail to link, either the ffmpeg portion or a higher level library. On 32bit, it's a little more complicated. ffmpeg/avcodec builds with PIC, but selectively. The mpegvideo_mmx file can not build with PIC, else it will not have enough registers to compile successfully. The -prefer-non-pic causes ffmpeg to build some files with PIC and some without, mpegvideo_mmx being built without PIC. I suspect you can break the build by overriding all this with one of --with-pic or --without-pic on the top level configure. Thanks to all for the feedback and build logs. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Kevin Brosius wrote: Well, this has been a long and somewhat painful investigation. :) I can answer why the original patch is not or should not be committed as is, Graham. It breaks 32 bit intel/amd platform builds. I've extended it and will commit a change that should work on all intel/amd 32 and 64 bit systems. Please let me know if anyone sees trouble with builds afterwards. Thanks to all for the feedback and build logs. It was nice to use some of those new build skills Hermann taught me a little while back. Next in my quest to hack on cinelerra is probably to learn some C++ . Anyway thanks Kevin for getting to the bottom of this but I still have a problem: /bin/sh ../libtool --tag=CC --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -o libmpeg2enc.la conform.lo mpeg2enc.lo putseq.lo putpic.lo puthdr.lo putmpg.lo putvlc.lo putbits.lo predict.lo readpic.lo writepic.lo transfrm.lo fdctref.lo idct.lo quantize.lo ratectl.lo stats.lo motion.lo cpu_accel.lo fdct_mmx.lo fdctdata.lo idct_mmx.lo idctdata.lo quant_mmx.lo quantize_x86.lo predict_mmx.lo predcomp_mmxe.lo predcomp_mmx.lo -lm -ldl -lpthread ar cru .libs/libmpeg2enc.a .libs/conform.o .libs/mpeg2enc.o .libs/putseq.o .libs/putpic.o .libs/puthdr.o .libs/putmpg.o .libs/putvlc.o .libs/putbits.o .libs/predict.o .libs/readpic.o .libs/writepic.o .libs/transfrm.o .libs/fdctref.o .libs/idct.o .libs/quantize.o .libs/ratectl.o .libs/stats.o .libs/motion.o .libs/cpu_accel.o .libs/fdct_mmx.o .libs/fdctdata.o .libs/idct_mmx.o .libs/idctdata.o .libs/quant_mmx.o .libs/quantize_x86.o .libs/predict_mmx.o .libs/predcomp_mmxe.o .libs/predcomp_mmx.o ar: .libs/fdct_mmx.o: No such file or directory make[2]: *** [libmpeg2enc.la] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 [EMAIL PROTECTED]:~/install/hvirtual$ I tested svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 smp with nvidia opengl driver. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 [EMAIL PROTECTED]:~/install/hvirtual$ I tested svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 smp with nvidia opengl driver. Kevin Please ignore my message for now. I'm not sure what's wrong but I'm getting this same build error for svn 1017 as well at present. I must have messed something up. I will do a clean svn upload and try again. That could take a while on dial up. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
