Re: [CinCV] Animating in Cinelerra ( was: thanks to g-raffa)
Cinelerra is useable with everything so long as you're happy to transcode where necessary. Mostly with animation its easiest to use image lists and image sequence formats (PNG sequences are pretty good). If you want vector animation then unfortunately the answer may not be oss. I have fun with anime studio pro 6.2. They're at version 9 now but 6.2 was the last native Linux version. It's cheap to buy and a fun, productive tool. Synfig is powerful oss vector animator but quirky, gnarly and slow. You'll likely get bogged down in the tech with that one . Pencil is not stable enough and the vector part is a joke. I do frame by frame animation with chains of scripts, gimp and gap plugin, command line tools like imagemagick, a sheet feed scanner, art rage running on wine, mypaint animation version... some nice little gtk mini applications, and some nautilus scripts I stole from anime studio forum members. Inkscape might be a good way to create static animation layers with vector techniques. You would then have to rasterise your scene before bring it into your compositing stage. LinuxStopmotion is sounding like an awesome upgrade on the only real Linux tool of any worth in that area. I will be playing with that one soon and can't wait. I hear stuff about Blender all the time but don't know anything from personal experience if it works or is worth the time investment. Other than that Linux anmation has a bit of vapourware and half finished products (ktoon). Graham Robert Lee robert@gmx.net wrote: hello, what linux programm would you use for animations? what works good with cinelerra? greetz LEE Am Montag, den 26.12.2011, 12:45 +0100 schrieb Haldun ALTAN: Thank you for your nice words Hermann. I used to call this the lazy way :)) haldun. Le 25/12/2011 04:11, Ichthyostega a écrit : Am 24.12.2011 19:07, schrieb Haldun ALTAN: Well of course you duplicate the last image every time and you move your letters on that image so you wont begin everything on each move ;-)) It's a liitle bit work but it's ok. how clever, just using the proven principles of stop-motion in the virtual world of computers! Hermann V ___ 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
Re: [CinCV] avi yuv2 render size is huge and no playback plugins
While abstractly I understand the difference between codecs and containers/formats, everyone always talks as if its easy for end users like me to choose the underlying codec of their container formats. If there were some way for me to flip a switch on UYVY versus YUYV ordering, or mjpeg versus yuv2, then I would *love* to know about it. Right now I know of no way to control that in cinelerra or any other software. forgive me if I missed the point of the thread which I skipped through but - In the render dialog look beside the words 'Audio:' and 'Video:' for a little spanner symbol. You click on this symbol and you can indeed change the sorts of parameters you're talking about. Perhaps you already knew this but many (including me) miss the significance of these little symbols until pointed out. Graham ___ 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
Re: [CinCV] Re: my incompetence or buggy as hell?
Jeff Gerritsen wrote: However, the popping is gone, and when I select a section to render, the rendered file has no popping noises. I'm using the original uncoverted .avi file I experienced popping noises when I converted the .avi file to .dv using ffmpeg. I also used the same time marks in the .avi file, that the popping noises existed in the converted .dv file. The only difference is I'm using the unconverted .avi file instead of the converted .dv file. So to sum everything up, we've fixed several issues, but have a seemly benign intermittent error message that all one needs to do is click okay and continue. I may know what your problem is. DV format handling in Cinelerra-cv had such popping noises until some stage in the last 12 to 18 months when this problem was fixed (by Richard Baverstock I think). Putting the DV into a container format such as quicktime/mov or avi was the known workaround to avoid this popping prior to the dv bug fix being committed to svn. Any new cinelerra-cv version shouldn't have this problem. Personally I now find 'native' dv format very convenient to work with - and I have an cinelerra-cv checked out from the svn some 6 months ago. From what you are saying above - you might attribute the popping to the ffmpeg conversion from dv to avi/dv - but actually the issue, in the past, was with Cinelerra-cv. So you could conclude that, for cinelerra-cv, dv in an avi or mov container is handled by a different back-end than straight dv. Basically I think cinelerra has its own dv handler. I don't know if you are using cinelerra-cv or cinelerra from heroine virtual. It is possible the the popping fix never made it upstream to cinelerra- HV - I wouldn't know. If you have a new version of cinelerra-cv try one of those old dv files and you might find it is now working perfect. virtual int FileMOV::read_frame(VFrame*):quicktime_read_frame/quicktime_decode_video failed, result* This is a very annoying bug even if 'benign'. I come across it all the time. I'm pretty sure it is well bug-reported. I wouldn't worry removing your pulse audio support unless you come across actual problems in your own setup. Fixing problems that are there is troublesome enough! High Quality FOSS video editing is history in the making - I like to use and watch Cinelerra and the Lumiera project because something really exciting for the whole world is coming together here. I do sometimes wonder what I might be achieving if I instead focussed on productivity (by using FCP) - but, for one thing, that would require me to pirate and crack software and I find the whole experience demoralising. cheers Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: my incompetence or buggy as hell?
After spending another two - three hours, I have found the following tip! The version of cinelerra I was using was compiled last May 2008 and that version would not work with .AVI files. I checked with yumex and found a later version dated Nov 2008. I uninstalled the May 2008 version and installed the latest version (2.1-21.git20081103.fc9). This new version fixes a few bugs, most notability the inability to work with .avi files. Well lets not celebrate too quickly. Sometimes when I work with a .avi file on the timeline this error is generated: I'm not sure what your Linux experience is so forgive me if you are way beyond this tip - a gotcha that gotme early on with cinelerra. A install old packaged cinelerra B compile/install new cinelerra C install even newer packaged cinelerra type 'cinelerra' and you end up running version B not version C. Or some variation on that... It's worth doing a search through your filesystem for 'cinelerra' copies if you are not a Linux old-hand and this may have happened. Packaged versions of cinelerra tend to get installed in /usr/bin and compiled versions in /usr/local/bin or some other place. This problem is true with most Linux apps but -for me- Cinelerra was one of the first apps where I compiled my own and fiddled with multiple versions to get what I needed. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Cineralla crashes at end of rendering
cinelerracv 2.1.0-1svn20081017akirad2 cinelerracv-gl 2.1.1-git090131adirad2 cineleracv-smp 2.1.1-git090131adirad2 Thanks for any advice. Murray These three are the cinelerracv packages which this mail list concentrates on. cv is the ordinary package which should work for everyone. smp is an optimised package for hardware with multiple cores and processors. gl is for those with a opengl2.0 video acceleration. If you have both smp and opengl2.0 I would go for the gl package. Hint: nvidia video cards 6xxx and onward have opengl2.0. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] what is the best burning tool?
schoappied wrote: What is the best burning tool to write a video dvd? I've already the iso, made by dvdstyler. Thanks in advance, \s ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra The command line tool is growisofs. If you're in gnome just right click on the .iso file and select write to disk. K3B is my own favourite all purpose CD burner and will burn an iso no probs. If you're DVD burner is old it's a good idea to slow down the write speed from maximum to perhaps half the available speed. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] slomo or fast forward?
Jeroen Tuijn wrote: I know there is no video editor like Cinelerra on Linux, i i can create a lot of effects, but 1 thing or 2 things i can't create is a slow motion effect and a fast forward effect, does anyone know how t o create this kind of effect? , Jeroen Tuyn ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra Reframe RT. Try some values less than 1. Your slow motion will be jerky but you could try to smooth it a little with interpolate. good luck Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Lumiera: grouping an locking?
Obviously, a rubber-like, editable curve would be an important implementation of this concept, but also we could have interpolating data sets, beat loops, mathematical functions (sine oscillations) or even fractal noise patterns. These would be added as plugins, of course. wipes druel... I love the sound of this structure and these sorts of tools. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] openSUSE 11
Hi The instructions you're following look like they might have become dated. There are patches in the current svn which should make all the -fpic and related flags automatically get set right for 64 bit builds. I suggest to try a 'naked' (no flags) configure and see if it works. ./configure Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Vote for a Name for a new NLE
leandro ribeiro wrote: Verite is strange, yet compelling! [x] Verite (without the CV) Graham How to vote? Make an X in the Box before the name, and send this mail back to the list. [ ] Cinchrony [ ] CinNG [ ] StCinner [ ] Freecine [ ] Video Edith [x] VeriteCV [ ] CineCV [ ] Free Cut Pro [ ] CiNLEss [ ] cinleia [ ] CineTris [ ] LerraCine -- Claude Jones Brunswick, MD, USA ___ 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
Re: [CinCVS] Audio/Voice enhancement
Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Terje J. Hanssen schreef: I'm a beginner on both audio and video NLE, and not quite ready to start exploring Cinelerra's or other free audio tools yet. But I wonder: Will it be difficult or relative easy to move the complete voice to a lower frequency band, or alternatively, just increase the lower frequency band of the voice? Soundstretch gives by far the best quality in my experience for lowering frequency while keeping the same timing. It is a command line tool. You would separate your audio out, soundstretch it, then bring it back in. Graham Basically this is a filter operation. If you invent the filter then it is just a operation on a sample, and it can be done with any tool you want. In praat you can say you want to filter certain frequencies even with an 'if statement'. Just use your imagination. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHqGyOYH1+F2Rqwn0RCob+AJdZtV0bMivYJhNHN3m5hsPVydBKAJ0Vl9ES IfG4ab6G6oPzNG91IXrG4Q== =csIN -END PGP SIGNATURE- ___ 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
Re: [CinCVS] Cin-3
Thinking about distributed rendering, plugins should of course never assume an X11-connection. Can't we have rendering that uses Open GL hardware acceleration then? (And then of course distributed rendering with hardware acceleration on the nodes...) ...long long long term wish list of course Graham Burkhard ___ 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
Re: [CinCVS] Re: Cin-3
Well, as far as DV is concerned, the _codec_ DV works, if it's in an AVI or Quicktime container. That's what libdv is used for. Raw DV may still be broken. I gave up using containerless DV long ago. No raw dv -containerless- seems to work fine now (Thanks to Baver and some other...) It's my preferred intermediate format for some things. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering problem
John Griffiths wrote: Edouard, Thanks, but that did not help. I am still getting [svq3 @ 0x5f8f0c0]unsupported slice header (1F) I can render from a series of png files to RAW DV and to Quicktime and audio to ac3. I have not tried all the render types, but I am trying to create a DVD and according to the documentaion, I need to render using YUV4linux rendering only the video and using mpeg2enc or ffmpeg. I am stumped. I have been using Cinelerra and although it crashes a bit too often, it is powerful and I have made several DVDs sucessfully. After the upgrade, I just cannot get YUV4linux to render. Any other ideas? Thanks, John The problem getting YUV4linux rendering of any kind has happened to me and continued through a number of cinelerra upgrades via svn (there are probably still some of my bug reports filed covering this period). I could never track down the cause of the YUV problems and ended up using other render methods. It is possible that what finally fixed it was dumping all my versions of cinelerra and downloading a fresh svn source tree but as you can probably tell I'm guessing. One day it was just working and so I had to try and remember what could have fixed it... I thought you might appreciate knowing that you're not the only one who has had this problem. best of luck Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Popping sound on playback and rendering ....
Jeff Gerritsen wrote: Greetings, I have noticed a popping sound when I playback and render a segment in the compositor window. At first I thought it was related to my original recording from the camera or low batteries on the wireless microphone. However I was playing back the input dv file in mplayer and noticed no popping sounds at the time mark I herd popping sounds in cinelerra playback window. So if it isn't in the original dv file and only on the rendered output file - cinelerra is adding extra noises - hum This sounds like a cinelerra bug that was corrected about 4-6 months back. Which version and vintage of cinelerra do you run? Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Popping sound on playback and rendering ....
KH KH wrote: 2008/1/11, Jeff Gerritsen [EMAIL PROTECTED]: As an admenment to my priop post I'm running on FC6. I have Fedora 8 package for cinlerra that fit well the livna third part repository As FC6 is now end of life you could consider upgrading... Yes - or alternatively you may have luck building from source - some do. By default cinelerra installs into a /local/ directory so it isn't hard to remove if it doesn't work how you want. Remove the freshrpms version first so you know what you're running. Check out the svn source and then build according to the instructions on the cv.cinelerra.org site. You chances are pretty good even as a beginner. Personally I recommend to rely on the build scripts and not use any compile flags unless necessary. Just have something like this: ./autogen.sh ./configure make sudo make install best of luck Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to Add Title Screens?
I was more thinking of changing the view scroll and zoom so the user sees the image in a suitable size. Interesting lateral solution although it is possible it could be the beginning of an out of control main window. But lets not be afraid of change. I have my own suggestion to solve this problem: a new UI element on the main window. It would be a numeric box with an up down control. It would specify the duration of any still images that get dropped onto the timeline (according to the units specified in time format). The first time a still image is dropped a highlight could go there to draw the users attention. Where would it fit? At 1280 pixels wide my main window still has spare room at the bottom right. A UI element could go between the automation range and type and the selection range boxes. I think a better idea would be to start to add more options to the menu with audio fade: Audio Fade, Video Fade, Zoom, X, Y, Still Image Duration (the right hand range finder would dissappear because this is single value not a range), What else? I'm sure there are a few other numeric value items that would be good to access from here. The benefit is that them there is room to specify the function of the gui element in words. The 'highlight' when a still image is dropped on the timeline would include also changing the Audio Fade menu to the 'Still Image Duration' item. This list and the range finder on the bottom need to be linked more clearly in the gui - A thin frame joining them together perhaps. The frame could then flash once and the menu item change whenever one the relevant elements is manipulated (eg add or move an audio or video control point). So if we incorporated this new item into the Audio/Video Fade menu then there is still extra space at the bottom. A really good use for this space would be a selection list for Time Format. I would switch formats a lot more often during a project if I didn't need to enter the preferences menu. But then I believe there is a keyboard shortcut to switch formats - but I could never remember that one. These suggestions may be a little immature - but I thought I would make them anyway. It is at least possible that this and other outstanding issues may be solvable through normal gui design and without radical changes in window behavior. Happy New Year to all Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] img2list
Attached is my own bash script 'animtext' for making cinelerra image
lists. It works for jpg and png and can automatically determines which
to use. It also works out the image size for you.
The instructions are in comments at the beginning of the script. The
script relies on you having imagemagick installed.
Just cd into the directory with your image files and type 'animtext' for
the most basic mode of operation.
Last I checked this worked. Let me know if something has broken. This
is part of a larger set of scripts which are currently in too chaotic a
state to release... But I will get them there sometime - they are
really handy for general image manipulation working with animation with
cinelerra, imagemagick and a digital camera.
Graham
#/bin/sh
#Create cinelerra style text file listing image paths for each frame
#this script can be called standalone or from within the animate script
#it takes three parameters: filetype (png or jpg) (default is to try and
determine what file type is in the directory), framerate (default is 12) and
directory to index (default is the directory from which the script is called)
#you probably need to make sure you choose a legitimate cinelerra frame rate
#examples:
#animtext
#(this uses default framerate of 12, does its own checking of the filetype in
the directory, and uses the current directory)
#
#animtext jpg 23.976 animations/sources/1/
#
#animtext jpg 30 /home/gray/animations/sources/2/
hd=`echo ~`
startdir=$PWD
if [ $1 ]
then
filetype=$1
else
#check png and jpgs
#needs refinement as, for instance, .jng would be considered legitimate in
this test
ls -1 $sourcedir | grep .[pj][np][g] ${hd}/animreadytemptext.txt
#select the first that appears in any of those categories
testfile=$(cat ${hd}/animreadytemptext.txt | sed -n 1p)
#run the imagemagick identifier to make sure of what it is
test=`identify ${testfile}`
if echo ${test} | grep JPEG -q
then
filetype=jpg
elif echo ${test} | grep PNG -q
then
filetype=png
fi
fi
mmv '*.jpeg' '#1.jpg' 2/dev/null
mmv '*..JPEG' '#1.jpg' 2/dev/null
mmv '*.PNG' '#1.png' 2/dev/null
#rename .jpeg .jpg * 2/dev/null
#rename .JPEG .jpg * 2/dev/null
#rename .PNG .png * 2/dev/null
#following code fails now my distro doesn't support rename
filetype=$(echo $filetype | tr '[A-Z]' '[a-z]' | sed '+s+e++')
echo
echo 'This script will create a Cinelerra compliant text index of the
'${filetype}' image files in the directory. The index will be called
'${filetype}'.txt and will be created in the same directory as the images
themselves. With cinelerra open up this text-index file to access the
animation. If you move the image files or the directory then you will need to
recreate this index file.'
echo
if [ $1 ]
then
echo 'Creating a text file listing the '${filetype}' files.'
else
echo 'Creating a text file listing the '${filetype}' files. (Use 1st
parameter to over-ride)'
fi
echo
if [ $2 ]
then
framerate=$2
echo 'Using framerate '${framerate}'.'
else
framerate=12
echo 'Default framerate of 12 will be used. (Use second parameter to
specify).'
fi
echo
if [ $3 ]
then
if [ ${3:0:1} = / ]
then
indexdir=${3}
else
indexdir=`echo $PWD`'/'${3}
fi
#add trailing backslash
if [ ${indexdir:(-1)} = '/' ]
then
indexdir=${indexdir}
else
indexdir=${indexdir}'/'
fi
echo 'Indexing files in the '${indexdir}' directory.'
else
indexdir=`echo $PWD'/'`
echo 'Indexing files in the current directory. (Use third parameter to
override).'
fi
echo
#list filenames in correct order
cd ${indexdir}
#ls -1 '${indexdir}'*.${filetype} ${hd}/animreadytemptext.txt
ls -1 *.${filetype} ${hd}/animreadytemptext.txt
if [ ${filetype} = jpg ]
then
filetypeheader=JPEGLIST
else
filetypeheader=PNGLIST
fi
#create filetype header
echo ${filetypeheader} ${hd}/animreadytemptext2.txt
echo `echo $filetypeheader | sed 'i# First line is always'`
${hd}/animreadytemptext2.txt
echo # Frame rate: ${hd}/animreadytemptext2.txt
echo ${framerate} ${hd}/animreadytemptext2.txt
testfile=$(cat ${hd}/animreadytemptext.txt | sed -n 1p)
#size=identify ${indexdir}${testfile}
size=`identify ${indexdir}${testfile}`
#create Width header
echo # Width: ${hd}/animreadytemptext2.txt
identifyfiletype=$(echo -n $filetypeheader | sed '+s+LIST++')
width=`echo $size | sed '+s+.*'${identifyfiletype}' ++' | sed '+s+x.*++'`
echo $width ${hd}/animreadytemptext2.txt
#create Height header
echo # Height: ${hd}/animreadytemptext2.txt
if [ ${filetype} = png ]
then
height=`echo ${size} | sed '+s+.*PNG [0-9]*x++' | sed '+s+ [0-9]*x[0-9]*.*++'`
else
height=`echo ${size} | sed '+s+.*JPEG [0-9]*x++' | sed '+s+DirectClass.*++'`
fi
echo $height ${hd}/animreadytemptext2.txt
#create list of files with full paths
for f in `cat ${hd}/animreadytemptext.txt`
do
destfile=${indexdir}${f}
echo ${destfile} ${hd}/animreadytemptext2.txt
done
#save the list and
Re: [CinCVS] img2list / patch
E Chalaron wrote:
Hence the patch included in my previous email
E
Thanks for that E. I am glad to have an opportunity to improve my script.
New script attached is now using find instead of ls *
It is also improved in a few other places (spaces in filenames work
okay, error outputs properly suppressed).
Graham
#/bin/sh
#Create cinelerra style text file listing image paths for each frame
#this script can be called standalone or from within the animate script
#it takes three parameters: filetype (png or jpg) (default is to try and
determine what file type is in the directory), framerate (default is 12) and
directory to index (default is the directory from which the script is called)
#you probably need to make sure you choose a legitimate cinelerra frame rate
#examples:
#animtext
#(this uses default framerate of 12, does its own checking of the filetype in
the directory, and uses the current directory)
#
#animtext jpg 23.976 animations/sources/1/
#
#animtext jpg 30 /home/gray/animations/sources/2/
hd=`echo ~`
startdir=$PWD
if [ $1 ]
then
filetype=$1
else
#check png and jpgs
#needs refinement as, for instance, .jng would be considered legitimate in
this test
ls -1 $sourcedir | grep .[pj][np][g] ${hd}/animreadytemptext.txt
#select the first that appears in any of those categories
testfile=$(cat ${hd}/animreadytemptext.txt | sed -n 1p)
#run the imagemagick identifier to make sure of what it is
test=`identify ${testfile}`
if echo ${test} | grep JPEG -q
then
filetype=jpg
elif echo ${test} | grep PNG -q
then
filetype=png
fi
fi
mmv '*.jpeg' '#1.jpg' /dev/null 21
mmv '*..JPEG' '#1.jpg' /dev/null 21
mmv '*.PNG' '#1.png' /dev/null 21
#rename .jpeg .jpg * 2/dev/null
#rename .JPEG .jpg * 2/dev/null
#rename .PNG .png * 2/dev/null
#following code fails now my distro doesn't support rename
filetype=$(echo $filetype | tr '[A-Z]' '[a-z]' | sed '+s+e++')
echo
echo 'This script will create a Cinelerra compliant text index of the
'${filetype}' image files in the directory. The index will be called
'${filetype}'.txt and will be created in the same directory as the images
themselves. With cinelerra open up this text-index file to access the
animation. If you move the image files or the directory then you will need to
recreate this index file.'
echo
if [ $1 ]
then
echo 'Creating a text file listing the '${filetype}' files.'
else
echo 'Creating a text file listing the '${filetype}' files. (Use 1st
parameter to over-ride)'
fi
echo
if [ $2 ]
then
framerate=$2
echo 'Using framerate '${framerate}'.'
else
framerate=12
echo 'Default framerate of 12 will be used. (Use second parameter to
specify).'
fi
echo
if [ $3 ]
then
if [ ${3:0:1} = / ]
then
indexdir=${3}
else
indexdir=`echo $PWD`'/'${3}
fi
#add trailing backslash
if [ ${indexdir:(-1)} = '/' ]
then
indexdir=${indexdir}
else
indexdir=${indexdir}'/'
fi
echo 'Indexing files in the '${indexdir}' directory.'
else
indexdir=`echo $PWD'/'`
echo 'Indexing files in the current directory. (Use third parameter to
override).'
fi
echo
#list filenames in correct order
cd ${indexdir}
#ls -1 '${indexdir}'*.${filetype} ${hd}/animreadytemptext.txt
#ls -1 *.${filetype} ${hd}/animreadytemptext.txt
find -H . -name '*.'${filetype} -type f | sed '+s+\.\/++' |
sort ${hd}/animreadytemptext.txt
#
#in my case having thousands of frames
#makes the ls command in Graham script to fail...
#If you want to patch your scripts with the find line..
#it should work for any amount of files
#(find . -name \* -type f | sort | xargs cat) | \
#pngtoy4m etc \ y4mtoqt -o reelname.mov
#The issue with it is that it does double up the data at some point so #with
about 100 GB for a 20 minutes movie I need 200 GB.. a bit of a #waste really.
#Of course, ls * is a big no-no if you have 34000 files. ls . does the same.
#find -H . -name '*.jpg' -type f | sort
if [ ${filetype} = jpg ]
then
filetypeheader=JPEGLIST
else
filetypeheader=PNGLIST
fi
#create filetype header
echo ${filetypeheader} ${hd}/animreadytemptext2.txt
echo `echo $filetypeheader | sed 'i# First line is always'`
${hd}/animreadytemptext2.txt
echo # Frame rate: ${hd}/animreadytemptext2.txt
echo ${framerate} ${hd}/animreadytemptext2.txt
testfile=$(cat ${hd}/animreadytemptext.txt | sed -n 1p)
#size=identify ${indexdir}${testfile}
size=`identify ${indexdir}${testfile}`
#create Width header
echo # Width: ${hd}/animreadytemptext2.txt
identifyfiletype=$(echo -n $filetypeheader | sed '+s+LIST++')
width=`echo $size | sed '+s+.*'${identifyfiletype}' ++' | sed '+s+x.*++'`
echo $width ${hd}/animreadytemptext2.txt
#create Height header
echo # Height: ${hd}/animreadytemptext2.txt
if [ ${filetype} = png ]
then
height=`echo ${size} | sed '+s+.*PNG [0-9]*x++' | sed '+s+ [0-9]*x[0-9]*.*++'`
else
height=`echo ${size} | sed '+s+.*JPEG [0-9]*x++' | sed '+s+DirectClass.*++'`
fi
echo $height
Re: [CinCVS] finding keyframes
[EMAIL PROTECTED] wrote: Hi all, Can anyone tell me how to find which frames are the keyframes? I suppose it is wise when first creating keyframes to label them? I did some editing with stills and now I want to change some of the camera and projector movements but I'm finding it hard to find the keyframes. In this case I can simply start again, but I welcome hints! Thanks, Scott Benson Windows Overlays Check the boxes on what automations you want to access on the timeline. Plugin Autos refers to keyframing of plug in effects. The rest should be obvious cheers Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Towards a better cin ChromaKey
I've tried some edge noise reduction, based on giving each non-key pixel a transparency proportional to how many key pixel neighbours it has within a given radius (usually 1-2). This cuts the visible noise markedly but doesn't eliminate it. I might try adding some edge blurring code to see if this gets the noise within a tolerable level. Cheers David This chroma key approach sounds like it should work well - I would love to play with it as a cinelerra plugin. My chroma key setups generally involve inferior lighting and drop cloths as well. I think the following comments would apply even if I were using better gear... Cinelerra's Chroma key (hsv) has limitations but I haven't used the old cinelerra Chroma key plugin since this one was written (about 12 months back). I do find I need to combine it with other effects to get a reasonable result and that a good chroma key plug-in could automate some of this stuff. Here is an example of an effect chain I use for chroma key. 1 Apply blur plug-in, radius 3, to all color channels, horizontal and vertical direction. If this initial blur is not done then the next step with Chroma key (hsv) produces stange horizontal striping and jagged blocky edges to the mask area. This seems to be something to do with color sampling. I'm not sure if it is a bug in chroma key hsv. I finalise the radius of this blur effect in step 3. 2 Set up and apply Chroma key HSV. I use the color picker on the compositor to get an initial color reading and then tweak the color hue while watching what happens with the mask. (with chroma key hsv it is pointless to fiddle with the value and saturation levels as the other Chroma key hsv controls over-ride them). 3 Tweak the blur level from effect 1 to get the right balance between a smooth mask edge and a detailed mask. Err on the side of detail not smoothness as the next step helps with the smoothness. Don't worry about blurring of the subject showing through the mask as step 5 will remedy this. 4. Apply Zoom-blur to the new track to create an anti-aliased mask edge and to wrap it snugly around the chroma key subject. Zoom blur should be applied on alpha channel only. Zoom in or out. Adjust X and Y to make sure the zoom centers on the key subject in the frame (you could always keyframe this if the subject is moving). Here you will see that zoom blur is far from ideal as it means that further away from the x y center the more inaccurately the edges are tracked. But it is still the best compromise I've found so far to get a good mask edge. 5. Create a new track and drop the same footage onto it. Place the new track above the old one. Apply the Reroute plug-in with settings Top Alpha Replace as a shared effect to both tracks. Also apply the ChromaHSV as a shared effect to your new track. This will mean the Chroma hsv spill light controls are applied to the image showing through the mask. 6 Adjust the spill light control on your Chroma key (hsv). (the 'Compensation level' slider seems to be broken as zero compensation does not equal zero but this is still an effective control for spill light). 7. Add a further blur to the alpha channel on the new track to further smooth the mask edge... Step 1 / 3 / 5 could happen automatically as part of the chroma key architecture as far as I can see. Step 4 /7 is where some new ideas are needed for the best way to get a nice anti-aliased edge. You then need to be able to 'dilate' or 'erode' this anti-aliased alpha mask to slightly expand or contract it around the subject. Spill light control on the chroma hsv basically works but could definitely be debugged a little and made more sophisticated. I look forward to seeing anything you can come up with. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] DVD aspect ratio 16:9
This is what needs to be done. I think, one can not change the format inside a title, so if you want to do it, you have to make files with different formats into separate titles and play them one after the other. Unfortunately, on some DVD players pause a little in the transition between the titles which might make the movie look bad. I also discovered you can't explicitly change the format for each seperate title but only for seperate titlesets. So I tried putting the different aspect footage each in a different titleset. See the attached dvdauthor.xml. Make sure you include the jumppad command at the top - it creates a dummy menu for each titleset so the vmgm master menu can refer to this. I also found out that if you don't specify resolution, aspect etc. then the dvd player infers this from the footage. So you could probably just use the 'nopanscan' video format for the titleset, keep all the titles in a single titleset, and then let the dvd player infer the different aspect ratios from the footage. From what ZF posted I'm guessing the different aspect footage does need to be split up into different titles at the least. all the best Graham ?xml version='1.0' encoding='iso-8859-15'?dvdauthor dest=/home/gray/video/mencodes/dwiq//DVD jumppad=yes vmgm menus video format=PAL resolution=720x576 / pgc vob file=/home/gray/video/mencodes/dwiq//genmenu.mpg pause=inf/ button name=0 jump titleset 1 title 1; /button button name=1 jump titleset 2 title 1; /button button name=2 jump titleset 3 title 1; /button button name=3 jump titleset 4 title 1; /button button name=4 jump titleset 5 title 1; /button button name=5 jump titleset 6 title 1; /button button name=6 jump titleset 7 title 1; /button /pgc /menus /vmgm titleset titles video format=PAL aspect=16:9 resolution=720x576 widescreen=nopanscan / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo0.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=16:9 resolution=720x576 widescreen=nopanscan / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo1.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=4:3 resolution=720x576 / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo2.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=16:9 resolution=720x576 widescreen=nopanscan / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo3.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=4:3 resolution=720x576 / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo4.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=4:3 resolution=720x576 / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo5.mpg/ postcall vmgm menu;/post /pgc /titles /titleset titleset titles video format=PAL aspect=4:3 resolution=720x576 / pgc vob file=/home/gray/video/mencodes/dwiq//gibvideo6.mpg/ postcall vmgm menu;/post /pgc /titles /titleset /dvdauthor
Re: [CinCVS] DVD aspect ratio 16:9
Marcin Kostur wrote: I want to produce dvd with 16:9 and even some 4:3 clips simultaneously. Do you have any idea how? What i obtained with dvdstyler and 720x576 (PAL) anamorphous mpeg2 was a video on TV with correct aspect but pan-scanned. Hi Marcin - the following is not definitive information but it works for me. Your mpegs are authored okay but your vobs need some work. I don't use dvdstyler but ManDVD. ManDVD generates an xml file which dvdauthor then interprets. I assume dvdstyler works with dvdauthor also... ManDVD doesn't support a nopanscan option but I add my own line by hacking the dvdauthor xml file. Have a look a the video format... line just beneath titles: ?xml version='1.0' encoding='iso-8859-15'?dvdauthor dest=/home/gray/video/productions/wf//DVD vmgm menus video format=PAL resolution=720x576 / pgc postjump titleset 1 menu;/post /pgc /menus /vmgm titleset menus video format=PAL resolution=720x576 / pgc vob file=/home/gray/video/productions/wf//genmenu.mpg pause=inf/ button name=0 jump title 1; /button button name=1 jump title 2; /button button name=2 jump title 3; /button button name=3 jump title 4; /button /pgc /menus titles video format=PAL aspect=16:9 resolution=720x576 widescreen=nopanscan / pgc vob file=/home/gray/video/productions/wf/wh1.mpeg/ postjump title 2;/post /pgc pgc vob file=/home/gray/video/productions/wf/wh2.mpeg/ postjump title 3;/post /pgc pgc vob file=/home/gray/video/productions/wf/wh3.mpeg/ postjump title 4;/post /pgc pgc vob file=/home/gray/video/productions/wf/wh4.mpeg/ postcall menu;/post /pgc /titles /titleset /dvdauthor The video format... line makes all tv/dvd combos show all the frame (except for overscan of course) by forcing letter boxing. For using different aspects within the same dvd I'm not so sure. You could try adding a video format... line for each time the video format properties change or you could try restricting your video format flag to just widescreen=nopanscan then see if the dvd player can work out the rest. I think the aspect information would be encoded within the mpg files anyway. I'll be interested in hearing your definitive solution when you have it solved. Best of luck Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] debian sid make problem and/or dependency conflict
Norval Watson wrote: No luck so far.. I did not have nasm installed at all so first I tried nasm 0.99.0-1 from sid repo and got same make error. Then I compiled nasm 0.99.2 from latest source, still the same make error. Then I tried nasm 0.98.38-1.2 from etch, still same error. Maybe I'll wait for Vale's new sid package :) Thanx for the tips.. Norv Did you 'sudo make uninstall' the nasm you built from source? Otherwise there is a chance that it is still using this nasm you built from source even though you installed the etch package. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] debian sid make problem and/or dependency conflict
Norval Watson wrote: Hi, I am trying to compile Cinelerra from svn on debian amd64 sid.. getting a similar problem as described in https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-August/011324.html ./configure then make ends with ar: .libs/fdct_mmx.o: No such file or directory make[2]: *** [libmpeg2enc.la] Error 1 make[2]: Leaving directory `/home/norv/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/norv/hvirtual' make: *** [all] Error 2 My svn version.. [EMAIL PROTECTED]:~/hvirtual$ svn update At revision 1019. ./configure --disable-mmx reports that OpenGL is missing ./configure --enable-mmx gives same make result as ./configure I tried compiling because current Cinelerra package on debian sid amd64 has dependency conflicts .. Cinelerra depends on libopenexr2c2a but libopenexr2ldbl is installed Thanx, Norv Try downgrading your nasm to etch version (0.98). You can do this in synaptic (if you use that) by searching for and selecting the nasm package and then finding 'Force version' in one of the menus. You pick the previous version then apply the change. Once that's done select 'lock version' so a subsequent upgrade doesn't put you back at square one. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Metaclips
the same happends with audio, Adobe Premiere Pro CALLS from the timeline an audio editor: Adobe audition, it´s so simple, but works and the users had more control over the timeline, and no render is needed, well the soft makes de render internally.Wouln´t be great to have this in cinelerra? just RIGTH CLICK in an audioclip and and a popup or menu saying: OPEN in AUDACITY, then cinelerra runs a fast audio render, and replaces i the timeline the audio with the fake lossless WAV. that´s profesional, not very complex to achieve, correct me if i´m wrong, because audacity, can RUN-and-load externally: audacity temporary-audio.wav then just use the FX from audacity, and close-save and the timeline automatically refresh that file, cinelerra actually does this. Hi Marquitux I have no knowledge of Blender so I can't make too much comment on those suggestions. With audio production I have more experience. I suspect your Blender idea has similar unresolved conceptual issue as with your Audacity suggestion: You're asking Cinelerra (or Audacity as a child process of Cinelerra) to create project source files 'on the fly'. This is a radical departure from the Cinelerra way of working as I see it. You can't just 'refresh the file' as you say because the timeline audio is a subset (and superset) of source audio file(s). Also I think the source files should, in general, not be touched by Cinelerra. Otherwise the conceptual framework of cinelerra gets undermined. So you actually have to create new source material : the rendered audio segment. You could, I guess, do this in /tmp folder which is then accessed during the final render job. But if /tmp folder is machine specific then your project is no longer portable. So instead I guess you ask the user where they want the new sources created. Or you could, like Ardour does, have a whole big folder per project, with xml, sources and renders (including timeline renders) all mixed up. But here is the cost of your new feature here: the simplicity of concept which underlies Cinelerra is lost. Ardour gives you the option to make your project folder self contained by copying all the audio source files into it - but somehow I think with video footage this is not an option. Cinelerra does need more options for making projects portable though. I'm not saying your idea is bad. Just that it has, at the moment, no flesh on those bones. Also the idea needs to be good enough to abandon a certain simplicity which underlies the complexity of Cinelerra. I'm unsure really whether I would use the feature. I'm happy at the moment with a workflow where I am controlling and keeping track of the sources and accessing Audacity, Ardour etc. in seperate processes. That's something a window manager does well. Also I can't see how a multimedia framework is going to resolve this issue for cinelerra. We're still talking apples (project files, final renders) and pears (source editing). Do you have any idea how your idea might fit in with the Cinelerra way of working with files, projects and rendering at the end? Another idea you mentioned I really like : integrating GIMP driven effects with Cinelerra's keyframe automation. I wonder if the GIMP engine is capable of working well with all four Cinelerra processes: timeline preview, Compositor, background render and final render processes. I guess the real question is: with how much work... Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Metaclips
Jonas Wulff wrote: Not even two, just maybe half a cent... Wouldn't it be possible not to integrate the final product of blender/audacity editing into the timeline but a temporary preview (leaving the original file untouched), and storing the parameters? (Actually that's what I understood marquitux meant) So that only if you render the *final* output in cinelerra, first all blender 'segments' are rendered in blender (maybe creating .blend files on the fly, using the stored parameters, or just using python), saved and then used to render the output with cinelerra... Audacity really doesn't work this way. Ardour does. No idea about Blender. If that's possible that would fit the Cinelerra model great. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] problems installing on FC7
I wound up pulling down the source and compiling it without internal ffmpeg which avoids these problems. If you have a 64 bit system you also need to stuff around with the PIC settings to get it to build. Hopefully that's no longer accurate since svn 1018 (thanks to Kevin). Which of course doesn't solve dependency nightmares... Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Compiling SVN on Suse 10
Edouard Chalaron wrote: Hi there I am trying to compile (I am desperate to ) the SVN on a Dual X64 Suse10.0 Configure works perfectly, find all libs etc ... but the make actually stops on mistake I cant understand. Any help appreciated. See below the end of the make output Thanks Edouard Make sure you have the very latest svn version. Some AMD64 compile problems that look a lot like yours were fixed just a few days back with svn 1018. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Compiling SVN on Suse 10
Edouard Chalaron wrote: Hello Graham Thanks for the quick reply.. I have just downloaded the SVN with the usual svn line command. I suppose this the latest, or am I wrong ? It would be the latest at the time you donwloaded - I just wanted to make sure you downloaded/updated in the last two days and not a week ago. After svn update completed it tells you what svn version you have. Run it again if unsure. Got plenty of updates, went for a make clean just to make sure Now I failed to report one thing : running autogen is giving me plenty of warnings about m4 deprecated stuff, can this have an influence? That's normal. Maybe I should go directly for a configure rather than autogen AND configure, Is it a good idea ? No it sounds like that part you are doing fine. The other thing that was going wrong for me compiling latest svn on AMD 64 (smp) was that I had just updated nasm from version 0.98 to 0.99. So you might want to check that too. I had to downgrade to the 0.98 version of nasm to successfully compile. So . Any other idea ? :) Cheers Edouard That's about all my ideas. But others on this list have provided me great help compiling so don't give up if that doesn't work. Is there any precompiled cinlerra for your distro - or are you avoiding this for some reason? Graham Make sure you have the very latest svn version. Some AMD64 compile problems that look a lot like yours were fixed just a few days back with svn 1018. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no mailto: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
Re: [CinCVS] Render errors for quicktime, AVI
Jim Scott wrote: I checked out the current SVN yesterday and compiled it with no problems for amd64. I can render to most audio formats, DV, and yuv4mpeg. Cinelerra crashes whenever I try to render video into either quicktime or AVI format. Any idea what the issue might be? Backtrace of one crash is below. Sorry to hear about your problems Jim. I can't interpret your backtrace but here is some data: I can render here successfully on an AMD 64 to: 1. DV/avi from mpeg2 source and, 2. from the same source to component YCbCrA 8-bit 4:4:4:4 in quicktime container and then 3. to uncompressed RGBA in quicktime. I'm using everything-up-to-the-moment debian sid and cinelerra cv svn 1018. When I say 'successfully the resulting clips for expiriments two and three were actually black and garbled respectively. But the containers themselves had no problems. So I am not sure what your problem is but thought I'd contribute some useful info to help you try and narrow it down. Let me know if I can help again. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra Tutorial #4
Aaron Newcomb wrote: Hi all! I am getting ready to tape my fourth Cinelerra tutorial which is about rendering and transcoding. However, most of my rendering is very simple. Basically I render everything to rawdv (this is changing as I move toward HD aspect ratios however) and transcode from there into multiple formats mostly for the web. I thought I would also include some instruction on transcoding for a DVD since I figure most people will want to do that as well. Any thoughts on what else might be useful for people to know about rendering in Cinelerra? Lossless rendering with alpha channel - necessary for intermediate render steps. Its a while since I got this working but I do remember you need to use a quicktime box. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra Tutorial #4
Graham Evans wrote: Aaron Newcomb wrote: Hi all! I am getting ready to tape my fourth Cinelerra tutorial which is about rendering and transcoding. However, most of my rendering is very simple. Basically I render everything to rawdv (this is changing as I move toward HD aspect ratios however) and transcode from there into multiple formats mostly for the web. I thought I would also include some instruction on transcoding for a DVD since I figure most people will want to do that as well. Any thoughts on what else might be useful for people to know about rendering in Cinelerra? Lossless rendering with alpha channel - necessary for intermediate render steps. Its a while since I got this working but I do remember you need to use a quicktime box. Graham I just checked ... you use component Y'CbCrA 8-bit 4:4:4:4 in a quicktime container for YUVA-8 bit color model or use Uncompressed RGBA for the RGBA-8bit color model. These are the only formats which I have succeeded with so far to properly save alpha channel footage with no glitches. Make sure you specify the right color model in the Format dialog otherwise the resulting render is black or chaotic with no warning why. I use this technique to render out chromakey footage. As well as using chromakey HSV (often in several layers) I mask out stray chromakey glitches (such as when you use a too small back-cloth), blur zoom on the chromakey effects for nice smooth anti-alias style edge and apply any other simple corrections which will save me work later. Then I render. Using the pre-rendered footage I can now begin editing with all speed and no effects cluttering up the timeline. Perhaps thats a seperate episode. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra Tutorial #4
IL'dar AKHmetgaleev wrote: На Tue, 28 Aug 2007 09:04:15 +0800 Graham Evans [EMAIL PROTECTED] записано: Any thoughts on what else might be useful for people to know about rendering in Cinelerra? Lossless rendering with alpha channel - necessary for intermediate render steps. Its a while since I got this working but I do remember you need to use a quicktime box. I'm working mostly in RGBA color space and using PNG, TGA or TIFF image sequences for intermediate and archiving renders. For audio I'm using PCM files but for archiving I'm converting it to FLAC. Thanks for the tip. As you seem to be interested in the high quality formats I have a question. I notice this is working with the RGBA float color model as well as RGBA 8 bit. Using TIFF with RGBA float should potentially give the ultimate high quality intermediate render. But I notice that the rendered images (for PAL DVD) are 1.2MB no matter which color model you use. Hve you done any investigation into a workflow to preserve the maximum possible color depth? Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra Tutorial #4
Aaron Newcomb wrote: On 8/27/07, Graham Evans [EMAIL PROTECTED] wrote: I just checked ... you use component Y'CbCrA 8-bit 4:4:4:4 in a quicktime container for YUVA-8 bit color model or use Uncompressed RGBA for the RGBA-8bit color model. These are the only formats which I have succeeded with so far to properly save alpha channel footage with no glitches. Make sure you specify the right color model in the Format dialog otherwise the resulting render is black or chaotic with no warning why. I use this technique to render out chromakey footage. As well as using chromakey HSV (often in several layers) I mask out stray chromakey glitches (such as when you use a too small back-cloth), blur zoom on the chromakey effects for nice smooth anti-alias style edge and apply any other simple corrections which will save me work later. Then I render. Using the pre-rendered footage I can now begin editing with all speed and no effects cluttering up the timeline. So, what happens if you don't do this first? Is the playback just to slow and timeline too cluttered to be useful in getting the effect right? Just curious. That's right - playback gets slower, the timeline gets cluttered, and the projects themselves can grow fragile compared to rendered out material. The key is making sure you are confident you won't need to go backward and tweak a control... Or alternatively you keep that part of the project as a separate sub-project in case you do need to go back and tweak. There is an option in the Video menu Render effect which does intermediate rendering in a much more limited way. Personally I don't use this option. Doing it manually gives you much more power and get a better understanding of how all the pieces work. Intermediate render steps are also a part of the ardour workflow - which has many parallels to cinelerra. Ardour has 'Render' options in right-click menus as well as other manual ways of doing this. You are basically breaking a complex project down into a sequence of manageable steps. all the best - look forward to seeing your next episode Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra Tutorial #4
IL'dar AKHmetgaleev wrote: На Tue, 28 Aug 2007 11:28:03 +0800 Graham Evans [EMAIL PROTECTED] записано: I notice this is working with the RGBA float color model as well as RGBA 8 bit. Using TIFF with RGBA float should potentially give the ultimate high quality intermediate render. But I notice that the rendered images (for PAL DVD) are 1.2MB no matter which color model you use. Hve you done any investigation into a workflow to preserve the maximum possible color depth? Largest video that I did was 15 minutes. And it has only about 3 minutes of video which require prerendering and intermediate storing. I'm often using OpenEXR. It is good format to storing float images. And it is supported by blender and pixie. That worked thanks. 6.3MB for an RGBAfloat image or 2.1MB for the same with lossless compression. I wonder how long before GIMP supports exr format... In the meantime I'm going to download cinepaint. I am realising that a lot more codecs work on cinelerra than I previously thought - you just need to get your color model right or they silently fail... Thanks again. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Bradley A. Hare wrote: Jason van Gumster wrote: I can't be the only one who's done successful complex editing in Cinelerra. I do fair amount of of work, professionally and independently, and while I'll admit Cinelerra isn't perfect, it certainly does the job for me on the projects I choose to use it on. Could you describe these in a little more detail, e.g. source formats project size, hardware config etc. ?? Some people seem to have better luck than others with Cinelerra, knowing why would probably be helpful for everyone - regardless of their current opinion. Regards, Brad Hare If you just start up cinelerra open and say I'm going to have some fun (or learn some neat tricks to teach students) then you are likely working in different ways all the time. You're finding new problems too quickly and not persisting long enough to discover what triggers your problems, to file a bug report and to design a work around. I think this is a risk of working in a hypothetical way with cinelerra. How to crash cinelerra tends to be pretty deterministic. And almost everything has a work around. It is also very common (we see from mails on this list) that the problem is in what the user is asking the program to do. The world of video formats and NLEs is complex. Cinelerra tends to let you feed invalid parameters to render engines. This means you need to then learn what the parameters mean and their valid ranges. There's a learning opportunity for students. But that depends on what type of curriculum you have in mind - something you haven't mentioned. Cinelerra is only fun to play with once you've learned its quirkiness by completing a few projects and not before. I have done some successful work with cinelerra. Only some at a professional level and not much of great length or complexity. But I have found in my experimental work that when the scale or complexity increases I can work in pieces: use intermediate renders to lossless formats, break the project into scenes (get out the paper and pen). This has the advantage of making the compositor and background render engine work more efficiently for previewing. 'Crashing through' with cinelerra was no more difficult than with ardour. Ardour is another fantastic powerful program which suffers random crashes, which harnesses really powerful formats and which has new users who keep expecting things to be as simple as with, say, Audacity. Audacity is to ardour as kino is to cinelerra (except Audacity is way more mature than kino). Asking cinelerra to shift to working with a single codec, and to limit its output formats is liking asking ardour to become a loss based audio editor like audacity. You've got to have some real determination plus an actual non-hypothetical task to get useful behaviour from cinelerra. As plenty of linux users have already learned this determination this isn't a problem for many. I have worked on cinelerra with dv2/avi source, with mpeg 2 taken from dvds, and now I am mostly working with png and jpg list source material (animation frames taken with a digital still camera and stitched together with a script.) For intermediate renders I also work with a lossless format which supports alpha channel in a Quicktime container.As with most of the successful render output formats this works well as an input format too. There's no point me listing successful cinelerra final render formats - there are a thousand threads already on those topics. Most of the successful render output formats work well as input formats too. I suspect you would need to be an effective user of cinelerra before you could design an interesting/useful curriculum based on it. all the best Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure AMD64 debian sid
Christian Thaeter wrote: try ./configure --disable-mmx Christian That worked. So - Kevin - I can now confirm that the svn 1018 commit fixed all -PIC related build problems for me. Thanks for the mmx suggestion Christian - I guess that should have been obvious from the errors. It's just that a week ago I didn't need this flag and now I do. I am puzzled as to what could have changed (and it isn't Kevin's commit). I suppose it is possible that in the course of fixing build problems some time back I had changed a file somewhere and then the original got re-instated when I downloaded svn 1018. Other than that I am curious whether disabling mmx is costing me anything in terms of optimisations. Anyway thanks also to Daniel for the suggestion. But anyone following the thread should be aware there is a compatibility problem with ffmpeg versions since August 2006. Hopefully Kevin's commit means that more people can now build using the internal ffmpeg and not have to worry about this issue. Graham Evans ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure AMD64 debian sid
Kevin Brosius wrote: On 2007-08-23 08:12, Graham Evans wrote: Christian Thaeter wrote: try ./configure --disable-mmx Christian That worked. So - Kevin - I can now confirm that the svn 1018 commit fixed all -PIC related build problems for me. Haha, um, Christian seems to have missed the point that the recent build fixes allow us to build with mmx on 64bit. :) Graham, have you made any installation changes on that system related to nasm? You have a good nose! Nasm was updated in sid on 19th august to 0.99.01-0. I probably uploaded it later that same day just after successfully building svn 1017. Anyway I rolled back nasm to the debian etch version 0.98.38-1.2. Lo and behold I have a successful build for svn 1018 with no --disable-mmx flag (no flags of any kind). So we have a nasm problem. Let me know if it is my job to report a bug on nasm and any clues just what that bug is. Otherwise I expect there is some more research needed on cinelerra build detection. Anyway I'm not sure if you still want your other questions answered but it was easy enough: The second thing to check is what configure is using for architecture. Take a look at the initial setup run and let us know what you see for things like arch and target-arch. I'd expect x86_64 and combinations of x86_64 with a distro flag. ./configure output begins: checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu config.log begins ... hostname = linux3 uname -m = x86_64 uname -r = 2.6.21-2-amd64 uname -s = Linux uname -v = #1 SMP Tue Jul 10 21:39:38 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown ... Was this for a build with a bare configure run, or where there other options passed. Bare bones - configure finds all the options I want. From the manual I see I could feed it some optimisations but I haven't done that yet. thanks for the help Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] build failure AMD64 debian sid
No problem Graham. I would have said this is a different problem anyway. :) I am still getting build problems with a fresh checkout of cinelerra. I seem to have ruled out the most recent cinelerra change as the cause by reproducing the problem with svn 1017 (thus the new thread title). Svn 1017 was building for me less than a week ago but the build now terminates as below. I guess that leaves the other sid deb packages as likely culprits. I tried downgrading core-utils which changed versions a few days back but that didn't help. What else can I look for? Should I be trying to use some compiler flags (as opposed to none)? I am using cinelerra cv svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 with nvidia opengl driver. The build teminates with the output I've posted right at the end of the email but I think possibly more relevant is the build output a bit further up which has lots of these: ...predcomp_mmx.s:517: error: invalid operands in non-64-bit mode predcomp_mmx.s:518: error: invalid operands in non-64-bit mode predcomp_mmx.s:519: error: invalid operands in non-64-bit mode predcomp_mmx.s:520: error: invalid operands in non-64-bit mode ... and these... quant_mmx.s:429: error: invalid operands in non-64-bit mode quant_mmx.s:430: error: invalid operands in non-64-bit mode quant_mmx.s:431: error: invalid operands in non-64-bit mode quant_mmx.s:432: error: invalid operands in non-64-bit mode ... and possibly more usefully here is one of the gcc commands leading up to one of these sequences of errors: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../quicktime -I../libmpeg3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -MT quantize_x86.lo -MD -MP -MF .deps/quantize_x86.Tpo -c quantize_x86.c -fPIC -DPIC -o .libs/quantize_x86.o /bin/sh ../libtool --tag=CC --mode=compile ../admin/nasm -g -O2 -c -o predict_mmx.lo predict_mmx.s ../admin/nasm -g -O2 -c predict_mmx.s -fPIC -DPIC -o .libs/predict_mmx.o \1 better written as $1 at ../admin/nasm line 12. Use of $# is deprecated at ../admin/nasm line 27. nasm -felf predict_mmx.s -o .libs/predict_mmx.o predict_mmx.s:45: error: invalid operands in non-64-bit mode predict_mmx.s:47: error: invalid operands in non-64-bit mode predict_mmx.s:49: error: invalid operands in non-64-bit mode ... Does this mean anything to anyone? This should be a pure 64 system but it seems some part of the build system is confused. Here is the termination output... predcomp_mmx.s:524: error: invalid operands in non-64-bit mode predcomp_mmx.s:526: error: invalid operands in non-64-bit mode predcomp_mmx.s:527: error: invalid operands in non-64-bit mode /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/hvirtual2/hvirtual/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual2/hvirtual/hvirtual' make: *** [all] Error 2 grateful for any help... Graham E ___ 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
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
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
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. Graham --- a/quicktime/ffmpeg/libavcodec/i386/Makefile.am +++ b/quicktime/ffmpeg/libavcodec/i386/Makefile.am @@ -12,7 +12,7 @@ AM_CFLAGS = \ $(LARGEFILE_CFLAGS) \ $(CPU_CFLAGS) \ -DHAVE_MMX $(SSE_FLAGS) \ - -O3 -prefer-non-pic \ + -O3 \ -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I$(srcdir)/../.. -I../.. libavcodeci386_la_SOURCES = \
Re: [CinCVS] Re: [Cinelerra-commits] r1007 - in trunk/hvirtual: . libmpeg3/video
Well, I think the trouble here is that either ffmpeg should follow the PIC behavior of the rest of the build, or is broken for PIC in general. I saw a note that debian policy required build with PIC for a time. I don't think that will continue, as present comments say PIC should not be required. I do see PIC used in the general Cin portion of the build here on Suse. Do you know, or can you check, if PIC was used in your builds of the main portion of Cin, Graham? Hi Kevin Let me know if I have gone wrong but I think I have the neccessary skills to answer your questions. Note all the following tests are performed on cinelerra CV svn 1017 with Hermann's patch as attached to my last email. This builds and runs succesfully and performs well as far as I can see. Firstly - I am guessing this is a typical gcc command for cinelerra: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./.. -DHAVE_MMX -DUSE_MMX -DX86_CPU -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -MT idct.lo -MD -MP -MF .deps/idct.Tpo -c idct.c -fPIC -DPIC -o .libs/idct.o I'm not sure if that includes the PIC flag you were looking for. Also, if you have a build log, would you show me the compile options of mpegvideo_mmx when it builds? (If it builds... It will only build if mmx is specified or auto detected as true. I'd like to know if it does not auto detect mmx also.) MMX is detected I suppose from this: 'CPU_CFLAGS='-DHAVE_MMX -DUSE_MMX -DX86_CPU ' Compile options for mpegvideo_mmx: if /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../../..-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -I../.. -g -O2 -MT mpegvideo_mmx.lo -MD -MP -MF .deps/mpegvideo_mmx.Tpo -c -o mpegvideo_mmx.lo mpegvideo_mmx.c; \ then mv -f .deps/mpegvideo_mmx.Tpo .deps/mpegvideo_mmx.Plo; else rm -f .deps/mpegvideo_mmx.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -I../.. -g -O2 -MT mpegvideo_mmx.lo -MD -MP -MF .deps/mpegvideo_mmx.Tpo -c mpegvideo_mmx.c -fPIC -DPIC -o .libs/mpegvideo_mmx.o Thanks all, And a quick comment about ffmpeg external option - my understanding is that ffmpeg versions since about August 2006 are incompatible with the current cinelerra. There is already a bug filed about that. I think the recommended way to build cinelerra at present is to somehow get internal ffmpeg working. On debian etch + going to a version of ffmpeg early enough to get a successful build breaks dependencies in lots of unrelated deb packages. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra productions
[EMAIL PROTECTED] wrote: On Sun, 12 Aug 2007, Kevin Brosius wrote: Have you considered doing a dvd/cd release on one of the online publishers? You make a small clip available for download, so that people see enough to like or not like your film. Then you point them at the online publisher who will ship them a cd/dvd for $5-15US. I've released a video file through Lulu and generally been pleased: http://www.lulu.com/content/602488 I'm finding this download is not resumable. This makes it useless for dial-up. Also you have to hand over an email address. the video looks very interesting - I will get it in the end. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] I found a linux motion interpolator! :))
I assume your second box is a node in a renderfarm, correct? If so, I'd like to hear about your farm setup (CPU speeds of primary farm PCs) and perceived performance improvement. scott Hi Scott Primary box is running on an AMD64 X2 4200 with 2GB RAM. Second box has 1GB RAM and AMD64 3200. I have a pair of ASUS A8N-SLI Motherboards and the boxes connect through a 10/100 ethernet switch. Perceived performance improvement of background rendering was close to double that of the primary box running on its own. That was an impression I got watching the background render completion bar as the node data comes back (inch inch inch *jump* inch inch inch *jump*). Logic would say it can't be double so perhaps a 30-40% speed increase for background render on this sort of set up is closer... The real result for me was that the 'transaction speed' (parcelling our of jobs, NFS transfers etc.) appeared to be practically zero in relation to the time taken by the actual rendering. I wonder if this would change as the number of nodes increased. Those qualitative results are from 2 months back. I was running FC4 64 on both machines on cloned hard drives. Cinelerra CV version was probably something like svn 1008. I'm sorry I can't provide a genuine quantative result at the moment. It would be pretty easy but...my second 'node' is out of action waiting for me to have the money to buy a new hard-drive. Logically I also need to get myself a 10/100/1000 switch to take advantage of the GB onboard network ports on my machines. And some RAID/LVM striped drives would be nice addition too. all the best and thanks for 'Crazed Mule... ' I'm really enjoying it. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] I found a linux motion interpolator! :))
The YUV intermediate isn't too bad a problem either. I'm used to working with uncompressed Quicktimes and TIFF sequences so it is, in fact, quite nice. :) Agreed, it's no real hassle, and going to/from yuv doesn't seem to cost a lot of quality. I haven't noticed any loss. Cheers David **wish list** Wouldn't it be great if this could be modified into a cinelerra plug in... Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] I found a linux motion interpolator! :))
Personally, I'm quite happy to re-time video segments outside of Cin, then just import them into Cin. In fact, I've written a python front-end which gives a simple interface and takes care of all the details, so it can take a clip in any format at any fps, and convert it to a high-quality .mov/mpeg4 with the desired fps. Motion estimation is CPU intensive, far more so than even camera/projector zooms. It's questionable whether this belongs in Cin at all - whether on the Cin timeline or as a Cin effect. You'd never in your wildest dreams be able to re-time and play in realtime in the Cin viewer or compositor. Everyone uses cinelerra for different things obviously. Personally my use for this tool would be in (stopmotion) animation work. I anticipate retiming and smoothing segments of the animation. This sort of work would require a gui and a compositor and as much integration as possible. Speed is not such an issue for me - many of Cinelerras effects are a long way from real time. That's what the background renderer is for. I use it all the time. I have a second networked computer running cinelerra to make it more effective. If this approach was as effective in reality as in my fantasies I might even decide to change the way I animate. You could leave out setting up and photographing simple intermediate frames when you think the interpolator might do a good job. I wonder if there would be any possibilty of this working smoothly or whether it would make the animation 'shimmer' as the yuvmotionfps engine cuts in and out... That would require some testing. At the very least this approach could be used to fix mistakes in the animation (eg chop out a frame where your hand is in shot and then interpolate it back in)... and then after editing a whole scene I might increase the framerate across the board from say 12fps to 24fps. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] framerate converter script
David McNab wrote: Hi all, I've written a little utility script called 'framerate', which wraps up all the yuv encoding/decoding and yuvmotionfps invocation and final encoding for the motion-estimating re-timer I mentioned earlier. Thanks for this David - it will make my experiments much easier! Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] motion interpolation software
David McNab wrote: Hi, Can anyone recommend any software for linux which can do reasonable detection/interpolation of motion to help bring low framerate video up to speed? I take it you think the Cinelerra interpolator doesn't fit this bill..? Graham Cheers David ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cant find motion filter!
Christian Thaeter wrote: tiziano monti wrote: Hi, I'm italian boy, I'm excuse myself for the english. I'm using debian lenny (64bit) on AMD athlon 64 bit machine. I try to install cinelerra from repository, but I can't find the motion effect for the motion tracking. I try to install form source but I obtain: make[2]: Entering directory `/home/tiziano/hvirtual/mpeg2enc' /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/tiziano/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tiziano/hvirtual' make: *** [all] Error 2 I want test motion tracking, but I can't! Anyone help me? Thanks. try to ./configure --disable-mmx If that doesn't work let us know where you your source code is from. Current svn (1016) source compiles for me without any flags. But around 6 weeks ago installing from svn source was not amd64 friendly and required hacks. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra's best codec for animation?
Matt Jordan wrote: Hello, I'm using Cinelerra as part of an open source pipeline for more-or-less traditional-looking 2D animation. I draw backgrounds and character animation in Inkscape and Gimp, export still frames as true color pngs, and assemble clips in Cinelerra to composite with sound, effects, etc. I've been working on getting good at the mechanics of the process (basic interface stuff, panning and zooming still image backgrounds, dissolves, and so on) and have so far been using quicktime for linux as my output. It's fine for this stage, but I'm seeing some noticeable degradation of the png images in the resulting animation files. In particular, the edges are soft and out of focus and they generally lack sufficient detail. Hi Matt I am working on stop motion animation using digital still camera. I agree Inkscape is one of those 'killer apps'. With your cinelerra problem it isn't totally clear what codec you have been using. Quicktime is a container not a codec. When you mention pngs after mentioning Quicktime I could assume you are rendering out of cinelerra to a png image list format in a Quicktime container. But rather than assume could you be totally clear about this. You mention using png images as a source format so there is some confusion here. Please clarify. I haven't got far in my work yet but so far I render out to png image list formats until I am ready to 'publish' to an mpeg/flv format or whatever. There IS a problem using png as the render format: if you want to encode alpha channel data. This can be useful if you need an intermediate editing format to bring back into cinelerra later. In that case you need to use an RGBA uncompressed format in a quicktime container. I think. I don't have the details handy but if you need that info email me and I will find it. It is very hungry but with the small volume of footage for animations then perhaps that isn't a problem. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering a YUV4MPEG Stream causes Cinelerra to crash...?
Jeff Gerritsen wrote: Graham, Thanks for the replay. I've interspaced the answers below. On Tuesday 31 July 2007 20:49:37 Graham Evans wrote: Jeff A few questions. What is this script? //home/jagerrit/cine_render.sh#/bin/bash mpeg2enc -v 0 -K tmpgenc -r 16 -4 1 -2 1 -D 10 -E 10 -g 15 -G 15 -q 6 -b 8600 -f 8 -o $1 Okay this is not a method I use. Obviously others have had success as it IS in the manual. Perhaps they will come to the rescue. Otherwise... You now have some useful information you could repost succinctly and perhaps you'll get an answer. There is also the option of filing a bug. Otherwise... You could try using one of the DVD presets from the YUV4MPEG dialog box in either the ffmpeg or mpeg2enc list. Usually I have found that where these go wrong you get enough information in the cinelerra output to change the command line to something that works. There are other ways of getting DVD material from cinelerra. A popular one is to render to a Quicktime container using the dv codec. This allows you to render out both the sound and the video at the same time. You then use a command line tool such as transcode or mencoder to convert this to multiplexed DVD mpeg. The method I use is to render out sound and video seperately. Video I render using cinelerras MPEG II renderer (uses mpeg2enc). It can take some time to find successful settings in the dialog box. (spanner icon). The sound I render out as AC3. I then use the mplex command-line tool to combine the sound and video into a DVD ready form. If you let us know what you want to do next more help may be forthcoming... good luck Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering a YUV4MPEG Stream causes Cinelerra to crash...?
One, is there a procedure to obtain an error trace log? run cinelerra from a terminal so you get the output messages. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering a YUV4MPEG Stream causes Cinelerra to crash...?
Jeff A few questions. What is this script? //home/jagerrit/cine_render.sh And some more basic questions: Are you aware that YUV4MPEG Stream is not a format but a tool for piping the cinelerra render output to a format? Have you found the (easily missed) spanner icon in the render dialog which allows you to set up all the render options - in this case the pipe commands used? It isn't clear from your posts that you have got this far. In which case you might find the cinelerra manual handy. Graham / ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Error: FileMOV:read_frame(VFrame*): quicktime_read_frame/quicktime_decode_video failed
Alexander Grundner wrote: I wish I was having the same experience the guy in bug 343 is reporting. For me, it doesn't play fine when the error pops up. In fact, it plays choppy, loops, and struggles to move forward in the timeline. It also loads video AVI files, on occasion, as AUDIO -- go figure. From my experience this is a sign that cinelerra doesn't recognise the codec. You may already know this but in case you don't: avi is not a codec it is a container format. It can contain different codecs - some of which cinelerra can read and some which it can't. When it can't read the codec I think it assumes that the data is some sort of raw audio. Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] final video doesn't respect the cutting of the scenes
I've found two GUI frontend for dvdauthor: Dvd Styler and Q DVD Author. Can you suggest me which is the best? ManDVD is the only tool I've found which performs the whole process (right up to burning the DVD). As an added bonus it has a really friendly gui ... although at present it seems to lack the -nopanscan option. You can hack the process a little to get access to extra options (I interrupt ManDVD, fiddle with the xml file and then use dvdauthor to finish the authoring process). It has been a while since I tried the two tools you mentioned so perhaps they are working better now. If you want to do anything ambitious you will need to learn a bit about the command line tool dvdauthor (which is one of the back end to these programs). Looking at the xml files created by any of these gui tools is a really good way to learn about the xml files which dvdauthor uses. Also you probably won't get good quality results without learning a bit about the DVD format, resolutions, aspect ratios, file structures and all that general stuff (try wikipedia). Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Finished product with cinelerra (OT)
Daniel Jircik wrote: Hi I just cut this for a spoken word performance artist and I think it turned out well. http://tonzi.com/video/dreamachine-lullaby/ dvgrab for capture blender for efx gimp for image work cinelerra for NLE Nice piece. Thanks for sharing it. And great to see the OSS listed in the credits. For others trying to access using swfdec 4.3+ plugin on 64bit mozilla your embedded youtube doesn't work but the original youtube can be accessed from here: http://www.youtube.com/watch?v=DkyP-x1szNg Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: {Spam?} [CinCVS] another/ new cin-cvs compile error
Alexis Ballier wrote: What you say does not match what is going on in this bug: http://bugs.cinelerra.org/show_bug.cgi?id=390 I found that bug applied for versions of ffmpeg back at least to August 2006. That only applies to ffmpeg versions compiled with --enable-swscaler. I had sent a patch for this also, a while ago, but it has never been merged. That explains very well thank you. The debian versions of ffmpeg must be compiled with this option. I will go find your patch. Alexis. thanks for the fixes Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: {Spam?} Re: {Spam?} [CinCVS] another/ new cin-cvs compile error
Jan Luo wrote: yeah, you are absolutely right! downgraded to ffmpeg-0.4.9_p20070330 and all was good again - will this stay like this - no recent ffmpeg? thanks a lot! jan Glad it worked for you. Also nice to know an 'external' ffmpeg version which cinelerra is working with. There is a bug filed for cinelerra cv on this but it may be uneccessary. As hvirtual releases new cinelerra versions then new versions of ffmpeg should eventually be introduced upstream. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] reference monitor
Christian Thaeter wrote: Kurt Georg Hooss wrote: aha! thanks christian. today i could test only with another computer monitor in twinview mode (resolution set to 768x576) and that worked fine. so i guess it will probably do well with the tv also. next time i have the tv set here i'll try to find out whether two computer monitors *and* the tv set can be used Many of the nvidia cards I have investigate don't allow twin-view and external TV at the same time. If this is the case it may be possible to get a second video card working for the compositor view. Let us know how you go. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: {Spam?} [CinCVS] another/ new cin-cvs compile error
Well, that's only very recent ffmpeg versions that broke cinelerra : they removed the extern C stuff if the .h when included from c++. And cinelerra does use ffmpeg from c++... trivial patch enclosed. Regards, Alexis. (Ps: I will fix that in gentoo shortly, hopefuly) What you say does not match what is going on in this bug: http://bugs.cinelerra.org/show_bug.cgi?id=390 I found that bug applied for versions of ffmpeg back at least to August 2006. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Still Pictures not exactly in the manual
My cinelerra is loading jpgs, pngs (and TIFF) fine - although my greyscale jpeg came out green. hmm. You need to describe in more detail the steps you are taking. For instance perhaps you have 'load new resources only' set in the load window. Perhaps you are loading only single frames of png and failing to see them arrive as they are so small on the timeline. It's too hard to tell what is going wrong. There is no version of cinelerra I have heard fail this very basic task. Although such a bug could exist you have failed to convince as yet... Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] cinlerra install
Douglas Pollard wrote: I have not been able to get cinelerra to install in ubuntu studios i386 with synaptic. click applications, sound video, shows an icon for it but it won't open. And it shows as installed in synaptic. In add/remove it does not show up as installed? Has anyone been able to install this way. doug ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra It sounds like you have some doubt about whether it installed or not. The best way to resolve this is to try to run cinelerra from a terminal. Open up a terminal (accessories menu perhaps?). Type: cinelerra Hit enter. That should give you more information on what is going on. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Need help generating properly interlaced output from progressive input ....
rob switzer wrote: Hi, I recently created a project in 24fps/720x480 and 25fps/720x576 progressive formats, and would like to export/convert this project into properly interlaced formats suitable for burning to both NTSC and PAL dvd formats. my suggestions... I don't see the point of interlacing the footage for the PAL dvd. Wouldn't that be trying to encode information (50 fields per second) that isn't there? My understanding of the dvd format is that it handles progressive footage fine. If that seems fine then your 25fps is ready to go for PAL. If you want to use cinelerra for that then open the project then :either export/render from cinelerra as mpeg2, or use the yuv4mpeg pipeline with the DVD presets for ffpmeg or mpeg2enc. Export your sound seperately as AC3 then use mplex to merge the sound and video streams. Use whatever tools to author the dvd. (All this is described in good detail in the cinelerra manual). Can't help you with NTSC sorry but a recent version of mencoder is likely to have a really good Telecine converter for that. Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Resources window is empty
Bruce Bales wrote: Trying to get started with cinelerra. I moved the divider in the resource box to the side (too far?) and all the contents of the resource window disappeared. Can't get it back. It's completely empty. I removed and reinstalled cinelerra then purged and reinstalled it, but no luck. Can't find any configure file that might help. bruce The configure files are tricky to find as they have the legacy name: ~/.bcast (From the Broadcast 2000 era). Without looking at your specific problem I can tell you: if you delete that folder cinlerra will recreat with default settings. good luck Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering with blackbars for 16:9 on 4:3
Stephan wrote: Let the project ratio be PAL for exemple (4:3): The source is 4:3 in your video track, now, simply resize the timeline of the video (right mouse menu on the video track) to the height 405 (720x405 is 16/9). So you have your 16:9 with black bars and everything is centered (the resize is really a crop). If you need go back to 4:3, simply resize the timeline to the project size. Et voilà ;^) This method requires 1 less effect so I like it. Does it mess up the interlacing in the same way as the translation effect? 405 is an odd number which worries me... Hermann thanks for the explanation of cinelerra behaviour. I regularly change the aspect of still images before importing but I never realised this issue effected all media in cinelerra. his leads to some additional problems, e.g. if you use a circular gradient effect, it gets stretched out as ellipse I suppose this means the circles applied on my 4:3 footage are also ellipses by about 7%. A nice new feature inded /would be/ the ability to insert such a strech effect automatically on some media in the project, even before it is So we could have a manually operated 'render path manager' (perhaps reached by clicking a button in the Format dialogue) which shows options: *apply a stretch to raw media (use 16:9 footage in 4:3 project, using 4:3 footage in 16:9 project, still photo in PAL frame, custom stretch etc.) *double the frame rate and apply frames to fields on raw media - this will correct the functioning of various effects when working with interlaced footage but will slow down the pipeline. Obviously those are too many words... Anyway I can see such a thing being really useful and a step towards ...a more extensive render path manager. I guess eventually all the media and project information could be on a render path dialogue attached to each media asset (right click on the media in the assets I guess) with media info on the left and project info on the right side. Cinelerra could show at the bottom of the dialogue how it proposes to manage the interlacing and aspect ratio issues in the pipeline and the user could manually tweak any parts of the pipeline they wish. Is that a canonical solution? Anyway something new in cinelerra to help deal with these issues would be a fine enhancement. Good luck! Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering with blackbars for 16:9 on 4:3
replicant wrote: Use the format dialogue to set the ratio and dimensions of video to be rendered. Use camera (and/or projector) to zoom and position your original video in the frame. (Click camera icon in the compositor window and change zoom factor then drag the image within the compositor frame to position it where you want it.) Wherever there is no image there will be black bars. Set the ratio to 4:3? or leave it at 16:9? When I set it to 4:3 it stretches everything out .. I'm seeing this problem now. That behaviour doesn't seem right to me. Can anyone comment if they think this is a bug? Assuming it's wrong beahviour I'll call this a 'workaround': Set your ratio to 4:3 - that is the ratio you want in the rendered track. Not sure why it would resize your input track...So to correct this: Drag the translation effect over your track. You then have all the parameters you need. I'm guessing you mainly need to set 'Out H' (reduce it until the ratio is correct again) and possibly Y (to move the letterbox opening down the screen). Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Resampling best practices
Ed Colmar wrote: Replying to myself here, since I did not get any from the list. I'll simplify my question. What is the best codec/file format to use when slicing video footage into smaller resolutions, which will then get loaded back into cinelerra for editing? I have been going down the list of formats and just by trial and error trying to find one that works for me, but I'd love some guidance. Cheers -e- Component Y'CbCrA 8-bit 4:4:4:4 in a Quicktime container with twos complement audio is the only working uncompressed format which correctly stores alpha information. I found that after exhaustive (exhausting!) testing 9 months ago so things may have changed. It is a good choice if you're playing around with alpha effects such as masks, chromakey etc. The bandwidth on a PAL full screen video is about 41MB sec! I'm not sure about its performance in terms of compositor playback because I haven't played with it for a while. If you don't need alpha info I would start by trying out something like Component YCbCr 8-bit 4:2:2, again in a Quicktime container. Straight DV export is working well and is not heavily compressed, with no alpha. Most people around here seem to put it in a Quicktime container. This may be a legacy of the long period of time when straight DV export wasn't working. You could also try TIFF or PNG sequences for a non compressed format (although alpha doesn't work properly last time I checked). Bear in mind that if you don't select a container format (such as Quicktime of avi) then you produce a folder of images which is not fully portable. The text list of TIFF or PNG images in the folder uses absolute file paths. It needs to be recreated if you move your image directory. If you want to accept some compression for bandwidth reasons then why not Ogg /Theora... Hopefully thats helpful. Feel free to feed your own discoveries back into the list. Best of luck... Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Compiling problems, Debian, AMD64, -fPIC
Ichthyostega wrote: Hello all, I saw several people with presumably the same compiling problems here recently -- -- So I want to report my solution. Thanks Hermann - I will try the patched makefile on svn 1008 with my almost-stock Debian sid (6 May 07) and a manual compile. I suspect it will go okay but I'll let you know. Will this get committed? Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] X11-OpenGL slower than X11-XV ???
mark stavar wrote: Alas, It would appear that, though my card and glxinfo _say_ they support OpenGL 2.0, it would appear that in fact they do not. (GeForce FX 5700 256Mb) I seem to remember looking into this and discovering that the Geforce 5xxx series only support OpenGL 2.0 with software/emulation of some functions. I also read that you need to put a line in your xorg.conf to enable this but perhaps with newer nvidia drivers that isn't neccessary. You might need to do some googling and/or buy a new card. Some cinelerra functionality won't be accelerated on OpenGL anyway. Somewhere there is a list of which effects get accelerated (try the manual). The order of processing in the effects chain also impacts on whether the OpenGL is effective. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] X11-OpenGL slower than X11-XV ???
Section ServerLayout Identifier Default Layout Screen Default Screen 0 0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse EndSection Section Files # path to defoma fonts FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Load i2c Load bitmap Load ddc Load extmod Load freetype Load glx Load int10 Load vbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Monitor Identifier Generic Monitor HorizSync 28.0 - 64.0 VertRefresh 43.0 - 60.0 Option DPMS EndSection Section Device Identifier nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] Driver nvidia EndSection Section Screen Option TwinView True Option TwinViewOrientation RightOf Option UseEdidFreqs True Option MetaModes 1024x768,1024x768; 832x624, 832x624 Identifier Default Screen Device nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] MonitorGeneric Monitor DefaultDepth24 Option UseDisplayDevice CRT #replace 'string' with either 'DFP' (Digital flat panel connected via DVI port), 'CRT' (any monitor that is connected via VGA ports), or 'TV' SubSection Display Depth 1 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection SubSection Display Depth 4 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection SubSection Display Depth 8 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection SubSection Display Depth 15 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection SubSection Display Depth 16 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection SubSection Display Depth 24 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 1x1 EndSubSection EndSection ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
$ make -k CFLAGS='-O0 -g' # this errors out in fdct_mmx.c with operands invalid for `pshufw' $ rm quicktime/ffmpeg/libavcodec/i386/fdct_mmx.*o $ make CFLAGS='-O2 -g' (It seems that this file wants to be compiled with some different sort of optimization.) BTW, I just noticed that the build flags of quicktime/ffmpeg/libavcodec/i386/ include -O3. Try removing that from Makefile.am - it is needed on i*86, but may not be needed on x86_64. -- Hannes A successful build - finally...thank you Hannes. As they say in Experts exchange or wherever - you win the prize... I'm not clear yet on where the build was going wrong but most definitely in the quicktime/ffmpeg/libavcodec/i386 directory. I decided to try with the latest automake (1.10) and my eventual success suggests the debian build comments in the autogen.sh script now need to be deleted (they say to use automake 1.7). Another discovery : I came across references in makefiles to previously used automake versions. I manually purged a lot of hvirtual directory files to overcome this. So perhaps the autogen.sh script does not clean out all the old files properly. Some of these maybe: depcomp, libtool, ltmain.sh, mkinstalldirs... I started with a no flags: ./configure then: make once it broke I used: make -k 'O0 -g' make (to remind me where breakages were still happening) rm quicktime/ffmpeg/libavcodec/i386/..[broken lib].*o fiddled with the Makefile in quicktime/ffmpeg/libavcodec/i386/ and used either make CFLAGS='-O3 -g' CFLAGS='-O0 -g' or: CFLAGS='-O2 -g' until all the build errors were solved. My final Makefile in the i386 directory had no -O3 optimisation, no -prefer-non-pic and included an -fPIC flag. Until I discover exactly which steps were necessary my bug report is probably not useful - I will only submit one if someone here tells me it's a good idea. Hopefully my skills will eventually allow me to make packages and submit patches. But that could be quite a while away... For now all I can do is say thanks everyone for all the help. I'm happy to have my Cinelerra back! Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] X11-OpenGL slower than X11-XV ???
mark stavar wrote: I am getting the same results -- my playback is faster and smoother with X11-Xv than with OpenGL. Now mine is probably not a hig-end graphics card (and a little dated now) but it supports OpenGL 2.0. A tad disappointing :-( Hi mark Like Bruce you probably have a problem of some sort. I just tried out the open gl video driver (PreferencesVideo OutVideo DriverOpenGL) and got 30 fps for the following effects chain playing in Open GL: camera z enlarge 2.2 (bicubic, gamma (no auto no histrogram), rgd and chromakey hsv) only 4 fps playing in X11-XV I also noticed that no restart is neccessary to swap video drivers just press stop and play. My video was H.264 video in a mov container and had sound (alsa driver). I have a pretty good setup with lots of memory but if your opengl is working properly you should be seeing a big contrast with the x11-xv driver. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg with different optimizations. Like: $ rm ffmpeg/libavcodec/cputest.*o $ make CFLAGS='-O0 -g' okay tried all that. Except I found deleting the files had no effect - they were just recreated each time. Instead I deleted makefile references to these files. All the references were in the makefile in the directory: quicktime/ffmpeg/libavcodec/i386/ If I configure and run with the complicated CFLAGS which Hermann supplied I end up only needing to delete: simple_idct_mmx.* dsputil_mmx*.* motion_est_mmx*.* without Hermanns configuration, or with the Make CFLAGS='-O0 -f' i needed to delete those files plus also: fdct_mmx.* idct_mmx.* dsputil_mmx*.* all in that same makefile. Anyway deleting these files finally causes a new type of build error 'undefined reference to mm flags'. I didn't try to fix this one as I assumed it was a problem created by my deletions (output snippet below this email). I'm seeing the pattern of problem libraries being associated with mmx. I wonder if something is still broken in the auto configuration of mmx flags for x86_64? Or if this indicates any particular one of my dependencies as the problem. Any more ideas on the topic? Graham E. ffmpeg/libavcodec/.libs/libavcodec.a(utils.o): In function `avcodec_encode_video': utils.c:(.text+0x139a): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(utils.o): In function `avcodec_decode_video': utils.c:(.text+0x14d4): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function `MPV_frame_end': mpegvideo.c:(.text+0x5cde): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function `select_input_picture': mpegvideo.c:(.text+0x8e11): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o): In function `ff_draw_horiz_band': mpegvideo.c:(.text+0x195a9): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o):mpegvideo.c:(.text+0x1f90c): more undefined references to `mm_flags' follow ffmpeg/libavcodec/.libs/libavcodec.a(dsputil.o): In function `dsputil_init': dsputil.c:(.text+0x23a58): undefined reference to `dsputil_init_mmx' ffmpeg/libavcodec/.libs/libavcodec.a(imgresample.o): In function `h_resample': imgresample.c:(.text+0x83d): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function `slice_decode_thread': mpeg12.c:(.text+0xa84d): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function `mpeg_decode_frame': mpeg12.c:(.text+0xbc30): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o): In function `decode_frame': mpeg12.c:(.text+0xc07e): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o): In function `ff_rate_control_init': ratecontrol.c:(.text+0x13d): undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o):ratecontrol.c:(.text+0xbf0): more undefined references to `mm_flags' follow collect2: ld returned 1 exit status make[1]: *** [libquicktimehv.la] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual/quicktime' make: *** [all-recursive] Error 1 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Ichthyostega wrote: actually, success in running can help a bit. Am I asuming right you are trying to install on debian or ubuntu? Well, I'm more familiar with that then with RPMs :-) I have just switched to debian etch-amd64(smp) (upon official release) from fedora core 4-64. After about a week I decided to 'upgrade' to sid and that was when I decided it was time to get cinelerra working again... If you want to investigate further on debian/ubuntu, the next step after successfully running would be to re-compile the bin package you just successfully installed. Ideally this would give you a working compile (for further investigation different switches or for getting things like opengl running). okay - I will slowly begin to try such things out - I have lots to learn about deb packages so that should be fun.. Basically, the version in Cinelerra-SVN is a valid debian package. So it could be feesible to take a diff between vale's package and the Cinelerra-SVN. For this to work you would need the same SVN-revision which was used to create vale's package. ah. interesting! Maybe I can do that... Do you know the tools available for building on debian? -- see below for sort of a short version how to build on debian. I'm attaching this just in case it may be helpful. very new to me. Perhaps I will try rebuilding x264 and libavcodec(cvs51?) using the deb packages as my next step. Further, I allways get a -fPIC problem with x264 and have to... ln -s /usr/lib/libx264_pic.a /usr/lib/libx264.a just one more note - I don't have a lib264_pic.a file - neither my own build of x264 nor the x264 deb package created this. Did you name it yourself during your rebuild? once again you've given me a way to move forward. thank you Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
just wanted to point out: the problem of some objects to be liked dynamically but not beeing built with -fPIC is the most common source of build problems on x86_64. I learned to look at this first when problems pop up: are really all (note all) parts to be linked in built with -fPIC ?? I think this is a very likely cause of the build failures (after having exhausted many other possible causes). I wonder where to go looking in terms of downgrading or build my own packages. The external ffmpeg on sid list the following dependencies: libavcodeccvs51 libavformatcvs51 libavutilcvs49 libc6 libfreetype6 libimlib2 libsdl1.2debian libswscalecvs0 I guess the internal ffmpeg relies on some of these progs too. This is another line of re This is the important part. I.e. you should verify in the output of the make command, that you find this sequence of flags really in the generated command invocations somewhere (of courese there are some additional flags and there is the list of libs to include and the path to the source to compile -- but you should find your flags literally in every gcc or g++ invocation. This means esp. that in *every* invocation there is a -fPIC at some point (and no -fpic) I'm learning huge amounts from this exercise - one small step closer to being able to hack on cinelerra! ...but building it would be a good start : p But the problem is allways in the included ffmpeg directory? my problem is in building from the quicktime directory when the link is made to something in the ffmpeg/libavcodec directory. This problem: When I tried these flags after descending into quicktime or ffmpeg directories this caused the build to abort quickly with: gcc: cannot specify -o with -c or -S with multiple files occurs everywhere in the build tree if I use the CFLAGS you specified. Deleting the stray '-' Then you could hand edit the Makefile just in the FFMPEG directory to insert the right CFLAGS and CXXFLAGS (of cours this hand edits are lost as soon as you re-invoke ./configure). yes tried that: *poured over the build output tracking back from the breakpoint to refferred packages and then back again from them. *made some mini Makefiles of my own, fiddling with -prefer-non-pic flags (ie deleted them) when building in the libavcodec/386/ directory *tried deleting DUSE_MMX flags when building in the libavcodec after reading a bit on this thread: On Friday 26 January 2007 09:58, Alexis Ballier wrote..(some stuff about mmx flags sent to ffmpeg with x86_64 builds...) *mostly just confirmed that the CFLAGS and the -fPIC flags seemed to be passed on okay. None of this worked. or changed the final result. Although I've definitely added to my repetoir of techniques. some other stray details: Building with your flags causes the build to break at a slightly different point: .../usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): could not read symbols: Bad value... rather than .../usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.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(cputest.o): could not read symbols: Bad value ... Also - the only gcc command not to use the CFLAGS (like -fPIC) which I could find was the one which the program broke on: gcc -shared .libs/atom.o .libs/avcc.o .libs/avi_hdrl.o .libs/avi_idx1.o .libs/avi_movi.o .libs/avi_strl.o .libs/avi_odml.o .libs/avi_ix.o .libs/avi_indx.o .libs/avi_riff.o .libs/cmodel_default.o .libs/cmodel_float.o .libs/cmodel_yuv420p.o .libs/cmodel_yuv422.o .libs/codecs.o .libs/colormodels.o .libs/ctab.o .libs/dinf.o .libs/dref.o .libs/edts.o .libs/elst.o .libs/esds.o .libs/graphics.o .libs/hdlr.o .libs/ima4.o .libs/interlacemodes.o .libs/jpeg.o .libs/libdv.o .libs/libmjpeg.o .libs/matrix.o .libs/mdat.o .libs/mdhd.o .libs/mdia.o .libs/minf.o .libs/moov.o .libs/mp4a.o .libs/mvhd.o .libs/plugin.o .libs/qtcache.o .libs/qtdv.o .libs/qtffmpeg.o .libs/qth264.o .libs/qtpng.o .libs/qtmp3.o .libs/quicktime.o .libs/raw.o .libs/rawaudio.o .libs/rle.o .libs/smhd.o .libs/stbl.o .libs/stco.o .libs/stsc.o .libs/stsd.o .libs/stsdtable.o .libs/stss.o .libs/stsz.o .libs/stts.o .libs/tkhd.o .libs/trak.o .libs/twos.o .libs/udta.o .libs/ulaw.o .libs/util.o .libs/v308.o .libs/v408.o .libs/v410.o .libs/vmhd.o .libs/vbraudio.o .libs/vorbis.o .libs/workarounds.o .libs/yuv2.o .libs/yuv4.o .libs/yv12.o .libs/wmx2.o .libs/wma.o .libs/mpeg4.o -Wl,--whole-archive ffmpeg/libavcodec/.libs/libavcodec.a encore50/.libs/libencore.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/home/gray/install/hvirtual/libmpeg3/.libs /usr/lib/liba52.so -L/usr/lib /usr/lib/libvorbisenc.so /usr/lib/libvorbisfile.so /usr/lib/libvorbis.so
Re: [CinCVS] theme S.U.V. not found
Martin Ellison wrote: That's a link step, so the compiler options are not going to help there. But you might (a) Google for all these messages, (b) check the wikis and (c) trawl through any posts to this list. As I remember I had the same R_X86_64_32S error a few weeks ago. I think I got around it by using the external ffmpeg. Believe me - google, wiki and trawl is my modus operandi. And I have discovered all the previous information relating to these problems which HAVE arisen before. This suggests the problem may be with a new build of a package which cinelerra relies on - and this is my current line of investigation. I have confirmed the external ffmpeg definitely bypasses these problems. But it has others: There is a bug filed on using the current ffmpeg with cinelerra. It is probably a stretch to call it a bug as this is the reason cinelerra relies on internal ffmpeg - the api for ffmpeg has changed. It might be easier for me to learn how to patch cinelerra to call using the new swscale methods than to keep hammering away at this build. But actually that would be a whole new learning curve. Even using the oldest ffmpeg available on etch repositories (august 2006) produces this problem. I'm worried if I go back to a sarge ffmpeg I will start to break my other multimedia packages. I could try downgrading ffmpeg and linking against it however... Graham On 27/04/07, *Graham Evans* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: just wanted to point out: the problem of some objects to be liked dynamically but not beeing built with -fPIC is the most common source of build problems on x86_64. I learned to look at this first when problems pop up: are really all (note all) parts to be linked in built with -fPIC ?? I think this is a very likely cause of the build failures (after having exhausted many other possible causes). I wonder where to go looking in terms of downgrading or build my own packages. The external ffmpeg on sid list the following dependencies: libavcodeccvs51 libavformatcvs51 libavutilcvs49 libc6 libfreetype6 libimlib2 libsdl1.2debian libswscalecvs0 I guess the internal ffmpeg relies on some of these progs too. This is another line of re This is the important part. I.e. you should verify in the output of the make command, that you find this sequence of flags really in the generated command invocations somewhere (of courese there are some additional flags and there is the list of libs to include and the path to the source to compile -- but you should find your flags literally in every gcc or g++ invocation. This means esp. that in *every* invocation there is a -fPIC at some point (and no -fpic) I'm learning huge amounts from this exercise - one small step closer to being able to hack on cinelerra! ...but building it would be a good start : p But the problem is allways in the included ffmpeg directory? my problem is in building from the quicktime directory when the link is made to something in the ffmpeg/libavcodec directory. This problem: When I tried these flags after descending into quicktime or ffmpeg directories this caused the build to abort quickly with: gcc: cannot specify -o with -c or -S with multiple files occurs everywhere in the build tree if I use the CFLAGS you specified. Deleting the stray '-' Then you could hand edit the Makefile just in the FFMPEG directory to insert the right CFLAGS and CXXFLAGS (of cours this hand edits are lost as soon as you re-invoke ./configure). yes tried that: *poured over the build output tracking back from the breakpoint to refferred packages and then back again from them. *made some mini Makefiles of my own, fiddling with -prefer-non-pic flags (ie deleted them) when building in the libavcodec/386/ directory *tried deleting DUSE_MMX flags when building in the libavcodec after reading a bit on this thread: On Friday 26 January 2007 09:58, Alexis Ballier wrote..(some stuff about mmx flags sent to ffmpeg with x86_64 builds...) *mostly just confirmed that the CFLAGS and the -fPIC flags seemed to be passed on okay. None of this worked. or changed the final result. Although I've definitely added to my repetoir of techniques. some other stray details: Building with your flags causes the build to break at a slightly different point: .../usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(simple_idct_mmx.o): could not read symbols: Bad value... rather than .../usr
Re: [CinCVS] theme S.U.V. not found
just wanted to point out: the problem of some objects to be liked dynamically but not beeing built with -fPIC is the most common source of build problems on x86_64. I learned to look at this first when problems pop up: are really all (note all) parts to be linked in built with -fPIC ?? Hermann or someone else - perhaps you can help me here. As a test I installed Vales debian x86_64 packages and that went without a hitch. I think that means my external dependencies are okay... or not? Perhaps building is one thing and executing a binary is another. The pre-built packages are: cinelerra, libmpeg3hv and libquicktimehv Does success in running the pre-build eliminates any of the things I need to look for in resolving my build problems? Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
sorry Hannes - not sure how that got sent to personal address... You can try to build the internal ffmpeg with different optimization options like this: $ make terminates with an error $ cd quicktime/ffmpeg $ make clean $ make CFLAGS='-O0 -g' hopefully works... $ cd ../.. make Try different optimization levels in CFLAGS. -- Hannes Okay so I configure without any flags at all then when it breaks I move to the ffmpeg directory, make clean and the make CFLAGS=-O0 -g. After a second of building this produces an error: gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -I../.. -O0 -g -MT fdct_mmx.lo -MD -MP -MF .deps/fdct_mmx.Tpo -c fdct_mmx.c -o .libs/fdct_mmx.o/tmp/ccdU7310.s: Assembler messages: /tmp/ccdU7310.s:2075: Error: suffix or operands invalid for `pshufw' make[2]: *** [fdct_mmx.lo] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/quicktime/ffmpeg/libavcodec/i386' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual/quicktime/ffmpeg/libavcodec' make: *** [all-recursive] Error 1 If I run make in the ffmpeg directory with no flags then it builds successfully. Then when I cd ../.. make I get the same exit as before: /usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.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(cputest.o): could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libquicktimehv.la] Error 1 make[3]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory ` I will try some other CFLAGS but with my lack of skills in this area I will need to be very lucky... Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
I will try some other CFLAGS but with my lack of skills in this area I will need to be very lucky... Graham E. I tried things like: make CXXFLAGS=-fPIC make OPTCFLAGS=-fPIC make CFLAGS=-fPIC make CXXFLAGS=3D-g -fPIC You can probably tell the level of my skills from the flags I used - these I found from googling ffmpeg /amd64 compile problems. Anwyay the builds were all successful but then when I cd ../.. make the total build fails as before. And now I need to give up again until I receive further advice. Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Please tell why you can't do dynamic builds. Themes and plugins are loaded dynamically as modules, they really need dynamic builds. Changing this would be not trivial (using libltdl for the module loader for example). I suggest to fix dynamic builds rather than trying static builds. Once I had the same error, but it turned out that set GLOBAL_PLUGIN_DIR wrong (from a former test). Running cinelerra under strace control will reveal such cases (what files/paths it searches and which ones fail). Running strace cinelerra didn't produce anything meaningful to my eyes. The attempt to static build was just to get around amd 64 compile problems - to do with ffmeg/libavcodec linking (see the svn 1008 build failure thread). It sounds like I have just used impossible configure options (--disable-shared, --enable-static, -with/without-fpic etc...) If you still want me to play around with strace or post or email you output let me know... Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Are you sure about the syntax? I thought one did CXXFLAGS=-fPIC make or CXXFLAGS=-fPIC make not sure -although I sourced my syntax off the web- but #2 didn't work either. Thanks Martin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Hi Hermann work. On debian, this is very common a problem with the libx264. So they (DEBIAN,UBUNTU) provide in their package both versions, one built with -fpic and one built with -fPIC. So all you have to do there is to walk to /usr/lib and put a symlink ln -s libx264_pic.a libx264.a I myself found out about this after spending hours and hours trying to build some dependencies. AArrrgh. Of course it is stated in the README, but who is able to read all READMEs of all packages he is using?? I've actually built a new x264 according to some instructions I found on a ubuntu forum. I'm pretty sure I got that part right -also none of my errors seem to relate to x264 so far. I did my last cinelerra build some months ago, and I used the following in the Debian buildfile ifeq ($(DEB_HOST_ARCH),amd64) CFLAGS=-ffast-math -msse3 -march=athlon64 -funroll-loops -minline-all-stringops - -fprefetch-loop-arrays -fPIC CXXFLAGS=$(CFLAGS) -fno-check-new CONFFLAGS+=--enable-sse3 --with-pic endif This is excellent detail thank you. I've played around with your flags in various configurations but so far **no success**. What I really need to know is whether these are the flags are passed to the cinelerra build process as a whole or whether your script is building cinelerra in parts and these flags were just those given to the internal ffmpeg. Or perhaps the make in the quicktime directory? When I tried these flags after descending into quicktime or ffmpeg directories this caused the build to abort quickly with: gcc: cannot specify -o with -c or -S with multiple files When I tried them on cinelerra as a whole I got various different results but so far none of them look like progress. Of course your situation is different; I would guess the CONFFLAGS are the flag passed to ./configure, which you are invoking by hand, and you can put the CFLAGS and CXXFLAGS into the environement prior to invoking ./configure, so they are picked up and written into every generated makefile (is that the way it works? not sure though). I have found two different ways that seem to work. On the main cinelerra build: ./configure -xxx -xxx CFLAGS= CXXFLAGS= FFMPEGCFLAGS= and also ./configure -xxx -xxx make CFLAGS= CXXFLAGS= and just make CFLAGS= CXXFLAGS= for trying to build from the ffmpeg directory. I know building is hell, but you can survive it (most of us survived it) ;-) I want my cinelerra back so I will get this worked out. Or perhaps vale will update amd 64 packages for opengl and bluedot. big hint! Maybe I'll be expert enough by the end of this to do it myself. Hope that helps it helps even if it doesn't. thanks again. Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
I just noticed my configure output contains these lines: config.status: creating po/Makefile.in config.status: WARNING: po/Makefile.in.in seems to ignore the --datarootdir setting does anyone know if this is significant? Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] theme S.U.V. not found
I run a fresh cinelerra install (had some problems building - see thread '[CinCVS] build failure svn 1008'). There is currently no ~/.bcast directory and I get a crash after a brief flash of life: MWindow::init_theme: theme S.U.V. not found. Running as root makes no difference. I tried copying a ~/.bcast from an old installation and this time it fails with: MWindow::init_theme: theme Blue Dot not found. I have checked and the bluedot and suv themes were installed into /usr/local/lib/cinelerra as expected. Obviously my problems might relate to the options and steps I had to go through to build. Any ideas will be very appreciated. Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Martin Ellison wrote: Maybe it's your path. It seems that it is looking in the wrong place. It seems all these problems have come up before but I can't find the solutions. Apparently the themes aren't building properly because of the static linking options I've used in my configure line. But I can't get a successful build without those options... Static and dynamic linking is beyond my knowledge at present so my remaining options are: sacrifice open gl and try out the http://giss.tv/~vale deb packages, perhaps try and compile with an old external ffmpeg (mid 2006 cvs is not early enough and earlier than that is likely to mess with my other sid programs), or open up my fedora core 4 64 partition which runs latest cinelerra CV no probs... Thanks for the suggestions anyway... if anyone thinks of anything else I'd be glad to hear from them. Graham E. On 25/04/07, *Graham Evans* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I run a fresh cinelerra install (had some problems building - see thread '[CinCVS] build failure svn 1008'). There is currently no ~/.bcast directory and I get a crash after a brief flash of life: MWindow::init_theme: theme S.U.V. not found. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] compiling problemes
Levente Kovacs wrote: Hi folks, I am a newbie, and having hard rime compiling the code. Make in the guicast directory says: /usr/bin/ld: cannot find -lXxf86vm If I edit the Makfile by hand and delete the -lXxf86vm, Wrong move. You need to find the missing piece instead. Obviously the configure script didn't pick this up. having a quick search in synaptic I notice libxxf86vm and libxxf86vm.dev. Install those and try again. Good luck. Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure svn 1008
You can also try this (before you try the suggestion in my answer to this other thread): ./configure --without-pic thanks Hannes. That one didn't work. Or any variations on it. So now for the other thread... ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] build failure svn 1008
I have just changed from fc4 to debian-sid. I am on an amd-64-smp processor and running the nvidia drivers. Everything is up to date. I downloaded cinelerra cv svn1008 but my build fails like this: o /usr/lib/libjpeg.so -lpng -lz -lm -ldl -lpthread -Wl,--no-undefined -Wl,-soname -Wl,libquicktimehv-1.6.0.so.1 -o .libs/libquicktimehv-1.6.0.so.1.0.0 /usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.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(cputest.o): could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libquicktimehv.la] Error 1 make[3]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 I have tried many things and done lots of searching around the archives but have failed to solve this. Any suggestions? Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure svn 1008
Bas Alphenaar wrote: I'm on 64 bit Gentoo and I had the exact same problem.I solved the problem by installing (emerging on Gentoo) ffmpeg seperately and then running ./configure with the --with-external-ffmpeg flag. I hope this solves the problem for you. Bas thanks for the tip. I forgot to mention (although you guessed) my Debian Sid is pure 64. I tried the external ffmpeg flag already. The result is different but my build still terminates. This time with: make[2]: Entering directory `/home/gray/install/hvirtual/guicast' source='bcbar.C' object='bcbar.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ /bin/sh ../libtool --tag=CXX --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I../quicktime -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o bcbar.lo bcbar.C libtool: ignoring unknown tag CXX libtool: ignoring unknown tag CXX mkdir .libs g++ -DHAVE_CONFIG_H -I. -I.. -I../quicktime -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c bcbar.C -fPIC -DPIC -o .libs/bcbar.o ../libtool: line 1281: g++: command not found make[2]: *** [bcbar.lo] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/guicast' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 Graham Evans wrote: I have just changed from fc4 to debian-sid. I am on an amd-64-smp processor and running the nvidia drivers. Everything is up to date. I downloaded cinelerra cv svn1008 but my build fails like this: o /usr/lib/libjpeg.so -lpng -lz -lm -ldl -lpthread -Wl,--no-undefined -Wl,-soname -Wl,libquicktimehv-1.6.0.so.1 -o .libs/libquicktimehv-1.6.0.so.1.0.0 /usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.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(cputest.o): could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libquicktimehv.la] Error 1 make[3]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual/quicktime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual' make: *** [all] Error 2 I have tried many things and done lots of searching around the archives but have failed to solve this. Any suggestions? Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure svn 1008
I'm now working my way through the http://giss.tv/~vale deb packages trying to pick up any missing dependencies. Now that I have changed wrong versions and installed some missing libav* and libav*.dev files (for instance from bugzilla I found out that libavcodec0 is wrong and the libavcodeccvs51 is what I need) I am getting the same result (as per my original post) with or without external ffmpeg. Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What is the best way to import a sequence of images?
Check out: https://svn.bourget.cc/svn/wackystuff/programs/CreateCinelerraSequence/ It's a script that creates a JPEGLIST or PNGLIST out of a bunch of PNG files. This way, it loads into Cinelerra as *one* single video, and doesn't take the overhead of loading thousands of assets. php! - necesity is the mother of invention I have written a bash script for exactly the same function over the last few days. It seems to be pretty solid. http://www.karricountry.com.au/animtext.sh To use it I move the script into my /usr/bin: mv cp ~/animtext.sh /usr/bin/animtext Then, in a terminal, go to the directory with the image files and type animtext The script should identify the filetype and create and index file. Optional parameters: animtext filetype framerate filepath as in: animtext png 23.976 animation/sources/1 If you don't like my default framerate of 12 then hack the script. I have another script which works but which needs some debugging. It is triggered when I hotplug my camera. It downloads the images into a date indexed folder, does pre-processing of raw, jpg and png images, rotates 180 degrees if neccessary , changes aspect ratios if neccessary and then calls this animtext script. The idea is to keep mechanical processing out of cinelerra and have a better experience in terms of render speed and previewing... My animation workflow is getting pretty smooth with a bit of amateur bash programming. I will post a link to the second script once it is more solid. Graham E. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] getting started - can't play edited clip - regular clip play stops working
The interesting thing would be if there are any ALSA users who do _not_ need this option. The hardware/OS/ALSA version combination may give some clues where the workaround is needed. -- Hannes I seem to be one of those interesting cases. On reading your message I switched from oss to alsa and didn't enable the workaround. Sound was fine and playback smooth. No lock-ups. Not after a restart either. Any reliable way of reproducing this problem ? I am using Audigy 2ZS sound card on an Asus A8n-sli premium mobo. 2gb ram, AMD64 X2 4200+. Onboard sound disabled. Single PCI-Express Geforce6 video card with nvidia binary blob driver. On the Creative Labs card I am using the default emu10k1 'standard pcm playback device' (hw 0,1) rather than the newer 32 bit p16v chip. The setup is FC4_64. Alsa version 1.0.10-3 I'm not great at troubleshooting but happy to try... Graham ___ 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
Re: [CinCVS] new to group
On Sun, 2007-02-04 at 17:11 -0800, Chris Reynolds wrote: I found the filedv.C patch but when I did patch filedv.C filedv.C.patch I got the error message patch: Can't find file filedv.C : No such file or directory is this because I installed cinelerra on Ubuntu Dapper by updating my sources.list and then using apt-get to install it? I tried compiling it from source but never could get that to work . Chris Chances are what you have is a binary of cinelerra - you can't apply a patch to cinelerra in that form. Valentina and muzzol, on this list, are working on ubuntu packaging (making new binaries) after the previous maintainer retired. The latest message to this list on that topic was Jan 20th 2007. Vale has cinelerra packages here: #debian amd64 deb http://giss.tv/~vale/debian64 ./ deb-src http://giss.tv/~vale/debian64 ./ #ubuntu edgy deb http://giss.tv/~vale/ubuntu32 ./ deb-src http://giss.tv/~vale/ubuntu32 ./ #ubuntu edgy amd64 deb http://giss.tv/~vale/ubuntu64 ./ deb-src http://giss.tv/~vale/ubuntu64 ./ - but those are packages for ubuntu edgy. If you want to try building from source just keep searching through the list archives to work through each problem as you come to it. Otherwise you will probably have to wait.. Graham Richard Rasker [EMAIL PROTECTED] wrote: Op zo, 04-02-2007 te 14:13 -0800, schreef Chris Reynolds: Wanted to say hi and post a question. I'm pretty new to Cinelerra and I've run into an issue that I can't figure out. I've got a dv file that I captured wth kino in 16:9 and I edited it down. Then I wanted to render it back out as dv so I could take it into another program. Problem is the aspect ratio keeps getting switched to 4:3 even though I have it set to 16:9 in the project settings. I'm also getting this weird popping sound every 2 seconds or so that isn't in my original dv file. Anyone have any suggestions ?. I don't know about the aspect ration problems, but the problem with regular popping sound is an old one - see my question titled Raw DV rendering problems? about this, from September 12th on this list (and of course the answers). I guess you have an (older) pre-packaged version; the best solution is to build a recent Cinelerra version from source, at least until some recent version has been packaged into whatever package format you use. Regards, Richard Rasker ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra Chris Reynolds http://builderofstuff.com Computers are like air conditioners - They can't do their job properly if you open windows. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] getting started - can't play edited clip - regular clip play stops working
Can someone tell me what I'm doing wrong? Sounds like something to do with background rendering. In Preferences/ Performance turn that off and see if that helps. Graham ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build problem undefined reference to `mm_flags'
On Sun, 2006-10-29 at 00:19 +0930, Pierre Marc Dumuid wrote: I fixed this for gour and Jean-Luc (see discussion in IRC log).. Could you confirm that it is fixed for yourself? (I assume you don't configure with --enable-mmx) Pierre success with r948! On your other question: In this case my only flag was --enable-opengl (unnecessary I believe). I have been fiddling with the --enable-mmx and the --enable-3dnow options. My r940 build included them. My failed r947 builds I tried both with and without these flags. Looking at the irc logs I am not the only one unclear on the effect of these options. If I spot any performance differences by eliminating them I will let the list know. thanks for fixes and enhancements Pierre Graham Pierre ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] build problem undefined reference to `mm_flags'
I just ran into problems trying to upgrade from svn 940 to svn 947 on fc4_64. I ran a make clean and autogen then ./configure --enable-opengl Make aborted as follows: ... /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/utils.c:635: undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(utils.o)(.text+0x1e55): In function `avcode c_encode_video': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/utils.c:597: undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text+0x3c8): In function `DCT _common_init': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpegvideo.c:247: undefined refer ence to `MPV_common_init_mmx' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text+0x28b0): In function `ff _draw_horiz_band': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpegvideo.c:4006: undefined refe rence to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text+0x6748): In function `MP V_frame_end': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpegvideo.c:1593: undefined refe rence to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text+0x72fb): In function `MP V_encode_picture': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpegvideo.c:5299: undefined refe rence to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text +0x79a6):/home/gray/hvirt ual/quicktime/ffmpeg/libavcodec/mpegvideo.c:5457: undefined reference to `mm_fla gs' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text +0x8322):/home/gray/hvirt ual/quicktime/ffmpeg/libavcodec/mpegvideo.c:2219: undefined reference to `mm_fla gs' ffmpeg/libavcodec/.libs/libavcodec.a(mpegvideo.o)(.text +0x108d5):/home/gray/hvir tual/quicktime/ffmpeg/libavcodec/mpegvideo.c:5781: more undefined references to `mm_flags' follow ffmpeg/libavcodec/.libs/libavcodec.a(dsputil.o)(.text+0xd1de): In function `dspu til_init': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/dsputil.c:3911: undefined refere nce to `dsputil_init_mmx' ffmpeg/libavcodec/.libs/libavcodec.a(imgresample.o)(.text+0x553): In function `i mg_resample': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/imgresample.c:464: undefined ref erence to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o)(.text+0x2a62): In function `decod e_frame': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mdec.c:210: undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o)(.text+0x79ee): In function `mpeg_ decode_frame': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpeg12.c:3186: undefined referen ce to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(mpeg12.o)(.text+0x7ba1): In function `slice _decode_thread': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/mpeg12.c:2706: undefined referen ce to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o)(.text+0xac3): In function `f f_rate_control_uninit': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/ratecontrol.c:181: undefined ref erence to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(ratecontrol.o)(.text +0x17e0):/home/gray/hvi rtual/quicktime/ffmpeg/libavcodec/ratecontrol.c:630: more undefined references t o `mm_flags' follow ffmpeg/libavcodec/.libs/libavcodec.a(fft.o)(.text+0xb1): In function `ff_fft_ini t': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/fft.c:65: undefined reference to `mm_support' ffmpeg/libavcodec/.libs/libavcodec.a(fft.o)(.text +0x2ac):/home/gray/hvirtual/qui cktime/ffmpeg/libavcodec/fft.c:97: undefined reference to `ff_fft_calc_sse' ffmpeg/libavcodec/.libs/libavcodec.a(faandct.o)(.text+0x10): In function `ff_faa ndct248': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/faandct.c:180: undefined referen ce to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(faandct.o)(.text+0x420): In function `ff_fa andct': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/faandct.c:127: undefined referen ce to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(h263dec.o)(.text+0x1354): In function `ff_h 263_decode_frame': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/h263dec.c:640: undefined referen ce to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(asv1.o)(.text+0x1cc5): In function `encode_ frame': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/asv1.c:499: undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(asv1.o)(.text+0x1fe8): In function `decode_ frame': /home/gray/hvirtual/quicktime/ffmpeg/libavcodec/asv1.c:459: undefined reference to `mm_flags' ffmpeg/libavcodec/.libs/libavcodec.a(cljr.o)(.text +0x22f):/home/gray/hvirtual/qu icktime/ffmpeg/libavcodec/cljr.c:77: more undefined references to `mm_flags' fol low collect2: ld returned 1 exit status make[3]: *** [libquicktimehv.la] Error 1 make[3]: Leaving directory `/home/gray/hvirtual/quicktime' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gray/hvirtual/quicktime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/hvirtual' make: *** [all] Error 2 any ideas? Graham E.
