gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2023-10-06T13:24:52Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1[matroskamux] doesn't add references between I/B/P frames2023-10-06T13:24:52ZBugzilla Migration User[matroskamux] doesn't add references between I/B/P frames## Submitted by John Cannon
**[Link to original bug (#140783)](https://bugzilla.gnome.org/show_bug.cgi?id=140783)**
## Description
When muxing an AVI containing XviD video and MP3 audio into a MKV with the
matroskamux element it p...## Submitted by John Cannon
**[Link to original bug (#140783)](https://bugzilla.gnome.org/show_bug.cgi?id=140783)**
## Description
When muxing an AVI containing XviD video and MP3 audio into a MKV with the
matroskamux element it produces an invalid file with the following problems:
1) It sets the codec ID in the file to the native mpeg-4 identifier which is
wrong unless the framing meets extra requirements. Until you add mpeg4 frame
referencing you should use the VfW compatibility ID.
2) No references are written at all.
3) No track UID is written for the tracks.
4) Clusters are extremely small. You should put more frames in each cluster, ie
500ms.
### Blocking
* [Bug 309429](https://bugzilla.gnome.org/show_bug.cgi?id=309429)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/2matroskademux: support for multi-segment Matroska files2023-10-06T13:24:53ZBugzilla Migration Usermatroskademux: support for multi-segment Matroska files## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segme...## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segment without allowing you to switch to another one.
Unfortunatly, I can't upload an example file (I've seen this with a 4Go file).
Perhaps is there one in the Gstreamer test suite ?
Following Haali on #matroska, it's not about chapter but about segment.
Most files are one segment only and totem only support one segment (as all
others *NIX players).
My file is multi-segment, which is one step over chapters. (If I understand
correctly the spec, each segment can have his own tracks and chapters. Chapters
are only "bookmarks" in a big file)
The spec : http://www.matroska.org/technical/specs/index.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/3avidemux, qtdemux, dvdec: signal DVCPRO50 codec properly2023-10-06T13:24:53ZBugzilla Migration Useravidemux, qtdemux, dvdec: signal DVCPRO50 codec properly## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffde...## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffdec_dvvideo is able to decode those files properly
but totem chooses dvdec, not sure how to fix that.
playing them via gst-launch works:
gst-launch filesrc location=test.mov ! qtdemux ! ffdec_dvvideo ! ffmpegcolorspace ! xvimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/4RTP depayloaders should send tags with metadata such as codec and bitrate2023-10-06T13:24:54ZBugzilla Migration UserRTP depayloaders should send tags with metadata such as codec and bitrate## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of strea...## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of stream. More importantly though the plugins in question seem to report no information for Totem's proprties tab. Totem screenshot attached.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/5qtdemux: Support chapters2023-10-06T13:24:54ZBugzilla Migration Userqtdemux: Support chapters## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files ...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files such as:
http://downloads.oreilly.com/make/MAKE_2005-07-18.m4b
### Depends on
* [Bug 540890](https://bugzilla.gnome.org/show_bug.cgi?id=540890)
### Blocking
* [Bug 163546](https://bugzilla.gnome.org/show_bug.cgi?id=163546)
* [Bug 328298](https://bugzilla.gnome.org/show_bug.cgi?id=328298)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/7rtp: add minimal docs for payloaders and depayloaders2023-10-13T14:50:55ZBugzilla Migration Userrtp: add minimal docs for payloaders and depayloaders## Submitted by Venkatachala Upadhya
**[Link to original bug (#551631)](https://bugzilla.gnome.org/show_bug.cgi?id=551631)**
## Description
Hello kind people,
I am not able to access the following URLs
http://gstreamer.fre...## Submitted by Venkatachala Upadhya
**[Link to original bug (#551631)](https://bugzilla.gnome.org/show_bug.cgi?id=551631)**
## Description
Hello kind people,
I am not able to access the following URLs
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtpmp4adepay.html
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtpmpadepay.html
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtpmpapay.html
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtph264depay.html
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtph264pay.html
Thanks!
WBR,
Venkat.
--https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/8multifilesrc: fix seeking support2023-10-06T13:25:00ZBugzilla Migration Usermultifilesrc: fix seeking support## Submitted by Jorge
**[Link to original bug (#555260)](https://bugzilla.gnome.org/show_bug.cgi?id=555260)**
## Description
I build a pipeline like this:
multifilesrc ! jpegdec ! ffmpegcolorspace !videosink
(where multifi...## Submitted by Jorge
**[Link to original bug (#555260)](https://bugzilla.gnome.org/show_bug.cgi?id=555260)**
## Description
I build a pipeline like this:
multifilesrc ! jpegdec ! ffmpegcolorspace !videosink
(where multifilesrc has a "image/jpeg,framerate=15/1" cap for correct playing)
I can make it play/pause/stop, but it won't seek nor allow query for a position. Using from pyhton:
pos = self.player.pipeline.query_position(gst.FORMAT_DEFAULT, None)[0]
returns the following error:
gst.QueryError: query failed
And doing
self.player.pipeline.seek_simple(gst.FORMAT_DEFAULT, gst.SEEK_FLAG_FLUSH, 3)
does nothing (nor error, nor seeking). From trying stuff it seems as if multifilesrc only respects it's "index" property.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/826Wayland Env gst-launch-1.0 ximagesrc recording screen cannot play2021-01-26T16:43:02ZmouseWayland Env gst-launch-1.0 ximagesrc recording screen cannot playI'm in``` Wayland``` Env use it ```gst-launch-1.0 ximagesrc endx=1919 endy=1079 use-damage=false ! video/x-raw,framerate=15/1 ! videoconvert ! vp8enc min_quantizer=13 max_quantizer=13 cpu-used=5 deadline=1000000 threads=2 ! queue ! web...I'm in``` Wayland``` Env use it ```gst-launch-1.0 ximagesrc endx=1919 endy=1079 use-damage=false ! video/x-raw,framerate=15/1 ! videoconvert ! vp8enc min_quantizer=13 max_quantizer=13 cpu-used=5 deadline=1000000 threads=2 ! queue ! webmmux ! filesink location=/tmp/test.webm ```To record the current screen。I can get the right documents。But when I use VLC to play this video, it's wrong ```vlc /tmp/test.webm ```And with ```Xorg```, it's finehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/11matroskademux: fails to output data for video stream2023-10-06T13:25:03ZBugzilla Migration Usermatroskademux: fails to output data for video stream## Submitted by heb..@..il.com
**[Link to original bug (#580980)](https://bugzilla.gnome.org/show_bug.cgi?id=580980)**
## Description
Please describe the problem:
When I try to play a mkv file which happens to have a secondary aud...## Submitted by heb..@..il.com
**[Link to original bug (#580980)](https://bugzilla.gnome.org/show_bug.cgi?id=580980)**
## Description
Please describe the problem:
When I try to play a mkv file which happens to have a secondary audio vorbis (comments) Totem fails to decode stream.
here is the output:
(totem:12303): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstice.so': libjinglep2pbase-0.3.so.0: cannot open shared object file: No such file or directory
(totem:12302): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstice.so': libjinglep2pbase-0.3.so.0: cannot open shared object file: No such file or directory
** (totem:12302): DEBUG: Init of Python module
** (totem:12302): DEBUG: Registering Python plugin instance: YouTube+TotemPythonPlugin
** (totem:12302): DEBUG: Creating object of type YouTube+TotemPythonPlugin
** (totem:12302): DEBUG: Creating Python plugin instance
** (totem:12302): DEBUG: Init of Python module
** (totem:12302): DEBUG: Registering Python plugin instance: BBCViewer+TotemPythonPlugin
** (totem:12302): DEBUG: Creating object of type BBCViewer+TotemPythonPlugin
** (totem:12302): DEBUG: Creating Python plugin instance
Stream with high frequencies VQ coding
** Message: Error: Could not decode stream.
vorbisdec.c(815): vorbis_handle_header_packet (): /GstPlayBin:play/GstDecodeBin:decodebin1/GstVorbisDec:vorbisdec0:
couldn't read header packet
Steps to reproduce:
1. download this sample file: http://drop.io/co7xlpv
2. open totem
3. drag'n drop to totem the sample file containing secondary audio (vorbis)
Actual results:
An error message: Totem fails to decode stream.
Expected results:
Does this happen every time?
it happened every single time I've tried to play it
Other information:
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/14v4l2: Implement V4L2_MEMORY_DMABUF/USERPTR support2023-10-06T13:25:04ZBugzilla Migration Userv4l2: Implement V4L2_MEMORY_DMABUF/USERPTR support## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#583890)](https://bugzilla.gnome.org/show_bug.cgi?id=583890)**
## Description
v4l2src uses own mmapped buffer pool, but should ideall request buffers from xvideo for ze...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#583890)](https://bugzilla.gnome.org/show_bug.cgi?id=583890)**
## Description
v4l2src uses own mmapped buffer pool, but should ideall request buffers from xvideo for zerocopy. initial patch follows.
### Blocking
* [Bug 796986](https://bugzilla.gnome.org/show_bug.cgi?id=796986)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/17caca: Cleanups and fixes2023-10-16T14:48:09ZBugzilla Migration Usercaca: Cleanups and fixes## Submitted by Priit Laes `@plaes`
**[Link to original bug (#599018)](https://bugzilla.gnome.org/show_bug.cgi?id=599018)**
## Description
Created attachment 145832
0001-Exit-properly-when-invalid-driver-has-been-selected.patch
...## Submitted by Priit Laes `@plaes`
**[Link to original bug (#599018)](https://bugzilla.gnome.org/show_bug.cgi?id=599018)**
## Description
Created attachment 145832
0001-Exit-properly-when-invalid-driver-has-been-selected.patch
Currently, when specifying a driver that doesn't exist causes crash in
cacasink.
**Patch 145832**, "0001-Exit-properly-when-invalid-driver-has-been-selected.patch":
[0001-Exit-properly-when-invalid-driver-has-been-selected.patch](/uploads/1cf1fd6037b47d0de45b26a7bd36e1a2/0001-Exit-properly-when-invalid-driver-has-been-selected.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/19audiofirfilter: Add support for changing kernel size without draining the sam...2023-10-06T13:25:09ZBugzilla Migration Useraudiofirfilter: Add support for changing kernel size without draining the sample history## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#606322)](https://bugzilla.gnome.org/show_bug.cgi?id=606322)**
## Description
It would be nice if draining the history could be prevented when changing the kernel siz...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#606322)](https://bugzilla.gnome.org/show_bug.cgi?id=606322)**
## Description
It would be nice if draining the history could be prevented when changing the kernel size too. Currently it's only supported if the kernel size stays the same.
Following are some patches that partially implement this and some notes on what still needs to be done.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/20decodebin3: Race with caps changing in stream2023-10-06T13:25:09ZBugzilla Migration Userdecodebin3: Race with caps changing in stream## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#607471)](https://bugzilla.gnome.org/show_bug.cgi?id=607471)**
## Description
While playing the following file, I do not see the video, only a still image:
http://s...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#607471)](https://bugzilla.gnome.org/show_bug.cgi?id=607471)**
## Description
While playing the following file, I do not see the video, only a still image:
http://samples.mplayerhq.hu/archive/container/mov/mov+svq3+aac++animatrix_2_program_640-sample.mov
gst-launch then quits with the following error:
$ gst-launch playbin2 uri=file:///$PWD/mov+svq3+aac++animatrix_2_program_640-sample.mov
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstJpegDec:jpegdec0: Failed to decode JPEG image
Additional debug info:
gstjpegdec.c(1261): gst_jpeg_dec_chain (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstJpegDec:jpegdec0:
Error` #70`: Unsupported marker type 0x%02x
Execution ended after 3505994408 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
----
FWIW, I noticed that the stream topology that gets posted looks like this:
CONTAINER: video/quicktime
AUDIO: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, codec_data=(buffer)1210, rate=(int)44100, channels=(int)2
AUDIO: audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2
UNKNOWN: image/jpeg, width=(int)640, height=(int)272, framerate=(fraction)15/1
VIDEO: video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)272, framerate=(fraction)15/1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/22avidemux: Doesn't handle files with large gaps between audio/video streams pr...2023-10-06T13:25:11ZBugzilla Migration Useravidemux: Doesn't handle files with large gaps between audio/video streams properly## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#608945)](https://bugzilla.gnome.org/show_bug.cgi?id=608945)**
## Description
Open bug in lauchpad.net:
https://bugs.edge.launchpad.net/ubuntu/+source/gs...## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#608945)](https://bugzilla.gnome.org/show_bug.cgi?id=608945)**
## Description
Open bug in lauchpad.net:
https://bugs.edge.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/516832
loop in gstpad.c
"$ LANGUAGE=C GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem 2> log
0:00:00.091962270 4404 0x99e0080 WARN pyplugin gstpythonplugin.c:343:plugin_init: Couldn't g_module_open libpython. Reason: /usr/lib/libpython2.6.so: cannot open shared object file: No such file or directory
0:00:00.092094409 4404 0x99e0080 WARN GST_PLUGIN_LOADING gstplugin.c:422:gst_plugin_register_func: plugin "/usr/lib/gstreamer-0.10/libgstpython.so" failed to initialise
0:00:00.093664162 4404 0x99e0080 WARN GST_PLUGIN_LOADING gstplugin.c:422:gst_plugin_register_func: plugin "/usr/lib/gstreamer-0.10/libgstladspa.so" failed to initialise
(totem:4403): GLib-GObject-WARNING **: value "10752000" of type `guint' is invalid or out of range for property `connection-speed' of type `guint'
0:00:05.426087788 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426199813 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
0:00:05.426238924 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426270213 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
0:00:05.426303737 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426333629 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
..."
### See also
* https://launchpad.net/bugs/516832https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/24multifile: add support for reading filenames from a list file2023-07-02T19:34:22ZBugzilla Migration Usermultifile: add support for reading filenames from a list file## Submitted by Jonathan Matthew
**[Link to original bug (#615166)](https://bugzilla.gnome.org/show_bug.cgi?id=615166)**
## Description
Created attachment 158188
listfilesrc element
After watching someone on IRC struggling wi...## Submitted by Jonathan Matthew
**[Link to original bug (#615166)](https://bugzilla.gnome.org/show_bug.cgi?id=615166)**
## Description
Created attachment 158188
listfilesrc element
After watching someone on IRC struggling with multifilesrc for the nth time, I figured it'd be easier to use in some cases if you could give it a file containing a list of source files, rather than having to number the files sequentially.
What I'm attaching is a quick hack based on multifilesrc. It might be worth considering adding the functionality to multifilesrc rather than creating a new element, or sharing the common code (which is most of it) some other way.
**Attachment 158188**, "listfilesrc element":
[gstlistfilesrc.c](/uploads/c4b74b9c9103177a0997dec56f5841e6/gstlistfilesrc.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/31mpegaudioparse: Add support for LAME tags and adjust segments based on the pa...2022-05-04T19:50:42ZBugzilla Migration Usermpegaudioparse: Add support for LAME tags and adjust segments based on the padding information from it## Submitted by nyall
**[Link to original bug (#620323)](https://bugzilla.gnome.org/show_bug.cgi?id=620323)**
## Description
Currently, gstreamer is ignoring the lame tags in mp3s during gapless playback. These tags contain informat...## Submitted by nyall
**[Link to original bug (#620323)](https://bugzilla.gnome.org/show_bug.cgi?id=620323)**
## Description
Currently, gstreamer is ignoring the lame tags in mp3s during gapless playback. These tags contain information about the padding at the start and end of the files, which should be skipped to get perfect gapless playback of these files. Without using these tags, there'll always be a tiny silence or glitch between songs.
Here's an example of the lame tags in a file which should play back gaplessly:
$eyeD3 --lametag Track01.mp3
Track01.mp3 [ 3.77 MB ]
Encoder Version : LAME3.98r
LAME Tag Revision : 0
VBR Method : Variable Bitrate method2 (mtrh)
Lowpass Filter : 18500
Radio Replay Gain : -2.0 dB (Set automatically)
Encoding Flags : --nspsytune --nssafejoint
ATH Type : 4
Bitrate (Minimum) : 192
Encoder Delay : 576 samples
Encoder Padding : 960 samples
Noise Shaping : 1
Stereo Mode : Joint
Unwise Settings : False
Sample Frequency : 44.1 kHz
MP3 Gain : 0 (+0.0 dB)
Preset : V2
Surround Info : None
Music Length : 3.77 MB
Music CRC-16 : 07F9
LAME Tag CRC-16 : E5BF
The encoder delay and encoder padding tags describe how many samples were added at the start and end of the audio to complete the frames. Some more information is available on this page: http://gabriel.mp3-tech.org/mp3infotag.html
### Depends on
* [Bug 740196](https://bugzilla.gnome.org/show_bug.cgi?id=740196)1.21.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/39jpegdec: Pixart JPEG support2023-07-01T21:34:28ZBugzilla Migration Userjpegdec: Pixart JPEG support## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#642411)](https://bugzilla.gnome.org/show_bug.cgi?id=642411)**
## Description
Created attachment 180937
gdp payloaded stream
I've got a webcam that...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#642411)](https://bugzilla.gnome.org/show_bug.cgi?id=642411)**
## Description
Created attachment 180937
gdp payloaded stream
I've got a webcam that produces Progressive JPG frames and it seems jpegdec can't handle it.
I'm attaching the output of:
gst-launch v4l2src device=/dev/video1 num-buffers=5 ! gdppay ! filesink
**Attachment 180937**, "gdp payloaded stream":
[progressive-jpg.gdp](/uploads/e261fbf24de5d97ae6f62d54b408a510/progressive-jpg.gdp)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/46udp: add support for IGMPv3 SSM (Source Specific Multicast RFC 4604)2023-06-23T22:16:15ZBugzilla Migration Userudp: add support for IGMPv3 SSM (Source Specific Multicast RFC 4604)## Submitted by Julien Isorce `@cap`
**[Link to original bug (#652711)](https://bugzilla.gnome.org/show_bug.cgi?id=652711)**
## Description
Created attachment 190026
when joining a multicast stream, users can select the source the...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#652711)](https://bugzilla.gnome.org/show_bug.cgi?id=652711)**
## Description
Created attachment 190026
when joining a multicast stream, users can select the source they want to receive the stream from
* Overview: for now when joining a multicast stream, users cannot select the source they want to receive the stream from.
* Additional Information: The kernel configuration determines which IGMP version to use.
On linux you can select the minimum IGMP version to use.
On windows, you can only select the maximum IGMP version to use. IGMPv3 + SSM is avaible from winXP_SP1. On winXP (don't know on vista and seven) when a network interface sees a IGMPv1 or IGMPv2 it becomes impossible to send a IGMPv3 packet without restarting the network interface (http://support.microsoft.com/kb/815752)
~~**Patch 190026**~~, "when joining a multicast stream, users can select the source they want to receive the stream from":
[0001-udp-add-support-for-IGMPv3-SSM-Source-Specific-Multi.patch](/uploads/fab8301eb8905242656e9dec43e7807b/0001-udp-add-support-for-IGMPv3-SSM-Source-Specific-Multi.patch)
### Depends on
* [Bug 740791](https://bugzilla.gnome.org/show_bug.cgi?id=740791)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/47wavenc: Go EOS and report an error if larger than 2GB2024-03-07T13:02:34ZBugzilla 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/gst-plugins-good/-/issues/49multipartdemux: segfault2023-07-01T21:38:04ZBugzilla Migration Usermultipartdemux: segfault## Submitted by Nicola `@drakkan`
**[Link to original bug (#659573)](https://bugzilla.gnome.org/show_bug.cgi?id=659573)**
## Description
I have the following segfault with multipartdemux:
```
Program received signal SIGSEGV,...## Submitted by Nicola `@drakkan`
**[Link to original bug (#659573)](https://bugzilla.gnome.org/show_bug.cgi?id=659573)**
## Description
I have the following segfault with multipartdemux:
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeaed8700 (LWP 15906)]
0x00007ffff7211c60 in g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff7211c60 in g_str_hash ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff71def6d in g_hash_table_lookup ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff44d97be in gst_multipart_demux_get_gstname (
pad=<value optimized out>, buf=<value optimized out>)
at multipartdemux.c:246
#3 gst_multipart_find_pad_by_mime (pad=<value optimized out>,
buf=<value optimized out>) at multipartdemux.c:323
#4 gst_multipart_demux_chain (pad=<value optimized out>,
buf=<value optimized out>) at multipartdemux.c:589
#5 0x00007ffff7b57d0a in gst_pad_push (pad=0x7e4020, buffer=0x768180)
at gstpad.c:4710
#6 0x00007ffff50ce29a in gst_base_src_loop (pad=0x7e4020) at gstbasesrc.c:2552
#7 0x00007ffff7b7d61d in gst_task_func (task=0x6e7060) at gsttask.c:318
#8 0x00007ffff7219b16 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007ffff72173e4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff6b89d8c in start_thread (arg=0x7fffeaed8700)
at pthread_create.c:304
#11 0x00007ffff68d504d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x0000000000000000 in ?? ()
```
attacched is a dump of the stream that generate the problem, you can reproduce with:
gst-launch filesrc location=... ! multipartdemux ! ...
the stream is supposed to be audio/x-raw-int, rate=8000,channels=1,endianness=1234,width=16,depth=16,signed=truehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/50isomp4: Add support for GstForceKeyUnit events2023-07-02T16:24:35ZBugzilla Migration Userisomp4: Add support for GstForceKeyUnit events## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#660260)](https://bugzilla.gnome.org/show_bug.cgi?id=660260)**
## Description
Created attachment 197584
0002-Add-support-for-GstForceKeyUnit-events.patch
Th...## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#660260)](https://bugzilla.gnome.org/show_bug.cgi?id=660260)**
## Description
Created attachment 197584
0002-Add-support-for-GstForceKeyUnit-events.patch
The flowing patch adds support for GstForceKeyUnit events to ismlmux.
I have added a new property called 'fragment-method':
* NONE: do not fragment (default value for muxers that are not the ismlmux)
* TIME: fragment by time, set in the fragment-duration property (default value for the ismlmux, keeping the old behaviour)
* EVENT: Uses the GstForceKeyUnit event to generate fragments.
This muxer is different from the other ones (webm or mpegts) in the sense that it can mux several video qualities and the audio track is packed in a separate fragment. So to make it work the audio pad should be receiving GstForceKeyUnits too.
I have tested this patch using Flumotion's smooth streamer[1] with a pipeline similar to:
vsource ! keyunitsscheduler ! tee name=t ! h264enc ! ismlmux name=mux ! streamer
t. ! h264enc ! mux.
t. ! h264enc ! mux.
asource ! keyunitsscheduler ! aacenc ! mux.
This patch relies in the new API for GstForceKeyUnit events
[1] https://code.flumotion.com/cgit/flumotion-fragmented-streaming/
~~**Patch 197584**~~, "0002-Add-support-for-GstForceKeyUnit-events.patch":
[0002-Add-support-for-GstForceKeyUnit-events.patch](/uploads/176b0d0fd46156272a997d70b08f2e1e/0002-Add-support-for-GstForceKeyUnit-events.patch)
### Depends on
* [Bug 607742](https://bugzilla.gnome.org/show_bug.cgi?id=607742)
### Blocking
* [Bug 668091](https://bugzilla.gnome.org/show_bug.cgi?id=668091)
* [Bug 668094](https://bugzilla.gnome.org/show_bug.cgi?id=668094)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/52multipartdemux: boundary specified manually but gst quits because "Boundary n...2018-11-04T10:08:30ZBugzilla Migration Usermultipartdemux: boundary specified manually but gst quits because "Boundary not found"## Submitted by Roman Gaufman
**[Link to original bug (#665887)](https://bugzilla.gnome.org/show_bug.cgi?id=665887)**
## Description
I have a D-Link DCS-930L IP camera and when I get mjpeg from it, it looks something like this:
...## Submitted by Roman Gaufman
**[Link to original bug (#665887)](https://bugzilla.gnome.org/show_bug.cgi?id=665887)**
## Description
I have a D-Link DCS-930L IP camera and when I get mjpeg from it, it looks something like this:
# wget http://user:pass@192.168.1.15/video/mjpg.cgi mjpg.cgi contents:
Content-length: 45536
Date: 10-04-2011 07:41:20 PM IO_00000000_PT_000_000
Content-type: image/jpeg
(jpeg data)
--video boundary--
Content-length: 45607
Date: 10-04-2011 07:41:20 PM IO_00000000_PT_000_000
Content-type: image/jpeg
(jpeg data)
So the boundary is "--video boundary--" - I try to specify this to gstreamer with:
multipartdemux boundary="--video boundary--"
Yet I still get the following whether I specify the boundary or not:
Boundary not found in the multipart header
ERROR: pipeline doesn't want to preroll.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/55qtmux: Add support for DASH2023-07-01T21:39:31ZBugzilla Migration Userqtmux: Add support for DASH## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#668091)](https://bugzilla.gnome.org/show_bug.cgi?id=668091)**
## Description
Created attachment 205444
Add DASH comtaible muxer
Dash support for the ISO fi...## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#668091)](https://bugzilla.gnome.org/show_bug.cgi?id=668091)**
## Description
Created attachment 205444
Add DASH comtaible muxer
Dash support for the ISO file format has been defined in the Amendment 3 of the ISO/IEC 14496-12 standard.
Basic support can be added by appending the new 'styp', identical to the ftyp box in front of each fragment.
~~**Patch 205444**~~, "Add DASH comtaible muxer":
[0001-mp4dashmux-Add-DASH-compatible-mp4-muxer.patch](/uploads/dd2b0e8235d8c729a5b08e0f7ffb7b42/0001-mp4dashmux-Add-DASH-compatible-mp4-muxer.patch)
### Depends on
* [Bug 660260](https://bugzilla.gnome.org/show_bug.cgi?id=660260)
### Blocking
* [Bug 777984](https://bugzilla.gnome.org/show_bug.cgi?id=777984)
* [Bug 668094](https://bugzilla.gnome.org/show_bug.cgi?id=668094)
* [Bug 708221](https://bugzilla.gnome.org/show_bug.cgi?id=708221)
* [Bug 777540](https://bugzilla.gnome.org/show_bug.cgi?id=777540)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/58vp8enc: better defaults, more presets/profiles2020-01-28T07:33:40ZBugzilla Migration Uservp8enc: better defaults, more presets/profiles## Submitted by Tim Müller `@tpm`
**[Link to original bug (#670108)](https://bugzilla.gnome.org/show_bug.cgi?id=670108)**
## Description
Just some quick comments on our default values from an e-mail exchange with Ronald:
> mod...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#670108)](https://bugzilla.gnome.org/show_bug.cgi?id=670108)**
## Description
Just some quick comments on our default values from an e-mail exchange with Ronald:
> mode : Mode
> Enum "GstVP8EncMode" Default: 0, "vbr"
> (0): vbr - Variable Bit Rate (VBR) mode
> (1): cbr - Constant Bit Rate (CBR) mode
You may want to look into CQ mode (2) also.
> max-keyframe-distance: Maximum distance between key frames
> Integer. Range: 0 - 9999 Default: 60
60 is quite low (for high-quality encodes), any particular reason for that?
I think in our tests and on webmproject.org, we recommend 120 frames
as kf interval.
> multipass-mode : Multipass encode mode
> Enum "GstVP8EncMultipassMode" Default: 0, "one-pass"
> (0): one-pass - One pass encoding (default)
> (1): first-pass - First pass of multipass encoding
> (2): last-pass - Last pass of multipass encoding
Can the default be changes to 2pass? We really do all our internal
testing for high-quality encodes on 2pass, it'll generate much better
output (in the range of >1dB difference).
(tpm: can't ever default to 2-pass, since that requires co-operation by the application. 2-pass can only ever be opt-in)
> auto-alt-ref-frames : Automatically create alternative
> reference frames
> Boolean. Default: false
This isn't a good idea, alt-refs by themselves will also cause several
tenths of dB difference (in a positive way), I'd highly recommend you
turn them on for high-quality (2pass) encodes.
(tpm: only for high-quality 2-pass encodes? BBB: yes)
> lag-in-frames : If set, this value allows the encoder to consume
> a number of input frames before producing output frames.
> Unsigned Integer. Range: 0 - 64 Default: 0
Probably want to up this to e.g. 25 for high-quality encodes (unless 0
means 'don't touch').
(tpm: I think 0 means whatever the library default is, someone needs to check this)
> tune : Tune
> Enum "GstVP8EncTune" Default: 0, "psnr"
> (0): psnr - Tune for PSNR
> (1): ssim - Tune for SSIM
Minor nit, most people would claim ssim is a better default here, but
it's not that relevant.
I see you haven't mapped the ARNR options, which provide a quality
boost for noisy input (without affecting noiseless input much), are
you guys interested in exposing these options also? They affect the
way the alt-ref frame is used.
(tpm: might be good for input from webcams - though what would be even better if we could detect that kind of input and switch to that mode automatically)
Other possibly interesting pages:
http://www.webmproject.org/tools/encoder-parameters/https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/73jpegenc produces data in subsampling mode that rtpjpegpay can't handle2023-12-20T17:58:09ZBugzilla 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/gst-plugins-good/-/issues/85wavparse: doesn't detect ac3 streams marked as PCM2023-07-01T21:43:21ZBugzilla Migration Userwavparse: doesn't detect ac3 streams marked as PCM## Submitted by Putinei Ionut
**[Link to original bug (#701502)](https://bugzilla.gnome.org/show_bug.cgi?id=701502)**
## Description
Gstreamer can not detect wav files with ac3 stream.(Wavparse)## Submitted by Putinei Ionut
**[Link to original bug (#701502)](https://bugzilla.gnome.org/show_bug.cgi?id=701502)**
## Description
Gstreamer can not detect wav files with ac3 stream.(Wavparse)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/88RTSP pipeline freezes when set to a resume after a pause (PLAYING->PAUSED->PL...2018-11-04T10:15:08ZBugzilla Migration UserRTSP pipeline freezes when set to a resume after a pause (PLAYING->PAUSED->PLAYING), with Jitterbuffer in Buffering Mode## Submitted by vfu..@..ia.com
**[Link to original bug (#705355)](https://bugzilla.gnome.org/show_bug.cgi?id=705355)**
## Description
The RTP timestamp gap induced (nearly equal to the time the server/source has spent in PAUSED stat...## Submitted by vfu..@..ia.com
**[Link to original bug (#705355)](https://bugzilla.gnome.org/show_bug.cgi?id=705355)**
## Description
The RTP timestamp gap induced (nearly equal to the time the server/source has spent in PAUSED state), currently makes the jitter-buffer completely reset itself. This leads to freezing of the pipeline, due to the RTP-TS difference (equal to the time spent in PAUSED state) between the first RTP packet received after the the source/server has been set to PLAYING and the packet that was last received during the PAUSED state. This leads to a huge gap (TS discontinuity) between the first outgoing buffer from the jitter-buffer post-PAUSED (PLAYING before PAUSED) state and the last buffer that was sent pre-PAUSED (PLAYING after PAUSED) state. This leads to a long halt at the sink depending upon the time spent in PAUSED state . i.e long freeze of the pipeline.
Version: 1.1.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/92qtdemux: add support for webvtt subtitles2018-11-04T10:16:25ZBugzilla Migration Userqtdemux: add support for webvtt subtitles## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#707032)](https://bugzilla.gnome.org/show_bug.cgi?id=707032)**
## Description
Add support for WebVTT subtitles## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#707032)](https://bugzilla.gnome.org/show_bug.cgi?id=707032)**
## Description
Add support for WebVTT subtitleshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/95souphttpsrc: Need ability to exclude HTTP Range header and set content size2018-11-04T10:16:33ZBugzilla Migration Usersouphttpsrc: Need ability to exclude HTTP Range header and set content size## Submitted by Lori Anderson
**[Link to original bug (#709117)](https://bugzilla.gnome.org/show_bug.cgi?id=709117)**
## Description
Need to be able to disable the inclusion of the range header by souphttpsrc. The HTTP Range header ...## Submitted by Lori Anderson
**[Link to original bug (#709117)](https://bugzilla.gnome.org/show_bug.cgi?id=709117)**
## Description
Need to be able to disable the inclusion of the range header by souphttpsrc. The HTTP Range header is not allowed for dtcp encyrpted content. Also the HTTP Range header interferes with the usage of TimeSeekRange.dlna.org and Playspeed.dlna.org headers. The Range header should not be included when these other headers are added or for dtcp encrypted content. The proper headers will be added by the dlnasrc element which is a "manager" type element and will set the "exclude-range-header" property on souphttpsrc. The souphttpsrc will still use the starting byte position and all the same logic should be performed by souphttpsrc and basesrc,
The attached patch creates a boolean property "exclude-range-header" which specifies if the Range header should be included. The default is false. When false, souphttpsrc will include the Range header as it does currently. When this property is set to true, souphttpsrc will formulate the HTTP request as it does now except it will not include the Range header. It will be the responsibility of the dlnasrc "manager" element to do this.
If the HTTP Range header is not included, souphttpsrc will not be able to determine the size of the content. The ability to set the content size is needed when the Range header is not included. This patch adds the ability to set the content size through the "content-size" property. The dlnasrc "manager" element will set the size as necessary such as for dtcp/ip encrypted content.
Version: 1.x
### Blocking
* [Bug 709455](https://bugzilla.gnome.org/show_bug.cgi?id=709455)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/105avimux: add RGB16 support2020-11-19T16:03:29ZBugzilla Migration Useravimux: add RGB16 support## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723358)](https://bugzilla.gnome.org/show_bug.cgi?id=723358)**
## Description
Created attachment 267721
avimux: add RGB16 support
* actual result: avimux does not...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723358)](https://bugzilla.gnome.org/show_bug.cgi?id=723358)**
## Description
Created attachment 267721
avimux: add RGB16 support
* actual result: avimux does not support RGB16
* random riff kind of spec I found:
http://netghost.narod.ru/gff/vendspec/micriff/ms_riff.txt I can read "RGB565"
* with the attached patch I generated :
gst-launch-1.0 videotestsrc num-buffers=200 ! "video/x-raw, format=RGB16" ! avimux ! filesink location=rgb16.avi
Then vlc can play it
**Patch 267721**, "avimux: add RGB16 support":
[0002-avimux-add-RGB16-support.patch](/uploads/370ffe9937ff9f1626b10b3d0b275839/0002-avimux-add-RGB16-support.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/109souphttpsrc: add support to disconnect on playing->paused transition2018-11-04T10:17:32ZBugzilla Migration Usersouphttpsrc: add support to disconnect on playing->paused transition## Submitted by Branislav Katreniak
**[Link to original bug (#724786)](https://bugzilla.gnome.org/show_bug.cgi?id=724786)**
## Description
We implement playback from Pandora music service. The complication is that Pandora has hard r...## Submitted by Branislav Katreniak
**[Link to original bug (#724786)](https://bugzilla.gnome.org/show_bug.cgi?id=724786)**
## Description
We implement playback from Pandora music service. The complication is that Pandora has hard requirement to disconnect the http connection on playing -> paused transition.
Is such functionality interesting upstream?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/115Adding a "multifile" protocol in multifilesrc2023-07-01T21:55:22ZBugzilla Migration UserAdding a "multifile" protocol in multifilesrc## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#729456)](https://bugzilla.gnome.org/show_bug.cgi?id=729456)**
## Description
It would be easier to be able to play a multifilesrc from the playbin (for example). ...## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#729456)](https://bugzilla.gnome.org/show_bug.cgi?id=729456)**
## Description
It would be easier to be able to play a multifilesrc from the playbin (for example). It would be something like "gst-launch-1.0 playbin uri="multifile:///the/pattern/%d.png?start=START&index=INDEX&framerate=NUMERATOR/DENOMINATOR". I've been working on this and I'm ataching a couple of patches to do it.
The first modification is in Gstreamer (core), in gsturi.c/gsturi.h where I've added a very simple parser (I want to keep it simple now) and some types that would be used in gst-plugins-good/gst/multifile/multifilesrc.c (Second mofication: already done) and in gst-editing-services/ges/ges-multi-file-source.c (would be the next part).
Version: 1.x
### Blocking
* [Bug 415360](https://bugzilla.gnome.org/show_bug.cgi?id=415360)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/116alpha: Should translate BGRx to BGRA instead of AYUV2023-10-13T16:52:23ZBugzilla Migration Useralpha: Should translate BGRx to BGRA instead of AYUV## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#730014)](https://bugzilla.gnome.org/show_bug.cgi?id=730014)**
## Description
Currently in:
gst-launch-1.0 -v videotestsrc ! video/x-raw,format=BGRx ! alpha...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#730014)](https://bugzilla.gnome.org/show_bug.cgi?id=730014)**
## Description
Currently in:
gst-launch-1.0 -v videotestsrc ! video/x-raw,format=BGRx ! alpha alpha=0.5 ! glimagesink
glimagesink will receive AYUV. This seems much slower then producing BGRA and setting the alpha byte. Would be a nice enhancement to try and address that.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/118rtpjitterbuffer: free item if it is a duplicated one2023-07-01T22:02:30ZBugzilla Migration Userrtpjitterbuffer: free item if it is a duplicated one## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#731780)](https://bugzilla.gnome.org/show_bug.cgi?id=731780)**
## Description
A duplicate item is not inserted into the buffer, so it must be freed.## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#731780)](https://bugzilla.gnome.org/show_bug.cgi?id=731780)**
## Description
A duplicate item is not inserted into the buffer, so it must be freed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/120avidemux: add support for DEFAULT and PERCENT formats to position query2023-10-12T18:08:31ZBugzilla Migration Useravidemux: add support for DEFAULT and PERCENT formats to position query## Submitted by Dirk Van Haerenborgh
**[Link to original bug (#731851)](https://bugzilla.gnome.org/show_bug.cgi?id=731851)**
## Description
Created attachment 278679
proposed patch
This patch adds support for FORMAT_DEFAULT a...## Submitted by Dirk Van Haerenborgh
**[Link to original bug (#731851)](https://bugzilla.gnome.org/show_bug.cgi?id=731851)**
## Description
Created attachment 278679
proposed patch
This patch adds support for FORMAT_DEFAULT and FORMAT_PERCENT in avidemux, and also properly sets the return value to false for other unsupported formats
**Patch 278679**, "proposed patch":
[avidemux_position.patch](/uploads/c583919133c9b6ea08ebf38c0dd00346/avidemux_position.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/121New imagesequencesrc element2020-09-10T13:08:56ZBugzilla Migration UserNew imagesequencesrc element## Submitted by César Fabián Orccón Chipana
Assigned to **Tim Müller `@tpm`**
**[Link to original bug (#731890)](https://bugzilla.gnome.org/show_bug.cgi?id=731890)**
## Description
Created attachment 278728
It is an example of h...## Submitted by César Fabián Orccón Chipana
Assigned to **Tim Müller `@tpm`**
**[Link to original bug (#731890)](https://bugzilla.gnome.org/show_bug.cgi?id=731890)**
## Description
Created attachment 278728
It is an example of how to use GstImageSequenceSrc
Hello guys. I've written an element in gst-plugins-bad which I called as GstImageSequenceSrc. It works very similar to GstMultiFileSrc, but there are some differences.
Differences with GstMultiFileSrc.
* Handles a list of filenames instead of a printf pattern as GstMultiFileSrc does.
- Having a list of filenames is useful because you can set the filenames you want,
in the order you want. For example, you can add more filenames or sort the list.
- There are two ways to create this list:
a) Setting a location propertie. This value could look like:
1) "/some/folder/with/images/ or ."
2) "/a/path/img.jpg,/other/path/img2.jpg" or "img1.png,img2.png"
3) "/a/path/*.JPEG" or "*.png"
b) Setting the filename-list (GList) directly.
* Creates an "imagesequence://" protocol which allows the playbin to play this element. It handles a 'fake' uri but it is useful finally.
gst-launch-1.0 playbin uri="imagesequencesrc:///some/path/*.jpg?framerate=20/1&loop=1"
* It "detects" the mimetype of the images. You only have to worry about the framerate.
* It calculates the duration.
Things to improve:
* Seeking: it seeks to the wrong image sometimes (actually, after many seeks).
* The way duration is calculated.
PD: stormer was telling me to support png *and* jpeg files (both at the same time) but I don't see a usecase.
You can see the most-stable version of this element in
https://github.com/cfoch/gst-plugins-bad/tree/sequences/gst/sequences
Develop:
https://github.com/cfoch/gst-plugins-bad/tree/sequences-develop/gst/sequences
~~**Attachment 278728**~~, "It is an example of how to use GstImageSequenceSrc":
[test.c](/uploads/9b8abb9dd4eda1d72784fad547dfcf35/test.c)1.18.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/126videobox: Much slower than videocrop2018-11-04T10:24:44ZBugzilla Migration Uservideobox: Much slower than videocrop## Submitted by Stirling Westrup
**[Link to original bug (#734679)](https://bugzilla.gnome.org/show_bug.cgi?id=734679)**
## Description
I have an application that needs to do both video cropping and padding and which works with 4K v...## Submitted by Stirling Westrup
**[Link to original bug (#734679)](https://bugzilla.gnome.org/show_bug.cgi?id=734679)**
## Description
I have an application that needs to do both video cropping and padding and which works with 4K videos. We chose videobox for the task because its the only element that does reasonable padding and the fact that it can also crop was a major bonus.
However, in time trials we've found that videobox is much, MUCH slower than videocrop, even when its just cropping. For example, using gstreamer 1.4.0, this pipeline runs on a stock ivy-bridge server driving a SMSC zero client display at about 45 fps:
gst-launch-1.0 -v filesrc location=Sintel-4K.mkv ! decodebin ! videoconvert ! videocrop left=100 ! videoscale ! fpsdisplaysink sync=false video-sink="xvimagesink display=:2"
The same pipeline, with videobox used instead of videocrop gives us an average of about 20 fps, which is a huge drop. Worse the video in question is 24 fps, so with videobox we cannot play realtime without dropping frames.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/127vp8dec: Does not support alpha channel2023-07-01T22:07:18ZBugzilla Migration Uservp8dec: Does not support alpha channel## Submitted by ash..@..il.com
**[Link to original bug (#735450)](https://bugzilla.gnome.org/show_bug.cgi?id=735450)**
## Description
Created attachment 284508
TestVideo
The VP8 decoders do not retrieve the alpha channel from...## Submitted by ash..@..il.com
**[Link to original bug (#735450)](https://bugzilla.gnome.org/show_bug.cgi?id=735450)**
## Description
Created attachment 284508
TestVideo
The VP8 decoders do not retrieve the alpha channel from a video, I'm not exactly sure where about in the pipeline the problem lies, however when using playbin and appsink to stream a VP8 encoded video the alpha channel is simply defaulted to opaque. The VP8 codec does support an alpha channel.
Attached is a test video containing a video with an alpha channel.
**Attachment 284508**, "TestVideo":
[StarAlpha.mkv](/uploads/b55382fef04975abef24afac4cedbbc4/StarAlpha.mkv)
Version: 1.2.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/128rtph264pay does not multiplex NAL7/8 into stream2019-01-23T17:01:39ZBugzilla Migration Userrtph264pay does not multiplex NAL7/8 into stream## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#737158)](https://bugzilla.gnome.org/show_bug.cgi?id=737158)**
## Description
It is going to be a fuzzy bug description, since it is pretty difficult to get into the ...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#737158)](https://bugzilla.gnome.org/show_bug.cgi?id=737158)**
## Description
It is going to be a fuzzy bug description, since it is pretty difficult to get into the situation (or at least the mechanics are not yet completely understood).
Setup:
Bosh camera 7000HD -> multicast -> GStreamer -> multicast
The observervation is that in some cases, the multicast produced by GStreamer does not contain NAL 7 or NAL 8 anymore (SPS/PPS).
Inspecting the stream produced by gst:
GST_DEBUG=*rtph264depay*:5 gst-launch-1.0 urirecv uri=rtp://239.1.10.150:5560?encoding-name=H264 ! fakesink &> debug.log
cat debug.log |grep NAL\ type
0:00:07.528576767 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.529103204 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.561325168 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.561822120 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.595638566 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.595823129 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.654061855 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.664710192 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 5
0:00:07.664746755 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.664772356 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.696166012 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.696433236 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.726968750 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.727307893 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.759747537 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.760010576 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.795414358 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.795708060 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.826839379 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.827141668 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.860425025 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.860685137 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.897826353 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.898097606 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.928312577 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.928637917 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.959940404 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.960258549 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:07.994137746 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:07.994550716 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.026958550 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.027303859 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.060415338 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.060998735 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.101329021 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.101777605 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.128332276 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.128824585 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.161946122 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.162375439 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.195848923 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.196489829 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.228388281 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.228973891 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.261066901 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.261589890 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.295710226 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.296257095 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.328935565 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.329438413 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.361794269 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.362281580 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.396789626 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.397433648 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.427303597 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.427767760 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.460780794 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.461252011 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.498994997 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.499471681 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.528817003 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.529222642 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.561687590 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.562256349 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.595417445 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.596065328 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.656565072 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.667220752 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 5
0:00:08.667291162 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.667334135 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.696295908 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.696593032 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.727200842 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.727534839 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.759836036 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.760112852 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.794219887 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.794555158 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.825931621 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.826184106 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.860381240 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.860650321 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:08.900099536 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:08.900440603 20799 0x7f2110002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
Since it is difficult to reproduce; I do not have the detailed logging of the intermediate operation; but from what is logged; it looks as if the CAPS and config data from the originating encoder is captured:
application/x-rtp, media=(string)video, payload=(int)35, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)4d401e, sprop-parameter-sets=(string)"Z01AHppmBgG9gLUFAQUC\,aO48gA\=\=", a-recvonly=(string)"", npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1
The pipeline strips the stream to ES and builds it back up; the ES caps are complete too:
video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)014d401effe1000f674d401e9a660601bd80b50501050201000468ee3c80, width=(int)768, height=(int)432, framerate=(fraction)0/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1
The camera uses RTSP with multicast; listening to the multicast of the camera directly does show that the configuration data is sent in the stream (decoding picks up).
0:00:03.091789527 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.124916098 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.124953179 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.158041534 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.158089508 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.191482151 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.191541176 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.224806808 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.224853810 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.257984554 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.258053902 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.291415619 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.291450487 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.324816195 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.324850618 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.357952058 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.357990337 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.391543865 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.391581956 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.424825865 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.424868016 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.457976825 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.458012796 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.491435531 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.491473483 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.524802888 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.524838464 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.558039728 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.558109608 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.591548811 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 7
0:00:03.591586852 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 8
0:00:03.591611433 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.592684445 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 5
0:00:03.625016461 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.625053077 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.658144974 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.658179079 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.691586984 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.691622920 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.724907218 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.724943197 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.758021093 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.758057036 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.791483836 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.791533384 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.824975143 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.825009227 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
0:00:03.858000793 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 6
0:00:03.858045804 21125 0x7f6b18002850 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:`<rtph264depay0>` handle NAL type 1
As far as I know; I haven't seen it with any other camera than this one (might be a general problem; I don't know).
Version: 1.4.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/131pulsesink: cannot set device on commandline2019-12-12T23:50:27ZBugzilla Migration Userpulsesink: cannot set device on commandline## Submitted by Haarman
**[Link to original bug (#738199)](https://bugzilla.gnome.org/show_bug.cgi?id=738199)**
## Description
I cannot set the pulsesink on the commandline.
this does not seem to work, the sink gets changed but...## Submitted by Haarman
**[Link to original bug (#738199)](https://bugzilla.gnome.org/show_bug.cgi?id=738199)**
## Description
I cannot set the pulsesink on the commandline.
this does not seem to work, the sink gets changed but set back to the default:
PULSE_SINK=VirtualDefault gst-launch-1.0 -v filesrc location=/usr/share/sounds/KDE-Window-Shade-Up.ogg ! decodebin ! audioconvert ! audioresample ! pulsesink device=VirtualDefault
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: volume = 1
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: mute = false
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: current-device = VirtualDefault
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: volume = 1
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: mute = false
/GstPipeline:pipeline0/GstPulseSink:pulsesink0: current-device = alsa_output.pci-0000_00_1b.0.analog-stereo
Version: 1.2.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/141multifilesink: Add a property to disable writing streamheaders on new files2023-10-13T15:06:04ZBugzilla Migration Usermultifilesink: Add a property to disable writing streamheaders on new files## Submitted by clo..@..il.com
**[Link to original bug (#739979)](https://bugzilla.gnome.org/show_bug.cgi?id=739979)**
## Description
Currently, the multifilesink will check its GstCaps for a "streamheader" value. If this value exi...## Submitted by clo..@..il.com
**[Link to original bug (#739979)](https://bugzilla.gnome.org/show_bug.cgi?id=739979)**
## Description
Currently, the multifilesink will check its GstCaps for a "streamheader" value. If this value exists, it will then generate a header for each file.
However, there are several instances where being able to treat each file generated by the multifilesink as a continuation of the previous file.
In no particular order, and this is not an exhaustive list:
1 - splitfilesrc playback. This element treats a set of files as one large contiguous file. Unfortunately, headers mess up a variety of demuxers.
2 - moving files between file systems. For example, FAT32, common on SDCards, is limited to 4GB files. Being able to binary concatenate files together when transferred to a file system without such a limit would be very useful.
To solve this, I propose adding a "write-stream-headers" property, whose default is "true" (to preserve current behavior), but when set to "false" will not write "streamheader" information from GstCaps into the resulting files.
Version: 1.4.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/143rtspsrc, rtpjitterbuffer: cpu optimization2019-05-30T15:30:04ZBugzilla Migration Userrtspsrc, rtpjitterbuffer: cpu optimization## Submitted by Nicola `@drakkan`
**[Link to original bug (#740149)](https://bugzilla.gnome.org/show_bug.cgi?id=740149)**
## Description
Created attachment 290741
basesrc: workaround to save CPU in udpsrc
This bug is to keep ...## Submitted by Nicola `@drakkan`
**[Link to original bug (#740149)](https://bugzilla.gnome.org/show_bug.cgi?id=740149)**
## Description
Created attachment 290741
basesrc: workaround to save CPU in udpsrc
This bug is to keep track of this discussion and the patch
http://gstreamer-devel.966125.n4.nabble.com/rtspsrc-cpu-optimization-td4668972.html
**Patch 290741**, "basesrc: workaround to save CPU in udpsrc":
[0001-basesrc-workaround-to-save-CPU-in-udpsrc.patch](/uploads/3cbb47d6fbc8414821ea7377900352a7/0001-basesrc-workaround-to-save-CPU-in-udpsrc.patch)
Version: 1.4.4
### Depends on
* [Bug 751636](https://bugzilla.gnome.org/show_bug.cgi?id=751636)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/145avidemux doesn't set PTS on keyframes when operating in push mode2018-11-05T10:55:42ZBugzilla Migration Useravidemux doesn't set PTS on keyframes when operating in push mode## Submitted by Maroš Ondrášek
**[Link to original bug (#740961)](https://bugzilla.gnome.org/show_bug.cgi?id=740961)**
## Description
1.pull mode(PTS written on KF):
gst-launch-1.0 -v filesrc location='/tmp/xvid_packed_AS.avi' ...## Submitted by Maroš Ondrášek
**[Link to original bug (#740961)](https://bugzilla.gnome.org/show_bug.cgi?id=740961)**
## Description
1.pull mode(PTS written on KF):
gst-launch-1.0 -v filesrc location='/tmp/xvid_packed_AS.avi' !avidemux!fakesink silent=false
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2486 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: 0:00:00.040000000, offset: 0, offset_end: 1, flags: 00000040 discont ) 0x76b02840
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (125 bytes, dts: 0:00:00.040000000, pts: none, duration: 0:00:00.040000000, offset: 1, offset_end: 2, flags: 00002000 delta-unit ) 0x76b02a20
....
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (6576 bytes, dts: 0:00:04.400000000, pts: none, duration: 0:00:00.040000000, offset: 110, offset_end: 111, flags: 00002000 delta-unit ) 0x76b02c00
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (25142 bytes, dts: 0:00:04.440000000, pts: 0:00:04.440000000, duration: 0:00:00.040000000, offset: 111, offset_end: 112, flags: 00000000 ) 0x76b02d40
2.push mode(PTS not written on KF):
gst-launch-1.0 -v souphttpsrc location='https://dl.dropboxusercontent.com/u/38760017/xvid_packed_AS.avi' !queue2!avidemux!fakesink silent=false
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2486 bytes, dts: 0:00:00.000000000, pts: none, duration: 0:00:00.040000000, offset: 0, offset_end: 1, flags: 00004040 discont tag-memory ) 0x75b02140
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (125 bytes, dts: 0:00:00.040000000, pts: none, duration: 0:00:00.040000000, offset: 1, offset_end: 2, flags: 00004000 tag-memory ) 0x75b02000
....
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (6576 bytes, dts: 0:00:04.400000000, pts: none, duration: 0:00:00.040000000, offset: 110, offset_end: 111, flags: 00000000 ) 0x74933a30
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (25142 bytes, dts: 0:00:04.440000000, pts: none, duration: 0:00:00.040000000, offset: 111, offset_end: 112, flags: 00000000 ) 0x75c02320
Our HW decoder expects PTS to be written on keyframes when dealing with mpeg4 part2 codecs, but when avidemux operates in PUSH mode, there is no PTS available so playback doesn't work.
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/147avidemux: Jumping video timestamps in specific movie2023-10-13T15:09:39ZBugzilla Migration Useravidemux: Jumping video timestamps in specific movie## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#741711)](https://bugzilla.gnome.org/show_bug.cgi?id=741711)**
## Description
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773442
We fail to play this movie...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#741711)](https://bugzilla.gnome.org/show_bug.cgi?id=741711)**
## Description
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773442
We fail to play this movie. I fixed the audio parts already, now there's only the problem left that we get some video frames in the beginning with timestamps around 0 seconds... and soonish after they jump to 3 minutes.
VLC and avplay handle it properly.
http://demo.archermind.com/Test%20Sample/Video/MPEG%204/Divx3/Low-Motion/https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/150isomp4: Add support for Opus2023-06-02T10:31:29ZBugzilla Migration Userisomp4: Add support for Opus## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#742643)](https://bugzilla.gnome.org/show_bug.cgi?id=742643)**
## Description
It's official now: http://www.mp4ra.org/codecs.html
https://www.opus-codec.org/docs...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#742643)](https://bugzilla.gnome.org/show_bug.cgi?id=742643)**
## Description
It's official now: http://www.mp4ra.org/codecs.html
https://www.opus-codec.org/docs/opus_in_isobmff.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/154rtsp stream playback issue2023-07-02T16:26:48ZBugzilla Migration Userrtsp stream playback issue## Submitted by swapnil
**[Link to original bug (#743618)](https://bugzilla.gnome.org/show_bug.cgi?id=743618)**
## Description
While playing rtsp streams on ubuntu14.04, video is stuck.
Below mentioned gstreamer-1.0 pipeline wa...## Submitted by swapnil
**[Link to original bug (#743618)](https://bugzilla.gnome.org/show_bug.cgi?id=743618)**
## Description
While playing rtsp streams on ubuntu14.04, video is stuck.
Below mentioned gstreamer-1.0 pipeline was run to test this issue.
gst-launch-1.0 rtspsrc location= rtsp://10.25.20.77:554/3gp/H264+aac/H264_BP_level3_2000kbps_320x240_36fps_aac_112kbps_44.1khz_stereo.3gp ! rtph264depay ! avdec_h264 ! xvimagesink -v
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/165flacdec: silence happens with specific flac2023-05-30T10:05:00ZBugzilla Migration Userflacdec: silence happens with specific flac## Submitted by stephane Cerveau `@dabrain34`
**[Link to original bug (#745609)](https://bugzilla.gnome.org/show_bug.cgi?id=745609)**
## Description
After 10 seconds, the sound becomes silence and come back after a few seconds.
...## Submitted by stephane Cerveau `@dabrain34`
**[Link to original bug (#745609)](https://bugzilla.gnome.org/show_bug.cgi?id=745609)**
## Description
After 10 seconds, the sound becomes silence and come back after a few seconds.
In GST_DEBUG=flacdec:4, there is this message:
gst_flac_dec_handle_frame:`<flacdec638>` process_single failed
It looks like the file is damaged but in VLC or audirvana, the playback jumps to the new working timestamp.
Is it a normal behaviour ?
File link:
https://www.dropbox.com/s/4q82cpafhalovfb/06-Love_Man.flac?dl=0
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/176v4l2: Improve URI handler2023-10-12T18:07:37ZBugzilla Migration Userv4l2: Improve URI handler## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
Gs...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
GstUri backported from git in core
~~**Patch 300359**~~, "v4l2: add uri hander interface":
[0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch](/uploads/529f7b48ebdbb064e83eeee1311309fd/0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/181rtpbin: RTX packets only forwarded after two are received (probation period)2022-10-11T11:29:59ZBugzilla Migration Userrtpbin: RTX packets only forwarded after two are received (probation period)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#747919)](https://bugzilla.gnome.org/show_bug.cgi?id=747919)**
## Description
Currently an RTX packet is queued up in rtpsource on the receiver until a second one is ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#747919)](https://bugzilla.gnome.org/show_bug.cgi?id=747919)**
## Description
Currently an RTX packet is queued up in rtpsource on the receiver until a second one is received... because of the probation period. That's obviously not a good idea for RTX packets, as that one will then be far too late and we don't really have that many packets anyway.
Problem now is that nothing in rtpbin knows about RTX, and somehow we need to get this information to rtpsource so that it does not queue up things.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/185v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer b...2023-07-25T16:37:33ZBugzilla 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/gst-plugins-good/-/issues/186deinterleave: allow switching between 1 channel configs2019-01-28T23:39:22ZBugzilla Migration Userdeinterleave: allow switching between 1 channel configs## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs
This patch allows changing between configs that have positioning information if both are 1 channel, where positioning doesn't matter.
One could argue that upstream should not include any positioning, and this this patch should not be merged, so I'm putting it here.
**Attachment 303424**, "deinterleave: allow switching between 1 channel configs":
[0001-deinterleave-allow-switching-between-1-channel-confi.patch](/uploads/e84e21476417c1868d94fe0ceece7226/0001-deinterleave-allow-switching-between-1-channel-confi.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/187videocrop: Make videocrop controllable2021-03-13T12:57:20ZBugzilla Migration Uservideocrop: Make videocrop controllable## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id...## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id=740502)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/194souphttpsrc: add cookie jar2023-10-12T18:04:35ZBugzilla Migration Usersouphttpsrc: add cookie jar## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to downlo...## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to download content fragments.
In some cases, user-agent and cookie is needed to set to connect the http server but there is no way to get the current user-agent and cookie data from souphttpsrc.
I think souphttpsrc should handle the custom query of user-agent and cookies.
### Blocking
* [Bug 751372](https://bugzilla.gnome.org/show_bug.cgi?id=751372)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/197rtpjitterbuffer: wastes CPU processing too many unnecessary timers2019-05-30T16:22:01ZBugzilla Migration Userrtpjitterbuffer: wastes CPU processing too many unnecessary timers## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#751636)](https://bugzilla.gnome.org/show_bug.cgi?id=751636)**
## Description
I have found a case where the jitterbuffer gets a lot of timers and it spends a l...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#751636)](https://bugzilla.gnome.org/show_bug.cgi?id=751636)**
## Description
I have found a case where the jitterbuffer gets a lot of timers and it spends a lot of CPU processing them.
I open this bug to provide some patches to fix this problem.
### Blocking
* [Bug 740149](https://bugzilla.gnome.org/show_bug.cgi?id=740149)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/209osxaudiosrc drops frames when osxaudiosink misses frames2023-07-03T09:39:16ZBugzilla 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/gst-plugins-good/-/issues/216avidemux/qtdemux: Output raw video in unaligned buffers causing crashing in O...2019-09-03T07:19:21ZBugzilla Migration Useravidemux/qtdemux: Output raw video in unaligned buffers causing crashing in ORC video conversion code## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754353)](https://bugzilla.gnome.org/show_bug.cgi?id=754353)**
## Description
+++ This bug was initially created as a clone of [Bug 736965](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754353)](https://bugzilla.gnome.org/show_bug.cgi?id=754353)**
## Description
+++ This bug was initially created as a clone of [Bug 736965](https://bugzilla.gnome.org/show_bug.cgi?id=736965) +++
See discussions there
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/220qtdemux: segfault when running reverse playback validate scenario for a parti...2023-07-02T16:31:00ZBugzilla Migration Userqtdemux: segfault when running reverse playback validate scenario for a particular file## Submitted by Vineeth
**[Link to original bug (#755102)](https://bugzilla.gnome.org/show_bug.cgi?id=755102)**
## Description
I get a segfault when i run reverse playback scenario with a particular mp4 file.
This is the stack ...## Submitted by Vineeth
**[Link to original bug (#755102)](https://bugzilla.gnome.org/show_bug.cgi?id=755102)**
## Description
I get a segfault when i run reverse playback scenario with a particular mp4 file.
This is the stack trace.
gst_qtdemux_seek_to_previous_keyframe (qtdemux=`<optimized out>`) at qtdemux.c:3983
3983 seg_media_start_mov = seg->trak_media_start;
```
(gdb) bt
#0 gst_qtdemux_seek_to_previous_keyframe (qtdemux=<optimized out>) at qtdemux.c:3983
#1 gst_qtdemux_loop (pad=0x9b9270) at qtdemux.c:5235
#2 0x00007ffff75ac451 in gst_task_func (task=0x9d75f0) at gsttask.c:331
#3 0x00007ffff702688c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff7025f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff6da2182 in start_thread (arg=0x7fffe6bd2700) at pthread_create.c:312
#6 0x00007ffff6acf47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```
The crash is because, segment_index is -1.
For this particular sample, in gst_qtdemux_advance_sample
/* see if we are past the segment */
if (G_UNLIKELY (QTSAMPLE_DTS (stream, sample) >= segment->media_stop))
goto next_segment;
This condition gets satisfied and in next_segment label, segment_index is set to -1.
I was able to solve the crash .. but not sure if it is really correct..
While checking if we are past the segment, >= is being checked, so even though qtsample time is same as media_stop, we are skipping to next_segment.
Changing the check to '>' fixes the issue. We are really past the segment only when is greater than media_stop. Not sure if >= is really needed..https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/231libgstosxvideosink.so causes hangs on plugin load on OS X 10.62023-10-12T17:58:02ZBugzilla Migration Userlibgstosxvideosink.so causes hangs on plugin load on OS X 10.6## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?...## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?id=756154, for what it's worth.)
Any gst-launch, gst-inspect, etc. hangs on startup as long as libgstosxvideosink.so is in the plugin dir. When I manually remove it, problem goes away.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/234Matroskademux fails to create caps for ACM audio2018-11-28T12:03:45ZBugzilla Migration UserMatroskademux fails to create caps for ACM audio## Submitted by Matej `@Knopp`
**[Link to original bug (#757583)](https://bugzilla.gnome.org/show_bug.cgi?id=757583)**
## Description
Created attachment 314809
Patch
gst_riff_create_audio_caps expects codec data in strf, but ...## Submitted by Matej `@Knopp`
**[Link to original bug (#757583)](https://bugzilla.gnome.org/show_bug.cgi?id=757583)**
## Description
Created attachment 314809
Patch
gst_riff_create_audio_caps expects codec data in strf, but matroskademux passes it as strd
Sample file
https://s3.amazonaws.com/MatejK/Samples/2001-start.mkv
**Patch 314809**, "Patch":
[0001-matroskademux-pass-riff-codec-data-as-strf-not-strd.patch](/uploads/c79aa8790e1fd3408d15513c3b59e9ee/0001-matroskademux-pass-riff-codec-data-as-strf-not-strd.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/237gst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed2023-04-11T00:57:37ZBugzilla Migration Usergst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed## Submitted by bill-auger
**[Link to original bug (#758060)](https://bugzilla.gnome.org/show_bug.cgi?id=758060)**
## Description
Created attachment 315406
minimal pipeline exposing this bug
upon setting pipeline state to NUL...## Submitted by bill-auger
**[Link to original bug (#758060)](https://bugzilla.gnome.org/show_bug.cgi?id=758060)**
## Description
Created attachment 315406
minimal pipeline exposing this bug
upon setting pipeline state to NULL at shutdown the following assertion is thrown repeatedly countless times:
```
GStreamer-CRITICAL **: gst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed
```
this is accompanied by wild disk thrashing and in the larger project where this was discovered it quite often also renders the entire system unresponsive where the only remedy is to pull the plug
i have isolated this behavior to a bin containing a pngdec and imagefreeze and ghostpad src to another bin
a .cpp file with a minimal pipeline exposing this is attached - a thread dump and valgrind profile is available in this gist along with the same .cpp file
https://gist.github.com/bill-auger/b003a77c20cfbe8a704b
**Attachment 315406**, "minimal pipeline exposing this bug":
[pngdec.cpp](/uploads/2685e8aa9729c3df2a8dd3e48d63b4e5/pngdec.cpp)
Version: 1.6.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/239splitmuxsrc: Implement segment query2020-09-18T16:14:57ZBugzilla Migration Usersplitmuxsrc: Implement segment query## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#758365)](https://bugzilla.gnome.org/show_bug.cgi?id=758365)**
## Description
Summary says it all, this is required to be able to seek correctly through gst-rtsp-serve...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#758365)](https://bugzilla.gnome.org/show_bug.cgi?id=758365)**
## Description
Summary says it all, this is required to be able to seek correctly through gst-rtsp-server, in particular for formats with no parser.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/255decodebin/vaapi: ranking vaapi breaks plugging2023-10-13T15:26:04ZBugzilla Migration Userdecodebin/vaapi: ranking vaapi breaks plugging## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#761405)](https://bugzilla.gnome.org/show_bug.cgi?id=761405)**
## Description
Installing gstreamer-vaapi is enough to break auto plugging behaviour.
Because vaa...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#761405)](https://bugzilla.gnome.org/show_bug.cgi?id=761405)**
## Description
Installing gstreamer-vaapi is enough to break auto plugging behaviour.
Because vaapi modules require specific hardware (e.g. QuickSync) and a specific environment (DISPLAY set with running X Server); installing these modules break systems that depends on autoplugging.
Consider a simple application that does transcoding in the background, while using vaapi to decode video if an X server is running.
Due to the higher ranking (PRIMARY+2), the vaapi modules are always picked over the generic sofware based solution.
See the att'd simple example.
barco@EMS-005008087c8a:~$ gst-launch-1.0 uridecodebin uri=file:///home/barco/some-file.mkv ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Stream with high frequencies VQ coding
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode: Could not initialize supporting library.
Additional debug info:
gstvideodecoder.c(2571): gst_video_decoder_change_state (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode:
Failed to open decoder
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965
Freeing pipeline ...
The current workaround is lowering the ranking of the hardware based elements:
We might need to resort to (in the app):
GstPluginFeature *feature;
GstRegistry *registry = gst_registry_get();
feature = gst_registry_lookup_feature (registry, "vaapidecodebin");
if (feature != NULL) {
gst_plugin_feature_set_rank (feature, GST_RANK_NONE);
gst_object_unref (feature);
}
and so forth :-(
Though this is obviously not a viable solution when new modules are installed that were not yet considered.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/256rtpbin/rtxsend: Add unicast re-transmit support and support for session broad...2020-01-12T01:21:17ZBugzilla Migration Userrtpbin/rtxsend: Add unicast re-transmit support and support for session broadcasting using a multiudpsink## Submitted by GstBlub
**[Link to original bug (#761960)](https://bugzilla.gnome.org/show_bug.cgi?id=761960)**
## Description
rtpbin: Add rtcp-send-eos property.
This allows rtpbin to be used with a multiudpsink to broadcast t...## Submitted by GstBlub
**[Link to original bug (#761960)](https://bugzilla.gnome.org/show_bug.cgi?id=761960)**
## Description
rtpbin: Add rtcp-send-eos property.
This allows rtpbin to be used with a multiudpsink to broadcast to multiple endpoints. Setting this property to FALSE disables sending a EOS event to be sent to the send_rtcp_src_%u pad when a session is terminated, which would otherwise cause all further RTCP packets to be dropped.
rtprtxsend: Add a rtx_src request pad to allow sending unicast retransmits.
This allows a multiudpsink to be hooked up to rtpbin to broadcast to multiple receivers and use a rtprtxsend aux element to send lost packets only to the appropriate receiver using a dynudpsink.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/260rtspsrc: Add special support for ONVIF servers (custom headers, timestamp ext...2022-05-06T08:48:51ZBugzilla Migration Userrtspsrc: Add special support for ONVIF servers (custom headers, timestamp extraction, ...)## Submitted by Nicola `@drakkan`
**[Link to original bug (#762910)](https://bugzilla.gnome.org/show_bug.cgi?id=762910)**
## Description
Created attachment 322727
extract and apply onvif timestamp
extract absolute timestamp f...## Submitted by Nicola `@drakkan`
**[Link to original bug (#762910)](https://bugzilla.gnome.org/show_bug.cgi?id=762910)**
## Description
Created attachment 322727
extract and apply onvif timestamp
extract absolute timestamp from onvif rtp extension and apply to rtp buffers,
onvif ntp timestamp are converted to unix timestamp, the output is something like this
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4434 bytes, dts: 404561:47:11.657000000, pts: 404561:47:11.657000000, duration: none, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7fa7ac0132d0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4454 bytes, dts: 404561:47:11.993000000, pts: 404561:47:11.993000000, duration: none, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7fa7ac0134f0
**Patch 322727**, "extract and apply onvif timestamp":
[0001-onvifparse-extract-and-apply-onvif-timestamp.patch](/uploads/f8d11767a2a5f073a99375f3081ed48b/0001-onvifparse-extract-and-apply-onvif-timestamp.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/263flvdemux: Expose pads as early as possible and use GstStreams API2023-07-02T16:33:48ZBugzilla Migration Userflvdemux: Expose pads as early as possible and use GstStreams API## Submitted by Yann Jouanin
**[Link to original bug (#764260)](https://bugzilla.gnome.org/show_bug.cgi?id=764260)**
## Description
Created attachment 324837
Patch to add no-more-pads-threshold property
Currently when first v...## Submitted by Yann Jouanin
**[Link to original bug (#764260)](https://bugzilla.gnome.org/show_bug.cgi?id=764260)**
## Description
Created attachment 324837
Patch to add no-more-pads-threshold property
Currently when first video packet is more than 6 seconds delayed from first audio packet (or vice versa), the filter sends a no-more-pads events.
Because I encountered some case where this delay is not enough to read the stream (long GOP, still image), I wrote a patch to switch from a constant to a property
add no-more-pads-threshold property , default is set to 6 (like the previous constant)
**Patch 324837**, "Patch to add no-more-pads-threshold property":
[gstflvdemux_no-more-pads.patch](/uploads/abc6261a75321cf886de50a1853a55be/gstflvdemux_no-more-pads.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/264qtdemux: Support sidx based seek in pull mode2023-07-11T09:58:14ZBugzilla 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/gst-plugins-good/-/issues/267splitmuxsink: not sure GAP events are handled correctly2023-10-13T15:22:47ZBugzilla 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/gst-plugins-good/-/issues/268splitmuxsink: deadlock on stream error2023-10-13T15:24:35ZBugzilla Migration Usersplitmuxsink: deadlock on stream error## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764725)](https://bugzilla.gnome.org/show_bug.cgi?id=764725)**
## Description
splitmuxsink blocks streaming threads in handle_mq_input() but won't unblock them wh...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764725)](https://bugzilla.gnome.org/show_bug.cgi?id=764725)**
## Description
splitmuxsink blocks streaming threads in handle_mq_input() but won't unblock them when there is a stream error. Since it won't receive any buffer after that, its blocked forever.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/278qtdemux: early eos with totem-video-thumbnailer2023-10-12T17:54:26ZBugzilla Migration Userqtdemux: early eos with totem-video-thumbnailer## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#767406)](https://bugzilla.gnome.org/show_bug.cgi?id=767406)**
## Description
gstreamer1-plugins-bad-free-1.8.1-1.fc24.x86_64
gstreamer1-plugins-base-1.8.1-1.fc24.x...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#767406)](https://bugzilla.gnome.org/show_bug.cgi?id=767406)**
## Description
gstreamer1-plugins-bad-free-1.8.1-1.fc24.x86_64
gstreamer1-plugins-base-1.8.1-1.fc24.x86_64
gstreamer1-plugins-good-1.8.1-1.fc24.x86_64
gstreamer1-libav-1.6.3-1.fc23.x86_64
gstreamer1-1.8.1-1.fc24.x86_64
With the file at:
https://people.gnome.org/~hadess/IMG_0205.MOV
$ ./totem-video-thumbnailer IMG_0205.MOV foo.png
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
** (totem-video-thumbnailer:26874): WARNING **: Could not take screenshot: failed to retrieve or convert video frame
totem-video-thumbnailer couldn't get a picture from 'IMG_0205.MOV'
This error happens when:
g_signal_emit_by_name (play, "convert-sample", to_caps, &sample);
returns a NULL sample.
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/290rtpbin: remove arbitrary cutoff to not update ts-offset2021-01-12T21:33:58ZBugzilla Migration Userrtpbin: remove arbitrary cutoff to not update ts-offset## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#769972)](https://bugzilla.gnome.org/show_bug.cgi?id=769972)**
## Description
Created attachment 333402
rtpbin: remove arbitrary cutoff to not update ts-offset...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#769972)](https://bugzilla.gnome.org/show_bug.cgi?id=769972)**
## Description
Created attachment 333402
rtpbin: remove arbitrary cutoff to not update ts-offset
rtpbin: remove arbitrary cutoff to not update ts-offset
**Patch 333402**, "rtpbin: remove arbitrary cutoff to not update ts-offset":
[0001-rtpbin-remove-arbitrary-3-second-cutoff-for-not-upda.patch](/uploads/73dc8a5f94368c48dd053872b3a73996/0001-rtpbin-remove-arbitrary-3-second-cutoff-for-not-upda.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/303test-segment-seeks hangs on RPi2023-10-12T18:24:17ZBugzilla Migration Usertest-segment-seeks hangs on RPi## Submitted by Patrick
**[Link to original bug (#772066)](https://bugzilla.gnome.org/show_bug.cgi?id=772066)**
## Description
Created attachment 336368
Debug Log file
When using the latest master branch on RPi with Jessie, t...## Submitted by Patrick
**[Link to original bug (#772066)](https://bugzilla.gnome.org/show_bug.cgi?id=772066)**
## Description
Created attachment 336368
Debug Log file
When using the latest master branch on RPi with Jessie, the "test-segment-seek" test in "gst-plugins-good/tests/icles" stops updating the video after a couple of seeks.
To test this just start the test program with a h264 encoded video.
Tested with multiple different video files.
Attached is DEBUG output. I had to compress it, because it's to big otherwise.
**Attachment 336368**, "Debug Log file":
[Debug_log_6.txt.tar.gz](/uploads/b70ca91172a378e57c4c306fa1b87ab8/Debug_log_6.txt.tar.gz)
Version: 1.9.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/307tests: test_icy_stream being unstable again2021-10-12T20:01:29ZBugzilla Migration Usertests: test_icy_stream being unstable again## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#772232)](https://bugzilla.gnome.org/show_bug.cgi?id=772232)**
## Description
Looks like we still have occasional stability issues around the test icecast stream. Findin...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#772232)](https://bugzilla.gnome.org/show_bug.cgi?id=772232)**
## Description
Looks like we still have occasional stability issues around the test icecast stream. Finding one that's more stable would be nice (maybe one of the bigger US public radio ones?)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/310vp9: Add support for 10 bit and other subsampling2022-11-03T20:33:52ZBugzilla Migration Uservp9: Add support for 10 bit and other subsampling## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#773208)](https://bugzilla.gnome.org/show_bug.cgi?id=773208)**
## Description
See summary## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#773208)](https://bugzilla.gnome.org/show_bug.cgi?id=773208)**
## Description
See summaryhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/314rtpvp8pay: Fix allocation to support source-info property2020-09-28T16:01:50ZBugzilla Migration Userrtpvp8pay: Fix allocation to support source-info property## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773518)](https://bugzilla.gnome.org/show_bug.cgi?id=773518)**
## Description
Use gst_rtp_base_payload_allocate_output_buffer() in order to allocate
RTP buffer with ...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773518)](https://bugzilla.gnome.org/show_bug.cgi?id=773518)**
## Description
Use gst_rtp_base_payload_allocate_output_buffer() in order to allocate
RTP buffer with correct number of CSRCs according to the meta.
### Depends on
* [Bug 761947](https://bugzilla.gnome.org/show_bug.cgi?id=761947)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/321tests/jitterbuffer: fix indentation2019-05-30T15:30:53ZBugzilla Migration Usertests/jitterbuffer: fix indentation## Submitted by Håvard Graff (hgr)
**[Link to original bug (#773906)](https://bugzilla.gnome.org/show_bug.cgi?id=773906)**
## Description
Created attachment 339055
indentation-fix
And make the beautiful ascii-art gst-indent p...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#773906)](https://bugzilla.gnome.org/show_bug.cgi?id=773906)**
## Description
Created attachment 339055
indentation-fix
And make the beautiful ascii-art gst-indent proof.
**Patch 339055**, "indentation-fix":
[indentation-fix.patch](/uploads/44071074ffc829ad33e395521cc02284/indentation-fix.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/334Add support for resolving IPv4 address literals for DNS64 support2023-10-13T16:05:44ZBugzilla Migration UserAdd support for resolving IPv4 address literals for DNS64 support## Submitted by joe..@..il.com
**[Link to original bug (#776344)](https://bugzilla.gnome.org/show_bug.cgi?id=776344)**
## Description
The source of creating this bug can be found in the discussion here: http://gstreamer-devel.966125...## Submitted by joe..@..il.com
**[Link to original bug (#776344)](https://bugzilla.gnome.org/show_bug.cgi?id=776344)**
## Description
The source of creating this bug can be found in the discussion here: http://gstreamer-devel.966125.n4.nabble.com/NAT64-support-td4681208.html.
When on NAT64 networks, passing an IPv4 address literal does not get automatically resolved to its IPv6 equivalent so streaming via elements such as udpsink or udpsrc doesn't work. This is required for iOS as described here: https://developer.apple.com/library/content/documentation//NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/336videomixer internal data stream error when requesting some colorimetries2023-10-13T16:06:50ZBugzilla Migration Uservideomixer internal data stream error when requesting some colorimetries## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#776448)](https://bugzilla.gnome.org/show_bug.cgi?id=776448)**
## Description
This pipeline fails:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(strin...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#776448)](https://bugzilla.gnome.org/show_bug.cgi?id=776448)**
## Description
This pipeline fails:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, colorimetry=(string)bt2020" ! videomixer ! "video/x-raw, format=(string)NV12, width=(int)3840, height=(int)2160, framerate=(fraction)30, colorimetry=(string)bt2020" ! fakesink
ERREUR : de l’élément /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0 : Internal data stream error.
Also fails:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, colorimetry=(string)bt2020" ! videomixer ! "video/x-raw, format=(string)NV12, width=(int)3840, height=(int)2160, framerate=(fraction)30, colorimetry=(string)bt601" ! fakesink
Oddly, this works:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, colorimetry=(string)bt2020" ! videomixer ! "video/x-raw, format=(string)NV12, width=(int)3840, height=(int)2160, framerate=(fraction)30, colorimetry=(string)bt709" ! fakesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/338gtk4: Add Gst (GL) Gtk4 plugin2023-10-12T18:18:40ZBugzilla Migration Usergtk4: Add Gst (GL) Gtk4 plugin## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 wo...## Submitted by Yannick Inizan
**[Link to original bug (#776649)](https://bugzilla.gnome.org/show_bug.cgi?id=776649)**
## Description
Created attachment 342658
[PATCH] Add Gst (GL) Gtk4 plugin
Since latest version of Gtk 4 works correctly, we can build a plugin with this version.
**Patch 342658**, "[PATCH] Add Gst (GL) Gtk4 plugin":
[0001-Add-Gst-GL-Gtk4-plugin.patch](/uploads/c9ca16d576a27b9b20dc2dcfd7c565d3/0001-Add-Gst-GL-Gtk4-plugin.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/342RTSP URL with query is failing2023-10-12T23:17:36ZBugzilla Migration UserRTSP URL with query is failing## Submitted by Cyril
**[Link to original bug (#777104)](https://bugzilla.gnome.org/show_bug.cgi?id=777104)**
## Description
Like for 706568 which is for rtsp server, the rtspsrc has an issue with URL with query value.
For exam...## Submitted by Cyril
**[Link to original bug (#777104)](https://bugzilla.gnome.org/show_bug.cgi?id=777104)**
## Description
Like for 706568 which is for rtsp server, the rtspsrc has an issue with URL with query value.
For example, rtspsrc set with a location of "rtsp://localhost/test?x=1" will ask for:
DESCRIBE rtsp://localhost/test?x=1 RTSP/1.0
[...]
From there the server answers with a SDP containing this:
[...]
a=control:trackid=1
[...]
Then gstreamer sends a setup request with this URL: rtsp://localhost/test?x=1/trackid=1
It should be rtsp://localhost/test/trackid=1?x=1
The former breaks on the server because the "1/trackid=1" part is (correctly) interpreted as the query parameter value for the variable x while it's not the intention for gstreamer.
This is a real issue for me when x is a session / api key that's cannot be removed from the url.
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/345isomp4: initial ftyp/moov streamheader missing2023-10-13T15:59:32ZBugzilla Migration Userisomp4: initial ftyp/moov streamheader missing## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#777984)](https://bugzilla.gnome.org/show_bug.cgi?id=777984)**
## Description
i've tried to randomly enter a stream generated with mp4dashmux from
https://bugzill...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#777984)](https://bugzilla.gnome.org/show_bug.cgi?id=777984)**
## Description
i've tried to randomly enter a stream generated with mp4dashmux from
https://bugzilla.gnome.org/show_bug.cgi?id=668091 to play it in the browser using MSE. unfortunately, this failed, using a tcpserversink element and trying the various sync-methods. looking at the captured streams i discovered that the global headers are missing:
when it should start with:
0000 0000: 00 00 00 1C 66 74 79 70 69 73 6F 35 00 00 00 01 ....ftyp iso5....
0000 0010: 69 73 6F 35 69 73 6F 32 64 61 73 68 00 00 03 45 iso5iso2 dash...E
0000 0020: 6D 6F 6F 76 00 00 00 6C 6D 76 68 64 00 00 00 00 moov...l mvhd....
the randomly entered streams only start with:
0000 0000: 00 00 00 14 73 74 79 70 6D 73 64 68 00 00 00 00 ....styp msdh....
0000 0010: 6D 73 64 68 00 00 00 60 6D 6F 6F 66 00 00 00 10 msdh...` moof....
0000 0020: 6D 66 68 64 00 00 00 00 00 00 00 6B 00 00 00 48 mfhd.... ...k...H
qtmux does implement some streamheader handling, but it seems to be missing something for my use case. i'll investiage.
### Depends on
* [Bug 668091](https://bugzilla.gnome.org/show_bug.cgi?id=668091)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/346qtmux: fragment-duration property's problem2023-10-13T15:58:12ZBugzilla Migration Userqtmux: fragment-duration property's problem## Submitted by Changbok
**[Link to original bug (#778234)](https://bugzilla.gnome.org/show_bug.cgi?id=778234)**
## Description
Recently, I started dash format recording project via qtmux.
I will record stream to segmented mp4 for...## Submitted by Changbok
**[Link to original bug (#778234)](https://bugzilla.gnome.org/show_bug.cgi?id=778234)**
## Description
Recently, I started dash format recording project via qtmux.
I will record stream to segmented mp4 format.(So I made some patch for making up sidx box )
By the way, fragment-duration property value is just applied to audio stream because video stream is fragmented by keyframe unit. So audio and video's sidx entry has difference.
This is fragment-duration property's bug? or fragment-duration can be applied to audio stream case?
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/348vp8enc: Using Threads property causes major artifacts2020-02-12T22:54:53ZBugzilla Migration Uservp8enc: Using Threads property causes major artifacts## Submitted by pur..@..il.com
**[Link to original bug (#778934)](https://bugzilla.gnome.org/show_bug.cgi?id=778934)**
## Description
1.10.3 Mac OS - Installed via Brew
Using the "threads" property causes the encoded video to r...## Submitted by pur..@..il.com
**[Link to original bug (#778934)](https://bugzilla.gnome.org/show_bug.cgi?id=778934)**
## Description
1.10.3 Mac OS - Installed via Brew
Using the "threads" property causes the encoded video to refuse to play. Changing "error-resilient" to 1-3 with threads causes the video to play but incurs intense rainbow artifacting. Tested with various pipelines with varying degrees of success.
gst-launch-1.0 videotestsrc ! vp8enc ! decodebin ! autovideosink
will play
gst-launch-1.0 videotestsrc ! vp8enc threads=4 ! decodebin ! autovideosink
will not play
gst-launch-1.0 videotestsrc ! vp8enc threads=4 error-resilient=3 ! decodebin ! autovideosink
will play with heavy artifacts
gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc ! decodebin ! autovideosink
will play
gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc threads=4 ! decodebin ! autovideosink
will not play
gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004
will stream
gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc threads=4 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004
will stream
gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 undershoot=95 cpu-used=5 deadline=1 static-threshold=50 error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004
will stream without artifacts
gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 undershoot=95 cpu-used=5 threads=4 deadline=1 static-threshold=500 error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004
will stream with heavy artifacts
Bottom two streaming examples were viewed in WebRTC compatible browser.
Version: 1.10.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/356souphttpsrc: Implement soup session sharing2020-02-19T04:52:39ZBugzilla Migration Usersouphttpsrc: Implement soup session sharing## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#780140)](https://bugzilla.gnome.org/show_bug.cgi?id=780140)**
## Description
Also needs some patches for adaptivedemux to make use of that, but with that
it's then...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#780140)](https://bugzilla.gnome.org/show_bug.cgi?id=780140)**
## Description
Also needs some patches for adaptivedemux to make use of that, but with that
it's then possible to use exactly the same connection for the initial
manifest, any variant manifests and the fragments. Which speeds up
time-to-play a lot especially if using HTTPS where every connection setup is
very expensive.
### See also
* [Bug 785110](https://bugzilla.gnome.org/show_bug.cgi?id=785110)
* [Bug 762138](https://bugzilla.gnome.org/show_bug.cgi?id=762138)1.13.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/360rtpsession: send BYE after timeout only for internal sources that were the su...2022-10-11T11:40:48ZBugzilla Migration Userrtpsession: send BYE after timeout only for internal sources that were the suggested_ssrc in the past## Submitted by George Kiagiadakis `@gkiagia`
**[Link to original bug (#780867)](https://bugzilla.gnome.org/show_bug.cgi?id=780867)**
## Description
Created attachment 349172
rtpsession: send BYE after timeout only for internal so...## Submitted by George Kiagiadakis `@gkiagia`
**[Link to original bug (#780867)](https://bugzilla.gnome.org/show_bug.cgi?id=780867)**
## Description
Created attachment 349172
rtpsession: send BYE after timeout only for internal sources that were the suggested_ssrc in the past
There is a logic in rtpsession to send BYE for internal sources that are inactive for a long time. This is basically done as an optimization, to remove stale sources that have been created in the past for internal reasons but are no longer in use (see [bug 720440](https://bugzilla.gnome.org/show_bug.cgi?id=720440)).
However, previously, this logic would also affect retransmission sources. Rtx sources *can* be inactive for some time, for a very legitimate reason (no packet loss), but we shouldn't send BYE for them because they may still be used. They should stay around as receivers (as the RFC states for all inactive senders).
**Patch 349172**, "rtpsession: send BYE after timeout only for internal sources that were the suggested_ssrc in the past":
[0001-rtpsession-send-BYE-after-timeout-only-for-internal-.patch](/uploads/8f296857a4afa6d5b20c5941871717e7/0001-rtpsession-send-BYE-after-timeout-only-for-internal-.patch)Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/362qtmux "seek" error when in streaming mode2021-08-23T05:16:40ZBugzilla Migration Userqtmux "seek" error when in streaming mode## Submitted by yis..@..nt.com
**[Link to original bug (#781121)](https://bugzilla.gnome.org/show_bug.cgi?id=781121)**
## Description
Created attachment 349593
attachment showing a potential fix (in function gst_qt_mux_start_file(...## Submitted by yis..@..nt.com
**[Link to original bug (#781121)](https://bugzilla.gnome.org/show_bug.cgi?id=781121)**
## Description
Created attachment 349593
attachment showing a potential fix (in function gst_qt_mux_start_file(...) under .../gst/isomp4/gstqtmux.c
There should be no seek in the mux when we set property of "fragment-duration" to non-zero and "streamable" to TRUE. However I found the qtmux still did "seek" under the function gst_qt_mux_stop_file(...) for updating the qtmux->moov->mvex.mehd.fragment_duration in our case.
Basically the "streamable" config got ignored because the qtmux_klass->format != GST_QT_MUX_FORMAT_ISML in our case. The streamable was set in a later stage by the following piece of code under function gst_qt_mux_start_file (GstQTMux * qtmux) when the code found that the downstream is not seekable:
======
case GST_QT_MUX_MODE_FRAGMENTED:
if (!gst_qt_mux_downstream_is_seekable (qtmux)) {
GST_WARNING_OBJECT (qtmux, "downstream is not seekable, but "
"streamable=false. Will ignore that and create streamable output "
"instead");
qtmux->streamable = TRUE;
g_object_notify (G_OBJECT (qtmux), "streamable");
======
However it missed to update the qtmux->mux_mode to GST_QT_MUX_MODE_FRAGMENTED_STREAMABLE from GST_QT_MUX_MODE_FRAGMENTED after setting qtmux->streamable = TRUE
As we are not in GST_QT_MUX_MODE_FRAGMENTED_STREAMABLE which is needed to prevent the "seek" described above, we hit the issue.
A potential fix tested in our case is attached (screenshot of the change).
Please let us know if you need any more information regarding this bug.
Thanks,
Song
**Attachment 349593**, "attachment showing a potential fix (in function gst_qt_mux_start_file(...) under .../gst/isomp4/gstqtmux.c":
![qtmux_changes](/uploads/8fd151116ba25ffcc35b8175547d1f42/qtmux_changes.PNG)
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/366multifilesink: add "prefix" property2023-06-02T16:43:27ZBugzilla Migration Usermultifilesink: add "prefix" property## Submitted by Ligverd
**[Link to original bug (#781497)](https://bugzilla.gnome.org/show_bug.cgi?id=781497)**
## Description
Created attachment 350066
add property prefix multifilesink
add property "prefix"
multifilesi...## Submitted by Ligverd
**[Link to original bug (#781497)](https://bugzilla.gnome.org/show_bug.cgi?id=781497)**
## Description
Created attachment 350066
add property prefix multifilesink
add property "prefix"
multifilesink prefix="record/%Y/%m/%d/%H%M" location=-%010d.ts""
prefix is the syntax for strftime
and automatically creates the required directory
/2017/04/01/1056-0000000001.ts
**Patch 350066**, "add property prefix multifilesink":
[add_prefix_multifilesink.patch](/uploads/b852ae3bde60fd9f2f71aad118cfb86d/add_prefix_multifilesink.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/367vp9dec: "Internal GStreamer error: code not implemented" when post-processing...2023-06-02T16:51:00ZBugzilla Migration Uservp9dec: "Internal GStreamer error: code not implemented" when post-processing=true## Submitted by Florian Nierhaus
**[Link to original bug (#781559)](https://bugzilla.gnome.org/show_bug.cgi?id=781559)**
## Description
Hi,
I want to enable the post-processing in vp9dec .
When I enable it then I get:
...## Submitted by Florian Nierhaus
**[Link to original bug (#781559)](https://bugzilla.gnome.org/show_bug.cgi?id=781559)**
## Description
Hi,
I want to enable the post-processing in vp9dec .
When I enable it then I get:
ERROR default video-frame.c:161:gst_video_frame_map_id: failed to map video frame plane 0
WARN videofilter gstvideofilter.c:292:gst_video_filter_transform:`<videoconvert1>` warning: invalid video buffer received
ERROR:root:(GLib.Error('Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.', 'gst-core-error-quark', 3), 'gstvideofilter.c(292): gst_video_filter_transform (): /GstPipeline:main-pipeline/GstVide
oConvert:videoconvert1:\ninvalid video buffer received')
(GLib.Error('Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.', 'gst-core-error-quark', 3), 'gstvideofilter.c(292): gst_video_filter_transform (): /GstPipeli
ne:main-pipeline/GstVideoConvert:videoconvert1:\ninvalid video buffer received')
my pipeline works fine with post-processing disabled in vp9dec
I am using current master (v1.6.1-467-g15afee1) of libvpx and compiled it with:
--enable-vp9-postproc --enable-error-concealment --enable-postproc --enable-shared --enable-pic
Thank you and best regards,
Florianhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/370qtdemux: Parsing sgpd/sbgp box to support per sample group encryption2023-10-13T15:50:43ZBugzilla Migration Userqtdemux: Parsing sgpd/sbgp box to support per sample group encryption## Submitted by Seungha Yang
**[Link to original bug (#782224)](https://bugzilla.gnome.org/show_bug.cgi?id=782224)**
## Description
ISO/IEC 23001-7 Common encryption specification defines seig box
which can override default protec...## Submitted by Seungha Yang
**[Link to original bug (#782224)](https://bugzilla.gnome.org/show_bug.cgi?id=782224)**
## Description
ISO/IEC 23001-7 Common encryption specification defines seig box
which can override default protection parameters of Track Encryption box (tenc).
Note that, Sample to Group box (sbgp) and Sample Group Description box (sgpd)
are required for parsing seig box, since sbgp and sgpd are linked structure
and seig is one type of child box of sgpd.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/372rtspsrc: Wrong error message on 4042023-10-13T15:45:50ZBugzilla Migration Userrtspsrc: Wrong error message on 404## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#782482)](https://bugzilla.gnome.org/show_bug.cgi?id=782482)**
## Description
The message is about authentication when it's just a 404.
$ gst-play-1.0 rtsp://127....## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#782482)](https://bugzilla.gnome.org/show_bug.cgi?id=782482)**
## Description
The message is about authentication when it's just a 404.
$ gst-play-1.0 rtsp://127.0.0.1:8554/doesnt-exist
Press 'k' to see a list of keyboard shortcuts.
Now playing rtsp://127.0.0.1:8554/doesnt-exist
Pipeline is live.
ERROR Could not open resource for reading. for rtsp://127.0.0.1:8554/doesnt-exist
ERROR debug information: gstrtspsrc.c(5325): gst_rtspsrc_setup_auth (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source:
No supported authentication protocol was found
Reached end of play list.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/378splitmuxsink: Sink does not recover well after skew reset2023-10-13T15:54:52ZBugzilla Migration Usersplitmuxsink: Sink does not recover well after skew reset## Submitted by James Morris
**[Link to original bug (#783549)](https://bugzilla.gnome.org/show_bug.cgi?id=783549)**
## Description
I have a pipeline that gets video from RTSP and saves it using splitmuxsink.
Pipeline: rtspsrc !...## Submitted by James Morris
**[Link to original bug (#783549)](https://bugzilla.gnome.org/show_bug.cgi?id=783549)**
## Description
I have a pipeline that gets video from RTSP and saves it using splitmuxsink.
Pipeline: rtspsrc ! rtph264depay ! h264parse ! splitmuxsink
Occasionally, if the connection to the video source is not very good I start seeing skew issues. When this happens I see the warning message "rtp delta too big, reset skew." If the jitter buffer decides it is time to reset the skew the splitmuxsink gets confused and stops splitting files at the correct time for a while.
I tracked it down to the call handle_mq_input. From what I can tell before the function will call check_completed_gop it first does a check on the running time with the max running time. In the case of resetting timestamps caused by the skew reset, the running time doesn't seem to update until the frame timestamps catch up to the running time timestamps. Until then no splits are made and the video buffer is held on to and grows. Eventually either the pipeline shuts down or the timestamps catch up and a large file is written.
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/381splitmuxsink: Added new async-finalize mode2020-03-11T05:26:15ZBugzilla Migration Usersplitmuxsink: Added new async-finalize mode## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#783754)](https://bugzilla.gnome.org/show_bug.cgi?id=783754)**
## Description
See commit message## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#783754)](https://bugzilla.gnome.org/show_bug.cgi?id=783754)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/383rtpmanager: Add support for in-band synchronization (RFC 6051).2022-04-20T15:14:58ZBugzilla Migration Userrtpmanager: Add support for in-band synchronization (RFC 6051).## Submitted by GstBlub
**[Link to original bug (#784132)](https://bugzilla.gnome.org/show_bug.cgi?id=784132)**
## Description
Created attachment 354323
rtpmanager
This allows endpoints to synchronize instantly rather than ha...## Submitted by GstBlub
**[Link to original bug (#784132)](https://bugzilla.gnome.org/show_bug.cgi?id=784132)**
## Description
Created attachment 354323
rtpmanager
This allows endpoints to synchronize instantly rather than having to wait for the first RTCP SR.
~~**Patch 354323**~~, "rtpmanager":
[0001-rtpmanager-Add-support-for-in-band-synchronization-R.patch](/uploads/2daa428c2c926ff9edd973cdb5d24798/0001-rtpmanager-Add-support-for-in-band-synchronization-R.patch)Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/384meson: directories missing meson.build files2018-11-14T04:10:17ZBugzilla Migration Usermeson: directories missing meson.build files## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#784134)](https://bugzilla.gnome.org/show_bug.cgi?id=784134)**
## Description
Generated using:
diff <(find . -name Makefile.am | xargs -n1 dirname) <(find . -name ...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#784134)](https://bugzilla.gnome.org/show_bug.cgi?id=784134)**
## Description
Generated using:
diff <(find . -name Makefile.am | xargs -n1 dirname) <(find . -name meson.build | xargs -n1 dirname) |grep '`^`<'
< ./docs/plugins
< ./tests/icles
< ./tests/examples/equalizer
< ./tests/examples/jack
< ./tests/examples
< ./tests/examples/spectrum
< ./tests/examples/cairo
< ./tests/examples/v4l2
< ./tests/examples/shapewipe
< ./tests/examples/rtp
< ./tests/examples/audiofx
< ./tests/examples/level
< ./tests/files
< ./ext/libcaca
< ./ext/aalib
< ./ext/raw1394
< ./sys/sunaudio
< ./sys/oss4
< ./sys/osxaudio
< ./sys/waveform
< ./sys/osxvideo
< ./sys/osshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/388rtspsrc: reduce default latency from 2.0 secs to 0.5 secs2023-10-12T17:51:39ZBugzilla Migration Userrtspsrc: reduce default latency from 2.0 secs to 0.5 secs## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By d...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#784785)](https://bugzilla.gnome.org/show_bug.cgi?id=784785)**
## Description
Created attachment 355318
rtspsrc: reduce default latency from 2.0 secs to 0.5 secs
By default rtspsrc uses a fairly high default latency of 2 seconds.
I wonder if this really makes sense, and what this is based on.
If there's no Good Reason(tm) then perhaps we should reduce that drastically to something lower, maybe 500ms or even 250ms ?
People who are on very bad networks can still set this to something higher manually.
**Patch 355318**, "rtspsrc: reduce default latency from 2.0 secs to 0.5 secs":
[0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch](/uploads/f189ee328b755dcc3970016a9ac74065/0001-rtspsrc-reduce-default-latency-from-2.0-secs-to-0.5-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/390when play a rstp mov, gstomxvideodec get no codec_data for first frame2023-10-12T17:49:50ZBugzilla Migration Userwhen play a rstp mov, gstomxvideodec get no codec_data for first frame## Submitted by leven
**[Link to original bug (#785432)](https://bugzilla.gnome.org/show_bug.cgi?id=785432)**
## Description
when play a rstp mov, omx h264 decoder failed because of gstomxvideodec without codec_data for first frame...## Submitted by leven
**[Link to original bug (#785432)](https://bugzilla.gnome.org/show_bug.cgi?id=785432)**
## Description
when play a rstp mov, omx h264 decoder failed because of gstomxvideodec without codec_data for first frame, it contains sps/pps, they lost!!!!
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/393rtpsession: Also cache RTX stream caps and send caps2022-10-03T11:00:17ZBugzilla Migration Userrtpsession: Also cache RTX stream caps and send caps## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#785777)](https://bugzilla.gnome.org/show_bug.cgi?id=785777)**
## Description
See commit message## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#785777)](https://bugzilla.gnome.org/show_bug.cgi?id=785777)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/394osxaudiocore: fix typo2018-12-17T14:22:49ZBugzilla Migration Userosxaudiocore: fix typo## Submitted by Nicola `@drakkan`
**[Link to original bug (#786030)](https://bugzilla.gnome.org/show_bug.cgi?id=786030)**
## Description
Created attachment 357229
patch
kAudioFormatFlagIsSignedInteger is a format flags
...## Submitted by Nicola `@drakkan`
**[Link to original bug (#786030)](https://bugzilla.gnome.org/show_bug.cgi?id=786030)**
## Description
Created attachment 357229
patch
kAudioFormatFlagIsSignedInteger is a format flags
**Patch 357229**, "patch":
[0001-osxcoreaudio-fix-typo.patch](/uploads/3ca598e048ee2bc237907c13318d6c2f/0001-osxcoreaudio-fix-typo.patch)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/397gtkglsink: add "rotate-method" property2023-10-12T17:49:05ZBugzilla Migration Usergtkglsink: add "rotate-method" property## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#786991)](https://bugzilla.gnome.org/show_bug.cgi?id=786991)**
## Description
This should match the capabilities of glimagesink, this includes support for the AffineTr...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#786991)](https://bugzilla.gnome.org/show_bug.cgi?id=786991)**
## Description
This should match the capabilities of glimagesink, this includes support for the AffineTransformationMeta and the image-orientation tag as well as manual rotation using the property.
I didn't do it in glsinkbin becausse the GL happens in the GTK thread in that case.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/398qtdemux: segmentation fauit with protected DASH streams2022-02-16T09:51:00ZBugzilla Migration Userqtdemux: segmentation fauit with protected DASH streams## Submitted by Juergen Sachs `@jsachs`
**[Link to original bug (#787061)](https://bugzilla.gnome.org/show_bug.cgi?id=787061)**
## Description
Created attachment 358824
detailed gdb backtrace
When decoding a protected DASH st...## Submitted by Juergen Sachs `@jsachs`
**[Link to original bug (#787061)](https://bugzilla.gnome.org/show_bug.cgi?id=787061)**
## Description
Created attachment 358824
detailed gdb backtrace
When decoding a protected DASH stream, the qtdemux raises a segmentation fault. This can be reproduced by
gst-launch-1.0 http://freenettvcon10-i.akamaihd.net/dash/live/499767/freenet10/dash.mpd
The stream is the DASH source of a freenet.TV internet connect service "Insight (connect". Obviously this content is protected. Gstreamer should not crash event we no not have any protection handling plugin.
The crash occures in qtdemux when the audio init segment is parsed:
=====
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2062]
0xb0469428 in __gst_slow_read32_le (data=0x78657278 <Address 0x78657278 out of bounds>)
at /home/metz/Projekte/G_SX7/DCP_SYS/Install/Core/.tmp/include/gstreamer-1.0/gst/gstutils.h:255
255 return _GST_READ_UINT32_LE (data);
(gdb) bt
#0 0xb0469428 in __gst_slow_read32_le (data=0x78657278 <Address 0x78657278 out of bounds>)
at /home/metz/Projekte/G_SX7/DCP_SYS/Install/Core/.tmp/include/gstreamer-1.0/gst/gstutils.h:255
#1 0xb04a0a58 in qtdemux_parse_trak (qtdemux=0xb030e308, trak=0xb4103248)
at /home/metz/Projekte/G_SX7/DCP_SYS/Media/GST-1.0/gst-plugins-good/gst/isomp4/qtdemux.c:11140
=====
More detailed log attached
More information about the bug will follow
```
**Attachment 358824**, "detailed gdb backtrace":
[gdb.log](/uploads/fa18ce45cfef30b261ffee115c458713/gdb.log)
Version: 1.12.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/399Memory leak in gstqtmux.c2023-10-12T17:45:20ZBugzilla Migration UserMemory leak in gstqtmux.c## Submitted by Anton Nikolaevsky
**[Link to original bug (#787144)](https://bugzilla.gnome.org/show_bug.cgi?id=787144)**
## Description
Created attachment 358954
proposed fix
Hello!
I have an application which takes vid...## Submitted by Anton Nikolaevsky
**[Link to original bug (#787144)](https://bugzilla.gnome.org/show_bug.cgi?id=787144)**
## Description
Created attachment 358954
proposed fix
Hello!
I have an application which takes video stream from IP camera and streams it as video/mp4 through web-server. The application uses the following pipeline to produce browsers-friendly mp4-stream:
appsrc -> h264parse -> qtmux -> appsink
The problem is the application leaks GstBuffer-s steadily. AddressSanitizer reports the following 2 stacks with direct leaks:
Direct leak of 43792 byte(s) in 161 object(s) allocated from:
` #0` 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
` #1` 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
` #2` 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
` #3` 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
` #4` 0x7f978edcea05 in gst_buffer_new_allocate gstreamer-1.11.2/gst/gstbuffer.c:846
` #5` 0x7f97705743a8 in gst_h264_parse_wrap_nal gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:424
` #6` 0x7f9770577c7b in gst_h264_parse_process_nal gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:889
` #7` 0x7f977057a9e3 in gst_h264_parse_handle_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1222
` #8` 0x7f9770863093 in gst_base_parse_handle_buffer gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
` #9` 0x7f977086ee72 in gst_base_parse_chain gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
` #10` 0x7f978ee6cd74 in gst_pad_chain_data_unchecked gstreamer-1.11.2/gst/gstpad.c:4205
` #11` 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
` #12` 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
` #13` 0x7f97708aed19 in gst_base_src_loop gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
` #14` 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
` #15` 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
` #16` 0x7f978e667b9d in g_thread_pool_thread_proxy glib-2.42.1/glib/gthreadpool.c:307
` #17` 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
` #18` 0x7f97c3b05063 in start_thread /build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)
Direct leak of 8976 byte(s) in 33 object(s) allocated from:
` #0` 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
` #1` 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
` #2` 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
` #3` 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
` #4` 0x7f97708d109f in gst_byte_writer_reset_and_get_buffer gstreamer-1.11.2/libs/gst/base/gstbytewriter.c:244
` #5` 0x7f9770581b0a in gst_h264_parse_handle_sps_pps_nals gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2306
` #6` 0x7f9770582ccf in gst_h264_parse_pre_push_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2417
` #7` 0x7f9770866ead in gst_base_parse_push_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2455
` #8` 0x7f9770865783 in gst_base_parse_handle_and_push_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2337
` #9` 0x7f9770868e5a in gst_base_parse_finish_frame gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2678
` #10` 0x7f977057ac44 in gst_h264_parse_handle_frame gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1248
` #11` 0x7f9770863093 in gst_base_parse_handle_buffer gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
` #12` 0x7f977086ee72 in gst_base_parse_chain gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
` #13` 0x7f978ee6cd74 in gst_pad_chain_data_unchecked gstreamer-1.11.2/gst/gstpad.c:4205
` #14` 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
` #15` 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
` #16` 0x7f97708aed19 in gst_base_src_loop gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
` #17` 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
` #18` 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
` #19` 0x7f978e667b9d in g_thread_pool_thread_proxy glib-2.42.1/glib/gthreadpool.c:307
` #20` 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
` #21` 0x7f97c3b05063 in start_thread /build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)
With help of additional logs in gst-plugins-good-1.11.2/gst/isomp4/gstqtmux.c it was noticed that the buffers leak when the pipeline is about to stop (on client disconnect) and there were some buffers in GstQTPad::fragment_buffers. Unfortunately, I was not able to find the easy way
to reproduce such conditions with simple gst-launch command line use-case (tried filesrc and rtspsrc).
The proposed fix is attached.
**Patch 358954**, "proposed fix":
[gstqtmux.patch](/uploads/7a1721b87238fc0ab05f385a7f3a1ae3/gstqtmux.patch)
Version: 1.11.2