From: Edwin S. <ye...@ho...> - 2004-03-21 21:25:28
|
Hi, I see that you plan to have video capture support as of version 0.4. Have you had a look at dvr ( http://dvr.sourceforge.net ) ? Or do you already have in mind how to accomplish this? Maybe when I find the time, I'd like to start adding this feature (with your approval of course) for firewire. Regards, Edwin |
From: Rolf D. <Dub...@ph...> - 2004-03-21 21:41:27
|
On Sunday 21 March 2004 21:34, Edwin Schepers wrote: > Hi, > I see that you plan to have video capture support as of version 0.4. > Have you had a look at dvr ( http://dvr.sourceforge.net ) ? > Or do you already have in mind how to accomplish this? piave does already have a rudimentary support for capturing DV from digital camcorders via ieee1394. Please have a look at piave/utils/pgrab . The current problem is, that I don't have the time/knowledge to implement a GUI in kdenlive and Jason doesn't have a digital camcorder. We would be very happy if someone with the time and will to implement a GUI interface and a camcorder to test it could help us out. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Jason W. <jas...@bl...> - 2004-03-22 14:55:37
|
On Monday 22 March 2004 01:41, Rolf Dubitzky wrote: > On Sunday 21 March 2004 21:34, Edwin Schepers wrote: > > Hi, > > I see that you plan to have video capture support as of version 0.4. > > Have you had a look at dvr ( http://dvr.sourceforge.net ) ? > > Or do you already have in mind how to accomplish this? > > piave does already have a rudimentary support for capturing DV from digital > camcorders via ieee1394. Please have a look at piave/utils/pgrab . > The current problem is, that I don't have the time/knowledge to implement a > GUI in kdenlive and Jason doesn't have a digital camcorder. Actually I do have a video camcorder, however I have prioritized working on effects over working on capture. > We would be very happy if someone with the time and will to implement a GUI > interface and a camcorder to test it could help us out. Agreed :-) Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Edwin S. <ye...@ho...> - 2004-03-21 21:56:45
|
On Monday 22 March 2004 07:41 am, Rolf Dubitzky wrote: > piave does already have a rudimentary support for capturing DV from digital > camcorders via ieee1394. Please have a look at piave/utils/pgrab . > The current problem is, that I don't have the time/knowledge to implement a > GUI in kdenlive and Jason doesn't have a digital camcorder. We would be very > happy if someone with the time and will to implement a GUI interface and a > camcorder to test it could help us out. I have a digital camera. I'll have a look at pgrab. I don't have any knowledge (outside some kde programming), but that will only take time (well, only... :-) I never grabbed with Linux, but I'll get it working. Then I could start making a gui in kdenlive. Regards, Edwin |
From: Rolf D. <Dub...@ph...> - 2004-03-21 23:12:27
|
On Sunday 21 March 2004 22:05, Edwin Schepers wrote: > I have a digital camera. I'll have a look at pgrab. I don't have any > knowledge (outside some kde programming), but that will only take time > (well, only... :-) > I never grabbed with Linux, but I'll get it working. > Then I could start making a gui in kdenlive. That sound very good. I don't know how much you know about kdenlive/piave, but you probably have already understood, that kdenlive is the GUI part which depends _only_ on KDE/Qt and piave is the render engine which has all kinds of nasty dependencies on the file, audio, and video formats, audio systems, video systems and ieee1394 interface. The two components comunicate via a pretty simple protocol over sockets. This protocol needs to be extended to handle all that is necessary for capturing (which is trivial). I am _very_ interested in cpturing capabilties, so if you are really interested, I can implement all the necessary changes in piave and code all the communication to the actual hardware (most of this is already done anyway). So if you start creating a GUI component in kdenlive, all you need to do is send commands via the (existing) communication channel to piave. You don't need to bother with the underlying hardware. (In fact, you must not, since kdenlive should be independent of hardware dependencies) So the first command to send would probably be something like <captureGetDevices> to see what is actually attched to the PC. piave would answer something like the following (run "pgrab -v 2" to see if/how your cam is reported) <captureDevices> <ohci1394> <device devid="0" name="Sony DCR-TRV30E" type="AVC (subtype=VCR)" /> </ohci1394> </captureDevices> The device id is an integer for further reference of the device. The name is actually read from the device itself and can be displayed to the user. In case more than one device is attached, you can offer a selection box or whatever. Then kdenlive could then send commands like <capturePlay devid="0"> and <captureRecord devid="0"> <captureStop devid="0"> . . . I havn't really thought it through, that's just what comes from thetop of my head. Shouldn't be too dificult to come up with a reasonable syntax and set of commands. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Edwin S. <ye...@ho...> - 2004-06-28 20:21:33
|
On Monday 22 March 2004 09:12 am, Rolf Dubitzky wrote: > On Sunday 21 March 2004 22:05, Edwin Schepers wrote: > > I have a digital camera. I'll have a look at pgrab. I don't have any > > knowledge (outside some kde programming), but that will only take time > > (well, only... :-) > > I never grabbed with Linux, but I'll get it working. > > Then I could start making a gui in kdenlive. > > That sound very good. I don't know how much you know about kdenlive/piave, but > you probably have already understood, that kdenlive is the GUI part which > depends _only_ on KDE/Qt and piave is the render engine which has all kinds > of nasty dependencies on the file, audio, and video formats, audio systems, > video systems and ieee1394 interface. The two components comunicate via a > pretty simple protocol over sockets. This protocol needs to be extended to > handle all that is necessary for capturing (which is trivial). I am _very_ > interested in cpturing capabilties, so if you are really interested, I can > implement all the necessary changes in piave and code all the communication > to the actual hardware (most of this is already done anyway). > So if you start creating a GUI component in kdenlive, all you need to do is > send commands via the (existing) communication channel to piave. You don't > need to bother with the underlying hardware. (In fact, you must not, since > kdenlive should be independent of hardware dependencies) > > So the first command to send would probably be something like > > <captureGetDevices> > > to see what is actually attched to the PC. piave would answer something like > the following (run "pgrab -v 2" to see if/how your cam is reported) > > <captureDevices> > <ohci1394> > <device devid="0" name="Sony DCR-TRV30E" type="AVC (subtype=VCR)" /> > </ohci1394> > </captureDevices> > > The device id is an integer for further reference of the device. The name is > actually read from the device itself and can be displayed to the user. In > case more than one device is attached, you can offer a selection box or > whatever. > Then kdenlive could then send commands like > > <capturePlay devid="0"> > > and > > <captureRecord devid="0"> > <captureStop devid="0"> > . > . > . > > > I havn't really thought it through, that's just what comes from thetop of my > head. Shouldn't be too dificult to come up with a reasonable syntax and set > of commands. Hi Rolf, Do you already have something useful on this item, so I can start making a gui and do some testing ? Regards, Edwin |
From: Rolf D. <Dub...@ph...> - 2004-06-29 07:27:29
|
> > I havn't really thought it through, that's just what comes from thetop of > > my head. Shouldn't be too dificult to come up with a reasonable syntax > > and set of commands. > > Hi Rolf, > Do you already have something useful on this item, so I can start making a > gui and do some testing ? Yes, actually everything is ready but untested. I'll update piave CVS with my latest changes in the next few days (before the weekend). So be kind if stuff is not 100% stable and maybe we find some VEML commands that need to be changed. Jason and I experienced this very often. One of us implements the commands from his point of view, but from the other side things may look different. I'll also write up what syntax I propose, then we can discuss. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Jason W. <jas...@bl...> - 2004-03-22 14:55:40
|
On Monday 22 March 2004 03:12, Rolf Dubitzky wrote: > So if you start creating a GUI component in kdenlive, all you need to do is > send commands via the (existing) communication channel to piave. You don't > need to bother with the underlying hardware. (In fact, you must not, since > kdenlive should be independent of hardware dependencies) > > So the first command to send would probably be something like > > <captureGetDevices> Hi Edwin, A quick note about the communication between Kdenlive and Piave from a programming perspective - in Kdenlive, all of this communication happens in the KRender class, and this should remain the case - if you need to send a command to piave, you add a new method to KRender that sends the command. To recieve messages from piave, you process the command in KRender and emit a signal to say the command has been recieved. All communication is asynchronous, so you need to take this into accout, however that does not normally make coding more complicated, it just requires a different mindset. > > to see what is actually attched to the PC. piave would answer something > like the following (run "pgrab -v 2" to see if/how your cam is reported) > > <captureDevices> > <ohci1394> > <device devid="0" name="Sony DCR-TRV30E" type="AVC (subtype=VCR)" > /> </ohci1394> > </captureDevices> > > The device id is an integer for further reference of the device. The name > is actually read from the device itself and can be displayed to the user. > In case more than one device is attached, you can offer a selection box or > whatever. > Then kdenlive could then send commands like > > <capturePlay devid="0"> > > and > > <captureRecord devid="0"> > <captureStop devid="0"> This interface looks fine to me. The only difference I would suggest is to remove the <captureGetDevices> command and add the information of the return message to the <getCapabilities> reply that already get's sent. (you can add this now; it will not affect kdenlive). If you add the capture commands, you might be able to test them out using the new "send veml command" box in the debug dialog before the ui is complete. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Edwin S. <ye...@ho...> - 2004-03-22 20:16:24
|
On Monday 22 March 2004 18:07 pm, Jason Wood wrote: > On Monday 22 March 2004 03:12, Rolf Dubitzky wrote: Thank you guys for all the info. I first have to buy an appropriate cable... When I succeed capturing, I can really start. Regards, Edwin |
From: Rolf D. <Dub...@ph...> - 2004-03-23 04:08:15
|
On Monday 22 March 2004 17:07, Jason Wood wrote: > If you add the capture commands, you might be able to test them out using > the new "send veml command" box in the debug dialog before the ui is > complete. -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Rolf D. <Dub...@ph...> - 2004-03-23 04:10:27
|
On Monday 22 March 2004 17:07, Jason Wood wrote: > If you add the capture commands, you might be able to test them out using > the new "send veml command" box in the debug dialog before the ui is > complete. Hmm. When I click the button nothing happens... How does that work? Cheers, Rolf PS: I just finished the snapshot command. That should improve the look and usability quite a bit. -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Jason W. <jas...@bl...> - 2004-03-23 10:02:18
|
On Tuesday 23 March 2004 08:10, Rolf Dubitzky wrote: > On Monday 22 March 2004 17:07, Jason Wood wrote: > > If you add the capture commands, you might be able to test them out using > > the new "send veml command" box in the debug dialog before the ui is > > complete. > > Hmm. When I click the button nothing happens... How does that work? There is a new text edit box, just below the debug log and above the buttons). Type the command you want to send to piave there. Select whichever piave instance you want to recieve it from the list on the left. Now click the "send veml command" button. > PS: I just finished the snapshot command. That should improve the look and > usability quite a bit. Cool :-) Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Jason W. <jas...@bl...> - 2004-03-22 14:55:40
|
On Sunday 21 March 2004 17:05, Edwin Schepers wrote: > On Monday 22 March 2004 07:41 am, Rolf Dubitzky wrote: > > piave does already have a rudimentary support for capturing DV from > > digital camcorders via ieee1394. Please have a look at piave/utils/pgrab > > . The current problem is, that I don't have the time/knowledge to > > implement a GUI in kdenlive and Jason doesn't have a digital camcorder. > > We would be very happy if someone with the time and will to implement a > > GUI interface and a camcorder to test it could help us out. > > I have a digital camera. I'll have a look at pgrab. I don't have any > knowledge (outside some kde programming), but that will only take time > (well, only... :-) I have only thought at a quite high level on how the interface between Kdenlive and piave will work for capture. Here are my questions/thoughts on recording. Will Kdenlive use an existing monitor for capture (for example, the clip monitor), or a separate "record" monitor? My thoughts are that we should have a separate record monitor, so that we can customize it with record-specific functionality. I think that a separate piave process will be used (Edwin, don't be scared by this detail, it is all handled internally in Kdenlive ;-)), so we could tell piave very early on what it's task is. > I never grabbed with Linux, but I'll get it working. > Then I could start making a gui in kdenlive. If you have any questions on how to start, then please ask :-) As a hint though, take a look at the existing KMMMonitor class. This handles the exiting clip monitor and workspace monitor, and would be a good starting point for adding another monitor. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <Dub...@ph...> - 2004-03-22 15:06:22
|
On Monday 22 March 2004 17:07, Jason Wood wrote: > The only difference I would suggest is to remove the <captureGetDevices> > command and add the information of the return message to the > <getCapabilities> reply that already get's sent. (you can add this now; it > will not affect kdenlive). Hmm.. but getCapabilities is something you just need to do once (unless you install new plugins)captureGetDevices is something you might want to do more often to poll for new attached devices. > If you add the capture commands, you might be able to test them out using > the new "send veml command" box in the debug dialog before the ui is > complete. Ah, that's very cool I actually wanted to write something like that for piave to test stuff. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Jason W. <jas...@bl...> - 2004-03-22 15:53:38
|
On Monday 22 March 2004 19:06, Rolf Dubitzky wrote: > On Monday 22 March 2004 17:07, Jason Wood wrote: > > The only difference I would suggest is to remove the <captureGetDevices> > > command and add the information of the return message to the > > <getCapabilities> reply that already get's sent. (you can add this now; > > it will not affect kdenlive). > > Hmm.. but getCapabilities is something you just need to do once (unless you > install new plugins)captureGetDevices is something you might want to do > more often to poll for new attached devices. Good point, I had not thought of that. > > If you add the capture commands, you might be able to test them out using > > the new "send veml command" box in the debug dialog before the ui is > > complete. > > Ah, that's very cool I actually wanted to write something like that for > piave to test stuff. My last post saying I had finished committing everything was a little lie... I have definitely finished committing everything now. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <Dub...@ph...> - 2004-03-22 19:21:40
|
What's your timescale on the VEML changes. The problem is, I want to fix these ALSA problems, but the commits are somewhat in conflict with the VEML syntax chnges. I would need to do same CVS gymnastics or create a new branch to have both. However, if kdenlive can talk the new VEML, than we could have a 0.2.5 synched release for both projects. Cheers, Rolf On Monday 22 March 2004 20:50, Jason Wood wrote: > On Monday 22 March 2004 19:06, Rolf Dubitzky wrote: > > On Monday 22 March 2004 17:07, Jason Wood wrote: > > > The only difference I would suggest is to remove the > > > <captureGetDevices> command and add the information of the return > > > message to the > > > <getCapabilities> reply that already get's sent. (you can add this now; > > > it will not affect kdenlive). > > > > Hmm.. but getCapabilities is something you just need to do once (unless > > you install new plugins)captureGetDevices is something you might want to > > do more often to poll for new attached devices. > > Good point, I had not thought of that. > > > > If you add the capture commands, you might be able to test them out > > > using the new "send veml command" box in the debug dialog before the ui > > > is complete. > > > > Ah, that's very cool I actually wanted to write something like that for > > piave to test stuff. > > My last post saying I had finished committing everything was a little > lie... I have definitely finished committing everything now. > > Cheers, > Jason -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Jason W. <jas...@bl...> - 2004-03-23 09:55:45
|
On Monday 22 March 2004 23:21, Rolf Dubitzky wrote: > What's your timescale on the VEML changes. The problem is, I want to fix > these ALSA problems, but the commits are somewhat in conflict with the VEML > syntax chnges. I would need to do same CVS gymnastics or create a new > branch to have both. However, if kdenlive can talk the new VEML, than we > could have a 0.2.5 synched release for both projects. Which new VEML do you mean? Kdenlive 0.2.x will only use the previous VEML; it won't support the new <seq><par> stuff. Kdenlive 0.3.x will use the new VEML. It already supports it to a point where you can run Kdenlive 0.3 and the piave-0.3-pre tarball together. Neither Kdenlive 0.2.x or 0.3.x currently supports the capture VEML at the moment. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <Dub...@ph...> - 2004-03-23 15:48:49
|
On Tuesday 23 March 2004 14:52, Jason Wood wrote: > Kdenlive 0.3.x will use the new VEML. It already supports it to a point > where you can run Kdenlive 0.3 and the piave-0.3-pre tarball together. I see somehow I was not aware that the next release will be 0.3.x not 0.2.5. But that is of course what agreed upon earlier, sorry. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Edwin S. <ye...@ho...> - 2004-03-22 20:34:55
|
On Monday 22 March 2004 17:53 pm, Jason Wood wrote: > I have only thought at a quite high level on how the interface between > Kdenlive and piave will work for capture. Here are my questions/thoughts on > recording. > > Will Kdenlive use an existing monitor for capture (for example, the clip > monitor), or a separate "record" monitor? My thoughts are that we should have > a separate record monitor, so that we can customize it with record-specific > functionality. on what record-specific functionality are you thinking ? This monitor is only used for displaying what is being captured, not? > |
From: Jason W. <jas...@bl...> - 2004-03-23 10:05:25
|
On Monday 22 March 2004 15:43, Edwin Schepers wrote: > On Monday 22 March 2004 17:53 pm, Jason Wood wrote: > > Will Kdenlive use an existing monitor for capture (for example, the clip > > monitor), or a separate "record" monitor? My thoughts are that we should > > have a separate record monitor, so that we can customize it with > > record-specific functionality. > > on what record-specific functionality are you thinking ? This monitor is > only used for displaying what is being captured, not? Well, for example some of the things that we would want on the capture monitor that would not be on the clip/workspace monitors : * A record button :-) * A text box where you can type a description of the clip you are about to capture. * Some things on a normal monitor (snap markers, for example) will not be appropriate on a record monitor. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <Dub...@ph...> - 2004-03-23 15:57:34
|
On Tuesday 23 March 2004 15:02, Jason Wood wrote: > Well, for example some of the things that we would want on the capture > monitor that would not be on the clip/workspace monitors : > > * A record button :-) > * A text box where you can type a description of the clip you are about to > capture. > * Some things on a normal monitor (snap markers, for example) will not be > appropriate on a record monitor. During normal capturing, piave can detect the beginning of new scenes. So there might be a "split at new scene" button. Somewhere in the 'renderer setup' one might want to ad a textbox with a rule for creating filenames, like "/mybigdisk/video/tmp/capture-%i.dv" so people can define where their captured video goes. piave is not supposed to know about user preferences. Cheers, Rolf PS: the feature relies on the information piave get's from the camera. I experienced wrong info with my camcorder, so piave did either not split where it should, or did split where it shouldn't. However, since MovieDV under windows makes the same mistakes I think we have to live with this. I will check back with dvgrab and see if they have any smart logic to improve the scene detection. I am thinking of checking frame timestamps to detect cases where a frame has a 'new recording' tag, but the timestamp suggests otherwise. But all that does not have a high priority. -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |
From: Edwin S. <edw...@ho...> - 2004-03-23 20:20:20
|
On Wednesday 24 March 2004 01:57 am, Rolf Dubitzky wrote: > On Tuesday 23 March 2004 15:02, Jason Wood wrote: > > Well, for example some of the things that we would want on the capture > > monitor that would not be on the clip/workspace monitors : > > > > * A record button :-) > > * A text box where you can type a description of the clip you are about to > > capture. > > * Some things on a normal monitor (snap markers, for example) will not be > > appropriate on a record monitor. > > During normal capturing, piave can detect the beginning of new scenes. Very cool!! I'll implement this the same time. This is exacly what I'm looking for! |
From: Rolf D. <Dub...@ph...> - 2004-03-23 21:34:24
|
On Tuesday 23 March 2004 20:29, Edwin Schepers wrote: > Very cool!! I'll implement this the same time. This is exacly what I'm > looking for! vrey good. cry for help or complain if something is not working. I'll start and make the necessary changes in piave. I'll post a summary of the VEML commands for capturing asap. Cheers, Rolf -- contacts: http://www.physi.uni-heidelberg.de/~dubitzky |