gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2023-06-26T12:10:54Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/291Drop use of GSlice in GStreamer2023-06-26T12:10:54ZBugzilla Migration UserDrop use of GSlice in GStreamer## Submitted by Tim Müller `@tpm`
**[Link to original bug (#795828)](https://bugzilla.gnome.org/show_bug.cgi?id=795828)**
## Description
Created attachment 371701
Drop use of GSlice allocator in favour of plain g_malloc()/g_free()...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#795828)](https://bugzilla.gnome.org/show_bug.cgi?id=795828)**
## Description
Created attachment 371701
Drop use of GSlice allocator in favour of plain g_malloc()/g_free()
Just gonna put this here. Enjoy.
The "Benchmarks show" bit could probably need more verification, but in the few tests I have run I have found either positive performance impact or no discernable performance impact. It's hard to do proper measurements for our purposes, we need to test alloc from one thread and free in another thread for realistic usage, while at the same time having a test case where allocation/free takes up most of the cycles. I have run some tests on a low-powered windows ec2 machine, that showed GSLice being ridiculously slow compared to the system allocator there (windows server 2006 =~ win10).
IIRC main reason to use GSlice was because the sys allocator on` ~Windows` XP was horrendous, but that doesn't seem to be the case any longer, and on Linux the glibc allocator seems superior nowadays.
**Patch 371701**, "Drop use of GSlice allocator in favour of plain g_malloc()/g_free()":
[0001-Drop-use-of-GSlice-allocator-in-favour-of-plain-g_ma.patch](/uploads/438addaac2f08f0d1693e214ed8bab72/0001-Drop-use-of-GSlice-allocator-in-favour-of-plain-g_ma.patch)
### See also
* [Bug 754687](https://bugzilla.gnome.org/show_bug.cgi?id=754687)1.23.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3179dvdspu: figure out how to make it work with hardware decoders and subpicture ...2024-01-02T15:05:45ZBugzilla Migration Userdvdspu: figure out how to make it work with hardware decoders and subpicture overlays## Submitted by Jan Schmidt `@thaytan`
Assigned to **Jan Schmidt `@thaytan`**
**[Link to original bug (#685282)](https://bugzilla.gnome.org/show_bug.cgi?id=685282)**
## Description
Getting the DVD SPU to paint generically is a req...## Submitted by Jan Schmidt `@thaytan`
Assigned to **Jan Schmidt `@thaytan`**
**[Link to original bug (#685282)](https://bugzilla.gnome.org/show_bug.cgi?id=685282)**
## Description
Getting the DVD SPU to paint generically is a requirement for allowing the DVD elements to plug / output hardware decoder caps.
Here's a conversation we had about it on IRC:
Sep 26 01:37:04 * thaytan wonders how SPU works
Sep 26 01:37:19 `<bilboed>` thaytan, with vdpau ?
Sep 26 01:37:24 `<thaytan>` *nod*
Sep 26 01:37:35 `<thaytan>` how it should work, that is
Sep 26 01:37:36 `<bilboed>` they have also VdpBitmapSurface
Sep 26 01:38:01 `<bilboed>` so VdpVideoSurface => YUV stuff, VdpBitmapSurface => RGB stuff
Sep 26 01:38:11 `<bilboed>` VdpOutputSurface => output of the compositor for display
Sep 26 01:38:40 `<bilboed>` you can create VdpBitmapSurface and map(write) stuff on it
Sep 26 01:39:01 `<bilboed>` then you give it to the compositor with coordinates (and whatever else) and that's basically it
Sep 26 01:39:09 `<thaytan>` hmmm
Sep 26 01:39:26 `<bilboed>` so as a result ... I'm also gonna have to figure out how to solve hw-compositing
Sep 26 01:39:28 `<thaytan>` not sure I see how that fits into a GStreamer/rsndvdbin context
Sep 26 01:39:31 `<bilboed>` in a generic fashion that is
Sep 26 01:39:55 `<bilboed>` thaytan, was thinking you could slap GstOverlayMeta (or sth like that) with attached GstBuffers
Sep 26 01:40:06 `<bilboed>` thaytan, maybe videomixer or some generic element could do that
Sep 26 01:40:09 `<thaytan>` I guess it's a vdpspu element with video and subpicture inputs as currently with dvdspu
Sep 26 01:40:25 `<thaytan>` except the video pad accepts vdp output surface caps
Sep 26 01:40:38 `<bilboed>` I'd prefer to avoid creating yet-another-custom-element
Sep 26 01:40:45 `<thaytan>` but, I don't know what it outputs
Sep 26 01:41:12 `<thaytan>` bilboed: I don't know how to build it generically
Sep 26 01:41:48 `<thaytan>` the dvdspu element uses the video stream passing through to a) paint onto b) uses the timestamps to crank the SPU state machine
Sep 26 01:42:44 `<bilboed>` what do you need more apart from "put this RGB bitmap at these coordinates for this timestamp and this duration"
Sep 26 01:43:48 `<thaytan>` it needs the timestamps and segment info on the video stream so it knows which pixels to generate
Sep 26 01:44:04 `<thaytan>` it's more "here's a video frame, what's the overlay?"
Sep 26 01:44:13 `<thaytan>` also, dvdspu works in YUV too
Sep 26 01:44:13 `<bilboed>` sure, but it doesn't care about the *content* of that frame
Sep 26 01:44:28 `<thaytan>` bilboed: not if it's not doing the compositing, no
Sep 26 01:44:34 `<bilboed>` right
Sep 26 01:45:11 `<bilboed>` so it could see the stream go through, watch/collect segment/timestamps and decide what subpicture to attach to it (without *actually* doing any processing and letting downstream handle that)
Sep 26 01:45:13 `<thaytan>` but the model is still to pass the video buffer stream through the spu element so it can see the timing info it needs, right?
Sep 26 01:45:22 `<thaytan>` oh, of course
Sep 26 01:45:28 `<thaytan>` that's what I was suggesting, I guess I wasn't clear
Sep 26 01:45:35 `<__tim>` thaytan, dvdspu should support GstVideoOverlayComposition imho
Sep 26 01:45:38 `<bilboed>` I'm not *that* familiar with SPU
Sep 26 01:45:42 `<bilboed>` also, what __tim said :)
Sep 26 01:45:54 `<bilboed>` like that I don't have to solve it in 500 different elements
Sep 26 01:45:56 `<thaytan>` ok, I guess I'll have to look at the GstVideoOverlayComposition API
Sep 26 01:46:54 * bilboed is not looking forward "at all" to fixing this for cluster-gst
Sep 26 01:47:12 `<__tim>` it's very dumb, you can provide one or more ARGB or AYUV rectangles and either use helper API to put them onto the raw video, or attach them to the buffer; the sink or whatever can then take over the overlaying using that
Sep 26 01:47:40 `<__tim>` and it will do a bunch of conversions for you and cache them if the sink or whatever does the overlaying doesn't support what you supplied
Sep 26 01:48:54 `<thaytan>` well, that sounds feasible - although less efficient than dvdspu painting natively if the composite is in software
Sep 26 01:49:28 `<thaytan>` maybe it can be extended to add RLE AYUV rectangles as a format though?
Sep 26 01:49:44 `<__tim>` thaytan, how sure are you of that? because basically you have to parse the RLE data for every single frame, right? is that really so much faster than blitting some ready-made rectangle using orc?
Sep 26 01:50:04 `<thaytan>` dvdspu gets to skip a lot of transparent pixels
Sep 26 01:52:21 `<__tim>` yeah, but it's if else and loops etc. You might be right, I'm just curious how much difference it actually makes. Also, you don't have to use the API to blit your pixels, you can still do that as you do now and only attach the AYUV rectangle if downstream supports that
Sep 26 01:54:13 `<__tim>` it's just convenient because you only have one code path
Sep 26 01:55:01 `<thaytan>` it sounds like a structural improvement
### Blocking
* [Bug 663750](https://bugzilla.gnome.org/show_bug.cgi?id=663750)
* [Bug 725900](https://bugzilla.gnome.org/show_bug.cgi?id=725900)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2854v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer b...2023-08-01T11:53:19ZBugzilla Migration Userv4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer buffers## Submitted by Tobias Modschiedler
**[Link to original bug (#749016)](https://bugzilla.gnome.org/show_bug.cgi?id=749016)**
## Description
This topic was started in the discussion of [bug 746834](https://bugzilla.gnome.org/show_bug....## Submitted by Tobias Modschiedler
**[Link to original bug (#749016)](https://bugzilla.gnome.org/show_bug.cgi?id=749016)**
## Description
This topic was started in the discussion of [bug 746834](https://bugzilla.gnome.org/show_bug.cgi?id=746834) at Comment 18 (https://bugzilla.gnome.org/show_bug.cgi?id=746834#c18).
If GStreamer source buffers are larger that V4L2 buffers (which makes sense for MPEG-TS data), copying them fails in gst_v4l2_buffer_pool_copy_buffer().
I'll copy the relevant part of Nicolas' comment here:
---
GstV4l2 also kind of lack some support. If the buffer is bigger then the v4l2 buffer size, it simply fails. It's fine for raw data, but for encoded data it should probably spread the data over multiple buffers and properly set the size for the last one. For mpegts, the buffer size will always be a multiple of 188 anyway.
I think we could have mpegts specific code to select a decent default size (N * 188), or change the driver to pick a better default. Then if a buffer is bigger and we have encoded data, we should loop (copy and queue), until all data has been consumed.
---
I'm having problems coming up with a patch. The "multi-buffer" handling will probably be in gst_v4l2_buffer_pool_process() at label "copying". But what happens if only a part of the source buffer can be copied, i.e. not enough destination buffers can be acquired?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2779Override changes Gst.ElementFactory.make arguments2023-07-11T16:26:30ZBugzilla Migration UserOverride changes Gst.ElementFactory.make arguments## Submitted by Osmo Salomaa
**[Link to original bug (#748852)](https://bugzilla.gnome.org/show_bug.cgi?id=748852)**
## Description
I have gotten bug reports in Gaupol that the following code doesn't work if the user has gst-python ...## Submitted by Osmo Salomaa
**[Link to original bug (#748852)](https://bugzilla.gnome.org/show_bug.cgi?id=748852)**
## Description
I have gotten bug reports in Gaupol that the following code doesn't work if the user has gst-python installed (see` #748813`).
Gst.ElementFactory.make("textoverlay", name=None)
Your override changes both argument names, thus breaking keyword argument use, which I tend to often prefer since it makes the code self-documenting. To my knowledge, keyword argument use should be fine with PyGObject, i.e. they're part of the API, see e.g. gtk-demo.py [1].
Gaupol doesn't depend on gst-python and I was surprised to find out such a thing still exists, but there was no information at the web site [2]. So, if I may ask, what is this gst-python?, why is it needed? and is it intended that you override function signatures or just an accident? Can I as an application developer expect that things should work the same for users with and without gst-python?
[1] https://git.gnome.org/browse/pygobject/tree/demos/gtk-demo/gtk-demo.py
[2] http://gstreamer.freedesktop.org/modules/gst-python.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2771qtdemux: Premature EOS when some files are played in push mode2023-11-28T15:18:22ZBugzilla Migration Userqtdemux: Premature EOS when some files are played in push mode## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794199)](https://bugzilla.gnome.org/show_bug.cgi?id=794199)**
## Description
Created attachment 369503
Test vector
The attached file has 6 frames, in two ...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794199)](https://bugzilla.gnome.org/show_bug.cgi?id=794199)**
## Description
Created attachment 369503
Test vector
The attached file has 6 frames, in two GOPs, both with I-B-P layout.
It's demuxed correctly in pull mode.
$ gst-launch-1.0 -v filesrc location=ibpibp-non-frag.mp4 ! qtdemux ! fakesink silent=false |egrep 'segment|chain'
/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)333333333, stop=(guint64)2333333333, time=(guint64)0, position=(guint64)333333333, duration=(guint64)18446744073709551615;";) 0x5649226dcb20
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1025 bytes, dts: 0:00:00.000000000, pts: 0:00:00.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00000040 discont , meta: none) 0x7ff4c8005340
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (305 bytes, dts: 0:00:00.333333333, pts: 0:00:01.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (131 bytes, dts: 0:00:00.666666666, pts: 0:00:00.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005010
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (499 bytes, dts: 0:00:01.000000000, pts: 0:00:01.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7ff4c8005120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (487 bytes, dts: 0:00:01.333333333, pts: 0:00:02.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005340
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (215 bytes, dts: 0:00:01.666666666, pts: 0:00:01.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005450
On the other hand, it loses the last 2 frames when demuxed in push mode:
$ gst-launch-1.0 -v pushfilesrc location=ibpibp-non-frag.mp4 ! qtdemux ! fakesink silent=false |egrep 'segment|chain'
/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;";) 0x5619bebdeea0
/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)333333333, stop=(guint64)2333333333, time=(guint64)0, position=(guint64)333333333, duration=(guint64)18446744073709551615;";) 0x7f91ec0065c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1025 bytes, dts: 0:00:00.000000000, pts: 0:00:00.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00004040 discont tag-memory , meta: none) 0x7f91ec00a400
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (305 bytes, dts: 0:00:00.333333333, pts: 0:00:01.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00006000 delta-unit tag-memory , meta: none) 0x7f91ec00a510
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (131 bytes, dts: 0:00:00.666666666, pts: 0:00:00.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00006000 delta-unit tag-memory , meta: none) 0x7f91ec00a620
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (499 bytes, dts: 0:00:01.000000000, pts: 0:00:01.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00004000 tag-memory , meta: none) 0x7f91ec00a510
The offending code is this condition:
pts = QTSAMPLE_PTS (stream, sample);
[...]
if (G_UNLIKELY (demux->segment.stop != -1
&& demux->segment.stop <= pts && stream->on_keyframe)) {
GST_DEBUG_OBJECT (demux, "we reached the end of our segment.");
Note that the `demux->segment.stop <= pts` comparison is wrong because it's comparing buffer time across different GstSegments, instead of translating both to stream time.
The difference is very important because the user requests to play e.g. the range [0, 2) s *in stream time*; it should not need to care whether the track (buffer) presentation range is actually [0.333, 2.333) because this file already has an edit list to map that to [0, 2) s in stream time.
The `stream->on_keyframe` check is also interesting. I have not experimented with it too much, but on first glance it looks like it would avoid entering the `if` body on most files, which would explain why this issue has not been detected before. Since most GOPs are longer than 3 frames and for most files with basic edit lists, like the one attached, the buffer PTS match can only occur in the last GOP, the chances of it happening on both buffer PTS = segment.stop and exactly the next frame after an I-frame are quite low. (EOS is sent later because as a reaction of upstream sending EOS itself when there are no more bytes to read, not because of last frame emission*).
* To make things worse, our WebKit MSE implementation actually relies on EOS not being sent on last frame emission when working on push mode. Today I've learned that is the case most often but not always.
**Attachment 369503**, "Test vector":
![ibpibp-non-frag](/uploads/5a6ff5e18cae6435209066e3070ce674/ibpibp-non-frag.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2749osxaudiosrc drops frames when osxaudiosink misses frames2024-01-22T16:13:51ZBugzilla Migration Userosxaudiosrc drops frames when osxaudiosink misses frames## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink ...## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(866): GstFlowReturn gst_audio_base_src_create(GstBaseSrc *, guint64, guint, GstBuffer **) (): /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0:
Dropped 9261 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
I don't quite understand why osxaudiosrc drops frames when the *sink* is the one that's not receiving all of the frames. This doesn't happen with fakesink or filesink.
Also, it's "solved" by setting "osxaudiosink sync=0".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2721x264enc: Make sure sinkpad caps are never renegotiated2023-07-07T03:17:56ZBugzilla Migration Userx264enc: Make sure sinkpad caps are never renegotiated## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show_bug.cgi?id=795420)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2705directsoundsrc: device-name doesn't accept windows given names if there are s...2023-06-27T07:56:19ZBugzilla Migration Userdirectsoundsrc: device-name doesn't accept windows given names if there are special characters in## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High...## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High Definition Audio-Gerät)". But works if you change the naming in windows registry, which is only possible for testing purposes. May an device-ID (GUID) based solution is needed!?
$ GST_DEBUG=3,directsoundsrc:5 gst-launch-1.0.exe directsoundsrc buffer-time=10000 device-name="mic (High Definition Audio-Gerät)" ! directsoundsink buffer-time=200000
0:00:00.043914339 3444 02D27260 WARN audioresample gstaudioresample.c:1537:plugin_init: Orc disabled, can't benchmark int vs. float resampler
0:00:00.048490103 3444 02D27260 WARN GST_PERFORMANCE gstaudioresample.c:1540:plugin_init: orc disabled, no benchmarking done
0:00:00.064831675 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:164:gst_directsound_src_class_init: initializing directsoundsrc class
0:00:00.139332696 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:259:gst_directsound_src_init:<GstDirectSoundSrc@00513220> initializing directsoundsrc
0:00:00.144179343 3444 02D27260 ERROR GST_PIPELINE grammar.y:453:gst_parse_element_set: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Gerät)"
0:00:00.148407097 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
0:00:00.151341707 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
[Invalid UTF-8] WARNING: erroneous pipeline: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Ger\xe4t)"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2686baseparse/h264: basesink clipping one of the first NALUs because of DTS out o...2023-06-20T13:46:43ZBugzilla Migration Userbaseparse/h264: basesink clipping one of the first NALUs because of DTS out of segment## Submitted by Marwen
**[Link to original bug (#797257)](https://bugzilla.gnome.org/show_bug.cgi?id=797257)**
## Description
Created attachment 373871
The log for the first buffers
gst-launch-1.0 -v videotestsrc ! x264enc ! ...## Submitted by Marwen
**[Link to original bug (#797257)](https://bugzilla.gnome.org/show_bug.cgi?id=797257)**
## Description
Created attachment 373871
The log for the first buffers
gst-launch-1.0 -v videotestsrc ! x264enc ! h264parse ! capsfilter caps="video/x-h264, stream-format=byte-stream, alignment=nal" ! fakesink silent=0
I enabled the logs for the parser and sink with GST_DEBUG=baseparse:7,h264parse:7,codecparsers_h264:7,basesink:7 to have the full picture. You can find the log for the first buffers attached.
The sink is dropping the second NALU of the stream because it fells out of the segment. That's because, in absence of a valid pts, the basesink is clipping on the dts which i don't think is a good idea since dts can fall out of the segment (especially for the first frames of h264 streams with b-frames).
The problem here comes also from the parser when transforming from a byte-stream format AU aligned to NAL aligned: when an AU is containing multiple NALU, only the first output buffer (NALU) is having the pts/dts of the input buffer(AU) while the following NALUs are having pts set to none and dts incremented by duration for every buffer. The attached log shows :
- First input buffer to h264parse with size 7144:
--> baseparse gstbaseparse.c:2189:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 7144 with dts 999:59:59.933333334, pts 1000:00:00.000000000, duration 99:99:99.999999999
- producing following buffers (NALUs):
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 6 with dts 999:59:59.933333334, pts 1000:00:00.000000000, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 33 with dts 999:59:59.966666667, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 9 with dts 1000:00:00.000000000, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 761 with dts 1000:00:00.033333333, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 6335 with dts 1000:00:00.066666666, pts 99:99:99.999999999, duration 0:00:00.033333333
- Next input buffer to h264 with sie 5348:
--> baseparse gstbaseparse.c:2189:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 5348 with dts 999:59:59.966666667, pts 1000:00:00.133333333, duration 99:99:99.999999999
The main problem is that the second NALU (with buffer size 6) is clipped out in the basesink because it have no valid pts and its dts is falling out of the segment (start: 1000:00:00.000000000).
I'm not sure if it's better to set all NALUs to the same pts of the "parent" AU or set it to none, but the DTS is certainly set wrong.
So the questions are :
- Should the basesink ever clip based on the DTS (even if no PTS is valid) ?
- What should be the (PTS,DTS) of the NALUs coming from the same AU ?
**Attachment 373871**, "The log for the first buffers":
[gst_log_h264.txt](/uploads/0677d1bba84a0ee0b8a9e7318e5fd7b6/gst_log_h264.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2643gstplayer: Add gst_player_get_state API2023-06-12T14:47:59ZBugzilla Migration Usergstplayer: Add gst_player_get_state API## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start runni...## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start running.
However, if we need to get the current state when mainloop has not started running. There is no way to get the gstplayer state.
So considering add this gst_player_get_state() API to get the current player state.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2586vtenc: "Output state was not configured"2023-07-21T16:58:33ZBugzilla Migration Uservtenc: "Output state was not configured"## Submitted by Ilya Konstantinov
**[Link to original bug (#747546)](https://bugzilla.gnome.org/show_bug.cgi?id=747546)**
## Description
gst_vtenc_finish might be called before gst_vtenc_encode_frame ever manages to encode a single ...## Submitted by Ilya Konstantinov
**[Link to original bug (#747546)](https://bugzilla.gnome.org/show_bug.cgi?id=747546)**
## Description
gst_vtenc_finish might be called before gst_vtenc_encode_frame ever manages to encode a single frame, i.e.
```
i = 0;
while (g_async_queue_length (self->cur_outframes) > 0) {
GstVideoCodecFrame *outframe = g_async_queue_try_pop (self->cur_outframes);
/* Try to renegotiate once */
if (i == 0) {
meta = gst_buffer_get_core_media_meta (outframe->output_buffer);
if (!gst_vtenc_negotiate_downstream (self, meta->sample_buf)) {
`^``^` this code might never run before gst_vtenc_finish
```
In such case, VT's queue will be flushed and gst_video_encoder_finish_frame will be called for every frame, but negotiation will never happen, and therefore:
`ERROR videoencoder gstvideoencoder.c:2033:GstFlowReturn gst_video_encoder_finish_frame(GstVideoEncoder *, GstVideoCodecFrame *):<vtenc_h264-0> Output state was not configured`Piotr BrzezińskiPiotr Brzezińskihttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/827[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good2022-04-05T12:51:26ZBugzilla Migration User[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been sa...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been said that we should wait for` #657790` to be closed, and we might want to rename it from hls to something more generic (fragmented is the name of the plugin itself, just the folder is called hls). Ideally adding another fragmented streaming protocol with the help of the new base class.
Also there is no test suite yet but there is some work going on there.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/821dash: mpdparser: GstUri changed unexpectedly within combine_urls()2022-11-15T00:45:56ZBugzilla Migration Userdash: mpdparser: GstUri changed unexpectedly within combine_urls()## Submitted by WeiChungChang
**[Link to original bug (#765528)](https://bugzilla.gnome.org/show_bug.cgi?id=765528)**
## Description
Created attachment 326680
issued MPD file
Hi all:
I met a problem when combine_urls() ...## Submitted by WeiChungChang
**[Link to original bug (#765528)](https://bugzilla.gnome.org/show_bug.cgi?id=765528)**
## Description
Created attachment 326680
issued MPD file
Hi all:
I met a problem when combine_urls() is executed the result URL is broken.
Such as:
expected result =
"https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback?id=cf12500690581ecb&itag=133&source=youtube&requiressl=yes&ms=au&pl=16&mm=31&mv=m&mn=sn-ipoxu-u2xl&initcwndbps=1245000&ratebypass=yes&mime=video/mp4&gir=yes&clen=3617089&lmt=1439380361025617&dur=121.746&signature=8C0600A08A8FA47C3734F42B4721E2143EACDF94.705D52170E63A2E70291789D67FAC9C139B12965&mt=1461557621&upn=hP1NJs1_Lng&sver=3&fexp=3300118,3300134,3300161,3312381,9410705,9416126,9416891,9422596,9426927,9427482,9428398,9431012,9431364,9431865,9432033,9432132,9432684,9432839,9433096,9433193,9433425,9433947,9433997&key=dg_yt0&ip=42.73.160.27&ipbits=0&expire=1461579370&sparams=ip,ipbits,expire,id,itag,source,requiressl,ms,pl,mm,mv,mn,initcwndbps,ratebypass,mime,gir,clen,lmt,dur <https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback?id=cf12500690581ecb&itag=133&source=youtube&requiressl=yes&ms=au&pl=16&mm=31&mv=m&mn=sn-ipoxu-u2xl&initcwndbps=1245000&ratebypass=yes&mime=video/mp4&gir=yes&clen=3617089&lmt=1439380361025617&dur=121.746&signature=8C0600A08A8FA47C3734F42B4721E2143EACDF94.705D52170E63A2E70291789D67FAC9C139B12965&mt=1461557621&upn=hP1NJs1_Lng&sver=3&fexp=3300118%2c3300134%2c3300161%2c3312381%2c9410705%2c9416126%2c9416891%2c9422596%2c9426927%2c9427482%2c9428398%2c9431012%2c9431364%2c9431865%2c9432033%2c9432132%2c9432684%2c9432839%2c9433096%2c9433193%2c9433425%2c9433947%2c9433997&key=dg_yt0&ip=42.73.160.27&ipbits=0&expire=1461579370&sparams=ip%2cipbits%2cexpire%2cid%2citag%2csource%2crequiressl%2cms%2cpl%2cmm%2cmv%2cmn%2cinitcwndbps%2cratebypass%2cmime%2cgir%2cclen%2clmt%2cdur>
"
broken result = "https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback
"
static GstUri *
combine_urls (GstUri * base, GList * list, gchar ** query,
GstActiveStream * stream)
{
GstUri *ret = base;
...
/*here the ret is still sound*/
gst_uri_set_query_table (ret, NULL);
/*here the ret is broken...*/
}
The attached is the DASH MPD where this issue happened.
Could someone help on checking it?
Thanks.
**Attachment 326680**, "issued MPD file":
[1245000.mpd](/uploads/11a99708c1f0508a96ef0c9c5aeb03c9/1245000.mpd)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/325jhbuild : Error during phase build of gstreamer: Error running ninja2019-02-10T19:25:54ZBugzilla Migration Userjhbuild : Error during phase build of gstreamer: Error running ninja## Submitted by freeroot
**[Link to original bug (#791019)](https://bugzilla.gnome.org/show_bug.cgi?id=791019)**
## Description
JhBuild stops twice with those lines of errors.
ninja
[103/460] Generating Gst-1.0.gir with a cus...## Submitted by freeroot
**[Link to original bug (#791019)](https://bugzilla.gnome.org/show_bug.cgi?id=791019)**
## Description
JhBuild stops twice with those lines of errors.
ninja
[103/460] Generating Gst-1.0.gir with a custom command.
/usr/include/bits/mathcalls-helper-functions.h:21: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __fpclassifyf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__))' at '__value'
/usr/include/bits/mathcalls-helper-functions.h:25: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __signbitf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__))' at '__value'
/usr/include/bits/mathcalls-helper-functions.h:30: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __isinff128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));' at '__value'
/usr/include/bits/mathcalls-helper-functions.h:33: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __finitef128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));' at '__value'
/usr/include/bits/mathcalls-helper-functions.h:36: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __isnanf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));' at '__value'
/usr/include/bits/mathcalls-helper-functions.h:39: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __iseqsigf128 (_Float128 __x, _Float128 __y) __attribute__ ((__nothrow__ , __leaf__));' at '__x'
/usr/include/bits/mathcalls-helper-functions.h:42: syntax error, unexpected identifier, expecting ')' or ',' in 'extern int __issignalingf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__))' at '__value'
g-ir-scanner: link: cc -o /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect5teaozhm/Gst-1.0 /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect5teaozhm/Gst-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -lgstreamer-1.0 -lunwind -lgobject-2.0 -lm -ldl -lgmodule-2.0 -lglib-2.0 -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/jhbuild/install/lib -Wl,-rpath,/home/$$$/jhbuild/install/lib -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -L/home/$$$/jhbuild/install/lib
[132/460] Generating symbol file 'libs/gst/controller/gstcontroller-1.0@sha/libs/gst/controller/libgstcontroller-1.0.so.0.1300.0.sy[134/460] Generating symbol file 'libs/gst/controller/gstcontroller-1.0@sha/libs/gst/controller/libgstcontroller-1.0.so.0.1300.0.sy[138/460] Generating GstBase-1.0.gir with a custom command.
FAILED: libs/gst/base/GstBase-1.0.gir
/home/$$$/jhbuild/install/bin/g-ir-scanner -I/home/$$$/jhbuild/install/include/gobject-introspection-1.0 -I/home/$$$/jhbuild/install/include/glib-2.0 -I/home/$$$/jhbuild/install/lib/glib-2.0/include -pthread --no-libtool --namespace=GstBase --nsversion=1.0 --warn-all --output libs/gst/base/GstBase-1.0.gir '--add-init-section=extern void gst_init(gint*,gchar**);g_setenv("GST_REGISTRY_DISABLE", "yes", TRUE);g_setenv("GST_REGISTRY_1.0", "/no/way/this/exists.reg", TRUE);g_setenv("GST_PLUGIN_PATH_1_0", "", TRUE);g_setenv("GST_PLUGIN_SYSTEM_PATH_1_0", "", TRUE);gst_init(NULL,NULL);' --c-include=gst/base/base.h -I/home/$$$/DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/libs/gst/base -I/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -I./. -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. -I./libs -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/libs -I./. -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. -I./. -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. --filelist=/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base/gstbase-1.0@sha/GstBase_1.0_gir_filelist --include=GLib-2.0 --include=GObject-2.0 --include=GModule-2.0 --include=Gst-1.0 --symbol-prefix=gst --identifier-prefix=Gst --pkg-export=gstreamer-base-1.0 --cflags-begin -fvisibility=hidden -I./. -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. -I./libs -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/libs -I./gst/parse -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/gst/parse -I/home/$$$/jhbuild/install/include/glib-2.0 -I/home/$$$/jhbuild/install/lib/glib-2.0/include -pthread --cflags-end -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -L/home/$$$/jhbuild/install/lib --extra-library=unwind --extra-library=gobject-2.0 --extra-library=m --extra-library=dl -L/home/$$$/.cache/jhbuild/build/gstreamer/gst --extra-library=gstreamer-1.0 --extra-library=gmodule-2.0 --extra-library=glib-2.0 -pthread --add-include-path=/home/$$$/.cache/jhbuild/build/gstreamer/gst -I./. -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. -I./libs -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/libs -I./gst -I../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/gst --add-include-path=./. --add-include-path=../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/. --add-include-path=./libs --add-include-path=../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/libs --add-include-path=./gst --add-include-path=../../../../DONNEES/APPLICATIONS/JhBuild/checkout/gstreamer/gst -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -L/home/$$$/.cache/jhbuild/build/gstreamer/gst --library gstbase-1.0
g-ir-scanner: link: cc -o /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect9p723ycg/GstBase-1.0 /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect9p723ycg/GstBase-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -lgstbase-1.0 -lunwind -lgobject-2.0 -lm -ldl -lgstreamer-1.0 -lgmodule-2.0 -lglib-2.0 -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -L/home/$$$/jhbuild/install/lib -Wl,-rpath,/home/$$$/jhbuild/install/lib -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -L/home/$$$/jhbuild/install/lib
/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base/libgstbase-1.0.so : référence indéfinie vers « gst_buffer_list_calculate_size »
collect2: error: ld a retourné le statut de sortie 1
linking of temporary binary failed: Command '['cc', '-o', '/home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect9p723ycg/GstBase-1.0', '/home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect9p723ycg/GstBase-1.0.o', '-L.', '-Wl,-rpath,.', '-Wl,--no-as-needed', '-lgstbase-1.0', '-lunwind', '-lgobject-2.0', '-lm', '-ldl', '-lgstreamer-1.0', '-lgmodule-2.0', '-lglib-2.0', '-L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base', '-Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base', '-L/home/$$$/jhbuild/install/lib', '-Wl,-rpath,/home/$$$/jhbuild/install/lib', '-L/home/$$$/.cache/jhbuild/build/gstreamer/gst', '-Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst', '-L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base', '-Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/base', '-L/home/$$$/.cache/jhbuild/build/gstreamer/gst', '-Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst', '-L/home/$$$/jhbuild/install/lib', '-lgio-2.0', '-lgobject-2.0', '-Wl,--export-dynamic', '-lgmodule-2.0', '-pthread', '-lglib-2.0', '-L/home/$$$/jhbuild/install/lib']' returned non-zero exit status 1.
[139/460] Generating GstController-1.0.gir with a custom command.
g-ir-scanner: link: cc -o /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect4a4yq_b1/GstController-1.0 /home/$$$/.cache/jhbuild/build/gstreamer/tmp-introspect4a4yq_b1/GstController-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -lgstcontroller-1.0 -lunwind -lgobject-2.0 -lm -ldl -lgstreamer-1.0 -lgmodule-2.0 -lglib-2.0 -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/controller -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/controller -L/home/$$$/jhbuild/install/lib -Wl,-rpath,/home/$$$/jhbuild/install/lib -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/controller -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/libs/gst/controller -L/home/$$$/.cache/jhbuild/build/gstreamer/gst -Wl,-rpath,/home/$$$/.cache/jhbuild/build/gstreamer/gst -L/home/$$$/jhbuild/install/lib -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -L/home/$$$/jhbuild/install/lib
[140/460] Compiling C object 'libs/gst/check/gstcheck-1.0@sha/gstcheck.c.o'.
ninja: build stopped: subcommand failed.
*** Error during phase build of gstreamer: ########## Error running ninja *** [18/86]https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/323pkgconfig: Add information about libexecdir2020-10-30T14:21:48ZBugzilla Migration Userpkgconfig: Add information about libexecdir## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#797349)](https://bugzilla.gnome.org/show_bug.cgi?id=797349)**
## Description
See summary## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#797349)](https://bugzilla.gnome.org/show_bug.cgi?id=797349)**
## Description
See summaryhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/322Building pkg-config files always happens with silent rules; doesn't respect -...2021-09-24T13:05:00ZBugzilla Migration UserBuilding pkg-config files always happens with silent rules; doesn't respect --disable-silent-rules## Submitted by Ryan Schmidt
**[Link to original bug (#797335)](https://bugzilla.gnome.org/show_bug.cgi?id=797335)**
## Description
Created attachment 374036
patch
If I configure gstreamer 1.14.4 or 0.10.36 with --disable-sil...## Submitted by Ryan Schmidt
**[Link to original bug (#797335)](https://bugzilla.gnome.org/show_bug.cgi?id=797335)**
## Description
Created attachment 374036
patch
If I configure gstreamer 1.14.4 or 0.10.36 with --disable-silent-rules, silent rules are disabled, except for the part that "builds" (copies) the pkg-config .pc files; this part always displays e.g. " CP gstreamer-1.0.pc" instead of the actual cp command like I wanted it to.
I've attached what I believe to be the correct fix for gstreamer, but it looks like the problem affects the plugins as well and should be committed to each of them. I did not check all of your repositories so I don't know where all the fix is needed. I did see that gst-libav already includes this fix, and that some others like gst-editing-services and gst-rtsp-server appear (based on looking at the source code only) to have the opposite problem of always using non-silent rules. It would be good to get the pkgconfig/Makefile.am files of all of the repositories that use it to be consistent.
**Patch 374036**, "patch":
[pkgconfig-Makefile.am.patch](/uploads/8de8476df1433ef472f8ac61a0d51a9e/pkgconfig-Makefile.am.patch)
Version: 1.14.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/320gst: add some gdb python macros2018-11-08T14:23:21ZBugzilla Migration Usergst: add some gdb python macros## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#797283)](https://bugzilla.gnome.org/show_bug.cgi?id=797283)**
## Description
Just some basic gdb pretty printer for GStreamer types.## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#797283)](https://bugzilla.gnome.org/show_bug.cgi?id=797283)**
## Description
Just some basic gdb pretty printer for GStreamer types.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/319gst: Fix string leak when G_VALUE_COLLECT_INIT() was failed2022-11-10T09:20:51ZBugzilla Migration Usergst: Fix string leak when G_VALUE_COLLECT_INIT() was failed## Submitted by Seungha Yang
**[Link to original bug (#797226)](https://bugzilla.gnome.org/show_bug.cgi?id=797226)**
## Description
Returned string should be freed## Submitted by Seungha Yang
**[Link to original bug (#797226)](https://bugzilla.gnome.org/show_bug.cgi?id=797226)**
## Description
Returned string should be freedhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/318Add GstBuffer helper for wrapping a GBytes2022-11-10T09:20:51ZBugzilla Migration UserAdd GstBuffer helper for wrapping a GBytes## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#797212)](https://bugzilla.gnome.org/show_bug.cgi?id=797212)**
## Description
See commit## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#797212)](https://bugzilla.gnome.org/show_bug.cgi?id=797212)**
## Description
See commitMatthew Watersmatthew@centricular.comMatthew Watersmatthew@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/316tests: bufferpool test fails on 32-bit2022-11-10T09:20:51ZBugzilla Migration Usertests: bufferpool test fails on 32-bit## Submitted by Tim Müller `@tpm`
**[Link to original bug (#797176)](https://bugzilla.gnome.org/show_bug.cgi?id=797176)**
## Description
1/1 gstreamer / gst_gstbufferpool FAIL 0.82 s (exit status 1)
--- command --...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#797176)](https://bugzilla.gnome.org/show_bug.cgi?id=797176)**
## Description
1/1 gstreamer / gst_gstbufferpool FAIL 0.82 s (exit status 1)
--- command ---
CK_DEFAULT_TIMEOUT='20' GST_REGISTRY='/tmp/gb/subprojects/gstreamer/tests/check/gst_gstbufferpool.registry' GST_PLUGIN_PATH_1_0='/tmp/gb' GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_LOADING_WHITELIST='gstreamer' GST_PLUGIN_SCANNER_1_0='/tmp/gb/subprojects/gstreamer/libs/gst/helpers/gst-plugin-scanner' /tmp/gb/subprojects/gstreamer/tests/check/gst_gstbufferpool
--- stdout ---
Running suite(s): GstBufferPool
Unexpected critical/warning: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
Stack trace:
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(+0x6457c) [0xb7e3c57c]
/tmp/gb/subprojects/gstreamer/tests/check/../../libs/gst/check/libgstcheck-1.0.so.0(+0x8b98) [0xb7dbab98]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_logv+0x234) [0xb7cb28b4]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_log+0x25) [0xb7cb2a55]
/usr/lib/i386-linux-gnu/libglib-2.0.so.0(g_return_if_fail_warning+0x29) [0xb7cb3269]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(gst_buffer_resize_range+0x14e) [0xb7e1369e]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(gst_buffer_resize+0x24) [0xb7e13934]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(+0x3e741) [0xb7e16741]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(gst_buffer_pool_release_buffer+0x5d) [0xb7e1830d]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(+0x3943f) [0xb7e1143f]
/tmp/gb/subprojects/gstreamer/tests/check/../../gst/libgstreamer-1.0.so.0(gst_mini_object_unref+0xa8) [0xb7e47ba8]
/tmp/gb/subprojects/gstreamer/tests/check/gst_gstbufferpool(+0x2170) [0x4ce170]
/tmp/gb/subprojects/gstreamer/tests/check/../../libs/gst/check/libgstcheck-1.0.so.0(srunner_run_tagged+0x43d) [0xb7dc7e1d]
/tmp/gb/subprojects/gstreamer/tests/check/../../libs/gst/check/libgstcheck-1.0.so.0(srunner_run+0x28) [0xb7dc8518]
/tmp/gb/subprojects/gstreamer/tests/check/../../libs/gst/check/libgstcheck-1.0.so.0(srunner_run_all+0x20) [0xb7dc8540]
/tmp/gb/subprojects/gstreamer/tests/check/../../libs/gst/check/libgstcheck-1.0.so.0(gst_check_run_suite+0x67) [0xb7dbc187]
/tmp/gb/subprojects/gstreamer/tests/check/gst_gstbufferpool(+0x13c1) [0x4cd3c1]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb7aa09a1]
/tmp/gb/subprojects/gstreamer/tests/check/gst_gstbufferpool(+0x1401) [0x4cd401]
88%: Checks: 9, Failures: 1, Errors: 0
../../home/tpm/gst-build/subprojects/gstreamer/libs/gst/check/gstcheck.c:286:F:buffer_pool tests:test_buffer_modify_discard:0: Unexpected critical/warning: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
Check suite gst_buffer_pool ran in 0.056s (tests failed: 1)
--- stderr ---
0:00:00.783129140 3020 0x54f9c0 ERROR bufferpool gstbufferpool.c:553:gst_buffer_pool_set_active:`<bufferpool0>` pool was not configured
Version: 1.14.3