From: Ruben <ry...@gp...> - 2001-02-03 17:58:19
|
On 2001/Feb/03, Wim Taymans wrote: > I'm glad you are looking at GStreamer. Video editing is one of my goals > with GStreamer. I'm currently downloading and inspecting your code, so > more feedback will follow soon... I wait impatient :D > > * file: either an image (png, ppm, etc) or a video (currently only > > mpeg-1). They are leafs of the tree. > > We also have those elements as leaf nodes (GstElement). We actually are a > bit more modular, you'll have an element for reading from disk or network > an a separate element for decoding the media. Yes, this part isn't very well thinked, but I've no many alternatives :(, I've only file sources because I need to know the size of the source. It's very difficult to know the size of an MPEG-1 file, I can't figure out what should I do for network sources, and it would be impossible for a video-for-linux source where the user deceides when he wants to start saving and when he wants to stop. So the solution I have taken is that ganso only reads from file and the user is responsible for saving in files the media sources from HTTP, from RTP, from his webcam or from where he wants. > > * sequential composition: can have sub-nodes that will be played > > sequentially, with the posibility of padding before each node. > > > > * concurrent composition: it's like the layer-system of The GIMP, > > but applied to videos. Of course, as in GIMP, it's usefull if you have top > > layers with alpha. > > I'll have to look at the code to understand what you mean with the > composition. It's easy: Sequential (defines composition of media sources in time): --------------------------------------------- padding 0| Video 0 | padding 1 | Video 1| ... --------------------------------------------- ------ time ----> When the user uses the preview window to see what he will get, first he sees a black image (padding 0) during some frames, then the video 0, then another black image (padding 1) during some frames, then the video 1. This black image is really a "transparent" image, so if it's composed with concurrence with another thing, while the paddings, you will see the "bottom" video. Concurrent (defines composition of media sources in space): ------------------------------- <===========Video 0===========> ------------------------------- <======Video 1======> ------------------------------- <=========Video 2=========> ------------------------------- ------ time -----> The three videos are composed, if you use preview window, the first frame you will get the video 0, over it the video 1 and over them the video 2. If the upper videos has transparent zones, in these zones you will see what occurs below. For example, imagine that the Video 2 is an animation of a window opening, behind the window there is nothing, only transparency, so, when combined with Video 1, you will see a window opening and letting you see the second video. If the second video is a transparent hole that gets bigger after the window is completely opened, the result will be a window that opens, and let you see a hole that gets bigger and lets you see the Video 2. > The GStreamer core is media type independant and agnostic, we have a > property system to describe the media types. The meaning of the media data > is entirely handled by the plugins so in theary you can use whatever media > type you like. When ganso reads any video media, each time ganso read a frame (well, ganso not, its plugins, of course) it copies the frame to an internal format of 32 bits (8,8,8,8 -> red, green, blue, alpha). And all filter plugins have access to this format, so it's very easy to make a new filter, and don't have to worry about what kind of representation the media uses. > You should use GStreamer, no doubt about that. While our goals are exactly > the same as yours we should be able to integrate GStreamer. You have to > take into account though that this will be a first real-life use of > GStreamer in an app like GANSO, so you might have problems or requirements > that we need to add to the core. Yes, this is what I thought. Then I think it's better to make two branches of GAnSO, one traditional and other trying to use gstream.I wish it's well designed enough (ganso) to support both branches without very much cut&paste... > A quick look at the site tells me that the tree you use is mostly for > describing the video sequences and the how they will be merged together. Yes, the tree is only an internal reprepsentation of the data definition. When the resulting video gets builded, the codec asks this tree for images (of course for the codec is transparent the aspect of these tree, he only asks the root) and each node knows how to merge his internal nodes, spatially or temporally if it has to merge something. > the GStreamer architecture uses tree to do the actual rendering of those > sequences, there is a slight difference. I think the tree you use can > still be used to serve as input for a source element in GStreamer. But imagine that I have the gstream tree build up, and I can show the user a render of these tree. Now can I save this to a file? (I mean to an MPEG-1 file or a DivX file or so) If I can, then there is no difference... Regards -- __ )_) \/ / / email: mailto:ry...@gp... / \ / (_/ www : http://pinguino.dyndns.org [ GGL + GAnSO developer ] & [ GPUL member ] |