Re: [CinCV] Cin 3: my 3 cents
2008/3/27, Andreas Hermann Braml <[EMAIL PROTECTED]>: > I stand corrected, then (thanks @Thorsten, too!). When doing serious > audio on POSIX in a portable way, Jack is the way to go, right? The lazy answer is YES. ;-) Cheers -Richard -- Don't contribute to the Y10K problem! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
Richard Spindler wrote: > > While jack and pulse appear to try to solve the same problem, they > actually do have different features. > > Pulse is designed for: Audio "consumption", and "light" desktop usage: > Its for audio-players, for little plings and plongs, for making sure > that your skype headset works, that you can listen to NIN while > playing Doom, etc... > > Jack on the other hand is for Audio "Production", it is designed to be > able to record all the fancy sounds that your software synth does in > ardour, it is designed to dump all the streams from your 8-channel > soundcard to disk, it is there to put every sound from your gigabytes > of sound samples onto your speaker at the instant you press a key on > your midi-keyboard. etc... > > For simple Video Editing and some lightweight audio stuff, both pulse > and "jack" will work, and both "should" work, but keep in mind that > some people will prefer jack for its advanced features, and some will > prefer Pulse, because they want things to "just work", with a minimal > amount of fuzz. I stand corrected, then (thanks @Thorsten, too!). When doing serious audio on POSIX in a portable way, Jack is the way to go, right? Andreas -- My 5 today: #172820 (wine), #203724 (wine), #129405 (wine), #184940 (wine), #191132 (wine) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day signature.asc Description: OpenPGP digital signature
Re: [CinCV] Cin 3: my 3 cents
Hi everyone, Andreas Hermann Braml wrote: ... Jack is one of those red blankets. All major distros are on their move to pulseaudio right now. As I understand it, the functionality is similar to what jack provides (correct me if I'm wrong). So although in this case, there is a really handy app - Ardour - that uses jack, I don't think this should bring in jack automatically for Lumiera sound backend, too. Well, it could, as long as there is a pulseaudio backend, too ;) I'd like to object and give my official vote pro Jack/Ardour as invaluable partner apps for Lumiera. I do this because not too long ago I made a small movie of a piano player. I recorded audio separately with a good microphone and pasted that audio on top of the DV raw video material. Making the cut was okay, but audio editing is just not perfect in Cinelerra, although the program already makes a strong effort to provide good audio capabilities. Ardour is still ten times more advanced. As it stands today, I have to make the final cut in Cinelerra, move the audio manually to Ardour, do audio post-processing there, then remultiplex that on top of the visual material. Re-touching the cut is impossible afterwards. Instead of (again) duplicating a complete audio workstation in Lumiera, I suggest sticking as much as possible to the already difficult video processing and leave audio post-processing (possibly even mixdown and mix automation!) to an external app. In addition to audio and midi plugs, Jack offers a unified transport system to synchronize applications. I don't know if pulseaudio has such a thing, but the unified transport is extremely useful. As far as I know, pulseaudio is thought of as a drop-in replacement for ESD, so there's probably no transport... Anyway, there's more to Jack than just Ardour. Mastering with Jamin delivers pro-quality polished audio (also synchronized with the transport) and the jack-rack offers a simple-to-use LADSPA effects machine, so all those topics could move clear out of the way of future Lumiera developers. We already have plenty of high-performance audio apps in the Open Source arena. The video part is what's really missing, so if Lumiera emphasizes strongly on that, users will surely flock to it! - Ján ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
2008/3/27, Andreas Hermann Braml <[EMAIL PROTECTED]>: > Jack is one of those red blankets. All major distros are on their move > to pulseaudio right now. As I understand it, the functionality is > similar to what jack provides (correct me if I'm wrong). So although in > this case, there is a really handy app - Ardour - that uses jack, I > don't think this should bring in jack automatically for Lumiera sound > backend, too. Well, it could, as long as there is a pulseaudio backend, > too ;) While jack and pulse appear to try to solve the same problem, they actually do have different features. Pulse is designed for: Audio "consumption", and "light" desktop usage: Its for audio-players, for little plings and plongs, for making sure that your skype headset works, that you can listen to NIN while playing Doom, etc... Jack on the other hand is for Audio "Production", it is designed to be able to record all the fancy sounds that your software synth does in ardour, it is designed to dump all the streams from your 8-channel soundcard to disk, it is there to put every sound from your gigabytes of sound samples onto your speaker at the instant you press a key on your midi-keyboard. etc... For simple Video Editing and some lightweight audio stuff, both pulse and "jack" will work, and both "should" work, but keep in mind that some people will prefer jack for its advanced features, and some will prefer Pulse, because they want things to "just work", with a minimal amount of fuzz. Cheers -Richard -- Don't contribute to the Y10K problem! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
On Thu, 2008-03-27 at 16:03 +0100, Andreas Hermann Braml wrote: > Jack is one of those red blankets. All major distros are on their move > to pulseaudio right now. As I understand it, the functionality is > similar to what jack provides (correct me if I'm wrong). So although in > this case, there is a really handy app - Ardour - that uses jack, I > don't think this should bring in jack automatically for Lumiera sound > backend, too. Well, it could, as long as there is a pulseaudio backend, > too ;) You are wrong :) JACK is targeted at audio production and concentrates on low latency. It's also good for passing audio between applications. Pulseaudio comes from the "desktop" side and is built around allowing a bunch of applications to make *pling* or play some music. But Pulseaudio either is or will be able to use JACK as backend, hopefully allowing for peaceful coexistence of *pling*-makers and audio production ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
Hi! Though I'm definitely not a coder (OK, a bit Python once in a while), I follow this list closely, especially all the Lumiera related stuff. And whenever things like "let's do X by using Y" come up, I hear litte alarm bells ring in my head. I always fear that Y - though it means to reuse existing functionality, which is a good thing - might be some hard to port/compile/configure, non-standard way of doing things. Marcin Kostur wrote: > [...] > ...the jack is another story Jack is one of those red blankets. All major distros are on their move to pulseaudio right now. As I understand it, the functionality is similar to what jack provides (correct me if I'm wrong). So although in this case, there is a really handy app - Ardour - that uses jack, I don't think this should bring in jack automatically for Lumiera sound backend, too. Well, it could, as long as there is a pulseaudio backend, too ;) Reuse is good, but reusing something that already is a duplication of existing functionality is not. But that's only from my limited (user) perspective. Let those decide who code. Andreas signature.asc Description: OpenPGP digital signature
Re: [CinCV] Cin 3: my 3 cents
On Thu, 27 Mar 2008 15:06:00 +0100, Marcin Kostur <[EMAIL PROTECTED]> wrote: 2008/3/27, Herman Robak <[EMAIL PROTECTED]>: On a modern dual core it shouldn't be, but in Cinelerra 2.x it is. Richard Spindler has run some benchmarks on this, and if I recall correctly, he could decode two HDV streams on a laptop and still have CPU power to spare. Decode 2 streams is not enought. One needs backward play, play from random place. 2 streams mean - 1 track + fade transition ;-) Yes. Backward play should be full speed, and it ought to start instantly, not with a half second delay. If Cinelerra prerendered video from the cursor back to the next I-frame, it could achieve that. During forward playback Cinelerra should retain at least a couple of GOPs in a cache, so instant backward playback always would be possible. This is technically doable (but not implemented in Cinelerra) for all but a few corner cases. In those corner cases there should at most be a lag of about 1/4 second. I expect this of Lumiera. :-) Play from random place would require to decode an average 1/2 of GOP in 1/25s. Only in rare cases the editor will only have 1/25s available to produce a "difficult" frame in time. The _average_ time must be 1/25s or less, but a clever editor should strive to get a little ahead as soon as it can. Asynchronous decoding is the naive way. More clever ways are needed, like selectively pre-rendering regions that will likely fail to render in realtime. On dual core PC with soft composer fade transition gives me 7-9fps ;-) That's because Cinelerra isn't as clever as an HD video editor needs to be. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
Marcin Kostur wrote: > Dear developers (...developers,developers,developers)! > > Although I do not contribute to the cin3 source (so far ;-), > I have few thoughts: > > 1) Blender has great GUI and works with windows. If cin3 is working > on windows community is 100x bigger! > Blenders also are programming, AFAIK, NLE as a module... ;-) Compatibility with windows has other issues in videoediting, remember we have to chew on many many gigabytes of video data in nearly realtime. This requires a low level data management which is tied to the underlying OS (Posix for this). Next no one of the developers uses Windows and we don't want to support non-free OS'es. We won't reject patches if someone works on a windows port, but really, We don't care for it. Next, hermanr is absolutely right, we want a pro interface, but it should be familar and useable by novice users and people who know Cinelerra. > > 2) Since few month i use audio editor ardour2 - it has really > nice and quite stable multi-track interface. Maybe there is a chance > of reusing? The GUI decision is left out for now, we concentrate on the backend. You might contribute to the Brainstorming on the wiki: http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming But don't expect any concrete decision made anytime soon. > > 3) Cin3 must be fast and resposive with HDV. For example avidemux can > really fast play and scrub 1080i - many times faster than cin2. > Proxy on cin2 do the job but it is hassle to setup etc. > Should be "one button intermediate format mode". Agreed, this will be addressed > > 4) cin2&HDV - what would you think about mixture of proxy and bgrender: > each source track is bgrendered to images instead of result. Then > with OpenGL composer most of ops could go smooth? My experience is that > [EMAIL PROTECTED] decode is a bottleneck. Read the design documentation, basically this will be handled slightly different to what cinelerra currently does. There is always something like a background render which prepares frames which will be needed. The previewer will adapt on the current hardware capabilities and users choice (render for FX, resolution, framerate, quality, ...) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
On Thu, 27 Mar 2008, Marcin Kostur wrote: > > 2008/3/27, Herman Robak <[EMAIL PROTECTED]>: > >> On a modern dual core it shouldn't be, but in Cinelerra 2.x it is. > >> Richard Spindler has run some benchmarks on this, and if I recall > >> correctly, he could decode two HDV streams on a laptop and still have > >> CPU power to spare. > > Decode 2 streams is not enought. One needs backward play, play from random > place. 2 streams mean - 1 track + fade transition ;-) > Play from random place would require to decode an average 1/2 of GOP in > 1/25s. > > On dual core PC with soft composer fade transition gives me 7-9fps ;-) > > I think nice builtin proxy would do the job. I wonder if it would be possible to store more than one frame in texture memory from this proxy (resized to actual view resolution) in that way, it would be double buffered and allows hardware transitions previews. Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
> 2008/3/27, Herman Robak <[EMAIL PROTECTED]>: >> On a modern dual core it shouldn't be, but in Cinelerra 2.x it is. >> Richard Spindler has run some benchmarks on this, and if I recall >> correctly, he could decode two HDV streams on a laptop and still have >> CPU power to spare. Decode 2 streams is not enought. One needs backward play, play from random place. 2 streams mean - 1 track + fade transition ;-) Play from random place would require to decode an average 1/2 of GOP in 1/25s. On dual core PC with soft composer fade transition gives me 7-9fps ;-) I think nice builtin proxy would do the job. Marcin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
> conceivable to patch the sound output via jack from Lumiera into > a DAW like Ardour, and even back again to Lumiera. I was thinking of reusing ardour2 GUI with multitrack timeline. Like - broadcast2cinelerra ;-) ...the jack is another story mk ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
На Thu, 27 Mar 2008 13:10:47 +0100 "Herman Robak" <[EMAIL PROTECTED]> записано: > Alas, I only think that this would help Blender users to adopt > Lumiera, as far as usability is concerned. I like Blender's powerful > and flexible tiled interface, but I remember when I tried to figure > it out many years ago. It was hard! I do NOT want to see Lumiera > become more difficult to figure out for newbies than Cinelerra > already is. Do not forgot about people with multi-head setups and smart window managers like ion and xmonad. Current blender's UI is sucks for such screen layouts. It should be optional like in kdenlive, ardour and glade-3 -- Чтв Мар 27 19:35:00 KRAT 2008 Thu Mar 27 12:35:00 UTC 2008 -- Visit my home page http://www.akhil.nm.ru (Last update at 25th Mar 08:12) -- jabber: [EMAIL PROTECTED] -- Пытаться сделать мир на 1/6.7e9 лучше Ахметгалеев Ильдар aka AkhIL -- Linux artstation 2.6.22-gentoo-r10 #5 PREEMPT Mon Feb 18 08:20:04 KRAT 2008 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux up 26 days, 8:25, 20 users, load average: 2.58, 2.43, 2.74 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
2008/3/27, Herman Robak <[EMAIL PROTECTED]>: > On a modern dual core it shouldn't be, but in Cinelerra 2.x it is. > Richard Spindler has run some benchmarks on this, and if I recall > correctly, he could decode two HDV streams on a laptop and still have > CPU power to spare. I was planning to do such a benchmark, but I haven't done it yet, playing a single hdv stream using only a single core of the dual core machine works though. Cheers -Richard -- Don't contribute to the Y10K problem! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
On Thu, 27 Mar 2008 11:04:49 +0100, Marcin Kostur <[EMAIL PROTECTED]> wrote: Dear developers (...developers,developers,developers)! Although I do not contribute to the cin3 source (so far ;-), I have few thoughts: 1) Blender has great GUI and works with windows. If cin3 is working on windows community is 100x bigger! (Cin3 is called Lumiera) Alas, I only think that this would help Blender users to adopt Lumiera, as far as usability is concerned. I like Blender's powerful and flexible tiled interface, but I remember when I tried to figure it out many years ago. It was hard! I do NOT want to see Lumiera become more difficult to figure out for newbies than Cinelerra already is. Blenders also are programming, AFAIK, NLE as a module... ;-) As far as I know, it's performance is slow compared to Cinelerra. 2) Since few month i use audio editor ardour2 - it has really nice and quite stable multi-track interface. Maybe there is a chance of reusing? I don't know exactly what the developers' visions are in the audio department. They'll probably leverage the jack transport to synch Lumiera with Ardour and other audio applications. It's entirely conceivable to patch the sound output via jack from Lumiera into a DAW like Ardour, and even back again to Lumiera. 3) Cin3 must be fast and resposive with HDV. For example avidemux can really fast play and scrub 1080i - many times faster than cin2. Proxy on cin2 do the job but it is hassle to setup etc. Should be "one button intermediate format mode". MPEG2 seeking is quite sucky in Cinelerra. There is a lot of room for improvement there, and promising work is being done on quick and frame- accurate seeking. (not here, but on the libopenvideo mailing list) 4) cin2&HDV - what would you think about mixture of proxy and bgrender: each source track is bgrendered to images instead of result. Then with OpenGL composer most of ops could go smooth? My experience is that [EMAIL PROTECTED] decode is a bottleneck. On a modern dual core it shouldn't be, but in Cinelerra 2.x it is. Richard Spindler has run some benchmarks on this, and if I recall correctly, he could decode two HDV streams on a laptop and still have CPU power to spare. I hope you will not be angry with me for my "advices" ;-))) Of course not. :-) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Cin 3: my 3 cents
Dear developers (...developers,developers,developers)! Although I do not contribute to the cin3 source (so far ;-), I have few thoughts: 1) Blender has great GUI and works with windows. If cin3 is working on windows community is 100x bigger! Blenders also are programming, AFAIK, NLE as a module... ;-) 2) Since few month i use audio editor ardour2 - it has really nice and quite stable multi-track interface. Maybe there is a chance of reusing? 3) Cin3 must be fast and resposive with HDV. For example avidemux can really fast play and scrub 1080i - many times faster than cin2. Proxy on cin2 do the job but it is hassle to setup etc. Should be "one button intermediate format mode". 4) cin2&HDV - what would you think about mixture of proxy and bgrender: each source track is bgrendered to images instead of result. Then with OpenGL composer most of ops could go smooth? My experience is that [EMAIL PROTECTED] decode is a bottleneck. I hope you will not be angry with me for my "advices" ;-))) the best Marcin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
