GNOME Bugzilla – Bug 645385
Transitions act randomly depending on the video codec in use.
Last modified: 2013-09-24 16:03:36 UTC
Using the classical crossfade transition, I get strange bugs, always with the same sources. I thought it came from flash videos, but some flash videos do work well sometimes. I have a pipeline which is set in preview mode, and I get things like : -when the transition starts, the first video is reduced and pushed to a corner of the screen; -when the transition starts, the first video disappears and the second starts fading in. The problems always happen with the same videos, I can make them available on a random sharing website if needed.
Looks like: ->Theora, divx mpeg4, raw YUV, mpeg4 don't work, the output is different each time -> h.263, h.264, xvid mpeg4 work just fine
More information, please. The first problem you mention will sometimes happen when the resolutions of the two sources are different. We don't handle this case very well at the moment. Some combination of videobox/scale might be required inside the crossfade transition to scale the two streams relative to each other according to some simple rules (I think you can also use pad-properties on videomixer input pads to do scaling and position as well, but the borders will be transparent). Do you get any warnings or errors (GST_DEBUG=2) on the console?. Obvious culprits for the second case will be "Not linked" errors. A full debug log would be more useful. My guess is that it's a caps-negotiation failure somewhere in the decoder->colospace->videomixer portion of the pipeline.
The transition is composed of a bin which has 2 gohstpads linked to ffmpegvideocolorspace elements which are themselves linked to the videomixer and another ffmpecolospace conversion (used as a ghostpad) after the videomixer src. It could be drawn as such (for the crossfade only): ! ffmpegcolorspace ! videomixer(2) name=mix ! ffmpegcolorspace (ghostpad) ! ffmpegcolorspace ! mix. ! The problem is that we need to make sure the 2 videos have the same size (scaling) while being mixed. Introducing a videoscale between the sources and the mixer (sinks) with hard-coded Caps (height/width) to be sure the video have the same size make effects working properly. But, this is not a solution, and instead, we could: * have a fixed size for all the sources/track in a timeline, which I think for some reason has been preferred not to be done. * get the caps of the 2 incoming sources and make the scaling equal to the size of the smallest video coming in.
We definitely don't want to force the size of the incoming video. This is inefficient, inconvenient, and against the spirit of GES -- which is intended to be as automatic as possible. You want to chose your mixing resolution based on the desired output aspect ratio. If you are compositing a 4:3 source and a 16:9 source, the correct output resolution depends on whether the user thinks they have a 16:9 project or a 4:3 project. If it's a 16:9 project, then the right thing to do is to pillar-box the 4:3 source and scale the result to the resolution of the 16:9 source. If it's a 4:3 project, you letter box the 16:9 source and scale the result to match the resolution of the 4:3 source. But I think you always want to match the resolution of one source to the other so that we avoid having to apply software scaling to both streams. We may need to add an "output display-aspect-ratio hint" property to GESTimeline for this purpose. We can and should attempt to infer the desired output aspect ratio based on some heuristic, such as the DAR of the majority of sources in the timeline; however, it's quite likely that we will occasionally guess wrong, so we should allow the user to override this setting. As an advanced feature, we may want to support some per-clip overrides. For example, the user has a 720x50 pixel still image they wish to use as a title key. The banner should fade in along the bottom of the screen, not the centre. In this case we would want a per-clip override of the display aspect ratio, as well as a position adjustment (taking advantage of videomixer2's "x" and "y" pad properties).
*** Bug 655984 has been marked as a duplicate of this bug. ***
Created attachment 193825 [details] [review] fix transitions of videos with different sizes Temporary fix so transitions don't hang the video stream or look broken. A more cross-timeline solution will be needed in the future. Looking into it.
The solution is hackish/ugly and very racy. Since it waits for the caps to be set in the first video, and then set the capsfilter in the second video, this might happen in the wrong moment in some cases. Transitions with images are also broken. A proper solution, depends on the not-yet-available GESMaterials. So will wait until those are available before closing it.
commit 32f0a49c6a2f7cc9ce54fdc9ea982a3c9e003a68 Author: Luis de Bethencourt <luis@debethencourt.com> Date: Sun Aug 14 20:27:08 2011 +0200 ges/ges-track-video-transition.c: fix transition of different video sizes