- Apr 10, 2019
- Mar 23, 2019
-
-
Tim-Philipp Müller authored
This suppresses the annoying 'g-ir-scanner: link: cc ..' output that we get even if everything works just fine. We still get g-ir-scanner warnings and compiler warnings if we pass this option.
-
- Mar 20, 2019
-
-
Jakub Adam authored
-
- Mar 19, 2019
-
-
Jakub Adam authored
If there's image-orientation tag, make sure the image is correctly oriented before we scale it.
-
- Mar 16, 2019
-
-
Tim-Philipp Müller authored
-
- Mar 15, 2019
-
-
And handle the fact that adding to a layer can fail. Also plug some leaks in the dispose method (and use the dispose vmethod instead of finalize as appropriate).
-
Basically if we do not emit a "duration" change of the clip being splitted first when executing the 'reverse' operations would lead to fully overallaping clips.
-
This is implemented on top of a Tree that represents the whole timeline. SourceClips can not fully overlap anymore and the tests have been updated to take that into account. Some new tests were added to verify that behaviour in greater details
-
-
-
Making debugging tests simpler
-
Each timeline element is in a layer (potentially spanning over several), it is very often useful to retrieve an element layer priority (from an app perspective more than the element priority itself as that is a bit of an implementation detail in the end). Port tests to it
-
-
-
Keeping it internal And add an internal method to get layer priority for GESTimelineElements (dirty implementation to make it simple for now)
-
-
-
-
It will just happen from the context
-
So error out when that happens.
-
And should not be advertised as if the operation failed.
-
-
Just an helper method to get the 'priority of a the clip'
-
And fix unit tests to match the correct behaviour
-
-
And make re add them in the same order. And enhance tests to check that
-
-
Thibault Saunier authored
-
Thibault Saunier authored
Otherwise there is a race where we trigger the seek at the exact same time the composition is being teared down potentially leading to basesrc restarting its srcpad task which ends up being leaked. Fixes ges.playback.scrub_backward_seeking.test_title.audio_video.vorbis_theora_ogg and probably all its friends timeouting with the following stack trace: (gdb) t a a bt Thread 4 (Thread 0x7f5962acd700 (LWP 19997)): #0 0x00007f5976713efd in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f5976a9d3f3 in g_cond_wait (cond=cond@entry=0x7f5938125410, mutex=mutex@entry=0x7f59381253c8) at gthread-posix.c:1402 #2 0x00007f5976c9e26b in gst_task_func (task=0x7f59381253b0 [GstTask]) at ../subprojects/gstreamer/gst/gsttask.c:313 #3 0x00007f5976a7ecb3 in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307 #4 0x00007f5976a7e2aa in g_thread_proxy (data=0x7f5954071d40) at gthread.c:784 #5 0x00007f59767ea58e in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007f59767196a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f5963fff700 (LWP 19995)): #0 0x00007f597670e421 in __GI___poll (fds=0xe32da0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f5976a553a6 in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0xe32da0, timeout=<optimized out>, context=0xe31ff0) at gmain.c:4221 #2 0x00007f5976a553a6 in g_main_context_iterate (context=0xe31ff0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3915 #3 0x00007f5976a55762 in g_main_loop_run (loop=0xe32130) at gmain.c:4116 #4 0x00007f59768db10a in gdbus_shared_thread_func (user_data=0xe31fc0) at gdbusprivate.c:275 #5 0x00007f5976a7e2aa in g_thread_proxy (data=0xe1b8a0) at gthread.c:784 #6 0x00007f59767ea58e in start_thread (arg=<optimized out>) at pthread_create.c:486 #7 0x00007f59767196a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f5968dcc700 (LWP 19994)): #0 0x00007f597670e421 in __GI___poll (fds=0xe1bcc0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f5976a553a6 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0xe1bcc0, timeout=<optimized out>, context=0xe1b350) at gmain.c:4221 #2 0x00007f5976a553a6 in g_main_context_iterate (context=context@entry=0xe1b350, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3915 #3 0x00007f5976a554d0 in g_main_context_iteration (context=0xe1b350, may_block=may_block@entry=1) at gmain.c:3981 #4 0x00007f5976a55521 in glib_worker_main (data=<optimized out>) at gmain.c:5861 #5 0x00007f5976a7e2aa in g_thread_proxy (data=0xe1b800) at gthread.c:784 #6 0x00007f59767ea58e in start_thread (arg=<optimized out>) at pthread_create.c:486 #7 0x00007f59767196a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f5975df4fc0 (LWP 19993)): #0 0x00007f5976713efd in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f5976a9d3f3 in g_cond_wait (cond=cond@entry=0xe34020, mutex=0xe39b80) at gthread-posix.c:1402 #2 0x00007f5976a7f41c in g_thread_pool_free (pool=0xe34000, immediate=0, wait_=<optimized out>) at gthreadpool.c:776 #3 0x00007f5976c9f1ca in default_cleanup (pool=0xe256b0 [GstTaskPool]) at ../subprojects/gstreamer/gst/gsttaskpool.c:89 #4 0x00007f5976c9e32d in init_klass_pool (klass=<optimized out>) at ../subprojects/gstreamer/gst/gsttask.c:161 #5 0x00007f5976c9e502 in gst_task_cleanup_all () at ../subprojects/gstreamer/gst/gsttask.c:381 #6 0x00007f5976c214f4 in gst_deinit () at ../subprojects/gstreamer/gst/gst.c:1095 #7 0x000000000040394f in main (argc=6, argv=<optimized out>) at ../subprojects/gst-editing-services/tools/ges-launch.c:94
-
Thibault Saunier authored
-
- Mar 14, 2019
-
-
To allow 'reintrancy'. This was a 'regression' introduced in bad64296 Fixes https://gitlab.gnome.org/GNOME/pitivi/issues/2278
-
- Mar 12, 2019
-
-
-
-
-
-
Add some init/deinit related comment and make assertion when ges_deinit() is called from unexpected thread.
-
- Mar 07, 2019
-
-
Avoiding a g_critical
-
- Mar 06, 2019
-
-
This commit is to ensure cleanup internal elements on state change failure. nlecomposition posts its own error message after cleanup child. If we don't suppress child error, meanwhile, an application triggered downward state change (resulting from child error message) might be able to reach nlecomposition before internal cleaning child up. That eventually results to downward state change failure.
-
-
This will result in downward state change failure eventually when user is finalizing top level (i.g., gespipeline) bin.
-