- Nov 29, 2016
- Nov 23, 2016
- Nov 20, 2016
-
-
Tim-Philipp Müller authored
-
- Nov 17, 2016
-
-
Mathieu Duponchelle authored
It could yet be made be simpler, but it would require touching the rest of the timeline editing code. Fixes https://phabricator.freedesktop.org/T7587 Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D657
-
Sebastian Dröge authored
-
Thibault Saunier authored
In some cases when rippling clip we could get the algo lost because a transition existed between two clips (for example at the end of c1 and at the begining of c2) but while rippling it would have required a transition at the end of c2 and beginning of c1, and we were properly not destroying the old one (as the two clips were in the moving context) but we were still creating the other transition in the end... Reviewed-by: Alex Băluț <alexandru.balut@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D1362
-
Thibault Saunier authored
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D1361
-
Thibault Saunier authored
And make sure that we move the transition to the right layer, not trying to figure it out. Differential Revision: https://phabricator.freedesktop.org/D1360
-
Thibault Saunier authored
Avoiding problems when using subproject: 'Failed to load plugin something.so file too short'
- Nov 12, 2016
-
-
Sebastian Dröge authored
The seek action might currently be handled (in which case it is not in the actions list and the action lock is not locked), but not actually handled completely yet (the seqnum is not stored yet). To prevent this, we remember what the current action is that is being handled, and also compare to that. https://bugzilla.gnome.org/show_bug.cgi?id=774149
-
Sebastian Dröge authored
If there are e.g. multiple video sinks, we would get the same seek event multiple times. But we only want to handle it once. https://bugzilla.gnome.org/show_bug.cgi?id=774149
-
- Nov 01, 2016
-
-
Tim-Philipp Müller authored
-
- Oct 26, 2016
- Oct 25, 2016
-
-
Nirbheek Chauhan authored
This reverts commit 5665c2bf. Does not actually work. See: https://bugzilla.gnome.org/show_bug.cgi?id=773114#c31
-
- Oct 21, 2016
-
-
Thibault Saunier authored
-
- Oct 18, 2016
-
-
Scott D Phillips authored
-
- Oct 15, 2016
-
-
Nirbheek Chauhan authored
Use the default for each compiler on every platform instead. This improves our compatibility with compilers that don't have gnu99 as a c_std.
-
- Oct 14, 2016
-
-
Thibault Saunier authored
Bump meson requirement to 0.35
-
- Oct 11, 2016
-
-
Thibault Saunier authored
We set TrackElement track type very early when creating effects so it now uses that information to find TrackElement in clips by track type. Reviewed-by: Alex Băluț <alexandru.balut@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D1370
-
Thibault Saunier authored
-
- Sep 30, 2016
-
-
Thibault Saunier authored
-
Tim-Philipp Müller authored
-
- Sep 28, 2016
-
-
Thibault Saunier authored
-
Thibault Saunier authored
-
- Sep 26, 2016
-
-
Thibault Saunier authored
Differential Revision: https://phabricator.freedesktop.org/D1329
-
Thibault Saunier authored
Differential Revision: https://phabricator.freedesktop.org/D1328
-
Thibault Saunier authored
Those tag are meaningless in for the new stream created by the composition First step toward fixing T3070 Differential Revision: https://phabricator.freedesktop.org/D1327
-
Thibault Saunier authored
Computation was not taking into account the fact that the start of the element being moved could be at the middle of a group and not necessarily at the start! Fixes T7544 Reviewed-by: Alex Băluț <alexandru.balut@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D1282
-
Thibault Saunier authored
We were only concidering that we should let the group handle moving transitions when changing transitions but in fact as soon as a transition is happenning between two clips that are in a same group the group properly handles moving the transition, so let the group do its job. Fixes T7543 Differential Revision: https://phabricator.freedesktop.org/D1281
-
Thibault Saunier authored
GESLayer is now responsible for setting clips priorites. Also GESClip top effects priorities are now set by the ges_clip_set_top_effect_index method, the user should never call ges_timeline_element_set_priority as it will anyway be overriden by GES itself. Differential Revision: https://phabricator.freedesktop.org/D1280
-
Thibault Saunier authored
All operations should have higher priorites and sources should be on top of those. We now first set the operations priorities in a first pass and then stack sources on top of those. Differential Revision: https://phabricator.freedesktop.org/D1279
-
Thibault Saunier authored
Until now fade out was just fading in the new clip, but this is not correct and crossfade should at the same time fade out while fading in. Fixes https://phabricator.freedesktop.org/T3451 Differential Revision: https://phabricator.freedesktop.org/D1278
-
Thibault Saunier authored
In case effects have been added priorites might become wrong, but until the timeline is not commited, it does not matter. Make sure all priorities are correct before commiting compositions Differential Revision: https://phabricator.freedesktop.org/D1277
-
Thibault Saunier authored
Fix all tests as we now have 1 priority inside the layer dedicated to transitions (basically no source clip will ever have a priority of 0 inside a layer). Differential Revision: https://phabricator.freedesktop.org/D1276
-
Thibault Saunier authored
And simplify the way we start computing children priority making min_priority already relative to the clip itself. Differential Revision: https://phabricator.freedesktop.org/D1275
-
Thibault Saunier authored
Differential Revision: https://phabricator.freedesktop.org/D1274
-
- Sep 22, 2016
-
-
Sebastian Dröge authored
We would seek on a NULL pad then, which gives ugly assertions. https://bugzilla.gnome.org/show_bug.cgi?id=771843
-