GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T12:20:58Zhttps://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/25ges:tests:validate: Add tests disabling mixing in the default testsuite2021-09-24T12:20:58ZBugzilla Migration Userges:tests:validate: Add tests disabling mixing in the default testsuite## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#765935)](https://bugzilla.gnome.org/show_bug.cgi?id=765935)**
## Description
We should test that GES is useable even when disable mixing, meaning that
Gst el...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#765935)](https://bugzilla.gnome.org/show_bug.cgi?id=765935)**
## Description
We should test that GES is useable even when disable mixing, meaning that
Gst elements, and in particular demuxers properly handle seqnums as NLE
intensively relies on them to thread safely know when a sub pipeline is
EOS.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/23GESPipeline fails to change state in case of errors in timeline2021-09-24T12:20:57ZBugzilla Migration UserGESPipeline fails to change state in case of errors in timeline## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#753883)](https://bugzilla.gnome.org/show_bug.cgi?id=753883)**
## Description
Created attachment 309729
empty project
If GESProject contains some specific errors o...## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#753883)](https://bugzilla.gnome.org/show_bug.cgi?id=753883)**
## Description
Created attachment 309729
empty project
If GESProject contains some specific errors or is empty (like in attachment), and on project "loaded" I say GESPipeline (which should play Timeline I extracted) to change state to PLAY, it only changes state to READY and then no action is performed asynchronously (thread pool relaxing).
gst_element_get_state, however waits infinitely (in case timeout is -1).
**Attachment 309729**, "empty project":
[empty.xges](/uploads/de6988f9ec95b74e403f2baffdc10ffe/empty.xges)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/22clipoverlay: Make sure priorities of Textoverlays are always higher than the ...2021-09-24T12:20:56ZBugzilla Migration Userclipoverlay: Make sure priorities of Textoverlays are always higher than the sources they are overlayed on## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#750644)](https://bugzilla.gnome.org/show_bug.cgi?id=750644)**
## Description
Currently the user has to always make sure an overlay has a source to apply on (ad...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#750644)](https://bugzilla.gnome.org/show_bug.cgi?id=750644)**
## Description
Currently the user has to always make sure an overlay has a source to apply on (adding overlayclip on a layer with higher prio), and it has to make sure that it has a source to be applied on.
We should at least detect it and warn the user.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/21Playing timeline glitches when adding new asset2021-09-24T12:20:56ZBugzilla Migration UserPlaying timeline glitches when adding new asset## Submitted by Isaac Smith
**[Link to original bug (#747417)](https://bugzilla.gnome.org/show_bug.cgi?id=747417)**
## Description
Created attachment 301027
Bug example
When adding an asset to a playing GES timeline the video...## Submitted by Isaac Smith
**[Link to original bug (#747417)](https://bugzilla.gnome.org/show_bug.cgi?id=747417)**
## Description
Created attachment 301027
Bug example
When adding an asset to a playing GES timeline the video and audio output freeze for 1/10 of a second, annoyingly. The call to add_asset returns immediately, so the hiccup doesn't seem to be coming from my app's main thread. The attached Python code demonstrates the bug.
**Attachment 301027**, "Bug example":
[test.py](/uploads/14d5cbcd70c761a7c51a852f90a37783/test.py)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/20pipeline: Handle the case were we are still loading the project and the user ...2021-09-24T12:20:56ZBugzilla Migration Userpipeline: Handle the case were we are still loading the project and the user tries to set its state to PLAYING/PAUSED.## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#743938)](https://bugzilla.gnome.org/show_bug.cgi?id=743938)**
## Description
I want to use GESProject and GESPipeline to render .xges file into the .webm one. My code lo...## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#743938)](https://bugzilla.gnome.org/show_bug.cgi?id=743938)**
## Description
I want to use GESProject and GESPipeline to render .xges file into the .webm one. My code looks like this:
...
project = ges_project_new(uri); /// URI of XGES file
GESTimeline *timeline =
GES_TIMELINE(ges_asset_extract(GES_ASSET(project), &error));
if (error)
...
/// I handle error here
...
else
{
pipeline = ges_pipeline_new();
ges_pipeline_set_timeline(pipeline, timeline);
gchar *uri = g_strdup_printf("file://" RAMFS_PATH "t%"
G_GUINT64_FORMAT ".webm", operation_identifier); /// Yet another URI: .webm
file where output should be directed
ges_pipeline_set_render_settings(pipeline, uri,
GST_ENCODING_PROFILE(encoding_profile)); /// WebM with vp8 and Vorbis
g_free(uri);
ges_pipeline_set_mode(pipeline, GES_PIPELINE_MODE_RENDER);
...
/// Here I attach some stuff to bus to handle errors, eos, etc.
...
gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PLAYING);
...
I face a problem causing pipeline to work infinte time without sending error or EOS messages to bus. It happens first time I run pipeline. Second (and subsequent) pipelines seem to work without this error (or at least it becames rare). With gst-editing-services from git master error looks like this:
ERROR nlecomposition nle/nlecomposition.c:2524:_relink_children_recursively: Not enough sinkpads to link all objects to the operation ! 1 / 0
ERROR nlecomposition nle/nlecomposition.c:2527:_relink_children_recursively: Operation has no child objects to be connected to !!!
In GES 1.4.0 error looks a bit different:
ERROR gnlcomposition gnlcomposition.c:2385:compare_relink_single_node: Not enough sinkpads to link all objects to the operation ! 2 / 0
ERROR gnlcomposition gnlcomposition.c:2387:compare_relink_single_node: Operation has no child objects to be connected to !!!https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/19formatter: Add a way to serialize encoder setting in the formatted projects f...2021-09-24T12:20:55ZBugzilla Migration Userformatter: Add a way to serialize encoder setting in the formatted projects files## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#742379)](https://bugzilla.gnome.org/show_bug.cgi?id=742379)**
## Description
Steps to reproduce:
- Create a project, add a video to the timeline
- Open the render...## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#742379)](https://bugzilla.gnome.org/show_bug.cgi?id=742379)**
## Description
Steps to reproduce:
- Create a project, add a video to the timeline
- Open the render dialog, choose x264 and in advanced settings specify "Constant Quality" instead of "Constant Bitrate"
- Save the project, close the app, reopen it, load the project, notice the setting is lost.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/18ges formatter: Load and save children properties from track elements2021-09-24T12:20:55ZBugzilla Migration Userges formatter: Load and save children properties from track elements## Submitted by Lubosz Sarnecki
**[Link to original bug (#737744)](https://bugzilla.gnome.org/show_bug.cgi?id=737744)**
## Description
Created attachment 287539
This patch enables the formatter to load and store children propertie...## Submitted by Lubosz Sarnecki
**[Link to original bug (#737744)](https://bugzilla.gnome.org/show_bug.cgi?id=737744)**
## Description
Created attachment 287539
This patch enables the formatter to load and store children properties on track elements.
The ges-base-xml-formatter.c is currently unable to load and store children-properties from track elements.
This is needed to store and load position and size from clips, like in this xges example:
http://wiki.pitivi.org/wiki/XGES_Examples#Clip_Position_and_Size
A track element is described with a `<source>` XML tag. The example does not work without these patches, and Pitivi is not able to store values on track elements. There is no other way to manipulate the dimension of the clip in ges.
This is a series of patches written by Joris Valette.
He published them in following Github ticktes:
https://github.com/pitivi/gst-editing-services/issues/54
https://github.com/pitivi/gst-editing-services/issues/56
Since these patches never made it through code review, I am willing to improve them so they can get merged.
**Patch 287539**, "This patch enables the formatter to load and store children properties on track elements.":
[0001-formatter-save-and-load-source-s-children-properties.patch](/uploads/4cf7166824181cbb707e0a9ddfe8993b/0001-formatter-save-and-load-source-s-children-properties.patch)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/17timeline: add API to get sources neighbouring a position.2021-09-24T12:20:53ZBugzilla Migration Usertimeline: add API to get sources neighbouring a position.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#737504)](https://bugzilla.gnome.org/show_bug.cgi?id=737504)**
## Description
My use case was removing gaps in a timeline, the least complex algorithm I came up wit...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#737504)](https://bugzilla.gnome.org/show_bug.cgi?id=737504)**
## Description
My use case was removing gaps in a timeline, the least complex algorithm I came up with was : find out if a clip overlaps with other clips, if not find the next source and ripple it towards you.
These functions implement the second step correctly with a low complexity (not very theoretically versed but we use a sequence_search so I would guess a logarithmic complexity).
The new API is generic enough (allows to filter by track types and search for either clips ending or starting before or after you), and can come in pretty handy for script writers (or plugin writers for pitivi).
It is extensively tested and the tests obviously pass :)
In the future we could reuse these functions to handle the snapping mechanism internally.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/16Gracefully handle the fact that some encoder can not change their colorspace ...2021-09-24T12:20:53ZBugzilla Migration UserGracefully handle the fact that some encoder can not change their colorspace at the middle of the stream## Submitted by Lubosz Sarnecki
**[Link to original bug (#733565)](https://bugzilla.gnome.org/show_bug.cgi?id=733565)**
## Description
Created attachment 281393
xges to reproduce the bug.
GES cannot render pipelines which con...## Submitted by Lubosz Sarnecki
**[Link to original bug (#733565)](https://bugzilla.gnome.org/show_bug.cgi?id=733565)**
## Description
Created attachment 281393
xges to reproduce the bug.
GES cannot render pipelines which contain a PNG. The behavior is different for different encoders and muxers.
The playback of the timeline is fine.
ogg/theora: corrupted buffers are stored instead of the PNG. Rendering finished.
webm/vp8: works
qt/h264: rendering stops at the position where image and video meet.
These clip layouts do not work:
[ video ][ png ]
[ png ][ video ]
This works:
[ png ]
JPEG also works.
For the quicktime / h264 case, where the pipeline times out, this is printed in the debug log in a infinite loop, when the timeline "stops":
FIXME bin gstbin.c:4023:gst_bin_query: implement duration caching in GstBin again
The quicktime muxer produces following warning:
WARN qtmux gstqtmux.c:3253:gst_qt_mux_video_sink_set_caps:`<muxer>` pad video_0 refused renegotiation to video/x-h264, ...
**Attachment 281393**, "xges to reproduce the bug.":
[video-after-png.xges](/uploads/cc892d327f5ae65d15355c5033346507/video-after-png.xges)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/15[pitivi] Temporary live playback restriction caps2021-09-24T12:20:52ZBugzilla Migration User[pitivi] Temporary live playback restriction caps## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#731373)](https://bugzilla.gnome.org/show_bug.cgi?id=731373)**
## Description
In Pitivi, we encounter the usecase where we would need to downscale videos during li...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#731373)](https://bugzilla.gnome.org/show_bug.cgi?id=731373)**
## Description
In Pitivi, we encounter the usecase where we would need to downscale videos during live playback, so that they are only processed at the resolution of UI widget displaying the sink/previewer.
This approach has been demonstrated to significantly improve performance when applying effects on top of HD footage, with this proof of concept branch branch:
https://github.com/nekohayo/pitivi/commits/low-quality-preview
GES provides a set_restriction_caps method for tracks, allowing to set a width and height to clamp to. However, this API is insufficient because it was made to set permanent restriction caps (ex: rendering resolution scaling) and they get saved into the file format. Notwithstanding the fact that it interferes with the real rendering restriction caps, trying to manage this temporary stuff in Pitivi means piles upon piles of nasty hacks that conflict with each other.
- Trying to work around the current API means tracking the state globally, setting restriction caps only in certain situations and then trying to surgically remove them right before rendering and right before any project file saving. This doesn't work.
- Changes to restriction caps will make the pipeline go to pause. Since Pitivi autosaves a backup copy of the GES Project periodically, and GES serializes the restriction caps, Pitivi will uncontrollably stop playback whenever an automatic backup file save occurs.
Hence I have come to the conclusion that trying to work around this in Pitivi is impossible and that it is the responsibility of GES to provide a way to (un)set temporary/live/playback restriction caps globally. You need to be able to (un)inhibit those playback restriction caps (easily toggle them on/off) at any time, and since they're UI-dependent (they don't make sense outside of this context), they should never be saved into the project file.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/14Allow custom transitions2021-09-24T12:20:52ZBugzilla Migration UserAllow custom transitions## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#724744)](https://bugzilla.gnome.org/show_bug.cgi?id=724744)**
## Description
For example one might want to specify a PNG where the light intensity represents how the ...## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#724744)](https://bugzilla.gnome.org/show_bug.cgi?id=724744)**
## Description
For example one might want to specify a PNG where the light intensity represents how the transition advances.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/13GES needs a ges_clip_find_all_track_elements function2021-09-24T12:20:51ZBugzilla Migration UserGES needs a ges_clip_find_all_track_elements function## Submitted by Kim Lam
**[Link to original bug (#719878)](https://bugzilla.gnome.org/show_bug.cgi?id=719878)**
## Description
In order to set volume and mute state for a clip with Dual Mono audio a ges_clip_find_all_track_elements ...## Submitted by Kim Lam
**[Link to original bug (#719878)](https://bugzilla.gnome.org/show_bug.cgi?id=719878)**
## Description
In order to set volume and mute state for a clip with Dual Mono audio a ges_clip_find_all_track_elements is needed. Dual Mono files produces two audio track elements.
Something like the code below would work, but there's probably a more efficient way, since most of code is taken from ges_clip_find_track_element.
GList *
ges_clip_find_all_track_elements (GESClip * clip, GESTrack * track, GType type)
{
GList *tmp;
GESTrackElement *otmp;
GESTrackElement *foundElement;
GList *ret = NULL;
g_return_val_if_fail (GES_IS_CLIP (clip), NULL);
g_return_val_if_fail (!(track == NULL && type == G_TYPE_NONE), NULL);
for (tmp = GES_CONTAINER_CHILDREN (clip); tmp; tmp = g_list_next (tmp)) {
otmp = (GESTrackElement *) tmp->data;
if ((type != G_TYPE_NONE) && !G_TYPE_CHECK_INSTANCE_TYPE (tmp->data, type))
continue;
if ((track == NULL) || (ges_track_element_get_track (otmp) == track)) {
foundElement = GES_TRACK_ELEMENT (tmp->data);
gst_object_ref (foundElement);
ret = g_list_append(ret,foundElement);
}
}
return ret;
}
Version: 1.2.0https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/12Properly document how videomixing works2021-09-24T12:20:50ZBugzilla Migration UserProperly document how videomixing works## Submitted by Kim Lam
**[Link to original bug (#712714)](https://bugzilla.gnome.org/show_bug.cgi?id=712714)**
## Description
I am trying to display one video frame ontop (spatially) of a second video frame. The behavior of the sma...## Submitted by Kim Lam
**[Link to original bug (#712714)](https://bugzilla.gnome.org/show_bug.cgi?id=712714)**
## Description
I am trying to display one video frame ontop (spatially) of a second video frame. The behavior of the smart-mixer is interfering with this, because it is resizing the video frame whenever a timeline commit occurs. It would be nice to be able to fix the size of the output canvas in which video frames are drawn on. This would be useful for compositing from multiple video sources.
Version: 1.2.0https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/10[pitivi] After an async discovery is done, emit a signal with missing codecs ...2021-09-24T12:20:50ZBugzilla Migration User[pitivi] After an async discovery is done, emit a signal with missing codecs to install## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#686181)](https://bugzilla.gnome.org/show_bug.cgi?id=686181)**
## Description
GES will need to do the clip discovery for us, maintain the list of clips in a given ...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#686181)](https://bugzilla.gnome.org/show_bug.cgi?id=686181)**
## Description
GES will need to do the clip discovery for us, maintain the list of clips in a given project's library, but it should also tell us what codecs are missing so we can trigger the gstreamer codec installation dialog (if that thing still exists).
Version: 1.x
### Blocking
* [Bug 686182](https://bugzilla.gnome.org/show_bug.cgi?id=686182)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/9[pitivi] Support the notion of placeholder/empty clips and allow manually swa...2021-09-24T12:20:48ZBugzilla Migration User[pitivi] Support the notion of placeholder/empty clips and allow manually swapping clips## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#676388)](https://bugzilla.gnome.org/show_bug.cgi?id=676388)**
## Description
Let's say we have a project with clips A, B, C, that are all in the source list (piti...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#676388)](https://bugzilla.gnome.org/show_bug.cgi?id=676388)**
## Description
Let's say we have a project with clips A, B, C, that are all in the source list (pitivi's media library) and in the timeline.
For some reason, clip B is temporarily unavailable on the hard drive or the user has deleted it.
AFAICT, currently there is no mechanism to handle this; either the project loads fully with all related media, or it fails completely.
Ideally, we should allow loading a project and, if the user cannot immediately provide a replacement for the missing clip "B", tell the application that this clip B is to be considered a placeholder. Then, the application could show it as such in its media library and in the timeline.
Later on, the user could either delete the placeholder or provide a replacement for it (ex: right click, -> "Replace clip...").https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/8[pitivi] EDL (Edit Decision List) export2021-09-24T12:20:48ZBugzilla Migration User[pitivi] EDL (Edit Decision List) export## Submitted by moh..@..il.com
**[Link to original bug (#674605)](https://bugzilla.gnome.org/show_bug.cgi?id=674605)**
## Description
EDL (Edit decision list) is the most and ancient form of getting footage from and to other Editing...## Submitted by moh..@..il.com
**[Link to original bug (#674605)](https://bugzilla.gnome.org/show_bug.cgi?id=674605)**
## Description
EDL (Edit decision list) is the most and ancient form of getting footage from and to other Editing Applications. EDL import and export feature is available in all the editing application incl cinelerra(import & export), Blender (import). It would be very helpful if this feature be included in Pitivi. As Pitivi gives realtime playback of H.264 AVCHD Material it would be great if this feature been implemented. Right Now i am doing Cinelerra with Lot of Proxy files. Cinelerra has got EDL out hence doing in it. If this feature implemented in Pitivi I could edit and deliver EDL for Autodesk Smoke/ Blender users for Advanced Color Grading / VFX works. Please consider this request. I think implementing EDL isn't that impossible to do.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/7Ability to import and export project tarballs2021-09-24T12:20:48ZBugzilla Migration UserAbility to import and export project tarballs## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#673386)](https://bugzilla.gnome.org/show_bug.cgi?id=673386)**
## Description
In [bug 668028](https://bugzilla.gnome.org/show_bug.cgi?id=668028) we implemented the...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#673386)](https://bugzilla.gnome.org/show_bug.cgi?id=673386)**
## Description
In [bug 668028](https://bugzilla.gnome.org/show_bug.cgi?id=668028) we implemented the ability for pitivi to export project files and associated media as a tarball.
Ideally, GES should allow that in its formaters and allow importing directly from a tarball (no need for the user to manually extract from the tarball, to load the project and to run the missing clips URI search thing).https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/6Support relative paths to media files2021-09-24T12:20:47ZBugzilla Migration UserSupport relative paths to media files## Submitted by fh@..@..bix.de
**[Link to original bug (#668501)](https://bugzilla.gnome.org/show_bug.cgi?id=668501)**
## Description
I just came to the point where I wanted to make my PiTiVi Project with all resources publicly avai...## Submitted by fh@..@..bix.de
**[Link to original bug (#668501)](https://bugzilla.gnome.org/show_bug.cgi?id=668501)**
## Description
I just came to the point where I wanted to make my PiTiVi Project with all resources publicly available by putting all the files into a zip or tar archive. But after looking into the xptv file that PTV created and modifying the paths so they are relative to the project file, I got import errors.
Would be a nice idea to make those xptv files portable, huh?https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/5Import animated GIF files2021-09-24T12:20:47ZBugzilla Migration UserImport animated GIF files## Submitted by Laurent Pointecouteau
**[Link to original bug (#665636)](https://bugzilla.gnome.org/show_bug.cgi?id=665636)**
## Description
Currently, PiTiVi can import GIF files, but cannot render a video showing an animated GIF. ...## Submitted by Laurent Pointecouteau
**[Link to original bug (#665636)](https://bugzilla.gnome.org/show_bug.cgi?id=665636)**
## Description
Currently, PiTiVi can import GIF files, but cannot render a video showing an animated GIF. It would be nice to support that, instead of importing each frame of the GIF and trying to re-create the animation at hand.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/4Tests for huge timelines in the integration test suite2021-09-24T12:20:46ZBugzilla Migration UserTests for huge timelines in the integration test suite## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#664222)](https://bugzilla.gnome.org/show_bug.cgi?id=664222)**
## Description
The huge amount of rendering bugs in pitivi prompts for some more solid automated tor...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#664222)](https://bugzilla.gnome.org/show_bug.cgi?id=664222)**
## Description
The huge amount of rendering bugs in pitivi prompts for some more solid automated torture testing. Hopefully, the simpler use cases might be solved by the port to GES, but there remains a need for testing "serious business" projects. While rare, it is not unusual to hear reports of users trying to deal with hundreds of clips or very long timelines, and running into kernel limitations, hangs/crashes or memory problems.
For GES to be considered ready for serious production needs, we would need some test suite (using "insanity" to complement the existing "nekohayo"?) to run at least the following scenarios:
- a timeline with 2000 different clips
- a timeline with a couple of multi-gigabyte files
- feature-length projects (timelines that are 1-3 hours long)
Tests should ensure that those timelines render flawlessly, and could also profile loading times, seeking times, memory usage, etc.