gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-03-07T13:02:33Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3361wavenc: Go EOS and report an error if larger than 2GB2024-03-07T13:02:33ZBugzilla Migration Userwavenc: Go EOS and report an error if larger than 2GB## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,r...## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,rate=44100,channels=2 ! wavenc ! filesink location=/tmp/test.wav
creates a corrupt wav files. its opened in totem/audacity but only the first 2GB of data are played.
Ot is possible to open the file in audacity as raw samples, skipping the header(first 20bytes). So data gets written to disk but the wav headers are wrong.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3185jpegenc produces data in subsampling mode that rtpjpegpay can't handle2023-12-20T17:58:08ZBugzilla Migration Userjpegenc produces data in subsampling mode that rtpjpegpay can't handle## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#684502)](https://bugzilla.gnome.org/show_bug.cgi?id=684502)**
## Description
We probably need to add more data to the image/jpeg caps to specify it's subsampling mode...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#684502)](https://bugzilla.gnome.org/show_bug.cgi?id=684502)**
## Description
We probably need to add more data to the image/jpeg caps to specify it's subsampling mode so it can be configured, but I don't really understand how jpegenc works.
Test case:
gst-launch-1.0 videotestsrc ! 'video/x-raw, width=(int)160, height=(int)120, framerate=(fraction)30/1, format=(string)BGRx, pixel-aspect-ratio=(fraction)1/1' ! jpegenc ! rtpjpegpay ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0: Invalid component
Additional debug info:
gstrtpjpegpay.c(544): gst_rtp_jpeg_pay_read_sof (): /GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0
ERROR: pipeline doesn't want to preroll.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3117validate: Make it possible to run gst-validate-launcher on embedded device (t...2023-11-09T18:17:09ZBugzilla Migration Uservalidate: Make it possible to run gst-validate-launcher on embedded device (that might not support python)## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#736137)](https://bugzilla.gnome.org/show_bug.cgi?id=736137)**
## Description
The gst-validate-launcher is written in python, we should make sure that the tests...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#736137)](https://bugzilla.gnome.org/show_bug.cgi?id=736137)**
## Description
The gst-validate-launcher is written in python, we should make sure that the tests can be run on embedded platforms, and hopefully even the ones that do not support python (android, iOS?).
For that we might want to launch the test through ssh?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3042splitmuxsink: not sure GAP events are handled correctly2023-10-13T15:22:43ZBugzilla Migration Usersplitmuxsink: not sure GAP events are handled correctly## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764648)](https://bugzilla.gnome.org/show_bug.cgi?id=764648)**
## Description
Reading that code, I find 2 things supsicious:
- GAP events are not catched in...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764648)](https://bugzilla.gnome.org/show_bug.cgi?id=764648)**
## Description
Reading that code, I find 2 things supsicious:
- GAP events are not catched in handle_mq_input(), that means ctx->in_running_time won't be updated. In case of a long gap, that means it's going to queue other streams a lot because the stream with a gap won't be considered ready to let GOPs out. I think in_running_time should be set to gap's timestamp+duration, no?
- GAP's duration is not taken into account in handle_mq_output(). In the case of a long gap, that means out_running_time will stay in the past, and complete_or_wait_on_out() won't send EOS until we get the next buffer/gap on that stream which could freeze the pipeline for some time.
I'm not really sure how gap events works, so maybe I'm just wrong here.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3040ximagesrc: Support changing resolution at runtime2023-10-12T18:40:00ZBugzilla Migration Userximagesrc: Support changing resolution at runtime## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#794761)](https://bugzilla.gnome.org/show_bug.cgi?id=794761)**
## Description
Changing resolution at runtime is not supported when using ximagesrc to create a screenshot...## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#794761)](https://bugzilla.gnome.org/show_bug.cgi?id=794761)**
## Description
Changing resolution at runtime is not supported when using ximagesrc to create a screenshot video stream.
Is it possible to workaround this issue by using additional\alternative plugin?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2936tsdemux: Not able to play HEVC video clip in pull mode2023-08-25T09:25:43ZBugzilla Migration Usertsdemux: Not able to play HEVC video clip in pull mode## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format...## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format MPEG-TS.
System: Feodra 21 64bit
Video clip URL: http://www.elecard.com/en/download/videos.html
Under Big Buck Bunny - SD, 720p and 1080p HEVC video clip
msg:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Internal data stream error.
Additional debug info:
mpegtsbase.c(1342): mpegts_base_loop (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
stream stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2892audiobasesink: get time is racy2023-08-08T16:37:58ZBugzilla Migration Useraudiobasesink: get time is racy## Submitted by Philippe Renon
**[Link to original bug (#788562)](https://bugzilla.gnome.org/show_bug.cgi?id=788562)**
## Description
Here is a simplified version of the get_time method:
```
/* we call this function without hol...## Submitted by Philippe Renon
**[Link to original bug (#788562)](https://bugzilla.gnome.org/show_bug.cgi?id=788562)**
## Description
Here is a simplified version of the get_time method:
```
/* we call this function without holding the lock on sink for performance
* reasons. Try hard to not deal with and invalid ringbuffer and rate. */
static GstClockTime
gst_audio_base_sink_get_time (GstClock * clock, GstAudioBaseSink * sink)
{
[SNIP]
/* our processed samples are always increasing */
samples = gst_audio_ring_buffer_samples_done (ringbuffer); (1)
/** racy if a new sample is written when we are here... */
/* the number of samples not yet processed, this is still queued in the
* device (not played for playback). */
delay = gst_audio_ring_buffer_delay (ringbuffer); (2)
samples -= delay;
result = gst_util_uint64_scale_int (samples, GST_SECOND, rate);
return result;
}
```
It computes the time as time = samples - delay.
Where samples is the number of samples that have been written to the audio device and delay represents how much remains to be played by the device.
The race condition happens like this:
- samples value is gotten at line (1)
- a new sample is written to the device (but the samples variable does not account for it)
- delay value is gotten at (2) and is bigger than expected because of new sample that was written
If this happens then the delay is too big and when it gets subtracted to samples, the resulting time goes backwards (by 10ms in my case which corresponds I believe to the duration of a sample).
I don't know how to fix this issue because there are three classes involved : the audiobasesink, the audioringbugger and the specific sink (a directsoundsink in my case). The specific sink is involved because the get_delay method is implemented there.
There are solutions to mitigate the issue:
1. Get the delay before getting the samples
This will not solve the race condition but will make it less likely to happen.
If it happens, the clock will jump forward (and might jump backwards on a subsequent get_time
invocation).
2. Remember the last time value returned by get_time.
If the new time is before the last time then return the last time.
On a side note, I believe that directsoundsink delay method is also racy in a similar way.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2867GstToc can not be modified using pygobject2023-07-28T12:56:44ZBugzilla Migration UserGstToc can not be modified using pygobject## Submitted by Thomas Weißschuh `@t-8ch`
**[Link to original bug (#796889)](https://bugzilla.gnome.org/show_bug.cgi?id=796889)**
## Description
Created attachment 373196
reproduction case
When using pygobject it is not possi...## Submitted by Thomas Weißschuh `@t-8ch`
**[Link to original bug (#796889)](https://bugzilla.gnome.org/show_bug.cgi?id=796889)**
## Description
Created attachment 373196
reproduction case
When using pygobject it is not possible to create and modify and GstToc.
Modifications abort with:
(test.py:25237): GStreamer-CRITICAL **: 20:57:54.160: gst_toc_append_entry: assertion 'gst_mini_object_is_writable (GST_MINI_OBJECT_CAST (toc))' failed
The problem lies in the fact, that the GstToc is in reality a GstMiniObject.
Unfortunately there is no way to access the relevant methods/macros from python and raw casting from toc to miniobject is also not possible.
A reproduction case is attached.
**Attachment 373196**, "reproduction case":
[test.py](/uploads/7437fc40786b489654678a96d67d4a99/test.py)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2825RTP OPUS payloader/depayloader introduce delay which is not compensated properly2023-07-18T16:45:01ZBugzilla Migration UserRTP OPUS payloader/depayloader introduce delay which is not compensated properly## Submitted by Daniel F
**[Link to original bug (#796508)](https://bugzilla.gnome.org/show_bug.cgi?id=796508)**
## Description
Following pipeline creates testout.wav file with two channels. First one comes from audiotestsrc element...## Submitted by Daniel F
**[Link to original bug (#796508)](https://bugzilla.gnome.org/show_bug.cgi?id=796508)**
## Description
Following pipeline creates testout.wav file with two channels. First one comes from audiotestsrc element, without extra processing. 2nd one is the same audio, passed via opusenc/rtpopuspay/rtpopusdepay/opusdec. When you check generated file, you will find that there is 6ms delay between 2nd and 1st channel:
```
gst-launch-1.0 audiointerleave name=int start-time-selection=first audiotestsrc wave=ticks is-live=true do-timestamp=true ! tee name=tee ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x1,rate=(int)48000" ! queue ! int.sink_0 tee. ! queue ! audioconvert ! audioresample ! opusenc ! rtpopuspay min-ptime=20000000 max-ptime=20000000 ! capsfilter caps="application/x-rtp,media=(string)audio,encoding-name=(string)OPUS,payload=(int)97" ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x2" ! queue ! int.sink_1 int.src ! audioconvert ! audioresample ! wavenc ! filesink location=testout.wav sync=true
```
When I removed rtpopuspay/rtpopusdepay from pipeline, this extra delay disappeared and both channels were properly synchronized:
```
gst-launch-1.0 audiointerleave name=int start-time-selection=first audiotestsrc wave=ticks is-live=true do-timestamp=true ! tee name=tee ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x1,rate=(int)48000" ! queue ! int.sink_0 tee. ! queue ! audioconvert ! audioresample ! opusenc ! opusdec ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x2" ! queue ! int.sink_1 int.src ! audioconvert ! audioresample ! wavenc ! filesink location=testout.wav sync=true
```
I also tried to create pipeline with PCMA codecs/payloaders, and this one also is properly synchronized:
```
gst-launch-1.0 audiointerleave name=int start-time-selection=first audiotestsrc wave=ticks is-live=true do-timestamp=true ! tee name=tee ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x1,rate=(int)8000" ! queue ! int.sink_0 tee. ! queue ! audioconvert ! audioresample ! alawenc ! rtppcmapay min-ptime=20000000 max-ptime=20000000 ! capsfilter caps="application/x-rtp,media=(string)audio,encoding-name=(string)PCMA,payload=(int)8" ! rtppcmadepay ! alawdec ! audioconvert ! audioresample ! capsfilter caps="audio/x-raw,channels=(int)1,channel-mask=(bitmask)0x2" ! queue ! int.sink_1 int.src ! audioconvert ! audioresample ! wavenc ! filesink location=testout.wav sync=true
```
Version: 1.14.1 (reproduced in 1.23.0, too)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2813Gst.ValueList leaking memory2023-07-13T16:49:50ZBugzilla Migration UserGst.ValueList leaking memory## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#795305)](https://bugzilla.gnome.org/show_bug.cgi?id=795305)**
## Description
Created attachment 370993
reproduction script (python)
While working on a...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#795305)](https://bugzilla.gnome.org/show_bug.cgi?id=795305)**
## Description
Created attachment 370993
reproduction script (python)
While working on a python script that reads spectrum messages, i noticed that casting a Gst.ValueList does leak memory, as well as printing it.
Tapping directly into the array attribute does not trigger the leak.
I don't see what could cause this in the python gi override itself (https://cgit.freedesktop.org/gstreamer/gst-python/tree/gi/overrides/Gst.py#n535)
I am unsure whether this could be lower level than the gst-python overrides, please let me know if i should open a ticket somewhere else.
**Attachment 370993**, "reproduction script (python)":
[gst_valuelist_leak.py](/uploads/4a71148985c2935d073da9aea341069d/gst_valuelist_leak.py)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2812Data is none in buffer from GstVideo.VideoFrame2023-07-13T16:45:58ZBugzilla Migration UserData is none in buffer from GstVideo.VideoFrame## Submitted by Dineth W
**[Link to original bug (#794744)](https://bugzilla.gnome.org/show_bug.cgi?id=794744)**
## Description
Hey,
When trying to get buffer data from GstVideo.VideoFrame when inheriting from GstVideo.VideoFil...## Submitted by Dineth W
**[Link to original bug (#794744)](https://bugzilla.gnome.org/show_bug.cgi?id=794744)**
## Description
Hey,
When trying to get buffer data from GstVideo.VideoFrame when inheriting from GstVideo.VideoFilter using do_transform_frame.
Steps to Reproduce:
Run code below and it will show none for buffer
Actual Results:
No data in buffer
Black screen from ximagesink(which may be because i have to push outframe back. Dont know if i need to since i dont change any of the frame.)
Expected Results:
Gives a Gst.Buffer which should hold a full image frame to be manipulated (in the docs here https://lazka.github.io/pgi-docs/GstVideo-1.0/classes/VideoFrame.html it says that a Gst.Buffer will be returned)
Build Date & Hardware:
March 26 2018 on ubuntu 16.04 LTS
Additional Builds and Platforms:
Havnt tested on any other builds
Additional Information:
I believe my Gstreamer version is
gst-launch-1.0 version 1.8.3
GStreamer 1.8.3
https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
This was found by using gst-launch-1.0 --version in the command prompt
The buffer is None. Here is some sample code, let me know if i should post anything else or if i can help. Thanks for your time.
```python
import sys
import gi
gi.require_version('Gst', '1.0')
gi.require_version('GstVideo', '1.0')
from gi.repository import GObject, Gst, GstVideo
Gst.init(sys.argv)
GObject.threads_init()
Gst.segtrap_set_enabled(False)
class GstTimestamp(GstVideo.VideoFilter):
__gstmetadata__ = ('`<longname>`', '`<classification>`',
'`<description>`', '`<author>`')
__gsttemplates__ = (Gst.PadTemplate.new("sink",
Gst.PadDirection.SINK,
Gst.PadPresence.ALWAYS,
Gst.Caps.new_any()),
Gst.PadTemplate.new("src",
Gst.PadDirection.SRC,
Gst.PadPresence.ALWAYS,
Gst.Caps.new_any()))
def __init__(self):
GstVideo.VideoFilter.__init__(self)
def do_transform_frame(self,inframe,outframe):
#this should give me that data for the frame
data = inframe.buffer
#data is None
print data
#dont know if im properly sending data back since
#i just get blank screen
return Gst.FlowReturn.OK
#used for registration
def plugin_init(plugin):
Gst.Element.register(plugin, 'timestamper', 0,
GObject.type_register(GstTimestamp))
return True
def init():
version = Gst.version()
Gst.Plugin.register_static(
version[0], version[1], 'timestamper', 'Timestamper',
plugin_init, '1.0', 'GPL', 'timestamper',
'plugins-demo', 'demo')
init()
def connect(bus, name):
def _connect(f):
bus.connect(name, f)
return f
return _connect
def main():
pipeline = Gst.parse_launch('videotestsrc ! timestamper ! ximagesink')
bus = pipeline.get_bus()
bus.add_signal_watch()
#Gst.debug_set_active(True)
#Gst.debug_set_default_threshold(4)
@connect(bus, "message::error")
def on_error(bus, message):
pipeline.set_state(Gst.State.NULL)
exit(message.parse_error())
@connect(bus, "message::eos")
def on_eos(bus, message):
pipeline.set_state(Gst.State.NULL)
exit(0)
pipeline.set_state(Gst.State.PLAYING)
loop = GObject.MainLoop()
try:
loop.run()
except(KeyboardInterrupt):
pass
pipeline.set_state(Gst.State.NULL)
if __name__ == '__main__':
main()
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2802mpegtsmux: mux private data streams2023-10-01T20:31:56ZBugzilla Migration Usermpegtsmux: mux private data streams## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpeg...## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpegtsmux is not capable of muxing them. So, if you want to transcode a TS, but keep all non-audio/video streams as-is, this is not possible.
This is a request to add private data stream support to mpegtsmux.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2800qtdemux: Support sidx based seek in pull mode2023-07-11T09:58:12ZBugzilla Migration Userqtdemux: Support sidx based seek in pull mode## Submitted by Seungha Yang
**[Link to original bug (#764629)](https://bugzilla.gnome.org/show_bug.cgi?id=764629)**
## Description
qtdemux: Support sidx based seek in pull mode
tfra atom assists seeking to random access point....## Submitted by Seungha Yang
**[Link to original bug (#764629)](https://bugzilla.gnome.org/show_bug.cgi?id=764629)**
## Description
qtdemux: Support sidx based seek in pull mode
tfra atom assists seeking to random access point. Because it is not mandatory,
however, it is not desirable to rely only on it. In this context, sidx box
can help seek for fragmented file.
This patch enables qtdemux to seek for fragmented file if only sidx available
(i.e., there is no tfra box in a file).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2781Gst.Bin __init__ changed behavior between 1.10 and 1.12 GStreamer version2023-07-06T16:40:08ZBugzilla Migration UserGst.Bin __init__ changed behavior between 1.10 and 1.12 GStreamer version## Submitted by Andreu N
**[Link to original bug (#789055)](https://bugzilla.gnome.org/show_bug.cgi?id=789055)**
## Description
In version 1.10 Gst.Bin component behaved like a regular GObject class used in python. I mean, you could...## Submitted by Andreu N
**[Link to original bug (#789055)](https://bugzilla.gnome.org/show_bug.cgi?id=789055)**
## Description
In version 1.10 Gst.Bin component behaved like a regular GObject class used in python. I mean, you could define a new component using Gst.Bin as parent, define properties as GObject.ParamFlags.CONSTRUCT_ONLY and pass values to __init__ method in order to set them.
class MyBin(Gst.Bin):
foo = GObject.Property(type=str,
flags=GObject.ParamFlags.CONSTRUCT_ONLY |
GObject.ParamFlags.READWRITE)
def __init__(self, *args, **kwargs):
Gst.Bin.__init__(self, *args, **kwargs)
# your stuff
my_bin = MyBin(foo='bar')
But currently in Gst version 1.12 it raise an error because it does not pass properties to GObject.Object.__init__.
TypeError: __init__() got an unexpected keyword argument 'foo'
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2780gi.repository.Gst is no dict2023-07-06T16:32:47ZBugzilla Migration Usergi.repository.Gst is no dict## Submitted by Fnoop
**[Link to original bug (#776573)](https://bugzilla.gnome.org/show_bug.cgi?id=776573)**
## Description
Platform: Ubuntu 16.04 arm7l
Gstreamer 1.10.2 compiled from source into custom location (/srv/maverick...## Submitted by Fnoop
**[Link to original bug (#776573)](https://bugzilla.gnome.org/show_bug.cgi?id=776573)**
## Description
Platform: Ubuntu 16.04 arm7l
Gstreamer 1.10.2 compiled from source into custom location (/srv/maverick/software/gstreamer) with usual bunch of plugins (good/bad/ugly/libav). All plugins work except python:
Total count: 175 plugins (1 blacklist entry not shown), 1261 features
Blacklisted files:
libgstpythonplugin.so
Configure:
```
PKG_CONFIG_PATH=/srv/maverick/software/gstreamer/lib/pkgconfig LDFLAGS=-Wl,-rpath,/srv/maverick/software/gstreamer/lib ./autogen.sh --with-libpython-dir=/usr/lib/arm-linux-gnueabihf --prefix=/srv/maverick/software/gstreamer
```
Typelib set in
```
GI_TYPELIB_PATH=/srv/maverick/software/gstreamer/lib/girepository-1.0:/usr/lib/girepository-1.0
```
Result of `gst-inspect-1.0 --gst-disable-registry-update --gst-debug=4 /srv/maverick/software/gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so`:
```
0:00:00.001112829 12755 0x37280 INFO GST_INIT gstmessage.c:126:_priv_gst_message_initialize: init messages
0:00:00.003132362 12755 0x37280 INFO GST_INIT gstcontext.c:83:_priv_gst_context_initialize: init contexts
0:00:00.004453232 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:316:_priv_gst_plugin_initialize: registering 0 static plugins
0:00:00.004800606 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:224:gst_plugin_register_static: registered static plugin "static
elements"
0:00:00.004834814 12755 0x37280 INFO GST_PLUGIN_LOADING gstplugin.c:226:gst_plugin_register_static: added static plugin "staticeleme
nts", result: 1
0:00:00.004906564 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1738:ensure_current_registry: reading registry cache: /srv/maverick/
.cache/gstreamer-1.0/registry.armv7l.bin
0:00:00.005417853 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:537:priv_gst_registry_binary_read_cache: Unable to mmap file /
srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin : Failed to open file '/srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin': open() failed: No such file or direct
ory
0:00:00.005471145 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:547:priv_gst_registry_binary_read_cache: Unable to read file /
srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin : Failed to open file '/srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin': No such file or directory
0:00:00.005501561 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1594:scan_and_update_registry: Validating plugins from registry cach
e: /srv/maverick/.cache/gstreamer-1.0/registry.armv7l.bin
** (gst-plugin-scanner:12756): CRITICAL **: gi.repository.Gst is no dict
0:00:01.728468407 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1705:scan_and_update_registry: Registry cache changed. Writing new r
egistry cache
0:00:01.728540032 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:368:priv_gst_registry_binary_write_cache: Building binary regi
stry cache image
0:00:01.920471827 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:400:priv_gst_registry_binary_write_cache: Writing binary regis
try cache
0:00:02.137670728 12755 0x37280 INFO GST_REGISTRY gstregistrybinary.c:261:gst_registry_binary_cache_finish: Wrote binary registry ca
che
0:00:02.137935226 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1714:scan_and_update_registry: Registry cache written successfully
0:00:02.137977060 12755 0x37280 INFO GST_REGISTRY gstregistry.c:1773:ensure_current_registry: registry reading and updating done, re
sult = 1
0:00:02.138021643 12755 0x37280 INFO GST_INIT gst.c:720:init_post: GLib runtime version: 2.48.1
0:00:02.138071184 12755 0x37280 INFO GST_INIT gst.c:722:init_post: GLib headers version: 2.48.1
0:00:02.138114517 12755 0x37280 INFO GST_INIT gst.c:723:init_post: initialized GStreamer successfully
** (gst-inspect-1.0:12755): CRITICAL **: gi.repository.Gst is no dict
0:00:02.337317658 12755 0x37280 WARN GST_PLUGIN_LOADING gstplugin.c:526:gst_plugin_register_func: plugin "/srv/maverick/software/
gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so" failed to initialise
Could not load plugin file: File "/srv/maverick/software/gstreamer/lib/gstreamer-1.0/libgstpythonplugin.so" appears to be a GStreamer plugin, but it failed to initialize
```
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2778Port gst-python tests and examples to 1.02023-07-06T16:10:31ZBugzilla Migration UserPort gst-python tests and examples to 1.0## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#706699)](https://bugzilla.gnome.org/show_bug.cgi?id=706699)**
## Description
It is currently disabled but it would be quite nice to bring them back.## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#706699)](https://bugzilla.gnome.org/show_bug.cgi?id=706699)**
## Description
It is currently disabled but it would be quite nice to bring them back.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2773rtspsrc: protocols=http doesn't work with gst-rtsp-server examples2023-07-06T10:18:15ZBugzilla Migration Userrtspsrc: protocols=http doesn't work with gst-rtsp-server examples## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols...## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols=http location="rtsp://127.0.0.1:8554/test" ! fakesink
against an (gst-rtsp-server/examples) example (test-video) server does not work.
If using protocols tcp or default it works.
Attach logs from server(test-video) and client(rtspsrc protocols=http)
**Attachment 368399**, "logs from server":
[test-video_log.txt](/uploads/179cedbabfb20303dcbb8c8bb4809d7e/test-video_log.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2772flvmux: dts/pts on output buffers2023-07-06T14:53:46ZBugzilla Migration Userflvmux: dts/pts on output buffers## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initiall...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initially created as a clone of [Bug 793457](https://bugzilla.gnome.org/show_bug.cgi?id=793457) +++
$ gst-launch-1.0 videotestsrc ! x264enc ! flvmux ! fakesink silent=false -v | grep -e Segment -e chain | head -n 5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2770mpeg4videoparse: Need detect picture coding type when drain2023-07-06T09:54:03ZBugzilla Migration Usermpeg4videoparse: Need detect picture coding type when drain## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame....## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame. mpeg4videoparse will detect coding type when detect start code after VOP. our use case will drain after VOP and can't detect start code after VOP. Add check coding type code when drain.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2768Unable to send an EOS event to an adaptative demux pipeline such as HLS or DASH2023-07-06T10:52:00ZBugzilla Migration UserUnable to send an EOS event to an adaptative demux pipeline such as HLS or DASH## Submitted by parithi
**[Link to original bug (#795607)](https://bugzilla.gnome.org/show_bug.cgi?id=795607)**
## Description
I am trying to decode hls stream with following pipeline
```
$ gst-launch-1.0 souphttpsrc location=...## Submitted by parithi
**[Link to original bug (#795607)](https://bugzilla.gnome.org/show_bug.cgi?id=795607)**
## Description
I am trying to decode hls stream with following pipeline
```
$ gst-launch-1.0 souphttpsrc location=http://10.0.90.12:80/live/scte/master_1.m3u8 ! hlsdemux ! queue ! decodebin ! video/x-raw ! x264enc ! h264parse ! mpegtsmux ! udpsink port=8888 host=10.0.100.24 -e
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
`^`Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...
```
if I stop the playback by pressing "ctl+c" pipeline is not closing, it keeps on playing.
From my initial investigation found out that basesrc received EOS event but it is not propagated to downstream elements.
Version: 1.14.0