From: Matt L. <mat...@gm...> - 2005-06-16 19:34:37
|
Hi Everyone, I've been working with the video library (vidl), and I have a few proposed changes/additions I would like to make as long as nobody objects. I am also looking for some input on possibly changing the API a little. It seems to be a little messy and not appropriate for some common functionality (like writing a video). First, I'd like to introduce a vidl_frame_resource derived from vil_image_resource. When I ported vidl from vil1 to vil I added get_resource and get_view functions. Currently get_view decodes the frame into a vil_image_view and get_resource calls get_view and creates an in memory resource with vil_new_image_resource_of_view.=20 This behavior is overridden in the image list codec so the actual image file resource is returned. If we wish to treat the movie as an array of image resources we have to decode the entire movie into memory. This is very bad for large movies. I have implemented a vidl_frame_resource to be returned by movie->get_resource instead. The frame resource keeps a pointer to the movie and frame number. The frame is not decoded until get_view is called on the frame resource. The old functionality is still available by calling get_view and wrapping the view into a memory resource. Second, I'd like to add a new "codec" using FFMPEG to load movies.=20 Currently vidl is not very robust to different types of video encoding. It seems Amitha and the folks and GE are currently using the FFMPEG API (but not vidl) as a solution on both windows and linux. FFMPEG will handle same files as the other vidl codecs plus many others that are not supported. This will be an optional addition (only compiled if FFMPEG is present) and we don't need to put FFMPEG in v3p. However, I believe Amitha mention something about making precompiled binaries available for windows users since it will not compile in visual studio. I will make the changes described above unless anyone objects. Finally, does anyone have any suggestions on modifying the vidl API to make it more usable? It seems that it has been ported from Target JR and then ported again to use the new vil library. I'm not sure if the original API is acceptable anymore. The biggest problem I am having is saving movies. The API expects you to have created your entire movie object in memory and then save it all at once. It also only lets you specify the filename and type where "type" is the vidl codec to use (AVI, MPEG, image list). In general there are many more parameters that need to be specified and no way to specify them. My impression is that most VXL users who work with encoded video are not using vidl. It would be nice to have a core video library that handles reading and writing without so much trouble. Any suggestions other than a redesign from the ground up? Thanks, Matt Leotta Brown University |
From: Ian S. <ian...@st...> - 2005-06-21 08:36:55
|
Matt Leotta wrote: > I have implemented a vidl_frame_resource to be returned by > movie->get_resource instead. The frame resource keeps a pointer to > the movie and frame number. The frame is not decoded until get_view > is called on the frame resource. The old functionality is still > available by calling get_view and wrapping the view into a memory > resource. I don't know much about vidl, but this vidl_frame_resource is exactly the way I intended vil_image_resource to be used - I'm glad someone is finding it useful. > Finally, does anyone have any suggestions on modifying the vidl API > to make it more usable? It seems that it has been ported from Target > JR and then ported again to use the new vil library. I'm not sure if > the original API is acceptable anymore. The biggest problem I am > having is saving movies. The API expects you to have created your > entire movie object in memory and then save it all at once. It also > only lets you specify the filename and type where "type" is the vidl > codec to use (AVI, MPEG, image list). In general there are many more > parameters that need to be specified and no way to specify them. > My impression is that most VXL users who work with encoded video > are not using vidl. It would be nice to have a core video library > that handles reading and writing without so much trouble. Any > suggestions other than a redesign from the ground up? Frank Bettinger (who is no longer at Manchester) wrote a movie library and published it at contrib/mul/mvl2. There might be some ideas there. In my experience of writing vil, and other libraries with similar "properties" problems, I have used several solutions. I suspect that vil's may be suitable here: vil_image_resources read from disk can report various properties through the base class get_property method. However, setting these properties during image writing, is both trickier and easier: It is trickier, because having a set_property method in the base class, can lead to all sorts of error reporting difficulties. However, this turns out not to be a problem because writing is easier that reading in one special way. When you are reading an image (or movie) your programs often do not want to know when the image type is - they just want to be able to read the image. When writing, however, your program needs to know explicitly what image type it wants to use. So you can down cast from the vil_image_resource to the vil_jpeg_image (or what-ever) and set the relevent property (e.g. set_quality()) on the concrete derived class. Ian. |