Re: [CinCVS] bounty for DV1394/IEC61883 record function hang
On 2007-12-30 00:52, Scott C. Frase wrote: > Hey guys, > Since I have use for this particular function, it would be very nice for > Cinelerra to have the ability to import live video via DV1394 (DV video) > or IEC61883 (HDV, in my case) at the same time as audio. I hearby offer > $100 to anyone who wants to fix the problems outlined in bugs 307/334: > http://bugs.cinelerra.org/show_bug.cgi?id=307 > http://bugs.cinelerra.org/show_bug.cgi?id=334 Actually, you'd want to use the iec61883 interface layer for DV also. The dv1394 interfaces are deprecated from what I've read. > > I am willing to let a reliable, interested party borrow my video cam in > order to get this working. > > let me know if there are any takers, > scott I started some of this work a while back (a long while back) but moved to other things before doing much code. I'll let you know if I get back on it in the near future. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] YUV4MPEG stream too dark
Herman Robak wrote: > On Sat, 29 Dec 2007 09:09:45 +0100, Craig Lawson > <[EMAIL PROTECTED]> wrote: > >> This is a rather esoteric issue, and it caused me grief for a long time. >> Here's a UI proposal: offer an option to apply ITU-R BT.601 color space >> conversion in the render dialog, with a tool tip suggesting you probably >> want it for MPEG. The option would give a hint to the clueless, and >> experts can use the RGB - 601 filter as they see fit. > > Let's take a step back, and figure out what is going on and what > The Right Thing To Do actually is... > > Is this dark output only produced by YUV4MPEG, and not when you render > to MPEG video with Cinelerra directly? If so, why? > > If ITU-R BT.601 is the right colourspace for conformant MPEG video, > then the codec should do that conversion when needed. It would be a > pain if certain codecs need "special treatment". The trouble is (as > far as I understand it) to discover when it IS needed. Cinelerra can > know that, but whatever command line you attach to the YUV4MPEG pipe > may not. And since the pipe interface is opaque to Cinelerra; it > doesn't know what the codec in the other end does, Cinelerra can not > decide if a conversion is needed or not. > > Is the paragraph above a fair summary of the problem here? > > > Now, to see what would be the least fuss for the most users, we need > to know which codecs need the colourspace conversions, and which don't. > Bring on the special cases! > Good point, and I agree. My trouble was also with YUV4MPEG for DVD production, using mpeg2enc. If there is a 601 conversion filter which can be inserted into the pipe, then Cinelerra's YUV4MPEG menu can include it. ___ 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] ADVC, DV and HDV Hard disk recorder
Isn't the best solution for Hi8 to buy a Digital8 camcorder somewhere and play it out via Firewire? Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ADVC, DV and HDV Hard disk recorder
Herman Robak wrote on Sat, 29 Dec 2007 > On Sat, 29 Dec 2007 19:41:15 +0100, Terje J. Hanssen wrote > >> > Even that probably nobody here has used this new recorder before, I wish >> > to get viewpoints and suggestions as feedback before I possibly go for >> > this solution myself. Maybe I oversee something? >> > >> > First my selection from the manual: >> > >> > /Datavideo Technologies //DN-300 can record HDV via the IEEE-1394 >> > (iLink, FireWire) output from HDV Camcorders (.m2t), or DV from DV or >> > Analogue video sources (.dv). >> > The DN-300 can be as an external firewire drive from which files can be >> > dragged and dropped to a PC or MAC. The DN300 also has a built in >> > utility to convert .dv files to .avi files. >> > > Interesting, but pricey. Yes, also my (first) impression, somewhat pricy, about 10k NOK incl.vat http://www.macrovideo.no/wwwDatavideo/datavideopriser.htm On the other hand I need to convert and backup all of and edit parts of of my 70 Hi8 analog tapes each 60-90 minutes. A Canopus ADVC-110 alone would costs about 25-30% of DN-300 which has this function built-in. And another product, Macrosystem HDV-Recorder HDD/RT does cost nearly 70% more http://www.scandinavianphoto.no/product/item.aspx?iID=5298667 > I would have been tempted if it came with a battery. I guess not what you think of, but by adding 12% to its price there is a DC Stabilizer DDC–1512 for DN-300 so that it can be used with a unregulated 12V batteries, cigarette lighters or 12V supplies http://www.datavideo.us/products/dc_stabilizer_main_page.htm > It certainly has more compelling controls than the CitiDisk, > which really only has the small size and weight going for it. > > > >> > //The DN-300 uses a FAT32 file structure, so large tracks are broken >> > down into 2 GB files which are sequentially named. For example if Track >> > 02 is 1 hour in duration it will appear as follows (max 99 tracks): >> > >> > dv02.dv(2 GB) - dv02 is the file name for Track 02 >> > dv02_01.dv (2 GB) - Each 2 GB section is given a sequential _xx numeric >> > extension >> > dv02_02.dv (2 GB) >> > ... > >> > dv02_06.dv (77 MB) - The last file in the sequence is likely to be >> > smaller than 2GB. >> > > This can be quite annoying if you need to recode a long recording > quickly. As far as I can tell, ffmpeg doesn't take sequences of > files as input. > > Looks like video files (DV, MPG and AVI) might be joined together with Linux cat and when needed resync audio/video with mplayer/mencoder http://www.arsgeek.com/?p=435 If this method does work, it can be used before archieving (backup) "raw" DV and M2T files on typical 50GB BDR disks (almost 4 hours raw video) I'm not sure how empty, short parts on tapes will be treated as adding a new track. I know there occure short unrecorded parts with break in the RCTC timecodes which then starts from 00 againg on some of my Hi8 tapes. AFAIK RCTC timecodes neither can be preserved when converting to DV(?) > >> > 2. Is here something that may probibit the files and formats to be used >> > with Cinelerra as NLE? >> > > Various libs and apps may not recognise or parse the files well, > if they happen to violate the (wrong?) assumptions made by those > libs and apps. Kino and ffmpeg don't recognise the AVI files made > by the CitiDisk, for what it is worth. (but xine can play them) > > > >> > 3. At first I was somewhat doubtful about the FAT32 file system on the >> > DN-300 disk that did split larger tracks in filesizes of 2GB each. Maybe >> > this isn't any drawback, as 2GB in practice may be large enough to drag >> > and drop onto Cinelerra each time? >> > > Sure. Cinelerra can open several files at a time, which makes this > pesky splitting less annoying. Still I would like some file system > backend (an KDE ioslave or equivalent, maybe?) to lump such files > together to hide this kludge. > > Conclusion: And me that thought I had found the "default solution" that I could trust would work easy and flawless recording DV and HDV on, avoiding any capturing problems using dvgrab :) Therefore again, do you advice against it(s file structure) or will you possibly say that DN-300 looks to be a useful solutin for the described purpose? Thanks, Terje J. Hanssen ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] bounty for DV1394/IEC61883 record function hang
Hey guys, Since I have use for this particular function, it would be very nice for Cinelerra to have the ability to import live video via DV1394 (DV video) or IEC61883 (HDV, in my case) at the same time as audio. I hearby offer $100 to anyone who wants to fix the problems outlined in bugs 307/334: http://bugs.cinelerra.org/show_bug.cgi?id=307 http://bugs.cinelerra.org/show_bug.cgi?id=334 I am willing to let a reliable, interested party borrow my video cam in order to get this working. let me know if there are any takers, scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
On Sat, 2007-12-29 at 20:27 +0100, Christian Thaeter wrote: > Cinelerra has some race problems between threads which let them wait on > each other doing nothing, this is hard to fix unfortunally. But > generally I think adding more CPU's will add some performance > improvement. While in doubt, you may better opt for more ram (4 or more > GB of ram). For long time future I we will fix this (with what is called > cinelerra 3 now) to have no races and utilize multi cpu systems much > bettter, but don't hold your breath yet for that. > > Christian Hi Christian, Yes, I continue to notice race conditions here and there. For example, after doing some basic editing on a HDV project with two stereo audio tracks and one video track, I wanted to move one audio track down in the timeline. When I did this, I triggered a race condition that hung a CPU at 100% for 30 minutes. Bummer. Hannes gave me some instruction last year on how to track these issues down using kdbg: http://crazedmuleproductions.blogspot.com/search/label/kdbg I will try to capture some debug information the next time it happens. scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ADVC, DV and HDV Hard disk recorder
On Sat, 29 Dec 2007 21:05:19 +0100, Stefan de Konink <[EMAIL PROTECTED]> wrote: On Sat, 29 Dec 2007, Herman Robak wrote: When are such devices going to use more capable file systems?! When some people team up to create a small arm board with firewire :) and run linux on it :) The Debconf video team will be interested! :-) Others? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to Add Title Screens?
On Sat, 29 Dec 2007 20:54:38 +0100, Martin Ahnelöv <[EMAIL PROTECTED]> wrote: lör 2007-12-29 klockan 16:30 +0100 skrev Herman Robak: ... Cinelerra could do "helpful" things that would aid some users but disorient others, like changing the zoom level whenever a small item is dropped on the timeline. Any better suggestions? Yes, when dropping still images to the timeline, they could be one second long by default (or rather, a user-defined length). How often do you use images of one frame's length, anyway (if you aren't combining multiple png's into a animation, Well, you just pointed out a common usecase. I'm not sure how smart it would be to try and make Cinelerra "clever" and have one behaviour if the user loads several files and another if the user only loads a single image. I was more thinking of changing the view scroll and zoom so the user sees the image in a suitable size. see the note about customisable length). Cinelerra has a setting for this already, in the Preferences. But a better place for the setting would be the file load dialog. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ADVC, DV and HDV Hard disk recorder
On Sat, 29 Dec 2007, Herman Robak wrote: > When are such devices going to use more capable file systems?! When some people team up to create a small arm board with firewire :) and run linux on it :) Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ADVC, DV and HDV Hard disk recorder
On Sat, 29 Dec 2007 19:41:15 +0100, Terje J. Hanssen <[EMAIL PROTECTED]> wrote: Even that probably nobody here has used this new recorder before, I wish to get viewpoints and suggestions as feedback before I possibly go for this solution myself. Maybe I oversee something? First my selection from the manual: /Datavideo Technologies //DN-300 can record HDV via the IEEE-1394 (iLink, FireWire) output from HDV Camcorders (.m2t), or DV from DV or Analogue video sources (.dv). The DN-300 can be as an external firewire drive from which files can be dragged and dropped to a PC or MAC. The DN300 also has a built in utility to convert .dv files to .avi files. Interesting, but pricey. I would have been tempted if it came with a battery. It certainly has more compelling controls than the CitiDisk, which really only has the small size and weight going for it. //The DN-300 uses a FAT32 file structure, so large tracks are broken down into 2 GB files which are sequentially named. For example if Track 02 is 1 hour in duration it will appear as follows (max 99 tracks): dv02.dv(2 GB) - dv02 is the file name for Track 02 dv02_01.dv (2 GB) - Each 2 GB section is given a sequential _xx numeric extension dv02_02.dv (2 GB) ... dv02_06.dv (77 MB) - The last file in the sequence is likely to be smaller than 2GB. This can be quite annoying if you need to recode a long recording quickly. As far as I can tell, ffmpeg doesn't take sequences of files as input. 2. Is here something that may probibit the files and formats to be used with Cinelerra as NLE? Various libs and apps may not recognise or parse the files well, if they happen to violate the (wrong?) assumptions made by those libs and apps. Kino and ffmpeg don't recognise the AVI files made by the CitiDisk, for what it is worth. (but xine can play them) 3. At first I was somewhat doubtful about the FAT32 file system on the DN-300 disk that did split larger tracks in filesizes of 2GB each. Maybe this isn't any drawback, as 2GB in practice may be large enough to drag and drop onto Cinelerra each time? Sure. Cinelerra can open several files at a time, which makes this pesky splitting less annoying. Still I would like some file system backend (an KDE ioslave or equivalent, maybe?) to lump such files together to hide this kludge. When are such devices going to use more capable file systems?! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to Add Title Screens?
lör 2007-12-29 klockan 16:30 +0100 skrev Herman Robak: > On Sat, 29 Dec 2007 11:53:26 +0100, Martin Ahnelöv <[EMAIL PROTECTED]> > wrote: > > >> Since still images don't have a native "duration", it is perfectly > >> OK to extend their duration by dragging the end of the vertical bar > >> you see on the timeline. You may have to zoom the timeline view > >> until the bar gets a few pixels wide. The view controls are at > >> the bottom of the timeline window. > >> > >> > >> Variations of the question above come up from time to time. > >> Are there some hints that the GUI could give new users to make > >> this more discoverable? (apart from a "wizard" telling "You just > >> loaded a single image to the timeline." *sneer*) > >> > > > > You mean something like that the arrow transform itself to an arrow > > (pointing to the right if you are dragging the end of the clip, etc) > > when it hovers over a drag-able area? > > > > With arrow I don't mean the pointer, but like... the dubble-arrow that > > could be seen in various gtk-apps when you resize columns and > > separators. > > I'm not sure if I follow. Cinelerra's pointer _does_ change > appearance to a double-arrow when you hover above a clip boundary. > Did you mean something else? Ah, I see. I don't notice these things anymore ^^; > > There are at least two challenges: > > 1) Discovering where you should hover the mouse. > > 2) Finding single images and dragging their start/end > when they are just two pixels wide on the timeline. > > > Cinelerra could do "helpful" things that would aid some users > but disorient others, like changing the zoom level whenever a > small item is dropped on the timeline. Any better suggestions? > Yes, when dropping still images to the timeline, they could be one second long by default (or rather, a user-defined length). How often do you use images of one frame's length, anyway (if you aren't combining multiple png's into a animation, see the note about customisable length). Just a thought, Gasten ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
Scott C. Frase wrote: > On Thu, 2007-12-27 at 11:45 -0600, Timothy Baldridge wrote: >> Your disk performance may be holding you back as well. On the oil >> effect, you are CPU bound, on a faster effect (e.g. grayscale) you >> will be primarily IO bound. Here's an example. Only recently (in the >> past 3 years) has Discreet moved to x86. Before that they were selling >> their highest end product (for editing 4K film) on a quad CPU 1Ghz. >> But they smoked the competition when it came to performance. Why? Most >> of the time these systems had a 10-30 fibre channel RAID behind them. >> This allowed the Tezro and Onyx3 systems to edit 5 streams of >> real-time 4k video on a system that had basically no number crunching >> power. 9 times out of 10 you will be limited by your disk performance, >> not the CPU. >> >> I would suggest running a bonnie++ benchmark on your disks, from there >> you can calculate an approximate max fps processing rate for the >> disks. >> >> Timothy > Hi Timothy, > Thanks for the thought. I have been monitoring wait i/o via mpstat and > it doesn't seem to be the issue. Here's recent output of mpstat using a > bunch of effects on a HDV video render, including oil painting. The > sixth column is iowait: > > 01:15:45 PM CPU %user %nice%sys %iowait%irq %soft %steal > %idleintr/s > 01:15:55 PM0 87.300.000.600.000.000.300.00 > 11.80150.20 > 01:15:55 PM1 87.400.000.700.000.000.000.00 > 11.90127.90 > 01:15:55 PM2 86.700.000.400.200.000.300.00 > 12.40150.20 > 01:15:55 PM3 87.710.000.300.000.000.000.00 > 11.99128.00 > 01:15:55 PM4 87.400.000.400.000.000.000.00 > 12.20134.30 > 01:15:55 PM5 87.100.000.600.000.000.000.00 > 12.30128.00 > 01:15:55 PM6 86.700.000.100.000.000.000.00 > 13.20134.10 > 01:15:55 PM7 86.800.000.200.000.000.000.00 > 13.00128.50 > > > Notice that iowait is zero. I do have a couple of RAID 0 filesystems, > one based on software RAID and the other hardware. > > scott Cinelerra has some race problems between threads which let them wait on each other doing nothing, this is hard to fix unfortunally. But generally I think adding more CPU's will add some performance improvement. While in doubt, you may better opt for more ram (4 or more GB of ram). For long time future I we will fix this (with what is called cinelerra 3 now) to have no races and utilize multi cpu systems much bettter, but don't hold your breath yet for that. Christian > > > ___ > 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
[CinCVS] ADVC, DV and HDV Hard disk recorder
Even that probably nobody here has used this new recorder before, I wish to get viewpoints and suggestions as feedback before I possibly go for this solution myself. Maybe I oversee something? First my selection from the manual: /Datavideo Technologies //DN-300 can record HDV via the IEEE-1394 (iLink, FireWire) output from HDV Camcorders (.m2t), or DV from DV or Analogue video sources (.dv). The DN-300 can be as an external firewire drive from which files can be dragged and dropped to a PC or MAC. The DN300 also has a built in utility to convert .dv files to .avi files. Records DV from Digital or Analogue Video Inputs (DV via IEEE-1394 (iLink FireWire) or Component (YPbPr) / S-Video (Y/C) / Composite (CVBS) analogue video inputs). Records HDV (.m2t) from HDV input (HDV via IEEE-1394 (iLink, FireWire)). Full VTR playback functionality, including loop playback. RS-422 control GPI input Drag and Drop file transfer to PC or MAC via IEEE-1394. The DN-300 cannot be operated as a DV Device from a PC -The AVC Command set is not supported. //The DN-300 uses a FAT32 file structure, so large tracks are broken down into 2 GB files which are sequentially named. For example if Track 02 is 1 hour in duration it will appear as follows (max 99 tracks): dv02.dv(2 GB) - dv02 is the file name for Track 02 dv02_01.dv (2 GB) - Each 2 GB section is given a sequential _xx numeric extension dv02_02.dv (2 GB) dv02_03.dv (2 GB) dv02_04.dv (2 GB) dv02_05.dv (2 GB) dv02_06.dv (77 MB) - The last file in the sequence is likely to be smaller than 2GB. Once transferred to a PC/MAC files can be dropped onto a timeline, in a suitable NLE application, and they will playback seamlessly. The DN-300 has a built in file conversion utility which can convert .dv files to .avi files (type 1 or type 2). You can choose the format that best suits your NLE platform. N.B. The DN-300 requires sufficient HDD space to create the .avi file. For example a One GB .dv file will require at least One GB of free space on the DN-300 for the .avi file to be created. Tracks that have been recorded in M2T (HDV) cannot be converted to .avi The converted AVI file will not be displayed on the track list, but it will be available to drag and drop to a PC. The conversion takes about 60% realtime, i.e. A 1 hour track will take around 36 minutes to convert. / - Datavideo Technologies DN-300 DV&HDV stand alone, portable hard disk recorder looks to be an interesting and simple solution for both analog (S-)video to DV conversion, and for simple capturing of DV and HDV (M2T). Continuously directly recording for up to 18 hours on the large, portable 250GB hard disk can be made tapeless. Monitoring on a standard monitor while recording DV and HDV. Recorded files can playback on a standard monitor or the camcorders viewfinder. The drawback as far as I think, is its lack of a HDMI out port. Maybe its YUV port can be connected to a (PC connection) D-Sub port on a HDTV for playback viewing. Especially and of real interest here as I see it, is the feature to set DN-300 in "hard disk mode", mount it and use it as an external and portable Firewire disk for a PC or laptop for further NLE, postproduction, archieving (backup) and/or distribution purposes on i.e DVD/BD media. My questions: 1. Although (as usual) only PC and Mac are mentioned, is here something that may prohibit DN-300 to be mounted and used as an external Firewire disk on Unix as well? 2. Is here something that may probibit the files and formats to be used with Cinelerra as NLE? 3. At first I was somewhat doubtful about the FAT32 file system on the DN-300 disk that did split larger tracks in filesizes of 2GB each. Maybe this isn't any drawback, as 2GB in practice may be large enough to drag and drop onto Cinelerra each time? http://www.datavideo.info/en/products/dn300.shtm http://www.datavideo.info/prodimages/DN-300_Rear.jpg http://www.datavideo.info/specs/DN-300.pdf Regards, Terje J. Hanssen ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
On Thu, 2007-12-27 at 11:45 -0600, Timothy Baldridge wrote: > Your disk performance may be holding you back as well. On the oil > effect, you are CPU bound, on a faster effect (e.g. grayscale) you > will be primarily IO bound. Here's an example. Only recently (in the > past 3 years) has Discreet moved to x86. Before that they were selling > their highest end product (for editing 4K film) on a quad CPU 1Ghz. > But they smoked the competition when it came to performance. Why? Most > of the time these systems had a 10-30 fibre channel RAID behind them. > This allowed the Tezro and Onyx3 systems to edit 5 streams of > real-time 4k video on a system that had basically no number crunching > power. 9 times out of 10 you will be limited by your disk performance, > not the CPU. > > I would suggest running a bonnie++ benchmark on your disks, from there > you can calculate an approximate max fps processing rate for the > disks. > > Timothy Hi Timothy, Thanks for the thought. I have been monitoring wait i/o via mpstat and it doesn't seem to be the issue. Here's recent output of mpstat using a bunch of effects on a HDV video render, including oil painting. The sixth column is iowait: 01:15:45 PM CPU %user %nice%sys %iowait%irq %soft %steal %idleintr/s 01:15:55 PM0 87.300.000.600.000.000.300.00 11.80150.20 01:15:55 PM1 87.400.000.700.000.000.000.00 11.90127.90 01:15:55 PM2 86.700.000.400.200.000.300.00 12.40150.20 01:15:55 PM3 87.710.000.300.000.000.000.00 11.99128.00 01:15:55 PM4 87.400.000.400.000.000.000.00 12.20134.30 01:15:55 PM5 87.100.000.600.000.000.000.00 12.30128.00 01:15:55 PM6 86.700.000.100.000.000.000.00 13.20134.10 01:15:55 PM7 86.800.000.200.000.000.000.00 13.00128.50 Notice that iowait is zero. I do have a couple of RAID 0 filesystems, one based on software RAID and the other hardware. scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] S-Video decoder to MPEG2-4 encoder
Herman Robak wrote on Sun, 23 Dec 2007 > On Sun, 23 Dec 2007 02:57:22 +0100, David Kletzli <[EMAIL PROTECTED]> > wrote: > >> > When I was originally trying to figure out how to do this, there were >> > some web-references to the effect that all NTSC camcorders support this, >> > but for whatever reason the PAL camcorders are hit and miss with their >> > support - >> > something to do with the expense of putting in an A/D converter. > > More like taxes on devices that can record "television". > > Back in the day, there were European models of video camcorders which had > both the video input circuitry _and_ the plug ... but no opening in the > camera body to expose that plug! Workaround: Make a hole in the plastic > to uncover the plug you weren't supposed to have. > > Certain taxes cause a lot of brain damage... Although I haven't tested it yet, my new Sony HDR-FX7E HDV & DV camcorder allows HDV and DV recording from an external source through the i.Link Input. However, reading the above, I discovered on the web an adapter/cable product "DVMax enabler" that unlock many DV/D8 camcorders so that they can be used as a portable DV recorder http://www.mamut.net/dracosystem/subdet37.htm --Terje J. Hanssen ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to Add Title Screens?
On Sat, 29 Dec 2007 11:53:26 +0100, Martin Ahnelöv <[EMAIL PROTECTED]> wrote: Since still images don't have a native "duration", it is perfectly OK to extend their duration by dragging the end of the vertical bar you see on the timeline. You may have to zoom the timeline view until the bar gets a few pixels wide. The view controls are at the bottom of the timeline window. Variations of the question above come up from time to time. Are there some hints that the GUI could give new users to make this more discoverable? (apart from a "wizard" telling "You just loaded a single image to the timeline." *sneer*) You mean something like that the arrow transform itself to an arrow (pointing to the right if you are dragging the end of the clip, etc) when it hovers over a drag-able area? With arrow I don't mean the pointer, but like... the dubble-arrow that could be seen in various gtk-apps when you resize columns and separators. I'm not sure if I follow. Cinelerra's pointer _does_ change appearance to a double-arrow when you hover above a clip boundary. Did you mean something else? There are at least two challenges: 1) Discovering where you should hover the mouse. 2) Finding single images and dragging their start/end when they are just two pixels wide on the timeline. Cinelerra could do "helpful" things that would aid some users but disorient others, like changing the zoom level whenever a small item is dropped on the timeline. Any better suggestions? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] YUV4MPEG stream too dark
On Sat, 29 Dec 2007 09:09:45 +0100, Craig Lawson <[EMAIL PROTECTED]> wrote: This is a rather esoteric issue, and it caused me grief for a long time. Here's a UI proposal: offer an option to apply ITU-R BT.601 color space conversion in the render dialog, with a tool tip suggesting you probably want it for MPEG. The option would give a hint to the clueless, and experts can use the RGB - 601 filter as they see fit. Let's take a step back, and figure out what is going on and what The Right Thing To Do actually is... Is this dark output only produced by YUV4MPEG, and not when you render to MPEG video with Cinelerra directly? If so, why? If ITU-R BT.601 is the right colourspace for conformant MPEG video, then the codec should do that conversion when needed. It would be a pain if certain codecs need "special treatment". The trouble is (as far as I understand it) to discover when it IS needed. Cinelerra can know that, but whatever command line you attach to the YUV4MPEG pipe may not. And since the pipe interface is opaque to Cinelerra; it doesn't know what the codec in the other end does, Cinelerra can not decide if a conversion is needed or not. Is the paragraph above a fair summary of the problem here? Now, to see what would be the least fuss for the most users, we need to know which codecs need the colourspace conversions, and which don't. Bring on the special cases! -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] YUV4MPEG stream too dark
Yes, that would be a very good idea, because this problem made me quite desperate. I searched the mailing lists but couldn't find anything. Now I see that the manual does mention something about the RGB - 601 filter, but when I searched the manual I searched for "brightness" and not "contrast", so I didn't find it. Craig Lawson wrote: This is a rather esoteric issue, and it caused me grief for a long time. Here's a UI proposal: offer an option to apply ITU-R BT.601 color space conversion in the render dialog, with a tool tip suggesting you probably want it for MPEG. The option would give a hint to the clueless, and experts can use the RGB - 601 filter as they see fit. Craig. Bas Alphenaar wrote: Thank you, it worked! Craig Lawson wrote: Bas, Try adding the "RGB - 601" filter to your video track(s). Configure the filter for "RGB -> 601 compression" (the default). Does that make it work? Craig. Bas Alphenaar wrote: Hello Cinelerra people, Today I tried to render out a movie I made with Cinelerra revision 1045 via a YUV4MPEG stream. However, the resulting video seems to be too dark compared to the video in the compositor. I turned on "Use Pipe" and used mencoder with the following commands: mencoder - -ovc x264 -x264encopts bitrate=3000 -o % mencoder - -ovc lavc -lavcopts vcodec=mjpeg:vbitrate=3000 -o % I also tried x264 and MJPEG with ffmpeg and they have the same problem. I think the problem lies with the YUV4MPEG stream that Cinelerra generates, because no matter what the codec or the encoding program is, the video is always too dark. Any suggestions? Or maybe this is a bug? Bas Alphenaar ___ 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 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to Add Title Screens?
fre 2007-12-28 klockan 22:35 +0100 skrev Herman Robak: > On Fri, 28 Dec 2007 20:23:03 +0100, Thomas H. George > <[EMAIL PROTECTED]> wrote: > > > I am a complete newbie at video editing but have managed to patch some > > clips together. I would like them to start following several seconds of > > a title screen. I have read the title section in the manual and found > > the title icon in Cinelerra:Resources/video effects but the mechanics of > > using this escape me. I read the HOWTO: Professional-Looking Scrolled > > Credits in Cinelerra and eventually produced a png file which I can load > > into Resources and then move to the viewer where it is displayed as > > white text on a black background. If I try to put this in a video track > > I just get a vertical bar. > > > > My problem is certainly elementary and probably has been covered many > > times. If someone would point me toward an appropriate reference I > > would greatly appreciate it. > > By default, a still image is treated just like a video frame. > That is, it will be take up the same interval as one single video > frame on the timeline, typically 1/25 second or 1/30 second. > > Since still images don't have a native "duration", it is perfectly > OK to extend their duration by dragging the end of the vertical bar > you see on the timeline. You may have to zoom the timeline view > until the bar gets a few pixels wide. The view controls are at > the bottom of the timeline window. > > > Variations of the question above come up from time to time. > Are there some hints that the GUI could give new users to make > this more discoverable? (apart from a "wizard" telling "You just > loaded a single image to the timeline." *sneer*) > You mean something like that the arrow transform itself to an arrow (pointing to the right if you are dragging the end of the clip, etc) when it hovers over a drag-able area? With arrow I don't mean the pointer, but like... the dubble-arrow that could be seen in various gtk-apps when you resize columns and separators. Gasten ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] YUV4MPEG stream too dark
This is a rather esoteric issue, and it caused me grief for a long time. Here's a UI proposal: offer an option to apply ITU-R BT.601 color space conversion in the render dialog, with a tool tip suggesting you probably want it for MPEG. The option would give a hint to the clueless, and experts can use the RGB - 601 filter as they see fit. Craig. Bas Alphenaar wrote: > Thank you, it worked! > > Craig Lawson wrote: >> Bas, >> Try adding the "RGB - 601" filter to your video track(s). Configure >> the filter for "RGB -> 601 compression" (the default). Does that make it >> work? >> >> Craig. >> >> >> Bas Alphenaar wrote: >>> Hello Cinelerra people, >>> >>> Today I tried to render out a movie I made with Cinelerra revision >>> 1045 via a YUV4MPEG stream. However, the resulting video seems to be >>> too dark compared to the video in the compositor. I turned on "Use >>> Pipe" and used mencoder with the following commands: >>> >>> mencoder - -ovc x264 -x264encopts bitrate=3000 -o % >>> mencoder - -ovc lavc -lavcopts vcodec=mjpeg:vbitrate=3000 -o % >>> >>> I also tried x264 and MJPEG with ffmpeg and they have the same >>> problem. I think the problem lies with the YUV4MPEG stream that >>> Cinelerra generates, because no matter what the codec or the encoding >>> program is, the video is always too dark. Any suggestions? Or maybe >>> this is a bug? >>> >>> Bas Alphenaar >>> >> >> ___ >> 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
