GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-07-06T10:18:15Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2773rtspsrc: protocols=http doesn't work with gst-rtsp-server examples2023-07-06T10:18:15ZBugzilla Migration Userrtspsrc: protocols=http doesn't work with gst-rtsp-server examples## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols...## Submitted by Göran Jönsson
**[Link to original bug (#793502)](https://bugzilla.gnome.org/show_bug.cgi?id=793502)**
## Description
Created attachment 368399
logs from server
If running
gst-launch-1.0 -e rtspsrc protocols=http location="rtsp://127.0.0.1:8554/test" ! fakesink
against an (gst-rtsp-server/examples) example (test-video) server does not work.
If using protocols tcp or default it works.
Attach logs from server(test-video) and client(rtspsrc protocols=http)
**Attachment 368399**, "logs from server":
[test-video_log.txt](/uploads/179cedbabfb20303dcbb8c8bb4809d7e/test-video_log.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2772flvmux: dts/pts on output buffers2023-07-06T14:53:46ZBugzilla Migration Userflvmux: dts/pts on output buffers## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initiall...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initially created as a clone of [Bug 793457](https://bugzilla.gnome.org/show_bug.cgi?id=793457) +++
$ gst-launch-1.0 videotestsrc ! x264enc ! flvmux ! fakesink silent=false -v | grep -e Segment -e chain | head -n 5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2771qtdemux: Premature EOS when some files are played in push mode2023-11-28T15:18:22ZBugzilla Migration Userqtdemux: Premature EOS when some files are played in push mode## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794199)](https://bugzilla.gnome.org/show_bug.cgi?id=794199)**
## Description
Created attachment 369503
Test vector
The attached file has 6 frames, in two ...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#794199)](https://bugzilla.gnome.org/show_bug.cgi?id=794199)**
## Description
Created attachment 369503
Test vector
The attached file has 6 frames, in two GOPs, both with I-B-P layout.
It's demuxed correctly in pull mode.
$ gst-launch-1.0 -v filesrc location=ibpibp-non-frag.mp4 ! qtdemux ! fakesink silent=false |egrep 'segment|chain'
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)333333333, stop=(guint64)2333333333, time=(guint64)0, position=(guint64)333333333, duration=(guint64)18446744073709551615;";) 0x5649226dcb20
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1025 bytes, dts: 0:00:00.000000000, pts: 0:00:00.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00000040 discont , meta: none) 0x7ff4c8005340
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (305 bytes, dts: 0:00:00.333333333, pts: 0:00:01.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (131 bytes, dts: 0:00:00.666666666, pts: 0:00:00.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005010
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (499 bytes, dts: 0:00:01.000000000, pts: 0:00:01.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7ff4c8005120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (487 bytes, dts: 0:00:01.333333333, pts: 0:00:02.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005340
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (215 bytes, dts: 0:00:01.666666666, pts: 0:00:01.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00002000 delta-unit , meta: none) 0x7ff4c8005450
On the other hand, it loses the last 2 frames when demuxed in push mode:
$ gst-launch-1.0 -v pushfilesrc location=ibpibp-non-frag.mp4 ! qtdemux ! fakesink silent=false |egrep 'segment|chain'
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0x5619bebdeea0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)333333333, stop=(guint64)2333333333, time=(guint64)0, position=(guint64)333333333, duration=(guint64)18446744073709551615;";) 0x7f91ec0065c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1025 bytes, dts: 0:00:00.000000000, pts: 0:00:00.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00004040 discont tag-memory , meta: none) 0x7f91ec00a400
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (305 bytes, dts: 0:00:00.333333333, pts: 0:00:01.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00006000 delta-unit tag-memory , meta: none) 0x7f91ec00a510
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (131 bytes, dts: 0:00:00.666666666, pts: 0:00:00.666666666, duration: 0:00:00.333333334, offset: -1, offset_end: -1, flags: 00006000 delta-unit tag-memory , meta: none) 0x7f91ec00a620
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (499 bytes, dts: 0:00:01.000000000, pts: 0:00:01.333333333, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00004000 tag-memory , meta: none) 0x7f91ec00a510
The offending code is this condition:
pts = QTSAMPLE_PTS (stream, sample);
[...]
if (G_UNLIKELY (demux->segment.stop != -1
&& demux->segment.stop <= pts && stream->on_keyframe)) {
GST_DEBUG_OBJECT (demux, "we reached the end of our segment.");
Note that the `demux->segment.stop <= pts` comparison is wrong because it's comparing buffer time across different GstSegments, instead of translating both to stream time.
The difference is very important because the user requests to play e.g. the range [0, 2) s *in stream time*; it should not need to care whether the track (buffer) presentation range is actually [0.333, 2.333) because this file already has an edit list to map that to [0, 2) s in stream time.
The `stream->on_keyframe` check is also interesting. I have not experimented with it too much, but on first glance it looks like it would avoid entering the `if` body on most files, which would explain why this issue has not been detected before. Since most GOPs are longer than 3 frames and for most files with basic edit lists, like the one attached, the buffer PTS match can only occur in the last GOP, the chances of it happening on both buffer PTS = segment.stop and exactly the next frame after an I-frame are quite low. (EOS is sent later because as a reaction of upstream sending EOS itself when there are no more bytes to read, not because of last frame emission*).
* To make things worse, our WebKit MSE implementation actually relies on EOS not being sent on last frame emission when working on push mode. Today I've learned that is the case most often but not always.
**Attachment 369503**, "Test vector":
![ibpibp-non-frag](/uploads/5a6ff5e18cae6435209066e3070ce674/ibpibp-non-frag.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2770mpeg4videoparse: Need detect picture coding type when drain2023-07-06T09:54:03ZBugzilla Migration Usermpeg4videoparse: Need detect picture coding type when drain## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame....## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame. mpeg4videoparse will detect coding type when detect start code after VOP. our use case will drain after VOP and can't detect start code after VOP. Add check coding type code when drain.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2768Unable to send an EOS event to an adaptative demux pipeline such as HLS or DASH2023-07-06T10:52:00ZBugzilla Migration UserUnable to send an EOS event to an adaptative demux pipeline such as HLS or DASH## Submitted by parithi
**[Link to original bug (#795607)](https://bugzilla.gnome.org/show_bug.cgi?id=795607)**
## Description
I am trying to decode hls stream with following pipeline
```
$ gst-launch-1.0 souphttpsrc location=...## Submitted by parithi
**[Link to original bug (#795607)](https://bugzilla.gnome.org/show_bug.cgi?id=795607)**
## Description
I am trying to decode hls stream with following pipeline
```
$ gst-launch-1.0 souphttpsrc location=http://10.0.90.12:80/live/scte/master_1.m3u8 ! hlsdemux ! queue ! decodebin ! video/x-raw ! x264enc ! h264parse ! mpegtsmux ! udpsink port=8888 host=10.0.100.24 -e
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
`^`Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...
```
if I stop the playback by pressing "ctl+c" pipeline is not closing, it keeps on playing.
From my initial investigation found out that basesrc received EOS event but it is not propagated to downstream elements.
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2761Application Development Manual: add gst-launch crash course before diving int...2023-07-04T15:46:46ZBugzilla Migration UserApplication Development Manual: add gst-launch crash course before diving into code## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707586)](https://bugzilla.gnome.org/show_bug.cgi?id=707586)**
## Description
Ian Davidson suggested this:
On the GStreamer web site it says “Application Development Ma...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707586)](https://bugzilla.gnome.org/show_bug.cgi?id=707586)**
## Description
Ian Davidson suggested this:
On the GStreamer web site it says “Application Development Manual (Read this first) ” - so that would seem to be the place to start if you want to learn about Gstreamer.
Very early in the document (section 2.1), it says that “The programmer can use an extensive set of powerful tools to create media pipelines without writing a single line of code. ” That is good to know and is brought about by the library of 'Plug-ins'.
But – then as you continue to read the manual, you are thrown heavily into programming. Straight away.
Might I suggest that very early on you have mention of gst-launch – since, using that you can do things without having to write a single line of coding. However, the chapter on gst-launch itself is not an easy-to-read chapter: It starts with a 'simple commandline' and then shows a more complex one – but without any explanation. If we take the first example
gst-launch filesrc location=hello.mp3 ! mad ! audioresample ! osssink
you could then describe what is happening. e.g.:
gst-launch is a program which enables the user to construct pipelines using command-line parameters.
Filesrc is an element (or a plugin) – in this case it will read data from a file and needs to know the name of the file to open. It will output the data so as to be the source for the next element in the pipe-line.
The “!” symbol separates the first element from the next.
mad is the next element in the pipe-line: It will decode mp3 data. It picks up the source provided by the previous element and then outputs the decoded data for the next element in the pipe-line.
Once again, a “!” symbol separates the elements.
audioresample resamples the Audio. (I don’t know why this is a benefit – it could be explained)
Another “!”
osssink takes the audio signal and sends it to an output device which supports (or is supported by) OSS.
The second example could then be similarly explained – which would be a useful exercise since the single vob file is being demuxed with part of the data going one way and the rest another. A reference, at this point to the Overview of available plug-ins would be beneficial. Perhaps an example where more options need to be specified could also be explained.
Then you can say that, if you need to build this into an application, you can do the same stuff with code and if you need to do something which is not currently supported, you can write your own plug-in – so read on...
I hope this is usefulhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2750vtenc: vtenc_h264 causing too many Redistribute latency...2023-08-04T20:57:05ZBugzilla Migration Uservtenc: vtenc_h264 causing too many Redistribute latency...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ! videorate ! video/x-raw, format=UYVY, width=1920, height=1080, framerate=30/1 ! queue ! vtenc_h264 ! fakesink
I’m running gstreamer version 1.12.3 built from git source, on a 2017 15” Macbook Pro, w/macOS 10.12.6.
The relevant output:
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.154950000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.235169000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.241439000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.253913000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.278467000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:00.288046000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.371569000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:03.043466000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:03.065692000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:03.090887000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 4 fps 30/1 time 0:00:00.133333332
Redistribute latency...
The vtenc_h264 element is calling gst_video_encoder_set_latency() seemingly way too often. It results in gst-launch printing "Redistribute latency..." quite often (several times per second sometimes).
What's happening seems to be the element keeping track of the underlying encoder's pending frame count. If the pending frame count ever changes (checked every frame), then it calls gst_video_encoder_set_latency().
Is it not the case that instead of tracking exact latency each frame and forcing a pipeline latency redistribution every time it changes at all, the element should just check if the latency is greater than the currently configured range (checked via call to gst_video_encoder_get_latency()) and only call gst_video_encoder_set_latency() if it's outside the range?
I will attach a patch that works for me shortly.
Version: 1.12.3Piotr BrzezińskiPiotr Brzezińskihttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2749osxaudiosrc drops frames when osxaudiosink misses frames2024-01-22T16:13:51ZBugzilla Migration Userosxaudiosrc drops frames when osxaudiosink misses frames## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink ...## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(866): GstFlowReturn gst_audio_base_src_create(GstBaseSrc *, guint64, guint, GstBuffer **) (): /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0:
Dropped 9261 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
I don't quite understand why osxaudiosrc drops frames when the *sink* is the one that's not receiving all of the frames. This doesn't happen with fakesink or filesink.
Also, it's "solved" by setting "osxaudiosink sync=0".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2747wavparse: 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/gstreamer/-/issues/2746avidemux: Doesn't handle files with large gaps between audio/video streams pr...2023-07-10T14:54:29ZBugzilla 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/516832Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2745decodebin3: Race with caps changing in stream2023-07-10T13:17:57ZBugzilla 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/1Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2744audiofirfilter: Add support for changing kernel size without draining the sam...2023-07-01T21:18:37ZBugzilla 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/gstreamer/-/issues/2743RTP depayloaders should send tags with metadata such as codec and bitrate2023-07-01T19:23:24ZBugzilla 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/gstreamer/-/issues/2742qtdemux: Support chapters and provide a GstToc2023-07-01T19:20:38ZBugzilla Migration Userqtdemux: Support chapters and provide a GstToc## 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/gstreamer/-/issues/2741avidemux, qtdemux, dvdec: signal DVCPRO50 codec properly2023-07-03T07:51:12ZBugzilla 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/gstreamer/-/issues/2740matroskademux: support for multi-segment Matroska files2023-07-01T19:09:29ZBugzilla 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/gstreamer/-/issues/2726rmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking he...2023-06-27T23:17:01ZBugzilla Migration Userrmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking header, unprintable FOURCC>## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes...## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes my system Hangs (Windows x86, Linux, Win CE etc).
this problem for the video file is present from GST 0.1 to Even in GST 1.6. please help to guide me which part of code can be debugged further for the same.
>1: Test clip run command
gst-launch-1.0 --gst-debug-level=5 playbin uri=file:///D:/11_OnePiece_RV4.rmvb
>2: Test clip source file
Will attach somewhere and share the location in comment later on this bug.
>3: Logs with Debug level 5
Attached.
>4: My Analysis:
a. Test real media clip headers are correct.
I checked each and every information and links (including size and other details for all Types of FOURCC.
b. While decoding, it detects [.RMF, PROP , MDPR , MDPR, MDPR, CONT] correctly next available FOURCC is "DATA", which were never detected.
c. This file i am able to play on lots of other frameworks and plateform (VLC (Win/ Linux), Android devices etc.).
Logs analysis is as below (Line# 97156)
----
0:00:05.198350818 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 858, length 31, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.198403458 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 858 length 31, time 0
0:00:05.198453449 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 005683F0, maxsize:34 offset:0 size:31
0:00:05.198512048 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.198562370 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.198611699 6904 0F7AEA08 DEBUG default rmutils.c:83:gst_rm_utils_read_tags: File Content : (CONT) len = 31
0:00:05.198662022 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: title =
0:00:05.198718965 6904 0F7AEA08 DEBUG default rmutils.c:104:gst_rm_utils_read_tags: converting tag from CP1252 to UTF-8
0:00:05.198790807 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: artist = û¤·¤ÎZHU
0:00:05.198845433 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: copyright = bbs.jumpcn.com
0:00:05.198896418 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: comment =
0:00:05.198949058 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 005683F0
0:00:05.199001698 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199054999 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199105653 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC500, maxsize:13 offset:0 size:10
0:00:05.199173191 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199224506 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199275822 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199327800 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199381102 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199475787 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC4A0, maxsize:13 offset:0 size:10
0:00:05.199536372 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199586695 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199635362 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199684691 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 4, csize 6
0:00:05.199736338 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199784673 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199833340 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 8, csize 2
0:00:05.199883994 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199931999 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 0F7EC500
0:00:05.199983645 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.200037278 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.200087932 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC440, maxsize:13 offset:0 size:10
0:00:05.200147855 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.200198177 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.200246844 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.200295511 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 2, csize 8
0:00:05.200346827 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
----
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2725mpeg2dec: fix decoding into hardware-mapped buffers2023-06-27T18:06:23ZBugzilla Migration Usermpeg2dec: fix decoding into hardware-mapped buffers## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, a...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, and for performance reasons actually, we might not be able to directly write into buffers backed by 3rdparty hardware. So, this means that we need to maintain some temporary surface/buffers and those are what are being exposed through GstVideoMeta info. Then, internally, the implementation may decide to efficiently convert that into a native format instead.
More precisely, VA-API exposes a vaDeriveImage() API but it might not always be efficient to directly expose GPU memory buffers. So, a temporary surface suitable for CPU interop is being exposed instead. This same happens for VDPAU where there is no direct rendering API, so a temporary image is being used and exposed.
In practice, we just need to carefully maintain map/unmap chains. On map, a clean writable memory buffer is being exposed. On unmap, the contents written by the SW decoder is to be committed. Then, if the frame is to be used again (as reference for example), then it can be mapped again, but with read-only flags this time.
### Blocking
* https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/21 (was: [Bug 735360](https://bugzilla.gnome.org/show_bug.cgi?id=735360))https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2721x264enc: Make sure sinkpad caps are never renegotiated2023-07-07T03:17:56ZBugzilla Migration Userx264enc: Make sure sinkpad caps are never renegotiated## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show_bug.cgi?id=795420)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2705directsoundsrc: device-name doesn't accept windows given names if there are s...2023-06-27T07:56:19ZBugzilla Migration Userdirectsoundsrc: device-name doesn't accept windows given names if there are special characters in## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High...## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High Definition Audio-Gerät)". But works if you change the naming in windows registry, which is only possible for testing purposes. May an device-ID (GUID) based solution is needed!?
$ GST_DEBUG=3,directsoundsrc:5 gst-launch-1.0.exe directsoundsrc buffer-time=10000 device-name="mic (High Definition Audio-Gerät)" ! directsoundsink buffer-time=200000
0:00:00.043914339 3444 02D27260 WARN audioresample gstaudioresample.c:1537:plugin_init: Orc disabled, can't benchmark int vs. float resampler
0:00:00.048490103 3444 02D27260 WARN GST_PERFORMANCE gstaudioresample.c:1540:plugin_init: orc disabled, no benchmarking done
0:00:00.064831675 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:164:gst_directsound_src_class_init: initializing directsoundsrc class
0:00:00.139332696 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:259:gst_directsound_src_init:<GstDirectSoundSrc@00513220> initializing directsoundsrc
0:00:00.144179343 3444 02D27260 ERROR GST_PIPELINE grammar.y:453:gst_parse_element_set: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Gerät)"
0:00:00.148407097 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
0:00:00.151341707 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
[Invalid UTF-8] WARNING: erroneous pipeline: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Ger\xe4t)"