From: Matt L. <mat...@gm...> - 2008-09-02 16:57:22
|
Hi All, I'm cleaning up vidl2 a bit in preparation for the eventual move to core. There are a few unresolved issues with the API that I'd like to get some feedback on. First, I've added a num_frames() function to the vidl2_istream. This has been requested by users, and seems like it should be there. This function should return the number of frames in a video or -1 for live streams or other streams with indeterminate length. I've already implemented this for vidl2_image_list_istream and vidl2_ffmpeg_istream. All other istreams currently return -1. I could use some help with implementing this in vidl2_dshow_file_istream from Miguel and in vidl2_v4l_istream from Brendan. Of course, anyone else familiar with these is welcome to chip in. Second, I think we need to clear up the API regarding advance(), current_frame(), and read_frame(). The way it is now, advance() moves the stream pointer one frame ahead (usually without fully decoding the next frame), current_frame() decodes the current frame (if necessary) and returns the frame, and read_frame() calls advance() followed by current_frame(). It was also originally assumed that each istream could be opened in a state with the current frame pointing to an invalid frame before the first frame of the video. The reason for this was that a live stream could be opened without capturing any images until the first call of advance() (or read_frame()). The problem with opening in an invalid state is that when piping an istream into an ostream the image size and other properties often need to be known before opening the ostream. This usually requires accessing the first frame of the istream for probing anyway. The probing process can lead to dropping of the first frame because read_frame() calls advance() again before calling current_frame(). So the questions I have are: 1) Should each istream always open in a valid state so that a frame can be accessed with current_frame() and probed for properties? In the case of live streams we can always discard the initial frame by calling advance() right before the capture loop. However, this does require that capture devices be ready to capture when the stream is opened. 2) Should the redundant read_frame() function be removed? It may make iterating through streams easier for beginners, but it doesn't add any new functionality. 3) If read_frame() stays and each stream opens on the first frame, should read_frame() return the current frame and then advance instead of the reverse. Think i++ instead of ++i. This way you can open an istream and then immediately call read_frame() without dropping the first frame. There are still other lingering issues like synchronous vs asynchronous capture, but I think I'll leave that for another time. Thanks, Matt |
From: Brendan M. <bre...@gm...> - 2008-09-03 02:03:21
|
Hi Matt, 2008/9/3 Matt Leotta <mat...@gm...>: > Hi All, > > I'm cleaning up vidl2 a bit in preparation for the eventual move to > core. There are a few unresolved issues with the API that I'd like to > get some feedback on. > > First, I've added a num_frames() function to the vidl2_istream. > This has been requested by users, and seems like it should be there. > This function should return the number of frames in a video or -1 for > live streams or other streams with indeterminate length. I've already > implemented this for vidl2_image_list_istream and > vidl2_ffmpeg_istream. All other istreams currently return -1. I > could use some help with implementing this in vidl2_dshow_file_istream > from Miguel and in vidl2_v4l_istream from Brendan. Of course, anyone > else familiar with these is welcome to chip in. That should be easy for vidl2_v4l_istream. Since these are always live streams AFAIK, returning -1 is the right thing to do. Can anyone think of any situation where this isn't true? There's another issue with the v4l stuff - v4l is now obsolete and has been for some time. It has been replaced by v4l2. Unfortunately, I haven't kept up with the developments. I don't think it would take much to convert over to v4l2, but it's something I just don't have the time for at the moment. AFAIK v4l still works though. > > Second, I think we need to clear up the API regarding advance(), > current_frame(), and read_frame(). The way it is now, advance() moves > the stream pointer one frame ahead (usually without fully decoding the > next frame), current_frame() decodes the current frame (if necessary) > and returns the frame, and read_frame() calls advance() followed by > current_frame(). It was also originally assumed that each istream > could be opened in a state with the current frame pointing to an > invalid frame before the first frame of the video. The reason for > this was that a live stream could be opened without capturing any > images until the first call of advance() (or read_frame()). The > problem with opening in an invalid state is that when piping an > istream into an ostream the image size and other properties often need > to be known before opening the ostream. This usually requires > accessing the first frame of the istream for probing anyway. The > probing process can lead to dropping of the first frame because > read_frame() calls advance() again before calling current_frame(). So > the questions I have are: > > 1) Should each istream always open in a valid state so that a frame > can be accessed with current_frame() and probed for properties? In > the case of live streams we can always discard the initial frame by > calling advance() right before the capture loop. However, this does > require that capture devices be ready to capture when the stream is > opened. > > 2) Should the redundant read_frame() function be removed? It may make > iterating through streams easier for beginners, but it doesn't add any > new functionality. > > 3) If read_frame() stays and each stream opens on the first frame, > should read_frame() return the current frame and then advance instead > of the reverse. Think i++ instead of ++i. This way you can open an > istream and then immediately call read_frame() without dropping the > first frame. > > There are still other lingering issues like synchronous vs > asynchronous capture, but I think I'll leave that for another time. Unfortunately, asynchronous capture has significant implications for all the questions above. For reading stuff off disk, it probably doesn't matter much, most of the following is flavoured by wanting to capture stuff from a camera in real time. For question 1), generally having the stream open in a valid state is a good idea as it is likely to lead to fewer errors in user code based on sequence dependencies. Rather than an API that says: first do this, then do that, then that etc, it's generally better to have an API that packages up all the sequence dependencies into a convenient form. Unfortunately with things like capturing from a camera, this can cause significant IO blocking problems. With asynchronous IO, you'd like to be able to say "start getting the camera ready here asynchronously, so I can start using it there immediately without waiting). If you're ignoring asynch IO for the moment, then I'd say yes. Q 2). No, read_frame shouldn't be removed, again because of sequential dependencies. Almost all programs will want to do get current/capture next, so might as well make it easy for them. Q3). Again it depends heavily on asynchronous capture. With asynch, it should definitely be "return current; get next" since getting the next one can be done asynchronously and won't be blocking unless another read_frame is called before it's had a chance to capture. But if it's not asynchronous, then it makes more sense to do "get next; return current", since you probably want to get the latest frame. It's starting to feel like we need a bigger API to handle asynch and synch, or at least two read_frames (one asynch, one synch)? I was also thinking that having an iterator interface would be syntactically neat and familiar, but again asynchronous IO really makes a mess of that (e.g. (*i++) would be an asynchronous read_frame, whereas (*++i) would be a synchronous read_frame). > > Thanks, > Matt > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Matt L. <mat...@gm...> - 2008-09-03 14:48:56
|
On Tue, Sep 2, 2008 at 10:03 PM, Brendan McCane <bre...@gm...> wrote: > That should be easy for vidl2_v4l_istream. Since these are always live > streams AFAIK, returning -1 is the right thing to do. Can anyone think > of any situation where this isn't true? Well in that case it should be all set. I was under the impression that v4l did more than just live streams, but I've never really used it. > There's another issue with the v4l stuff - v4l is now obsolete and has > been for some time. It has been replaced by v4l2. Unfortunately, I > haven't kept up with the developments. I don't think it would take > much to convert over to v4l2, but it's something I just don't have the > time for at the moment. AFAIK v4l still works though. I've got an e-mail from someone claiming to have already written, but not checked in, a v4l2_istream. I'll forward that message along after this. If I get that code from him should it replace v4l_istream or is there a reason to keep both versions around? >> Second, I think we need to clear up the API regarding advance(), >> current_frame(), and read_frame(). The way it is now, advance() moves >> the stream pointer one frame ahead (usually without fully decoding the >> next frame), current_frame() decodes the current frame (if necessary) >> and returns the frame, and read_frame() calls advance() followed by >> current_frame(). It was also originally assumed that each istream >> could be opened in a state with the current frame pointing to an >> invalid frame before the first frame of the video. The reason for >> this was that a live stream could be opened without capturing any >> images until the first call of advance() (or read_frame()). The >> problem with opening in an invalid state is that when piping an >> istream into an ostream the image size and other properties often need >> to be known before opening the ostream. This usually requires >> accessing the first frame of the istream for probing anyway. The >> probing process can lead to dropping of the first frame because >> read_frame() calls advance() again before calling current_frame(). So >> the questions I have are: >> >> 1) Should each istream always open in a valid state so that a frame >> can be accessed with current_frame() and probed for properties? In >> the case of live streams we can always discard the initial frame by >> calling advance() right before the capture loop. However, this does >> require that capture devices be ready to capture when the stream is >> opened. >> >> 2) Should the redundant read_frame() function be removed? It may make >> iterating through streams easier for beginners, but it doesn't add any >> new functionality. >> >> 3) If read_frame() stays and each stream opens on the first frame, >> should read_frame() return the current frame and then advance instead >> of the reverse. Think i++ instead of ++i. This way you can open an >> istream and then immediately call read_frame() without dropping the >> first frame. >> >> There are still other lingering issues like synchronous vs >> asynchronous capture, but I think I'll leave that for another time. > > Unfortunately, asynchronous capture has significant implications for > all the questions above. For reading stuff off disk, it probably > doesn't matter much, most of the following is flavoured by wanting to > capture stuff from a camera in real time. Not necessarily. Depending on your needs, you can still do asynchronous capture without worrying about the order of calling advance() and current_frame(). The dc1394_istream captures live video asynchronously using a separate thread that continually captures frames into a ring buffer. When I "open" the stream I allocate a buffer of say 10 frames (usually just 2 or 3 is even enough). It spawns off a thread that continually captures images into the buffer by overwriting the oldest image. Asynchronously, the advance() function iterates through the same ring buffer but has a check to make sure the data is ready to prevent the vidl2 loop from outpacing the capture loop. This gives me asynchronous capture. It is fast, nonblocking, and rarely drops a frame. The disadvantage is that each capture is not triggered by a call to advance() so you can't precisely control the timing of the image capture. You tell the capture thread to collect at a certain frame rate and it does that by itself. Unfortunately, all of this functionality is provided within libdc1394. I'm sure we could duplicate it in vidl2 if there was general interest. Although it does require multithreading which we don't have a standard way of doing in vxl yet. > > For question 1), generally having the stream open in a valid state is > a good idea as it is likely to lead to fewer errors in user code based > on sequence dependencies. Rather than an API that says: first do this, > then do that, then that etc, it's generally better to have an API that > packages up all the sequence dependencies into a convenient form. > Unfortunately with things like capturing from a camera, this can cause > significant IO blocking problems. With asynchronous IO, you'd like to > be able to say "start getting the camera ready here asynchronously, so > I can start using it there immediately without waiting). If you're > ignoring asynch IO for the moment, then I'd say yes. I was hoping that in the case of live streams we could capture a single test image when opening. The camera can then go back into a waiting mode until the capture loop starts. The test image would be used to probe properties of the frames to come and will be discarded if the capture loop starts with advance() before the first current_frame(). > Q 2). No, read_frame shouldn't be removed, again because of sequential > dependencies. Almost all programs will want to do get current/capture > next, so might as well make it easy for them. Yeah, that was my original intent, but I recall there being some discussion a while back that it was redundant and not needed. > Q3). Again it depends heavily on asynchronous capture. With asynch, it > should definitely be "return current; get next" since getting the next > one can be done asynchronously and won't be blocking unless another > read_frame is called before it's had a chance to capture. But if it's > not asynchronous, then it makes more sense to do "get next; return > current", since you probably want to get the latest frame. The only advantage of "get next; return current" is that subsequent calls to current_frame() will return the same frame returned by the last read_frame() call. But this also leads to dropping the first frame, even in the non-asynchronous case. > It's starting to feel like we need a bigger API to handle asynch and > synch, or at least two read_frames (one asynch, one synch)? I was also > thinking that having an iterator interface would be syntactically neat > and familiar, but again asynchronous IO really makes a mess of that > (e.g. (*i++) would be an asynchronous read_frame, whereas (*++i) would > be a synchronous read_frame). Actually, I feel that this might be more of an argument for a smaller API (no read_frames functions). I am more in favor of no read_frames function than I am of having multiple read_frames functions. The idea of read_frames was to provided a simple function to use in a loop without really needing to know what what going on under the hood. It's not simple anymore when you have multiple versions. Instead of while(frame = istream.read_frame()) it's not too much harder to use for(bool valid = true; valid && frame = istream.current_frame(); valid = istream.advance()) or for asynchronous capture while(frame = istream.current_frame() && istream.advance()) These make the order of operations explicit. If they are still too complicated, maybe your idea of frame iterators could be used _instead_ of the read_frame() function. That would make a more compact and familiar way of iterating frames. A good C++ programmer should know the difference between ++i and i++, so they can be used appropriately to get the desired result. --Matt |
From: Brendan M. <bre...@gm...> - 2008-09-03 21:50:34
|
Hi Matt, 2008/9/4 Matt Leotta <mat...@gm...>: > On Tue, Sep 2, 2008 at 10:03 PM, Brendan McCane > <bre...@gm...> wrote: >> That should be easy for vidl2_v4l_istream. Since these are always live >> streams AFAIK, returning -1 is the right thing to do. Can anyone think >> of any situation where this isn't true? > > Well in that case it should be all set. I was under the impression > that v4l did more than just live streams, but I've never really used > it. > > >> There's another issue with the v4l stuff - v4l is now obsolete and has >> been for some time. It has been replaced by v4l2. Unfortunately, I >> haven't kept up with the developments. I don't think it would take >> much to convert over to v4l2, but it's something I just don't have the >> time for at the moment. AFAIK v4l still works though. > > I've got an e-mail from someone claiming to have already written, but > not checked in, a v4l2_istream. I'll forward that message along after > this. If I get that code from him should it replace v4l_istream or is > there a reason to keep both versions around? v4l is obsoleted in the 2.5.x and 2.6.x kernels, but is still useful for the 2.4.x kernels. So it depends if we want to support 2.4.x kernels. I couldn't find any information on the whether 2.4.x is still in widespread use, but it's probably just easier to make a v4l2_istream just in case someone wants to use 2.4. > > >>> Second, I think we need to clear up the API regarding advance(), >>> current_frame(), and read_frame(). The way it is now, advance() moves >>> the stream pointer one frame ahead (usually without fully decoding the >>> next frame), current_frame() decodes the current frame (if necessary) >>> and returns the frame, and read_frame() calls advance() followed by >>> current_frame(). It was also originally assumed that each istream >>> could be opened in a state with the current frame pointing to an >>> invalid frame before the first frame of the video. The reason for >>> this was that a live stream could be opened without capturing any >>> images until the first call of advance() (or read_frame()). The >>> problem with opening in an invalid state is that when piping an >>> istream into an ostream the image size and other properties often need >>> to be known before opening the ostream. This usually requires >>> accessing the first frame of the istream for probing anyway. The >>> probing process can lead to dropping of the first frame because >>> read_frame() calls advance() again before calling current_frame(). So >>> the questions I have are: >>> >>> 1) Should each istream always open in a valid state so that a frame >>> can be accessed with current_frame() and probed for properties? In >>> the case of live streams we can always discard the initial frame by >>> calling advance() right before the capture loop. However, this does >>> require that capture devices be ready to capture when the stream is >>> opened. >>> >>> 2) Should the redundant read_frame() function be removed? It may make >>> iterating through streams easier for beginners, but it doesn't add any >>> new functionality. >>> >>> 3) If read_frame() stays and each stream opens on the first frame, >>> should read_frame() return the current frame and then advance instead >>> of the reverse. Think i++ instead of ++i. This way you can open an >>> istream and then immediately call read_frame() without dropping the >>> first frame. >>> >>> There are still other lingering issues like synchronous vs >>> asynchronous capture, but I think I'll leave that for another time. >> >> Unfortunately, asynchronous capture has significant implications for >> all the questions above. For reading stuff off disk, it probably >> doesn't matter much, most of the following is flavoured by wanting to >> capture stuff from a camera in real time. > > Not necessarily. Depending on your needs, you can still do > asynchronous capture without worrying about the order of calling > advance() and current_frame(). The dc1394_istream captures live video > asynchronously using a separate thread that continually captures > frames into a ring buffer. When I "open" the stream I allocate a > buffer of say 10 frames (usually just 2 or 3 is even enough). It > spawns off a thread that continually captures images into the buffer > by overwriting the oldest image. Asynchronously, the advance() > function iterates through the same ring buffer but has a check to make > sure the data is ready to prevent the vidl2 loop from outpacing the > capture loop. > > This gives me asynchronous capture. It is fast, nonblocking, and > rarely drops a frame. The disadvantage is that each capture is not > triggered by a call to advance() so you can't precisely control the > timing of the image capture. You tell the capture thread to collect > at a certain frame rate and it does that by itself. > > Unfortunately, all of this functionality is provided within libdc1394. > I'm sure we could duplicate it in vidl2 if there was general > interest. Although it does require multithreading which we don't have > a standard way of doing in vxl yet. Well, that would be an excellent solution. But you're right, it probably should wait until the multithreading issue is sorted out. > >> >> For question 1), generally having the stream open in a valid state is >> a good idea as it is likely to lead to fewer errors in user code based >> on sequence dependencies. Rather than an API that says: first do this, >> then do that, then that etc, it's generally better to have an API that >> packages up all the sequence dependencies into a convenient form. >> Unfortunately with things like capturing from a camera, this can cause >> significant IO blocking problems. With asynchronous IO, you'd like to >> be able to say "start getting the camera ready here asynchronously, so >> I can start using it there immediately without waiting). If you're >> ignoring asynch IO for the moment, then I'd say yes. > > I was hoping that in the case of live streams we could capture a > single test image when opening. The camera can then go back into a > waiting mode until the capture loop starts. The test image would be > used to probe properties of the frames to come and will be discarded > if the capture loop starts with advance() before the first > current_frame(). OK then - I'd be happy with that. > >> Q 2). No, read_frame shouldn't be removed, again because of sequential >> dependencies. Almost all programs will want to do get current/capture >> next, so might as well make it easy for them. > > Yeah, that was my original intent, but I recall there being some > discussion a while back that it was redundant and not needed. > > >> Q3). Again it depends heavily on asynchronous capture. With asynch, it >> should definitely be "return current; get next" since getting the next >> one can be done asynchronously and won't be blocking unless another >> read_frame is called before it's had a chance to capture. But if it's >> not asynchronous, then it makes more sense to do "get next; return >> current", since you probably want to get the latest frame. > > The only advantage of "get next; return current" is that subsequent > calls to current_frame() will return the same frame returned by the > last read_frame() call. But this also leads to dropping the first > frame, even in the non-asynchronous case. > > >> It's starting to feel like we need a bigger API to handle asynch and >> synch, or at least two read_frames (one asynch, one synch)? I was also >> thinking that having an iterator interface would be syntactically neat >> and familiar, but again asynchronous IO really makes a mess of that >> (e.g. (*i++) would be an asynchronous read_frame, whereas (*++i) would >> be a synchronous read_frame). > > Actually, I feel that this might be more of an argument for a smaller > API (no read_frames functions). I am more in favor of no read_frames > function than I am of having multiple read_frames functions. The idea > of read_frames was to provided a simple function to use in a loop > without really needing to know what what going on under the hood. > It's not simple anymore when you have multiple versions. True. > > Instead of > > while(frame = istream.read_frame()) > > it's not too much harder to use > > for(bool valid = true; valid && frame = istream.current_frame(); > valid = istream.advance()) > > or for asynchronous capture > > while(frame = istream.current_frame() && istream.advance()) > > These make the order of operations explicit. If they are still too > complicated, maybe your idea of frame iterators could be used > _instead_ of the read_frame() function. That would make a more > compact and familiar way of iterating frames. A good C++ programmer > should know the difference between ++i and i++, so they can be used > appropriately to get the desired result. Well, I would prefer the iterator syntax to the wordier current_frame, advance syntax, and as you say, it's a nicer solution to multiple read_frames, but I'm not keen enough to do anything about it myself right now:-). I don't think it will be too big an issue if read_frame disappears ... > > --Matt > -- Cheers, Brendan |
From: Peter V. <pet...@ya...> - 2008-09-04 08:06:25
|
> for (bool valid = true; > valid && frame = istream.current_frame(); > valid = istream.advance()) > > or for asynchronous capture > > while (frame = istream.current_frame() && istream.advance()) > > These make the order of operations explicit. > Maybe your idea of frame iterators could be used > _instead_ of the read_frame() function. I'd say I like this setup! The explicitness of the "advance then read" or vice versa makes it clear, also for the occasional user, what's happening. -- Peter. ___________________________________________________ Sök efter kärleken! Hitta din tvillingsjäl på Yahoo! Dejting: http://ad.doubleclick.net/clk;185753627;24584539;x?http://se.meetic.yahoo.net/index.php?mtcmk=148783 |
From: Matt L. <mat...@gm...> - 2008-09-03 15:09:20
|
Antonio, Yes, I remember your e-mail about v4l2. It sounds like your code is complete enough to check into vidl2. Once, it is in VXL other developers can help finish it. Brendan McCane may have an interested in using your code to replace the current vidl2_v4l_isteam. If not we can check in a seperate vidl2_v4l2_istream. Please document which parts of the code you feel need improvement (either in the comments or a separate file) and e-mail the code to Brendan and myself. I can quickly get it checked in and building on the dashboard, but I don't have time to seriously test it and finish it up. Maybe Brendan can help with that? I'll wait for a decision on whether this should be an upgrade to vidl2_v4l_istream or a separate stream before I do anything. The only major changes vidl2 between 1.10 and 1.11 are the recent changes I described in my e-mail yesterday. Your code should still work fine with the addition of a member function: int num_frames() { return -1; } --Matt On Wed, Sep 3, 2008 at 5:17 AM, Antonio Garrido Carrillo <aga...@de...> wrote: > > Hi Matt, > > I have been writing some code for vidl2 (vxl-1.10.0) to use v4l2 API (I > don't > know if you remember I sent to you a e-mail about this). > > Well, the code is not finished, but I have writen a > videl2_v4l2_live_example > whichs works. Perhaps this code is interesting for you,. especially after > the > mail from Brendan. > > Cheers, > Antonio > > P.S. I am using vxl-1.10.0, but I could change it for vxl-1.11.0. Then, you > could > take a look at the source to know it you like the design or if you want to > change > something, or even, to know that the code is not interesting for vxl. > > Matt Leotta escribió: >> >> Hi All, >> >> I'm cleaning up vidl2 a bit in preparation for the eventual move to >> core. There are a few unresolved issues with the API that I'd like to >> get some feedback on. >> >> First, I've added a num_frames() function to the vidl2_istream. >> This has been requested by users, and seems like it should be there. >> This function should return the number of frames in a video or -1 for >> live streams or other streams with indeterminate length. I've already >> implemented this for vidl2_image_list_istream and >> vidl2_ffmpeg_istream. All other istreams currently return -1. I >> could use some help with implementing this in vidl2_dshow_file_istream >> from Miguel and in vidl2_v4l_istream from Brendan. Of course, anyone >> else familiar with these is welcome to chip in. >> >> Second, I think we need to clear up the API regarding advance(), >> current_frame(), and read_frame(). The way it is now, advance() moves >> the stream pointer one frame ahead (usually without fully decoding the >> next frame), current_frame() decodes the current frame (if necessary) >> and returns the frame, and read_frame() calls advance() followed by >> current_frame(). It was also originally assumed that each istream >> could be opened in a state with the current frame pointing to an >> invalid frame before the first frame of the video. The reason for >> this was that a live stream could be opened without capturing any >> images until the first call of advance() (or read_frame()). The >> problem with opening in an invalid state is that when piping an >> istream into an ostream the image size and other properties often need >> to be known before opening the ostream. This usually requires >> accessing the first frame of the istream for probing anyway. The >> probing process can lead to dropping of the first frame because >> read_frame() calls advance() again before calling current_frame(). So >> the questions I have are: >> >> 1) Should each istream always open in a valid state so that a frame >> can be accessed with current_frame() and probed for properties? In >> the case of live streams we can always discard the initial frame by >> calling advance() right before the capture loop. However, this does >> require that capture devices be ready to capture when the stream is >> opened. >> >> 2) Should the redundant read_frame() function be removed? It may make >> iterating through streams easier for beginners, but it doesn't add any >> new functionality. >> >> 3) If read_frame() stays and each stream opens on the first frame, >> should read_frame() return the current frame and then advance instead >> of the reverse. Think i++ instead of ++i. This way you can open an >> istream and then immediately call read_frame() without dropping the >> first frame. >> >> There are still other lingering issues like synchronous vs >> asynchronous capture, but I think I'll leave that for another time. >> >> Thanks, >> Matt >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > > |
From: Antonio G. C. <aga...@de...> - 2008-09-08 11:08:47
Attachments:
v4l2.tgz
|
Hi Matt, In this mail I send the code that I wrote to use a class vidl2_v4l2_istream. I tried the code to be more complete than the previous code for v4l, adding more control on the video device, so it is not yet finished. In fact, code to add controls of the device is still needed, although it is already working (I used it), then it could be added to vidl2. The code in attached v4l2.tgz file can be extracted in directory brl/bbas/vidl2 of vxl 1.11. Note that 3 files will be overwrited: - CMakelists.txt (for adding v4l2 code to the library) - examples/CMakelists.txt (for adding vidl2_v4l2_live_example.cxx) - vidl2_convert.cxx (Added convertions for RGB_24(P),MONO8 and YUYV_422) Is this code interesting for vxl? If so, it could be interesting to add code for controls and to be included as part of vidl2 library. Comments and suggestions are welcome. thanks, Antonio. University of Granada (Spain) Matt Leotta escribió: > Antonio, > > Yes, I remember your e-mail about v4l2. It sounds like your code is > complete enough to check into vidl2. Once, it is in VXL other > developers can help finish it. Brendan McCane may have an interested > in using your code to replace the current vidl2_v4l_isteam. If not we > can check in a seperate vidl2_v4l2_istream. > > Please document which parts of the code you feel need improvement > (either in the comments or a separate file) and e-mail the code to > Brendan and myself. I can quickly get it checked in and building on > the dashboard, but I don't have time to seriously test it and finish > it up. Maybe Brendan can help with that? I'll wait for a decision on > whether this should be an upgrade to vidl2_v4l_istream or a separate > stream before I do anything. > > The only major changes vidl2 between 1.10 and 1.11 are the recent > changes I described in my e-mail yesterday. Your code should still > work fine with the addition of a member function: > > int num_frames() { return -1; } > > > --Matt > > |
From: Matt L. <mat...@gm...> - 2008-09-08 20:07:24
|
Antonio, thanks for the code! I've already checked in your additions to vidl2_convert.cxx since they are more broadly useful. I can check your code in as is, but I don't have time to maintain it or any experience with video 4 linux to test it. I think either another VXL maintainer needs to try it out and then help maintain it, or we'll need you to become VXL maintainer and do it yourself. Are you interested in becoming a VXL maintainer? Brendan, as the other V4L expert, are you or is anyone in your group interested in picking this up? Either as is or as a starting point to upgrade the current V4L code. I'll hold off on checking in the rest of the code for now, but it looks alright to me. The design is a little different from some of the other live streams. It uses a "device" class which is configured and then passed to an istream instead of a parameters class. The device class holds parameters and does most of the work while the istream mostly a wrapper around the device. We don't really have a standard on initializing with parameters yet, but maybe we should. There was talk a while back about reading parameters from files using XML or some standard file format... --Matt On Mon, Sep 8, 2008 at 7:08 AM, Antonio Garrido Carrillo <aga...@de...> wrote: > Hi Matt, > > In this mail I send the code that I wrote to use a class vidl2_v4l2_istream. > I tried the code to be more complete than the previous code for v4l, adding > more control on the video device, so it is not yet finished. In fact, code > to add controls of the device is still needed, although it is already > working (I used it), then it could be added to vidl2. > The code in attached v4l2.tgz file can be extracted in directory > brl/bbas/vidl2 of vxl 1.11. > > Note that 3 files will be overwrited: > - CMakelists.txt (for adding v4l2 code to the library) > - examples/CMakelists.txt (for adding vidl2_v4l2_live_example.cxx) > - vidl2_convert.cxx (Added convertions for RGB_24(P),MONO8 and YUYV_422) > > Is this code interesting for vxl? If so, it could be interesting to add code > for controls > and to be included as part of vidl2 library. > > Comments and suggestions are welcome. > > thanks, > Antonio. > University of Granada (Spain) > > Matt Leotta escribió: >> >> Antonio, >> >> Yes, I remember your e-mail about v4l2. It sounds like your code is >> complete enough to check into vidl2. Once, it is in VXL other >> developers can help finish it. Brendan McCane may have an interested >> in using your code to replace the current vidl2_v4l_isteam. If not we >> can check in a seperate vidl2_v4l2_istream. >> >> Please document which parts of the code you feel need improvement >> (either in the comments or a separate file) and e-mail the code to >> Brendan and myself. I can quickly get it checked in and building on >> the dashboard, but I don't have time to seriously test it and finish >> it up. Maybe Brendan can help with that? I'll wait for a decision on >> whether this should be an upgrade to vidl2_v4l_istream or a separate >> stream before I do anything. >> >> The only major changes vidl2 between 1.10 and 1.11 are the recent >> changes I described in my e-mail yesterday. Your code should still >> work fine with the addition of a member function: >> >> int num_frames() { return -1; } >> >> >> --Matt >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Brendan M. <bre...@gm...> - 2008-09-08 23:09:39
|
2008/9/9 Matt Leotta <mat...@gm...>: > Antonio, thanks for the code! I've already checked in your additions > to vidl2_convert.cxx since they are more broadly useful. I can check > your code in as is, but I don't have time to maintain it or any > experience with video 4 linux to test it. I think either another VXL > maintainer needs to try it out and then help maintain it, or we'll > need you to become VXL maintainer and do it yourself. Are you > interested in becoming a VXL maintainer? > > Brendan, as the other V4L expert, are you or is anyone in your group > interested in picking this up? Either as is or as a starting point to > upgrade the current V4L code. Hi Matt, Ideally I would, but I'm absolutely snowed at the moment and am unlikely to get to it in the foreseeable future. I do think that it should follow the style of the the other vidl streams, that is, use a parameters class - that will make it simpler writing cross-platform code. > > I'll hold off on checking in the rest of the code for now, but it > looks alright to me. The design is a little different from some of > the other live streams. It uses a "device" class which is configured > and then passed to an istream instead of a parameters class. The > device class holds parameters and does most of the work while the > istream mostly a wrapper around the device. We don't really have a > standard on initializing with parameters yet, but maybe we should. > There was talk a while back about reading parameters from files using > XML or some standard file format... > > --Matt > > On Mon, Sep 8, 2008 at 7:08 AM, Antonio Garrido Carrillo > <aga...@de...> wrote: >> Hi Matt, >> >> In this mail I send the code that I wrote to use a class vidl2_v4l2_istream. >> I tried the code to be more complete than the previous code for v4l, adding >> more control on the video device, so it is not yet finished. In fact, code >> to add controls of the device is still needed, although it is already >> working (I used it), then it could be added to vidl2. >> The code in attached v4l2.tgz file can be extracted in directory >> brl/bbas/vidl2 of vxl 1.11. >> >> Note that 3 files will be overwrited: >> - CMakelists.txt (for adding v4l2 code to the library) >> - examples/CMakelists.txt (for adding vidl2_v4l2_live_example.cxx) >> - vidl2_convert.cxx (Added convertions for RGB_24(P),MONO8 and YUYV_422) >> >> Is this code interesting for vxl? If so, it could be interesting to add code >> for controls >> and to be included as part of vidl2 library. >> >> Comments and suggestions are welcome. >> >> thanks, >> Antonio. >> University of Granada (Spain) >> >> Matt Leotta escribió: >>> >>> Antonio, >>> >>> Yes, I remember your e-mail about v4l2. It sounds like your code is >>> complete enough to check into vidl2. Once, it is in VXL other >>> developers can help finish it. Brendan McCane may have an interested >>> in using your code to replace the current vidl2_v4l_isteam. If not we >>> can check in a seperate vidl2_v4l2_istream. >>> >>> Please document which parts of the code you feel need improvement >>> (either in the comments or a separate file) and e-mail the code to >>> Brendan and myself. I can quickly get it checked in and building on >>> the dashboard, but I don't have time to seriously test it and finish >>> it up. Maybe Brendan can help with that? I'll wait for a decision on >>> whether this should be an upgrade to vidl2_v4l_istream or a separate >>> stream before I do anything. >>> >>> The only major changes vidl2 between 1.10 and 1.11 are the recent >>> changes I described in my e-mail yesterday. Your code should still >>> work fine with the addition of a member function: >>> >>> int num_frames() { return -1; } >>> >>> >>> --Matt >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> >> > -- Cheers, Brendan |
From: Antonio G. C. <aga...@de...> - 2008-09-09 08:17:18
|
Brendan McCane escribió: > 2008/9/9 Matt Leotta <mat...@gm...>: > >> Antonio, thanks for the code! I've already checked in your additions >> to vidl2_convert.cxx since they are more broadly useful. I can check >> your code in as is, but I don't have time to maintain it or any >> experience with video 4 linux to test it. I think either another VXL >> maintainer needs to try it out and then help maintain it, or we'll >> need you to become VXL maintainer and do it yourself. Are you >> interested in becoming a VXL maintainer? >> >> Brendan, as the other V4L expert, are you or is anyone in your group >> interested in picking this up? Either as is or as a starting point to >> upgrade the current V4L code. >> > > Hi Matt/Brendan, I am not a v4l2 expert. I have written this code reading other programs but not studying the problem in depth. Probably, an v4l2 expert could improve this code. Anyway, although I do not have much time, I can read comments and try to maintain this code. > Hi Matt, > > Ideally I would, but I'm absolutely snowed at the moment and am > unlikely to get to it in the foreseeable future. > > I do think that it should follow the style of the the other vidl > streams, that is, use a parameters class - that will make it simpler > writing cross-platform code. > I was thinking about a new design for controls because, as indicated in v4l2 specification, different devices have different controls available, and furthermore, the range of possible values vary from device to device. Then, if I write a parameters class, which is te range of values? default value? or even, which are the controls associated with current input? Too many questions, then I delayed the design thinking that the best solution would be a set of classes that provide a better control of the device. For example, it could be possible to write an program which includes a dynamic set of controls obtained from the driver. Well, as you see, I have not yet written anything about controls. ;) > >> I'll hold off on checking in the rest of the code for now, but it >> looks alright to me. The design is a little different from some of >> the other live streams. It uses a "device" class which is configured >> and then passed to an istream instead of a parameters class. The >> device class holds parameters and does most of the work while the >> istream mostly a wrapper around the device. We don't really have a >> standard on initializing with parameters yet, but maybe we should. >> There was talk a while back about reading parameters from files using >> XML or some standard file format... >> That's right. The device class appears because a device is very different from a istream. These are two different objects and it is not easy to create a single class to handle a v4l2_istream including all power from istream and devices. I thought that a better design should separate the two concepts such that it would be easier to maintain both classes. Anyway, it could be interesting to think about a solution in which a parameter class is used, perhaps including the most important controls as a wrapper around the device controls... ¿? Antonio. |
From: Matt L. <mat...@gm...> - 2008-09-09 14:00:23
|
On Tue, Sep 9, 2008 at 4:16 AM, Antonio Garrido Carrillo <aga...@de...> wrote: > Hi Matt/Brendan, > > I am not a v4l2 expert. I have written this code reading other programs but > not studying > the problem in depth. Probably, an v4l2 expert could improve this code. > Anyway, although > I do not have much time, I can read comments and try to maintain this code. Since you have written working code to interface with v4l2, that makes you an "expert" in my opinion. It certainly means you have more knowledge on the subject than most VXL maintainers. I'll discuss design issues in a separate e-mail, but first let's get you developer access for VXL. Can someone with the appropriate privileges grant developer access to Antonio. I can vouch for his coding abilities since I looked at the code he sent. Thanks, Matt |
From: Ian S. <ian...@st...> - 2008-09-09 15:04:43
|
Antonio, I can give you developer access to the repository, but you need to create an account at sourceforge first, and let me know the username. regards, Ian. Matt Leotta wrote: > On Tue, Sep 9, 2008 at 4:16 AM, Antonio Garrido Carrillo > <aga...@de...> wrote: >> Hi Matt/Brendan, >> >> I am not a v4l2 expert. I have written this code reading other programs but >> not studying >> the problem in depth. Probably, an v4l2 expert could improve this code. >> Anyway, although >> I do not have much time, I can read comments and try to maintain this code. > > Since you have written working code to interface with v4l2, that makes > you an "expert" in my opinion. It certainly means you have more > knowledge on the subject than most VXL maintainers. I'll discuss > design issues in a separate e-mail, but first let's get you developer > access for VXL. > > Can someone with the appropriate privileges grant developer access to > Antonio. I can vouch for his coding abilities since I looked at the > code he sent. > > Thanks, > Matt |
From: Matt L. <mat...@gm...> - 2008-09-09 14:35:29
|
<addressing v4l2 design> On Tue, Sep 9, 2008 at 4:16 AM, Antonio Garrido Carrillo <aga...@de...> wrote: > I was thinking about a new design for controls because, as indicated in v4l2 > specification, > different devices have different controls available, and furthermore, the > range of possible values > vary from device to device. Then, if I write a parameters class, which is te > range of values? > default value? or even, which are the controls associated with current > input? This is all very similar to the vidl2_dc1394_istream class I wrote. That stream uses libdc1394 to control live capture from IEEE 1394 cameras. One key difference is that this library is based on a published standard describing the set of parameters to be used by compliant cameras. I'm not sure how standard or constrained the parameters are for v4l2. However, I think a similar design will work. The vidl2_dc1394_istream class does all the work interfacing with libdc1394. To open a stream you pass it a vidl2_iidc1394_params object. In this case the parameters struct follows the IIDC standard and is not specific to libdc1394 (the same params might be used in the future with a Windows 1394 camera driver). There is another struct named valid_options contained within vidl2_iidc1394_params. The vidl2_dc1394_istream has a static method to probe the bus for available cameras and stores the camera properties (like which options the camera supports) in the valid_options class. The user can then generate a valid set of parameters from this information. It's still a work in progress, but what I have seems to work. The key idea is a parameters class that holds all the values but does no work, and an istream that configures itself from the parameters and does all the work. We should probably standardize this a bit more for all vidl2 streams. For now I think you can check in the code as it is (I've already checked in your additions to vidl2_convert.cxx). You can adjust the design over time, when you have time. Hopefully we will work out a standard way of handling parameters at some point Thanks, Matt |
From: Antonio G. C. <A.G...@de...> - 2011-12-12 17:23:13
|
Hi all, After some time not using vxl, I am now re-compiling some programs before continue improving this great software... I have found vpgl moved to core, which is good, but I do not know why vpgl*radial_distortion* files are not been moved. I have been looking for some comments in the mailing list without success. I there any problem to include these files? I have seen they are still included in vxl-1.14.0, but not in svn... Thanks Antonio |
From: Amitha P. <ami...@us...> - 2008-09-04 12:32:02
|
On advance() and current_frame(): I personally prefer this, because it is clear when the acquisition starts, and when the program requires access to the pixels. I'm agnostic on read_frame(), but I think that we must have read_frame() == advance()&¤t_frame(). And, in fact, any other variants must be implemented in terms of advance() and current_frame(). On the asynchronous capture: I've found it useful in the past to simply have a helper class for asynchronous capture. Something like: async_istream< v4l2_istream > reader; The async_istream can manage buffers, threads, etc. This allows easy asynchronous reading of simple video files too, which does have a performance impact since processing can continue during I/O. It will have even more impact these days with multi-core CPUs. On stream parameters: it is indeed useful to be able to query stream parameters, such as width and height, before the processing begins. This is especially true for programs with a GUI, which may want to open a window, etc. Perhaps we could add a method "acquire_description" that will do whatever it takes to return a structure containing a description of the stream? This method may pause to initialize a camera, acquire an image, etc. Finally, on timestamps: I think now would be a good time to add a timestamp to the vidl2_frame. Time is a critical aspect of video, and we all end up carrying around the relevant information outside of the pixels anyway. We could either add a member to the vidl2_frame, or else add a method to each istream ("current_time()"?). I suggest that the timestamp structure contains an unsigned integer for the frame number, and a double representing the time in UTC. I think the time should be represented as seconds in the Unix way, since there is a well-known algorithm to convert from Y/M/D to a single number and back. Since a double has 53 bits of precision, at millisecond (10^-3 ~= 2^-10) resolution, we have can represent 1970 +/- 2^53/2^10/3600/24/365 ~= 278922 years before we run into issues. At microsecond resolution, this is +/- 272 years. I think we should use a double instead of a 64 bit integer for a timestamp because in most vision processes, we will be using the time to compute things like velocity anyway, and we'll be converting to a double before doing the arithmetic. Of course, for many video streams, the time will simply be the number of seconds from the first frame, but having the notion that it *should* be a representation of UTC makes it easier to develop algorithms that cope with multiple cameras, etc. I suggest that the timestamp structure always contains a frame number, but does not need to contain a time. If does not contain a time, but is asked for one, it will return the frame number. In a statement like (x0-x1)/(time1-time2).seconds() < threshold it will allow threshold to mean "units/second" or "units/frame", both of which are meaningful to vision, and clear from the processing context. Amitha. |
From: Matt L. <mat...@gm...> - 2008-09-04 14:36:21
|
On Thu, Sep 4, 2008 at 8:32 AM, Amitha Perera <ami...@us...> wrote: > On advance() and current_frame(): I personally prefer this, because it is > clear when the acquisition starts, and when the program requires access to > the pixels. I'm agnostic on read_frame(), but I think that we must have > read_frame() == advance()&¤t_frame(). And, in fact, any other > variants must be implemented in terms of advance() and current_frame(). I'm starting to see that however we define read_frame() it will cause confusion and duplicated or dropped frames for some users. I'm now more confident that read_frame() should simply be dropped. Users can use advance() and current_frame() to explicitly get the desired result. I also like the idea of a frame iterator to allow for easy video traversal. The pre- and post-increment operators provide both orderings of advance() and current_frame(). The only problem I see with the iterators is that currently frames are only guaranteed to be valid until the next call of advance(). For the post-increment we would have to require at least double buffering in all istreams to allow a frame to remain valid until two calls of advance(). > On the asynchronous capture: I've found it useful in the past to simply have > a helper class for asynchronous capture. Something like: > > async_istream< v4l2_istream > reader; > > The async_istream can manage buffers, threads, etc. This allows easy > asynchronous reading of simple video files too, which does have a > performance impact since processing can continue during I/O. It will have > even more impact these days with multi-core CPUs. Agreed. It makes it much easier on the istream class if it doesn't need to know about asynchronous operations. The helper class is a great idea and provides yet another good reason to get some sort of threading capability into vxl asap. > On stream parameters: it is indeed useful to be able to query stream > parameters, such as width and height, before the processing begins. This is > especially true for programs with a GUI, which may want to open a window, > etc. Perhaps we could add a method "acquire_description" that will do > whatever it takes to return a structure containing a description of the > stream? This method may pause to initialize a camera, acquire an image, > etc. What I'm doing now is extracting these properties from the first frame. That's why I'm requiring preloading of the first frame. Does it make more sense to explicitly add this functionality to the istream? Does that change the need to preload the first frame? It still seems nice that the video doesn't open in an invalid state. > Finally, on timestamps: I think now would be a good time to add a timestamp > to the vidl2_frame. Time is a critical aspect of video, and we all end up > carrying around the relevant information outside of the pixels anyway. We > could either add a member to the vidl2_frame, or else add a method to each > istream ("current_time()"?). I vote for timestamps attached to frames, but it might also be useful to have start_time() and current_time() functions on the stream itself. > I suggest that the timestamp structure contains an unsigned integer for the > frame number, and a double representing the time in UTC. I think the time > should be represented as seconds in the Unix way, since there is a > well-known algorithm to convert from Y/M/D to a single number and back. Is there any good reason why timestamps and frame numbers should be part of the same structure? > Since a double has 53 bits of precision, at millisecond (10^-3 ~= 2^-10) > resolution, we have can represent 1970 +/- 2^53/2^10/3600/24/365 ~= 278922 > years before we run into issues. At microsecond resolution, this is +/- 272 > years. > > I think we should use a double instead of a 64 bit integer for a timestamp > because in most vision processes, we will be using the time to compute > things like velocity anyway, and we'll be converting to a double before > doing the arithmetic. > > Of course, for many video streams, the time will simply be the number of > seconds from the first frame, but having the notion that it *should* be a > representation of UTC makes it easier to develop algorithms that cope with > multiple cameras, etc. I still don't see the big advantage of storing a timestamp as a double. Why not a 64-bit integer? It's true that most uses will end up converting to double, but they will likely also convert the units. The timestamp class could still have functions to return seconds, minutes, or hours as double. > I suggest that the timestamp structure always contains a frame number, but > does not need to contain a time. If does not contain a time, but is asked > for one, it will return the frame number. In a statement like > (x0-x1)/(time1-time2).seconds() < threshold > it will allow threshold to mean "units/second" or "units/frame", both of > which are meaningful to vision, and clear from the processing context. I don't think I like this idea. Yes, a frame should always have a frame number and a timestamp may be optional, but I think it should be made explicit whether or not the timestamp is available. In the example above, the threshold will need to be different unless your video is 1 FPS. I think it also makes sense to have some indicator of whether a timestamp is relative or absolute. Either use a bit in the timestamp, or have separate bool. The difference between two times should be relative. Also, many videos will not provide an absolute starting time but will provide a relative time from the start of the sequence. It might be nice to know which case you are dealing with. Finally, where does the absolute time information get stored on disk? This is all fine when processing live video, but more frequently users will be capturing video to disk and processing video read from disk. Do any video file formats have a field for storing absolute time? I don't think we can trust OS file creation times. What about image lists? I know some image formats store a timestamp, has this been added to vil? Maybe we need to start reading and writing a metadata file. --Matt |
From: Matthew L. <mat...@gm...> - 2008-11-21 13:35:42
|
Antonio, Your problem might be solved by a correction to the CMake module for finding ffmpeg. Can you report the output from running "ffmpeg - version" on your system? It's hard to match version numbers from the package name alone. My output looks like this: FFmpeg version SVN-r11312, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --disable-vhook --enable-shared --disable-mmx libavutil version: 49.6.0 libavcodec version: 51.49.0 libavformat version: 52.3.0 built on Oct 12 2008 13:50:49, gcc: 4.0.1 (Apple Inc. build 5488) FFmpeg SVN-r11312 libavutil 3212800 libavcodec 3354880 libavformat 3408640 My version is from subversion about a year ago (I think). I am aware that the ffmpeg API has been significantly changed and that vidl2 does not support those changes. However, I thought the change was more than just altering the include paths. Can you describe exactly how the headers have been redistributed in your version? The long term goal is to have a stable version of ffmpeg copied into VXL (in v3p) so there is always a working version available. Amitha Perera is working on that. We will also support linking to a "head" version of the ffmpeg which hopefully will be kept up reasonably up to date with the ffmpeg svn. I should probably start working on this head version, but I don't want to duplicate any of Amitha's efforts. Amitha, have you settled on a version of ffmpeg for v3p? If I was to check out the current version of ffmpeg would it be significantly different from what you are working on? Thanks, Matt On Nov 21, 2008, at 6:26 AM, Antonio Garrido Carrillo wrote: > > Hi Matt, > > I have been changing some code in vidl2, but in my system (mandriva > 2009) ffmpeg is > not compiled. > I have seen this is not done because include directories have been > changed. > I do not remember the problem with ffmpeg (last version). I remember > you said some > message because the new API is not compatible. > However, I have compiled vidl2 with ffmpeg support by adding a new > directory ffmpeg > with all headers files in package libffmpeg- > devel-0.4.9-3.pre1.14161.1mdv2009.0 > > Is this the original problem? that is, the redistribution of code in > different directories? > > Thanks > Antonio. > |
From: Amitha P. <ami...@us...> - 2008-09-08 15:09:05
|
[splitting the multiple threads of conversation into multiple read threads] Matt Leotta wrote: > On Thu, Sep 4, 2008 at 8:32 AM, Amitha Perera > <ami...@us...> wrote: >> On stream parameters: it is indeed useful to be able to query stream >> parameters, such as width and height, before the processing begins. This is >> especially true for programs with a GUI, which may want to open a window, >> etc. Perhaps we could add a method "acquire_description" that will do >> whatever it takes to return a structure containing a description of the >> stream? This method may pause to initialize a camera, acquire an image, >> etc. > > What I'm doing now is extracting these properties from the first > frame. That's why I'm requiring preloading of the first frame. Does > it make more sense to explicitly add this functionality to the > istream? Does that change the need to preload the first frame? It > still seems nice that the video doesn't open in an invalid state. I think preloading of the frame does the job, and I'm fine with that. I suggested something like "acquire_description()" because it may not be necessary to preload the frame, depending on the video source. Moreover, the latter can be trivially implemented if the first frame has been loaded. In any case, even if it costs a little to initialize the video resource, the initialization phase will be so short compared to the rest that we should probably ignore the effect. However, the preloading of the frame is completely hidden from the user, correct? Or are you suggesting that the state after open() is that the first frame has been loaded/captured? I'd be okay with either case; we just need to be clear. |
From: Matt L. <mat...@gm...> - 2008-09-08 20:45:21
|
On Mon, Sep 8, 2008 at 11:09 AM, Amitha Perera <ami...@us...> wrote: > [splitting the multiple threads of conversation into multiple read threads] > > Matt Leotta wrote: >> >> On Thu, Sep 4, 2008 at 8:32 AM, Amitha Perera >> <ami...@us...> wrote: >>> >>> On stream parameters: it is indeed useful to be able to query stream >>> parameters, such as width and height, before the processing begins. This >>> is >>> especially true for programs with a GUI, which may want to open a window, >>> etc. Perhaps we could add a method "acquire_description" that will do >>> whatever it takes to return a structure containing a description of the >>> stream? This method may pause to initialize a camera, acquire an image, >>> etc. >> >> What I'm doing now is extracting these properties from the first >> frame. That's why I'm requiring preloading of the first frame. Does >> it make more sense to explicitly add this functionality to the >> istream? Does that change the need to preload the first frame? It >> still seems nice that the video doesn't open in an invalid state. > > I think preloading of the frame does the job, and I'm fine with that. I > suggested something like "acquire_description()" because it may not be > necessary to preload the frame, depending on the video source. Moreover, the > latter can be trivially implemented if the first frame has been loaded. In > any case, even if it costs a little to initialize the video resource, the > initialization phase will be so short compared to the rest that we should > probably ignore the effect. > > However, the preloading of the frame is completely hidden from the user, > correct? Or are you suggesting that the state after open() is that the > first frame has been loaded/captured? I'd be okay with either case; we just > need to be clear. I was suggesting that the first frame has been loaded/captured after open() has been called. The advantage is that you can call current_frame() immediately after open() and get something valid. The disadvantage is that this doesn't always make sense for live video. If you don't call advance() before current_frame() when starting your capture loop you will start with the frame captured at the time open() was called. I like the idea of acquire_description(). There are some properties of video not currently associated with a frame (and probably shouldn't be) like frame rate. It's probably best that the istream can provide all its properties without necessarily decoding a frame (although it may have to do this internally). Is there any reason that acquire_description() couldn't happen as part of open()? If at least the properties of an open istream are always available then I am not concerned about an image always being available. |
From: Amitha P. <ami...@us...> - 2008-11-21 13:51:19
|
On Nov 21, 2008, at 6:26 AM, Antonio Garrido Carrillo wrote: > I remember you said some message because the new API is not > compatible. However, I have compiled vidl2 with ffmpeg support by > adding a new directory ffmpeg with all headers files in package > libffmpeg-devel-0.4.9-3.pre1.14161.1mdv2009.0 > > Is this the original problem? that is, the redistribution of code in > different directories? Antonio, ffmpeg 0.4.9-3 is the last "release" that the ffmpeg folks did, and that was a long time ago. In that sense, that is an "old" version of ffmpeg, and it may be compatible enough with the use in vidl2. The API problem exists in the current SVN version of ffmpeg. With your version of ffmpeg, I think following Matt's suggestions will get you a video-enabled vxl. Matthew Leotta wrote: > Amitha, have you settled on a version of ffmpeg for v3p? If I was to > check out the current version of ffmpeg would it be significantly > different from what you are working on? That has an implicit assumption that I'm working on it. :-) The ffmpeg process, unfortunately, only gets sporadic bursts of attention from me. However, there is a good chance that the effort will soon accelerate, because we may soon have a contractor to whom this will be tasked. Amitha. |
From: Matthew L. <mat...@gm...> - 2008-11-21 14:06:03
|
On Nov 21, 2008, at 8:51 AM, Amitha Perera wrote: > Matthew Leotta wrote: >> Amitha, have you settled on a version of ffmpeg for v3p? If I was >> to check out the current version of ffmpeg would it be >> significantly different from what you are working on? > > That has an implicit assumption that I'm working on it. :-) The > ffmpeg process, unfortunately, only gets sporadic bursts of > attention from me. However, there is a good chance that the effort > will soon accelerate, because we may soon have a contractor to whom > this will be tasked. > I'll take that to mean that you haven't decided on any particular version for v3p. When you start up on this again, do you plan to grab the current release of ffmpeg to import and make it work with vidl2 or do you plan to take a version that currently works with vidl2 and move it into v3p? --Matt |
From: Amitha P. <ami...@us...> - 2008-11-21 14:25:31
|
Matthew Leotta wrote: > I'll take that to mean that you haven't decided on any particular > version for v3p. When you start up on this again, do you plan to grab > the current release of ffmpeg to import and make it work with vidl2 or > do you plan to take a version that currently works with vidl2 and move > it into v3p? I plan to work on the latest version of ffmpeg. Amitha. |
From: Matthew L. <mat...@gm...> - 2008-11-21 15:06:26
|
On Nov 21, 2008, at 9:25 AM, Amitha Perera wrote: > Matthew Leotta wrote: >> I'll take that to mean that you haven't decided on any particular >> version for v3p. When you start up on this again, do you plan to >> grab the current release of ffmpeg to import and make it work with >> vidl2 or do you plan to take a version that currently works with >> vidl2 and move it into v3p? > > I plan to work on the latest version of ffmpeg. Alright, I will hold off on trying to learn the new ffmpeg API for now. I still need to focus on graduating anyway. --Matt |
From: Antonio G. C. <A.G...@de...> - 2008-11-24 08:33:18
|
Amitha Perera wrote: > > I plan to work on the latest version of ffmpeg. > > Amitha. > > Hi Amitha, I was thinking that my version was not very old and current vxl version could be easily adapted. My installed version (included in recent mandriva 2009) is: FFmpeg version SVN-r14161, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --prefix=/usr --enable-shared --libdir=/usr/lib --shlibdir=/usr/lib --incdir=/usr/include --enable-liba52 --enable-postproc --enable-gpl --enable-pthreads --enable-libnut --enable-libtheora --enable-libvorbis --enable-x11grab --enable-swscale libavutil version: 49.7.0 libavcodec version: 51.60.0 libavformat version: 52.17.0 libavdevice version: 52.0.0 built on Jul 11 2008 01:52:29, gcc: 4.3.1 20080626 (prerelease) FFmpeg SVN-r14161 libavutil 3213056 libavcodec 3357696 libavformat 3412224 libavdevice 3407872 But, as indicated, this is a old one, compared to svn version. I do not know much about ffmpeg, but I am interested in it because I found the library libavdevice, with files like dv1394, v4l, v4l2. As you know, I have recently added v4l2 support to vidl2, but could it be solved with ffmpeg as well? Last svn version could be much more interesting. Matthew Leotta wrote: > > > Alright, I will hold off on trying to learn the new ffmpeg API for > now. I still need to focus on graduating anyway. > > --Matt Ok Matt. My e-mail was sent only to know current status in this development, because I suppose this work is interesting before vidl2 change to core and/or more contribution on v4l2 (although it is practically finished). Antonio. |
From: Amitha P. <ami...@us...> - 2008-11-24 14:10:17
|
Antonio Garrido Carrillo wrote: > As you know, > I have recently added v4l2 support to vidl2, but could it be solved with > ffmpeg as well? Direct support for v4l2 and so on in vxl is still useful, regardless of whether ffmpeg supports it, because it allows these devices to be used even when ffmpeg is not available or is undesirable. (ffmpeg is licensed under the LGPL or GPL.) Amitha. |