Sorry git clone link is my private, use this instead git://github.com/offlinehacker/gst-plugins-good.git .

I think it would be better to not include all of videoscale inside videomixer but instead a) extend videomixer to allow scaling via properties and b) use a videoscale in front of the videomixer sinkpads.

But the only way for changing video size is by changing caps, but this way you can't make nice linear animations as far as i know, if i'm wrong please let me know. There's no need to include whole videoscale, we can just use functions from videoscale, but i don't know how to include source and header files from one plugin to another.

I don't see changing caps 100 and more times during animations efficient, could it be even done nice linear?

What I meant was adding support to videoscale to change the output width/height with a property as an additional mode to the current one that changes it based on the caps.
This would allow you to do nice animations with the videoscale/videomixer combination.

I see what you think, but this way you would have to make static output caps from videoscale element and you won't be able to scale beyond original size, or you have to crop(this does not present a real problem). This is more like videobox element with resizing capabilities as videscale, but i think this two elements(videscale and videobox) should be combined, forming one  well made videoresize element. Meybe i will make someday when i will have too mouch time.

While i support your idea, i still think that videomixer should receive my patch, since it would make life much easier to many users, and that's actually the only basic option that videmoxer fails. The fact is you can always throw it out when you came up with nicer solution. If you look from minimalistic aspecp videomixer shouldn't even have to have xpos and ypos properties nor alpha, but they are there, well the only property videomixer must have is z-index, everything else should be covered in other elements. 
If you look from other direction, why not keep all these stuff in and give users more options to make same thing. Well if you take this path you have to make sure you keep processing in elements optimized, so that additional options don't slow down processing if you don't use them.

Why would adding width/height scaling properties to videoscale prevent scaling beyong original size? It would allow to do the same that is currently possible by changing the downstream caps. videoscale would never crop but scale to the requested width/height.

Instead of copying the videoscale code it would make sense to refactor it into a library and use the public API of that library from videoscale and videomixer and possibly other elements. That's the plan for 0.11 (and the same for video format conversion, audio format conversion, resampling, ...) but it could be done for 0.10 too already.



Ideally there would be a videocomposition element that allows you to scale/crop/rotate/position different video streams and composite them with different operations (ADD, SUB, OVER, ...) in different orders.

Videocomposition element and public API sounds awsome, let me know and meybe i can contribute something. How can i become gstreamer developer anyway?

Nobody is working on that yet so you could just propose patches against libgstvideo that add a simple scaling API there.

Also I don't think anybody is planning on to work on a generic composition element, it's only something nice to have but nobody has the time to do it :) By using cairo (which unfortunately only supports (A)RGB currently) it should be possible to create such a element quite fast though.

Anybody planning to work on this?

The sink pads of the new compositor element in gst-plugins-bad now have width/height properties that allow for the input to be scaled, also dynamically via GstController, which I think covers the features requested in this bug report.