gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-09-24T11:10:33Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/149baseparse: Need push remaining data in adapter when switching to pass through...2021-09-24T11:10:33ZBugzilla Migration Userbaseparse: Need push remaining data in adapter when switching to pass through mode## Submitted by Lyon
**[Link to original bug (#760513)](https://bugzilla.gnome.org/show_bug.cgi?id=760513)**
## Description
When we are trying to play some h264/avi streams, with our own parser plugin linked with h264parse and then...## Submitted by Lyon
**[Link to original bug (#760513)](https://bugzilla.gnome.org/show_bug.cgi?id=760513)**
## Description
When we are trying to play some h264/avi streams, with our own parser plugin linked with h264parse and then avdec_h264, there will be some corrupt video be observed. while using avidemux link with h264parse, it plays well.
After doing some investigation.
- avdec_h264 only support alignment au format.
- and avidemux output caps not specify the alignment as "au"
So h264parse will do the parse to convert alignment to "au"
- however, when using our own parser plugin, the output plugins already set the video as alignment "au", so that h264parse work in pass through mode.
But it seems the h264parse's output lost the sps/pps data in the begging, which cause the video decoding error for some frames.
So it maybe bugs in h264parse pass through mode, suppose in pass through mode, the output should be the same as when h246parse not linked in the pipeline.
I'm not sure if this issue has been raised before, so I recorded the issue here
Thanks a lot ~
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/148[API] value, tag lists, caps: add pretty serialization2021-09-24T11:10:33ZBugzilla Migration User[API] value, tag lists, caps: add pretty serialization## Submitted by Tim Müller `@tpm`
**[Link to original bug (#760027)](https://bugzilla.gnome.org/show_bug.cgi?id=760027)**
## Description
Serialized caps or tags can at times be very very long if they contain large buffers, e.g. if s...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#760027)](https://bugzilla.gnome.org/show_bug.cgi?id=760027)**
## Description
Serialized caps or tags can at times be very very long if they contain large buffers, e.g. if streamheaders include coverart.
It would be nice if we had API for 'pretty' serialization of values, tags, caps, structures, etc, so we can use shortened versions in more places including logs and dot files.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/147collectpads: Cannot use GST_STREAM_FLAG_SPARSE with mpegtsmux2022-11-10T09:20:46ZBugzilla Migration Usercollectpads: Cannot use GST_STREAM_FLAG_SPARSE with mpegtsmux## Submitted by Alexander Vasiljev
**[Link to original bug (#759807)](https://bugzilla.gnome.org/show_bug.cgi?id=759807)**
## Description
Setting GST_STREAM_FLAG_SPARSE to one of inputs of mpegtsmux stops both input streams.
Ma...## Submitted by Alexander Vasiljev
**[Link to original bug (#759807)](https://bugzilla.gnome.org/show_bug.cgi?id=759807)**
## Description
Setting GST_STREAM_FLAG_SPARSE to one of inputs of mpegtsmux stops both input streams.
May be the cause is in libs/gst/base/gstcollectpads.c
Here is a patch. With this patch GST_STREAM_FLAG_SPARSE works as expected.
diff --git a/libs/gst/base/gstcollectpads.c b/libs/gst/base/gstcollectpads.c
index 8edfe41..14f9926 100644
--- a/libs/gst/base/gstcollectpads.c
+++ b/libs/gst/base/gstcollectpads.c
@@ -1440,7 +1440,8 @@ gst_collect_pads_recalculate_waiting (GstCollectPads * pads)
if (!GST_COLLECT_PADS_STATE_IS_SET (data, GST_COLLECT_PADS_STATE_WAITING)) {
/* start waiting */
gst_collect_pads_set_waiting (pads, data, TRUE);
- result = TRUE;
+ if (!GST_COLLECT_PADS_STATE_IS_SET (data, GST_COLLECT_PADS_STATE_LOCKED))
+ result = TRUE;
}
}
}
Version: 1.6.2https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/146basesink: seeking issue when async is set to false2022-11-10T09:20:46ZBugzilla Migration Userbasesink: seeking issue when async is set to false## Submitted by Eunhae Choi
**[Link to original bug (#759730)](https://bugzilla.gnome.org/show_bug.cgi?id=759730)**
## Description
If I set the async property to false of sink element, seeking does not works well.
Forward seeki...## Submitted by Eunhae Choi
**[Link to original bug (#759730)](https://bugzilla.gnome.org/show_bug.cgi?id=759730)**
## Description
If I set the async property to false of sink element, seeking does not works well.
Forward seeking seems like okey but backward seeking does not work.
You can check the issue with gst-play-1.0.
# gst-play-1.0 /home/eunhye/content/mp3/piano.mp3 --audiosink="pulsesink async=false"
Thank you.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/145gst_element_lost_state() interfers with base-time resetting of later gst_elem...2021-09-24T11:10:34ZBugzilla Migration Usergst_element_lost_state() interfers with base-time resetting of later gst_element_set_state()## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759604)](https://bugzilla.gnome.org/show_bug.cgi?id=759604)**
## Description
Created attachment 317583
testcase
Consider the following situation in a pipeline...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759604)](https://bugzilla.gnome.org/show_bug.cgi?id=759604)**
## Description
Created attachment 317583
testcase
Consider the following situation in a pipeline with `async=true` sinks:
1) `gst_element_lost_state()` due to flushing for whatever reason
2) `gst_element_set_state(PAUSED)` on the pipeline due to `BUFFERING`<100% before 1) finished to put the pipeline to `PLAYING` again
3) `gst_element_set_state(PLAYING)` on the pipeline much later because `BUFFERING`==100%
What will happen here is that 1) does a "state change" without going through the `GstElement::change_state()` machinery and as such no start_time will be set. It will update current/next/pending state to `PAUSED` and target state stays at `PLAYING`. 2) will then immediately return and only update the target state to `PAUSED` but nothing will go through `GstElement::change_state()` anywhere. Later 3) will change the state to `PLAYING` again but `base_time` is not updated as in 1) and 2) the start_time was not set.
The effect of this is that the running time continued all the time the pipeline was buffering, and as such now everything that was buffered is most likely too late and will be dropped.
Note that similar code to `gst_element_lost_state()` is also in GstBin's `handle_async_start()`, which will cause the same problems if a child element is posting async-start messages. So this situation could also happen in pipelines where sinks are dynamically added.
`gst_element_lost_state()` (and the async-start handling in GstBin) intentionally does not update `start_time` as a) the clock might not work anymore at this point and b) the running time should continue if it can as losing state should just be something that happens very shortly and should not interrupt playback (e.g. of other pipeline branches inside the pipeline!).
Attached is a test application that reproduces this behaviour. Take a look at where the `LOST_STATE` #define is used to get an idea of the different variants that can happen, and which work and which don't.
I'm not sure how to fix this without breaking other things. IMHO for 2.0 we should clean up all this state change machinery a lot and make sure we have a sensible state machine again that does not come with weird non-states like the ones that currently happen when state is lost.
**Attachment 317583**, "testcase":
[test.c](/uploads/0914a21d8d3c02ecabed5c41d9f78d55/test.c)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/144input-selector element generates wrong DTS timestamps with sync-mode=0 and mu...2022-06-03T00:10:06ZBugzilla Migration Userinput-selector element generates wrong DTS timestamps with sync-mode=0 and multiple rtspsrc (same video format/framerates)## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframe...## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframes.
This causes input-selector to miss keyframe from rtspsrc and this causes additional delay (video is paused for 1second) during camera switching using input-selector.
Test case:
I have 5 ip cameras (all are rtspsrc element) and one audio src (rtspsrc)
All 5 ip cameras are connected with input-selector element and it switched from one camera to another camera.
My code works perfectly fine [1] : http://hastebin.com/raw/adatujewes
But there is one flaw in streaming. I am seeing a pause for 1 second whenever input-selector is switching between camera.
Look at timestamp 1min 12sec on my streaming video url which is using my binary generated from code [1]:
[2] https://www.youtube.com/watch?v=NPlN_3YhmrM
You will see cameras are switched every 5 seconds after 1:12 on that url [2] However, there is a pause of 1 second when camera switching happens,
I tried with changing delay of queue/ replacing queue with queue2/ making rtspsec latency=0 .
But nothing helps me .
Proposed Solution:
Fix input-selector element so that it can wait for keyframes before switching to live stream. This will give gapless video switching from input-selector element.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/143basesrc: When live, sending EOS after early runtime errors have no effect2021-09-24T11:10:35ZBugzilla Migration Userbasesrc: When live, sending EOS after early runtime errors have no effect## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#759033)](https://bugzilla.gnome.org/show_bug.cgi?id=759033)**
## Description
Filing against v4l2src for now, as it's the only src I found that could reproduce t...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#759033)](https://bugzilla.gnome.org/show_bug.cgi?id=759033)**
## Description
Filing against v4l2src for now, as it's the only src I found that could reproduce this.
gst-launch-1.0 -e v4l2src ! identity error-after=1 ! fakesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/142Use common connection-speed range for all elements2022-11-10T09:20:46ZBugzilla Migration UserUse common connection-speed range for all elements## Submitted by Athanasios Oikonomou
**[Link to original bug (#758916)](https://bugzilla.gnome.org/show_bug.cgi?id=758916)**
## Description
Currently there there are differences between elements with connection-speed property.
...## Submitted by Athanasios Oikonomou
**[Link to original bug (#758916)](https://bugzilla.gnome.org/show_bug.cgi?id=758916)**
## Description
Currently there there are differences between elements with connection-speed property.
There are three ranges in total, 0 to 2147483 mmssrc/4294967 dashdemux,hlsdemux,mssdemux/18446744073709551.
Is there a reason having connection-speed not as guint64?
Here are all elements with connection-speed property.
dashdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
decodebin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
hlsdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
mmssrc
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 2147483 Default: 0
mssdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
playbin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
rtspsrc
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
uridecodebin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/141Suggestion: new SEEKABLE event and/or message2022-03-04T19:47:48ZBugzilla Migration UserSuggestion: new SEEKABLE event and/or message## Submitted by Carlos Rafael Giani
**[Link to original bug (#758642)](https://bugzilla.gnome.org/show_bug.cgi?id=758642)**
## Description
Currently, when one wants to find out if a pipeline is seekable, it is necessary to send out ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#758642)](https://bugzilla.gnome.org/show_bug.cgi?id=758642)**
## Description
Currently, when one wants to find out if a pipeline is seekable, it is necessary to send out a seeking query, and parse its seekable flag. The problem with this is that it is not always clear when it should be done. In most cases, it should work when the pipeline reaches the PAUSED state, or in case of decodebin, when the pad-added callback is invoked.
However, sometimes, this won't work. One example are AIFF files. It is not known until later if the file is actually seekable. The seeking query will therefore fail (which does *not* mean that the file isn't seekable, it means it can't be determined, at least not at that time). So, one has to continually issue the seeking query until it no longer fails. No matter how (by using a timer, or by re-issuing the query before a seek attempt, or in a pad probe every time a buffer passes through for example), the result is suboptimal.
For this reason, I think it should be possible for elements to notify the pipeline and application that it is now known if seekable is possible or not. It could send some sort of serialized SEEKABLE event up- and downstream, with one boolean inside, "is seekable yes/no". Somewhere else (in sinks for example), the event could become a message. This way, both elements and the application get the update.
Thoughts?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/140Faulty annotation of gst_buffer_new_wrapped_full / gst_memory_new_wrapped2021-09-24T11:10:36ZBugzilla Migration UserFaulty annotation of gst_buffer_new_wrapped_full / gst_memory_new_wrapped## Submitted by Rico Tzschichholz `@ricotz`
**[Link to original bug (#758550)](https://bugzilla.gnome.org/show_bug.cgi?id=758550)**
## Description
The data length attribute should point to maxsize instead of size.
Afaiu the relati...## Submitted by Rico Tzschichholz `@ricotz`
**[Link to original bug (#758550)](https://bugzilla.gnome.org/show_bug.cgi?id=758550)**
## Description
The data length attribute should point to maxsize instead of size.
Afaiu the relation of those arguments is "size <= maxsize - offset".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/139tests: Fix spuriously failing netclientclock test on OSX2021-09-24T11:44:43ZBugzilla Migration Usertests: Fix spuriously failing netclientclock test on OSX## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758323)](https://bugzilla.gnome.org/show_bug.cgi?id=758323)**
## Description
On OSX, startup sync might take longer than what has been assumed in the test,
h...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758323)](https://bugzilla.gnome.org/show_bug.cgi?id=758323)**
## Description
On OSX, startup sync might take longer than what has been assumed in the test,
hence failing the test. OSX seems to be exposed to more OS scheduling jitter,
i.e. the observed RTTs take some time to be become stable enough.
As the comment in the original test says:
"can't in general make a precise assertion here, because this depends on
system load and a lot of things. however within half a second they should
at least be within 1/10 of a second of each other... "
IMO, if we can't make a precise assertion here, we shouldn't make it at all in
the unit test. See attached patch for a fix.
Related to this, here is the debug output of one of the observations being
dropped (originally causing the longer sync time on OSX):
`<netclientclock0>`
Dropping observation, long RTT 0:00:00.000977094 > 2 * avg 0:00:00.000182319
That shows that the RTT is of course very low (via localhost), but that this
observation is too far off the avg, likely because OS schedule jitter. slomo
(thanks for the analysis of the problem) suggested that maybe we can also
allow a higher deviation for RTTs lower than 1-2 ms. However, I am not
familiar enough with the netclientclock to write a patch for that/further
discuss if that makes sense or not. It would make the initial sync faster on
OSX in this case. Due to the dropped observations, sync can sometimes take
longer than 500ms on that platform. Does anybody have comments on that?
Anyway, IMO the test should be fixed nonetheless, patch is attached.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/138bufferpool config: function to remove an option in the config2021-09-24T11:10:37ZBugzilla Migration Userbufferpool config: function to remove an option in the config## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#757925)](https://bugzilla.gnome.org/show_bug.cgi?id=757925)**
## Description
The use case I have for this is if an element wants to override/perform the creation of...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#757925)](https://bugzilla.gnome.org/show_bug.cgi?id=757925)**
## Description
The use case I have for this is if an element wants to override/perform the creation of a meta on the buffer.
A simple solution of using gst_buffer_foreach_meta(); gst_buffer_remove_meta() will fail to remove any locked buffers that a bufferpool adds to the buffer. This makes it optional and possible for the meta to not appear on the buffer in the first place.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/137gstbaseparse buf DISCONT issue2022-11-10T09:20:46ZBugzilla Migration Usergstbaseparse buf DISCONT issue## Submitted by Lyon
**[Link to original bug (#757575)](https://bugzilla.gnome.org/show_bug.cgi?id=757575)**
## Description
When we are update gstreamer from 1.4.5 to 1.6, we found some clips with mp3 audio cannot be played.
So we...## Submitted by Lyon
**[Link to original bug (#757575)](https://bugzilla.gnome.org/show_bug.cgi?id=757575)**
## Description
When we are update gstreamer from 1.4.5 to 1.6, we found some clips with mp3 audio cannot be played.
So we have a check and found that in gstbaseparse, there may be some modification can be made.
In gstbaseparse, The chain in buffer is pushed into adapter, and then send to subclass by tmpbuf (gstbuffer) frame by frame.
There is a commit which use new API to get buffer from adapter.
commit c3bcbadd5452d5b3450f70e49dad3e64f14de00a
Author: Sebastian Dr枚ge <sebastian@centricular.com>
Date: Tue Jun 30 11:18:24 2015 +0200
baseparse: Use new gst_adapter_get_buffer() API instead of gst_adapter_map()
This preserves GstMeta properly unless the subclass does special things
and The gst_adapter_get_buffer() will preserve all meta in adapter including GST_BUFFER_FLAG_DISCONT flag. So if the first chain in buffer contains several frames, these several frames will be sent to downstream with DISCONT flag.
However, the DISCONT flag is only needed for the first frame push to downstream, if the 2nd frame (and after 2nd frame) includes DISCONT flag, then audiodecoder may do flush operation, and which can make audio decoder subclass can not get enough data.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/136bin: removing child that failed state change does not restore clean state2021-09-24T11:10:38ZBugzilla Migration Userbin: removing child that failed state change does not restore clean state## Submitted by Aleksander Wabik
**[Link to original bug (#757360)](https://bugzilla.gnome.org/show_bug.cgi?id=757360)**
## Description
If one of the children of the bin fails state change, it is not sufficient to just remove it in ...## Submitted by Aleksander Wabik
**[Link to original bug (#757360)](https://bugzilla.gnome.org/show_bug.cgi?id=757360)**
## Description
If one of the children of the bin fails state change, it is not sufficient to just remove it in order to restore clean state. From a quick glance at the gstbin.c, it looks like:
- when element's state change fails, all remaining children do not change state, so the bin may have some children in a changed state, and others in the old state,
- removing the child that failed statechange does not cause remaining children to transite to the previously requested state,
- removing the child that failed statechange does not restore bin's last state change return to a proper value - it's still an error,
- removing a child that posted async-start, if all other children have already posted async-done, will not cause the bin to post async-done if last state change return is error (even if the element that errored was already removed from the bin).
The simple workaround is to call again gst_element_set_state() on the bin after I remove the child that failed state change.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/135Deprecate GST_MEMORY_FLAG_NO_SHARE2021-09-24T11:10:39ZBugzilla Migration UserDeprecate GST_MEMORY_FLAG_NO_SHARE## Submitted by pie..@..hoo.it
**[Link to original bug (#757254)](https://bugzilla.gnome.org/show_bug.cgi?id=757254)**
## Description
Created attachment 314325
Test case showing that meta are not propagated.
Custom metadata A...## Submitted by pie..@..hoo.it
**[Link to original bug (#757254)](https://bugzilla.gnome.org/show_bug.cgi?id=757254)**
## Description
Created attachment 314325
Test case showing that meta are not propagated.
Custom metadata API cannot be copied by
myapi_meta_transform (GstBuffer * transbuf, GstMeta * meta,
GstBuffer * buffer, GQuark type, gpointer data)
with some pipelines because transbuf is not writable.
Citing this message: http://lists.freedesktop.org/archives/gstreamer-devel/2015-October/055188.html
"It's a bug in videodecoder, the same bug probably also exists elsewhere."
Testcase attached.
**Attachment 314325**, "Test case showing that meta are not propagated.":
[TestMetaPropagation.tar.gz](/uploads/0559784a6bf3b6de53783e9eab6d0b4e/TestMetaPropagation.tar.gz)
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/134tracer: [API]: add register_hook_for_target.2021-09-24T11:10:39ZBugzilla Migration Usertracer: [API]: add register_hook_for_target.## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#757047)](https://bugzilla.gnome.org/show_bug.cgi?id=757047)**
## Description
See commit message## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#757047)](https://bugzilla.gnome.org/show_bug.cgi?id=757047)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/133segment: Make times signed and a fraction, and never return NONE for time con...2022-11-10T09:20:46ZBugzilla Migration Usersegment: Make times signed and a fraction, and never return NONE for time conversions for out-of-segment values## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757021)](https://bugzilla.gnome.org/show_bug.cgi?id=757021)**
## Description
+++ This bug was initially created as a clone of [Bug 756564](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757021)](https://bugzilla.gnome.org/show_bug.cgi?id=757021)**
## Description
+++ This bug was initially created as a clone of [Bug 756564](https://bugzilla.gnome.org/show_bug.cgi?id=756564) +++
+++ This bug was initially created as a clone of [Bug 748316](https://bugzilla.gnome.org/show_bug.cgi?id=748316) +++
For 2.0, we should make the times signed and always return a value in those functions even if they are out of segment. gst_segment_to_running_time_full() already does this, but the same is needed in general for other situations too.
While at that, we should also reconsider making all times into a fraction.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/132Error raised when calling get_value method2021-09-24T11:10:40ZBugzilla Migration UserError raised when calling get_value method## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#756950)](https://bugzilla.gnome.org/show_bug.cgi?id=756950)**
## Description
In http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstcontrolsource.c#n92 there ...## Submitted by Alexandru Balut `@aleb`
**[Link to original bug (#756950)](https://bugzilla.gnome.org/show_bug.cgi?id=756950)**
## Description
In http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstcontrolsource.c#n92 there is a method called gst_control_source_get_value:
/**
* gst_control_source_get_value_and_work_please:
* @self: the #GstControlSource object
* @timestamp: the time for which the value should be returned
* @value: (out): the value
*
* Gets the value for this #GstControlSource at a given timestamp.
*
* Returns: %FALSE if the value couldn't be returned, %TRUE otherwise.
*/
gboolean
gst_control_source_get_value_and_work_please (GstControlSource * self, GstClockTime timestamp,
gdouble * value)
{ ... }
In Python it ends up in gi.repository.GstController.GstControlSource.get_value. When the method is called, it raises a "RuntimeError: unable to get the value".
When creating a duplicate method with the name changed:
/**
* gst_control_source_get_value_and_work_please:
* @self: the #GstControlSource object
* @timestamp: the time for which the value should be returned
* @value: (out): the value
*
* Gets the value for this #GstControlSource at a given timestamp.
*
* Returns: %FALSE if the value couldn't be returned, %TRUE otherwise.
*/
gboolean
gst_control_source_get_value_and_work_please (GstControlSource * self, GstClockTime timestamp,
gdouble * value)
{
return gst_control_source_get_value(self, timestamp, value);
}
... it is mapped to Gst.ControlSource.get_value_and_work_please() and this one works, so it seems it's a pygobject binding problem causing get_value to fail.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/131Patch to add dump-max-size property to fakesink,fakesrc,identity2021-09-24T11:10:41ZBugzilla Migration UserPatch to add dump-max-size property to fakesink,fakesrc,identity## Submitted by James Stevenson
**[Link to original bug (#756687)](https://bugzilla.gnome.org/show_bug.cgi?id=756687)**
## Description
Created attachment 313453
Patch to limit size of buffer to be dumped when dump=true on fakesrc,...## Submitted by James Stevenson
**[Link to original bug (#756687)](https://bugzilla.gnome.org/show_bug.cgi?id=756687)**
## Description
Created attachment 313453
Patch to limit size of buffer to be dumped when dump=true on fakesrc,fakesink,identity
Limits the amount of buffer to be dumped to stdout when dump=true is on fakesrc, fakesink and identity elements.
It does this by adding dump-max-size property which specifics the number of bytes to dump.
Example:
videotestsrc ! fakesink dump=true dump-max-size=50
will dump the first 50 bytes instead of the whole buffer.
**Attachment 313453**, "Patch to limit size of buffer to be dumped when dump=true on fakesrc,fakesink,identity":
[0001-Added-dump-max-size-properties-to-fakesink-fakesrc-i.patch](/uploads/f228a52132a90fd776cc19f71c210f8e/0001-Added-dump-max-size-properties-to-fakesink-fakesrc-i.patch)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/130gstharness: add gst_harness_set_single_segment2021-09-24T11:10:42ZBugzilla Migration Usergstharness: add gst_harness_set_single_segment## Submitted by Håvard Graff (hgr)
**[Link to original bug (#755999)](https://bugzilla.gnome.org/show_bug.cgi?id=755999)**
## Description
Created attachment 312589
implementation with test
"borrowed" from gstidentity, single-...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#755999)](https://bugzilla.gnome.org/show_bug.cgi?id=755999)**
## Description
Created attachment 312589
implementation with test
"borrowed" from gstidentity, single-segment allows testing continuous timestamping even when multiple segments are involved, without having to do the "segment-math" manually.
~~**Patch 312589**~~, "implementation with test":
[gstharness-singlesegment.patch](/uploads/b4ff429b26a8275facfd235b34f94fed/gstharness-singlesegment.patch)
### Depends on
* [Bug 761914](https://bugzilla.gnome.org/show_bug.cgi?id=761914)