GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T12:20:55Zhttps://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.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/2PiTiVi core does not handle playing audio clips properly at non-native speeds.2021-09-24T12:20:46ZBugzilla Migration UserPiTiVi core does not handle playing audio clips properly at non-native speeds.## Submitted by Brandon Lewis
**[Link to original bug (#636235)](https://bugzilla.gnome.org/show_bug.cgi?id=636235)**
## Description
In theory the only thing required to cause a clip to play back at a speed greater than or less than...## Submitted by Brandon Lewis
**[Link to original bug (#636235)](https://bugzilla.gnome.org/show_bug.cgi?id=636235)**
## Description
In theory the only thing required to cause a clip to play back at a speed greater than or less than it's native rate is to set the media duration to something other than the duration.
To test this I created a pitivi project file (attached) with a single clip and then hand-edited the media duration of the clip such that it should play at 50% speed. While the video portion of the clip does seem to slow down, the audio continues to play back at its normal rate. There are plenty of other issues besides, but the playback issue mystifies me because a simple test script (also attached) is actually able to adjust playback speed using this method.
### Blocking
* [Bug 593828](https://bugzilla.gnome.org/show_bug.cgi?id=593828)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/1Looping feature for gnlobject2021-09-24T12:20:46ZBugzilla Migration UserLooping feature for gnlobject## Submitted by Laszlo Pandy
**[Link to original bug (#370836)](https://bugzilla.gnome.org/show_bug.cgi?id=370836)**
## Description
Currently, making loops using gnonlin requires making many gnlsources and placing them one after ano...## Submitted by Laszlo Pandy
**[Link to original bug (#370836)](https://bugzilla.gnome.org/show_bug.cgi?id=370836)**
## Description
Currently, making loops using gnonlin requires making many gnlsources and placing them one after another in the timeline. This is not optimal because the creation of many gnlsources will use more resources than necessary, and to move or change the source would require updating all the gnlsources. Gnlobject should handle looping by itself like so:
1. Create a gnlfilesource and set media-start to 0, media-stop to 5.
2. Set start to 0 and duration to 15.
3. Now when playing, the section of the file frrm 0 to 5 seconds should be played 3 times.
In other words, when the gnlfilesource reaches media-stop (at 5 seconds), it should go back to media-start (0 seconds) and play the file again. This is repeated until duration is exceeded, at which point the gnlfilesource will be silent.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/321basesrc: Allow for suppressing the initial negotiation2021-09-24T11:09:22ZBugzilla Migration Userbasesrc: Allow for suppressing the initial negotiation## Submitted by Carlos Rafael Giani
**[Link to original bug (#797332)](https://bugzilla.gnome.org/show_bug.cgi?id=797332)**
## Description
Run this example:
gst-launch-1.0 audiotestsrc ! "audio/x-raw,rate=44100" ! interaudiosin...## Submitted by Carlos Rafael Giani
**[Link to original bug (#797332)](https://bugzilla.gnome.org/show_bug.cgi?id=797332)**
## Description
Run this example:
gst-launch-1.0 audiotestsrc ! "audio/x-raw,rate=44100" ! interaudiosink interaudiosrc ! fakesink sync=true silent=false -v
We'd expect this to negotiate the downstream caps to 44100 Hz. This is also what happens - but initially, the caps are set to 48000 Hz instead. Here's the output:
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)ea61450f33201961286324e03482a1c5, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)2;) 0x7f0e5c004c20
/GstPipeline:pipeline0/GstInterAudioSrc:interaudiosrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, rate=(int)48000, channels=(int)2, layout=(string)interleaved
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ rate\=\(int\)48000\,\ channels\=\(int\)2\,\ layout\=\(string\)interleaved";) 0x7f0e5c004c90
/GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
/GstPipeline:pipeline0/GstInterAudioSink:interaudiosink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstInterAudioSrc:interaudiosrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";) 0x7f0e5c004d00
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0x7f0e5c004de0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = preroll *******
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2400 bytes, dts: none, pts: 0:00:00.000470130, duration: 0:00:00.027210884, offset: 0, offset_end: 1200, flags: 00004840 discont gap tag-memory , meta: none) 0x7f0e540086b0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2204 bytes, dts: none, pts: 0:00:00.027681014, duration: 0:00:00.024988662, offset: 1200, offset_end: 2302, flags: 00000000 , meta: none) 0x7f0e540087c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2204 bytes, dts: none, pts: 0:00:00.052669676, duration: 0:00:00.024988662, offset: 2302, offset_end: 3404, flags: 00000000 , meta: none) 0x7f0e540088d0
The reason for these initial 48000 Hz is that right at the beginning, basesrc tries to come up with fixated src caps. However, at that point, interaudiosrc does not have the actual caps yet (that is, the caps for the data that comes from interaudiosink). So, instead, interaudiosrc's fixate() function is called to fixate the template caps. The interaudiosrc.c fixate function contains this line:
gst_structure_fixate_field_nearest_int (structure, "rate", 48000);
This is not a bug in interaudiosrc. Rather, the basesrc class tries to output a caps event too early. It would be better if it were possible to inform basesrc that the srccaps will be known later, and that until then, it should not try to push a caps event downstream. It would be good to add functions to the API for this purpose.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/317basetransform: In in-place/passthrough mode assumes that subclass handles all...2023-06-16T22:21:22ZBugzilla Migration Userbasetransform: In in-place/passthrough mode assumes that subclass handles all possible metas## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797199)](https://bugzilla.gnome.org/show_bug.cgi?id=797199)**
## Description
Because the allocation query from upstream is just passed through in that case.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797199)](https://bugzilla.gnome.org/show_bug.cgi?id=797199)**
## Description
Because the allocation query from upstream is just passed through in that case.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/315Netbeans and gstreamer - adding gst variable to windows2022-11-10T09:20:51ZBugzilla Migration UserNetbeans and gstreamer - adding gst variable to windows## Submitted by Olda
**[Link to original bug (#797166)](https://bugzilla.gnome.org/show_bug.cgi?id=797166)**
## Description
Created attachment 373691
My system variables
Hello, I hope this would not be stupid question :)
F...## Submitted by Olda
**[Link to original bug (#797166)](https://bugzilla.gnome.org/show_bug.cgi?id=797166)**
## Description
Created attachment 373691
My system variables
Hello, I hope this would not be stupid question :)
First of all I´m sorry for my english - it´s a long time since I was in school.
I tried to use gstreamer in netbeans on windows (C/C++). When I compile my project on raspbian (RPI3 B+), everything is fine, but on local machine (windows) netbeans can not include gst/gst.h.
I installed gstreamer devel package and I don´t see in my system variables enviroment (in "path") nothing connected with gsteamer. I have read in documentation that gstreamer installer will add system variable path...
So I thought that I should add gstreamer library as pkg package, but windows doesn´t have any gstreamer variable.
I´d like to ask - how can I use gstreamer in netbeans? I did not find solution on google, so I think that this error is not common.
Thank you
Olda
**Attachment 373691**, "My system variables":
![system_variables](/uploads/67e04c5c56c7a6bdf9d1023c60f7a3ee/system_variables.png)