GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:22:56Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/381audiovisualizer: mutex unlock added in error case2021-09-24T13:22:56ZBugzilla Migration Useraudiovisualizer: mutex unlock added in error case## Submitted by Ponnam Srinivas
**[Link to original bug (#787869)](https://bugzilla.gnome.org/show_bug.cgi?id=787869)**
## Description
Created attachment 360023
attached patch
Hi,
In gst_audio_visualizer_chain function. ...## Submitted by Ponnam Srinivas
**[Link to original bug (#787869)](https://bugzilla.gnome.org/show_bug.cgi?id=787869)**
## Description
Created attachment 360023
attached patch
Hi,
In gst_audio_visualizer_chain function.
Jumps out of a held mutex without unlocking it.
if (!klass->render (scope, inbuf, &outframe)) {
ret = GST_FLOW_ERROR;
gst_video_frame_unmap (&outframe);
goto beach;
**Attachment 360023**, "attached patch":
[0001-audiovisualizer-mutex-unlock-added-in-error-case.patch](/uploads/537931b42608e1dcd50cd8f1c28d86fe/0001-audiovisualizer-mutex-unlock-added-in-error-case.patch)
Version: 1.13.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/380videotestsrc: -I and +Q regions are wrong2021-09-24T13:22:56ZBugzilla Migration Uservideotestsrc: -I and +Q regions are wrong## Submitted by Julien Isorce `@cap`
**[Link to original bug (#787582)](https://bugzilla.gnome.org/show_bug.cgi?id=787582)**
## Description
The pipeline gst-launch-1.0 videotestsrc ! ximagesink videotestsrc ! xvimagesink
does not...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#787582)](https://bugzilla.gnome.org/show_bug.cgi?id=787582)**
## Description
The pipeline gst-launch-1.0 videotestsrc ! ximagesink videotestsrc ! xvimagesink
does not output the same colors for some of the bottom left regions: Blue vs Purple. To be more precise the -I (in-phase) and +Q (quadrature) regions are wrong.
Same with:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=BGRx" ! ximagesink videotestsrc ! "video/x-raw, format=NV12" ! videoconvert ! ximagesink
The issue comes from https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/videotestsrc/videotestsrc.c#n71 , the coeffs for yuv and rgb do not match for -I and +Q. I.e. on the +Q, YCbCr(16, 235, 198) is dark purple but RGB(0, 128, 255) is blue.
With git blame I found that -I and +Q regions in videotestsrc have been introduced by commit 768253dc (year 2002). The values for yuv and rgb mentioned above are like this since that commit.
Then the -I and +Q coeffs for bt601 have been copied from bt709 in commit b97e582c (year 2008).
According to http://avisynth.nl/index.php/ColorBars_theory, this should be:
--- a/gst/videotestsrc/videotestsrc.c
+++ b/gst/videotestsrc/videotestsrc.c
@@ -67,8 +67,8 @@ static const struct vts_color_struct vts_colors_bt709_ycbcr_100[] = {
{63, 102, 240, 255, 255, 0, 0, (64 << 8)},
{32, 240, 118, 255, 0, 0, 255, (32 << 8)},
{16, 128, 128, 255, 0, 0, 0, (16 << 8)},
- {16, 198, 21, 255, 0, 0, 128, (16 << 8)}, /* -I ? */
- {16, 235, 198, 255, 0, 128, 255, (16 << 8)}, /* +Q ? */
+ {16, 157, 99, 255, 0, 54, 98, (16 << 8)}, /* -I ? */
+ {16, 172, 146, 255, 75, 17, 126, (16 << 8)}, /* +Q ? */
{0, 128, 128, 255, 0, 0, 0, 0},
{32, 128, 128, 255, 19, 19, 19, (32 << 8)},
};
@@ -97,8 +97,8 @@ static const struct vts_color_struct vts_colors_bt601_ycbcr_100[] = {
{81, 90, 240, 255, 255, 0, 0, (64 << 8)},
{41, 240, 110, 255, 0, 0, 255, (32 << 8)},
{16, 128, 128, 255, 0, 0, 0, (16 << 8)},
- {16, 198, 21, 255, 0, 0, 128, (16 << 8)}, /* -I ? */
- {16, 235, 198, 255, 0, 128, 255, (16 << 8)}, /* +Q ? */
+ {16, 158, 95, 255, 0, 58, 98, (16 << 8)}, /* -I ? */
+ {16, 175, 148, 255, 75, 15, 126, (16 << 8)}, /* +Q ? */
{-0, 128, 128, 255, 0, 0, 0, 0},
{32, 128, 128, 255, 19, 19, 19, (32 << 8)},
};
but this does not make yuv and rgb outputs to look the same either.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/379Unable to decode h.264 from RTSP server2021-09-24T13:22:55ZBugzilla Migration UserUnable to decode h.264 from RTSP server## Submitted by Allan Matthew
**[Link to original bug (#787044)](https://bugzilla.gnome.org/show_bug.cgi?id=787044)**
## Description
I've got an IPTV device which appears to work just fine with VLC and other RTSP-capable software. ...## Submitted by Allan Matthew
**[Link to original bug (#787044)](https://bugzilla.gnome.org/show_bug.cgi?id=787044)**
## Description
I've got an IPTV device which appears to work just fine with VLC and other RTSP-capable software. However within the playbin (as well as other pipelines I've tried) it appears h264parse is unable to handle the datastream. I see the following from the gstreamer debug output:
gst-launch-1.0 playbin uri=rtsp://192.168.1.168:554/hdmi --gst-debug=3
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.1.168:554/hdmi
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (request) SETUP stream 1
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
0:00:00.162460000 5723 0x7fe20900b450 FIXME default gstutils.c:3826:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
0:00:00.162479000 5723 0x7fe20900b4a0 FIXME default gstutils.c:3826:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc1:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
0:00:02.245090000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.245108000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.245112000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.245117000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
0:00:02.251065000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdechw0>` Sub-class should implement drain()
0:00:02.260569000 5723 0x7fe207820f70 WARN vtdec vtdec.c:310:gst_vtdec_negotiate:`<vtdechw0>` error: VTDecompressionSessionCreate returned -12913
0:00:02.260609000 5723 0x7fe207820f70 WARN videodecoder gstvideodecoder.c:745:gboolean gst_video_decoder_setcaps(GstVideoDecoder *, GstCaps *):`<vtdechw0>` Subclass refused caps
0:00:02.260617000 5723 0x7fe207820f70 WARN decodebin gstdecodebin2.c:2505:gboolean connect_pad(GstDecodeBin *, GstElement *, GstDecodePad *, GstPad *, GstCaps *, GValueArray *, GstDecodeChain *, gchar **):`<decodebin1>` Couldn't set vtdechw0 to PAUSED
0:00:02.261430000 5723 0x7fe207820f70 ERROR libav :0:: Overread VUI by 5 bits
0:00:02.261448000 5723 0x7fe207820f70 ERROR libav :0:: Overread VUI by 5 bits
0:00:02.261454000 5723 0x7fe207820f70 ERROR libav :0:: Decoding sps 0 from avcC failed
0:00:02.261549000 5723 0x7fe207820f70 WARN videodecoder gstvideodecoder.c:745:gboolean gst_video_decoder_setcaps(GstVideoDecoder *, GstCaps *):`<avdec_h264-0>` Subclass refused caps
0:00:02.261558000 5723 0x7fe207820f70 WARN decodebin gstdecodebin2.c:2505:gboolean connect_pad(GstDecodeBin *, GstElement *, GstDecodePad *, GstPad *, GstCaps *, GValueArray *, GstDecodeChain *, gchar **):`<decodebin1>` Couldn't set avdec_h264-0 to PAUSED
0:00:02.261831000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.285609000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.285719000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.285727000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.285731000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.285735000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
0:00:02.285939000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.285948000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.285952000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.285956000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
Redistribute latency...
0:00:02.487635000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.500567000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:02.992016000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.026161387 < -+0:00:00.020000000
0:00:03.002633000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.022304414 < -+0:00:00.020000000
0:00:03.056081000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.025659650 < -+0:00:00.020000000
0:00:03.098606000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.024199670 < -+0:00:00.020000000
0:00:03.162608000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.025542416 < -+0:00:00.020000000
0:00:03.237276000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.020886785 < -+0:00:00.020000000
0:00:03.344099000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021757938 < -+0:00:00.020000000
0:00:03.381288000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:03.503956000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.022442428 < -+0:00:00.020000000
0:00:03.727885000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021587424 < -+0:00:00.020000000
0:00:04.122796000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021214951 < -+0:00:00.020000000
0:00:04.609725000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:05.584356000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.020102705 < -+0:00:00.020000000
0:00:05.747763000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:06.979292000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:07.013708000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130181405, resyncing
0:00:08.208908000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:08.496646000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130068027, resyncing
0:00:09.347761000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:09.968630000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130204081, resyncing
0:00:10.581011000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:11.430185000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130249433, resyncing
0:00:11.814706000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:12.902327000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130113378, resyncing
0:00:12.947475000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
`^`Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:13.542908000
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
I've also attached a wireshark pcap.
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/378ximagesink,xvimagesink: handle drain query2021-09-24T13:22:54ZBugzilla Migration Userximagesink,xvimagesink: handle drain query## Submitted by Julien Isorce `@cap`
**[Link to original bug (#786738)](https://bugzilla.gnome.org/show_bug.cgi?id=786738)**
## Description
Created attachment 358306
xvimagesink: unref current image on a drain query
So that a...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#786738)](https://bugzilla.gnome.org/show_bug.cgi?id=786738)**
## Description
Created attachment 358306
xvimagesink: unref current image on a drain query
So that an upstream element can claim all buffers to return to its buffer pool.
**Patch 358306**, "xvimagesink: unref current image on a drain query":
[0001-xvimagesink-unref-current-image-on-a-drain-query.patch](/uploads/162d1d81f8c0dda0e3ad03fb1e738fd1/0001-xvimagesink-unref-current-image-on-a-drain-query.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/376glupload/glsink: Missing draining support2021-09-24T13:22:53ZBugzilla Migration Userglupload/glsink: Missing draining support## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#786175)](https://bugzilla.gnome.org/show_bug.cgi?id=786175)**
## Description
V4L2 in it's archaism requires that all buffers produced are returned before the dr...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#786175)](https://bugzilla.gnome.org/show_bug.cgi?id=786175)**
## Description
V4L2 in it's archaism requires that all buffers produced are returned before the driver can re-allocate buffers (renegotiate the frame size). This problem is solved by draining (returning back) all buffers when an allocation or drain query passes buy. This has been implemented properly in kmssink. The following pipeline currently fails on the first renegotiation:
gst-launch-1.0 v4l2src io-mode=dmabuf ! glimagesink
This work is not trivial and may require few iteration. My plan is to move the EGLImage cache inside the glupload object (needed anyway as the current cache with qdata is not thread safe). This will also clearing the cache when an allocation query, or a drain query is received.
That will help, but won't be sufficient, as the glupload element simply attach the imported buffer to a new buffer (it's half pass-through). We'll need to make sure that it runs in return a downstream allocation query. glvideoconvert would need to do the same when running asynchronously (sync fence) and finally the sinks themself need to copy their render buffer for potential redraws during the process. I think all this should be condition (e.g. sink can check if the render buffer has a parent buffer).
Version: 1.13.x
### Depends on
* [Bug 786051](https://bugzilla.gnome.org/show_bug.cgi?id=786051)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/375glupload: EGLImage cache is not thread safe2021-09-24T13:22:53ZBugzilla Migration Userglupload: EGLImage cache is not thread safe## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#786051)](https://bugzilla.gnome.org/show_bug.cgi?id=786051)**
## Description
When we receive a DMABuf, we create a cache associated EGLImage. While the wrapper ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#786051)](https://bugzilla.gnome.org/show_bug.cgi?id=786051)**
## Description
When we receive a DMABuf, we create a cache associated EGLImage. While the wrapper is refcounted, the way we store that EGLImage is not thread safe. The problem is that we don't get and ref the EGLImage atomically when retrieving the qdata. So in between, sometimes the EGLImage get destroyed, and then we ended with use after free crashing GStreamer or Mesa.
The pipeline I use to reproduce currently:
gst-launch-1.0 v4l2src device=/dev/video1 io-mode=dmabuf ! tee name=t \
t. ! queue ! glsinkbin sink=gtkglsink \
t. ! queue ! glsinkbin sink=gtkglsink \
t. ! queue ! glsinkbin sink=gtkglsink \
t. ! queue ! glsinkbin sink=gtkglsink \
t. ! queue ! glsinkbin sink=gtkglsink
Version: 1.13.x
### Blocking
* [Bug 786175](https://bugzilla.gnome.org/show_bug.cgi?id=786175)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/374bufferpool warning when dynamicaly manipulate a pipeline2021-09-24T13:22:52ZBugzilla Migration Userbufferpool warning when dynamicaly manipulate a pipeline## Submitted by que..@..oo.com
**[Link to original bug (#785994)](https://bugzilla.gnome.org/show_bug.cgi?id=785994)**
## Description
Created attachment 357191
dynamic pipeline manipulation base on gstreamer exemple
With the ...## Submitted by que..@..oo.com
**[Link to original bug (#785994)](https://bugzilla.gnome.org/show_bug.cgi?id=785994)**
## Description
Created attachment 357191
dynamic pipeline manipulation base on gstreamer exemple
With the attach code i received this warn at each filter change:
WARN bufferpool gstbufferpool.c:639:gst_buffer_pool_set_config: can’t change config, have outstanding buffers
(I use the gstreamer 1.0 environnement from apt-get depot)
**Attachment 357191**, "dynamic pipeline manipulation base on gstreamer exemple":
[dynamic_pipeline2.c](/uploads/fd7c232773dfec4f3769d9b3a8da7bc3/dynamic_pipeline2.c)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/373uridecodebin won't connect the sink to decoder while the audio information is...2021-09-24T13:22:51ZBugzilla Migration Useruridecodebin won't connect the sink to decoder while the audio information is wrong## Submitted by Randy Li (ayaka)
**[Link to original bug (#785795)](https://bugzilla.gnome.org/show_bug.cgi?id=785795)**
## Description
I have found lots of video sample files in MPEG TS format with an invalid audio channel. The FFm...## Submitted by Randy Li (ayaka)
**[Link to original bug (#785795)](https://bugzilla.gnome.org/show_bug.cgi?id=785795)**
## Description
I have found lots of video sample files in MPEG TS format with an invalid audio channel. The FFmpeg will ignore those audio channel, but Gstreamer will obey the PID information creating a data path for audio.
I have not looked into the uridecodebin, I think there is something wrong in audio part stopping the connection of the video decoder and video sink.
I talked to slomo last time, he said it could be a bug, so file it today.
You could find a video sample at
https://drive.google.com/open?id=0B0olUVfSCbB3TUxURkFOX2FVQVk
0009_rio_4K_60fps_hevc_20mbps.ts is the smallest files of them.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/371[gl] glcolorscale passthrough mode causing playback failure on video resoluti...2021-09-24T13:22:51ZBugzilla Migration User[gl] glcolorscale passthrough mode causing playback failure on video resolution change## Submitted by Samuel Hurst `@samuelh`
**[Link to original bug (#785745)](https://bugzilla.gnome.org/show_bug.cgi?id=785745)**
## Description
Created attachment 356793
Excerpt of log for the issue described
I've been using G...## Submitted by Samuel Hurst `@samuelh`
**[Link to original bug (#785745)](https://bugzilla.gnome.org/show_bug.cgi?id=785745)**
## Description
Created attachment 356793
Excerpt of log for the issue described
I've been using GStreamer on a Raspberry Pi 2 to display fullscreen DASH. There is no X session involved, it's using OpenGL ES directly on the framebuffer. As gst-launch-1.0 starts with a window size equal to the video resolution of the first DASH representation received and not fullscreen, I use a custom pipeline to resize the video window to match the output screen size. My pipeline is below:
gst-launch-1.0 souphttpsrc location=$MPD_URL ! dashdemux name=d \
d. ! video/quicktime ! queue ! qtdemux ! h264parse ! omxh264dec ! queue \
! glupload ! glcolorconvert ! glcolorscale \
! "video/x-raw(memory:GLMemory),width=$X_RES,height=$Y_RES" ! queue \
! glimagesink
d. ! audio/x-m4a ! queue ! qtdemux ! aacparse ! avdec_aac ! audioconvert \
! omxhdmiaudiosink
Where $MPD_URL is the MPD URL of a given stream, and $X_RES and $Y_RES representing the screen size to display on.
This works fine, unless the MPD contains a video representation with the same resolution as the screen output. Then, GStreamer has issues when the resolution changes away from that specified in the capsfilter downstream of the glcolorscale element.
For example:
* Player starts, output resolution is 1280x720
* dashdemux selects first representation of a much smaller video resolution than the output resolution
* Playback begins
* Good network conditions mean dashdemux picks a representation with video resolution equal to that of the output resolution of 1280x720
* Playback continues as normal
* Network conditions dictate that dashdemux changes representation again to a representation with a different video resolution to the output resolution
* The pipeline ends with a "not-negotiated" error
I've attached an excerpt of a debug log made with GST_DEBUG="*:3,glfilter:9,basetransform:9,GST_PADS:6" which shows the error (glcolorscale-passthrough.log.xz). Of particular note seem to be the lines which state:
0:00:19.704991143 317 0x25d830 WARN basetransform gstbasetransform.c:1346:gst_base_transform_setcaps:`<gluploadelement0>` transform could not transform video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)960, height=(int)540, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)50/1 in anything we support
After a bit of investigation, I discovered that it seemed to be that the element was stuck in passthrough mode, and that this was causing the playback to fail because once in passthrough mode the filter could not be brought out of it should the caps change upstream of the element. By removing the check for gst_base_transform_is_passthrough() in gst_gl_filter_transform_caps() in gst-plugins-bad/gst-libs/gst/gl/gstglfilter.c, it now forces it to do a full evaluation of the caps when it changes, instead of just taking a reference to the sink pad caps as they arrive.
By removing the aforementioned check for ::is_passthrough(), this has fixed the issue for me. I will also attach a patch that I'm now using internally. This has fixed the issue for me, but as I'm not an expert in either OpenGL nor the GstBaseTransform side of things I would like to ask what the GStreamer community's take on this is. I can't find any other GstBaseTransform element doing what GstGlFilter is doing with that ::is_passthrough() call, so I thought it a tad suspect.
If you need a test stream, I have created a standalone file which replicates the behaviour of dashdemux which I can provide. Unfortunately, the video is too large to upload here (9.1MB and the file size limit is 3.6MB), but I'm looking into other ways of getting it to you.
For reference, this is running from Git Master as of about three weeks ago with a few patches pulled in for gl and omx improvements ontop of that, and was also reproducible on the 1.12.1 release.
**Attachment 356793**, "Excerpt of log for the issue described":
[glcolorscale-passthrough.log.xz](/uploads/98d1cca4b3f71bac1d52e58ad4373990/glcolorscale-passthrough.log.xz)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/369appsink: forward the Protection Event to the application2021-09-24T13:22:51ZBugzilla Migration Userappsink: forward the Protection Event to the application## Submitted by y.bandou
**[Link to original bug (#785531)](https://bugzilla.gnome.org/show_bug.cgi?id=785531)**
## Description
Send the protection message to the application when we receive the protection Event in appsink.## Submitted by y.bandou
**[Link to original bug (#785531)](https://bugzilla.gnome.org/show_bug.cgi?id=785531)**
## Description
Send the protection message to the application when we receive the protection Event in appsink.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/368video-format: Add a new 10bit depth format packed into 20 bytes2021-09-24T13:22:50ZBugzilla Migration Uservideo-format: Add a new 10bit depth format packed into 20 bytes## Submitted by kevin
**[Link to original bug (#785384)](https://bugzilla.gnome.org/show_bug.cgi?id=785384)**
## Description
Hi,
Currently only have GST_VIDEO_FORMAT_P010_10LE video format. The Y of one pixel will be 16 bits fo...## Submitted by kevin
**[Link to original bug (#785384)](https://bugzilla.gnome.org/show_bug.cgi?id=785384)**
## Description
Hi,
Currently only have GST_VIDEO_FORMAT_P010_10LE video format. The Y of one pixel will be 16 bits for one pixel. We need NV12 10 bits LE with packed, not 0 pading. The Y of one pixel should be 10 bits for one pixel.
Can you help?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/366Internal Data Stream Error when trying to play certain ogg vorbis files2021-09-24T13:22:49ZBugzilla Migration UserInternal Data Stream Error when trying to play certain ogg vorbis files## Submitted by aha..@..ok.com
**[Link to original bug (#784851)](https://bugzilla.gnome.org/show_bug.cgi?id=784851)**
## Description
I am using Ubuntu 17.04 and the default gstreamer version from the ubuntu 17.04 repo.
I can n...## Submitted by aha..@..ok.com
**[Link to original bug (#784851)](https://bugzilla.gnome.org/show_bug.cgi?id=784851)**
## Description
I am using Ubuntu 17.04 and the default gstreamer version from the ubuntu 17.04 repo.
I can not play some of my ogg vorbis files. Some of them have worked before but do not work now after setting tags with EasyTAG (I set the album cover and track-/album-title).
I get an "internal data stream error" on Rhythmbox, Lollypop and Clementine.
I can play these files with ffplay.
Sadly, I can not upload an example file because of the file size limit.
They are all encoded in 256kbit/s, so they are too big.
Also, copyright could be an issue.
Output of "gst-play-1.0 01\ Hells\ Bells.ogg":
Geben Sie »k« ein, um die Liste der Tastenkombinationen zu sehen.
Momentan wird /home/ahahn94/Musik/AC-DC/Back In Black/01 Hells Bells.ogg wiedergegeben
ERROR Internal data stream error. for file:///home/ahahn94/Musik/AC-DC/Back%20In%20Black/01%20Hells%20Bells.ogg
ERROR debug information: gstoggdemux.c(4851): gst_ogg_demux_loop (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstOggDemux:oggdemux0:
streaming stopped, reason error (-5)
Das Ende der Wiedergabeliste wurde erreicht.
I hope you can help me fix this problem.
Greetings from Germany.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/365Rtsp-over-http includes port 80 in internal uri2021-09-24T13:22:49ZBugzilla Migration UserRtsp-over-http includes port 80 in internal uri## Submitted by Jeff Shanab
**[Link to original bug (#784703)](https://bugzilla.gnome.org/show_bug.cgi?id=784703)**
## Description
I am having trouble using the rtspsrc for rtsp-over-http that I am starting to think is a bug. Settin...## Submitted by Jeff Shanab
**[Link to original bug (#784703)](https://bugzilla.gnome.org/show_bug.cgi?id=784703)**
## Description
I am having trouble using the rtspsrc for rtsp-over-http that I am starting to think is a bug. Setting protocols and/or setting rtsph does not open a socket to port 80. I am forced to actually put ":80" in the uri. When I do it ends up in the uri posted and the device does not respond. This is contrary to the standard, the device should not see the port 80 in it's url. Multiple devices tested using live555 and curl without issue.
Tested with gst-launch on gstreamer 1.12 on windows x64 but primary usage is from c++ program.
Is this latest?, I am finding terribly outdated documentation and broken links on https://gstreamer.freedesktop.org/
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/364audio-channels: bindings-friendly positions_from_mask2021-09-24T13:22:49ZBugzilla Migration Useraudio-channels: bindings-friendly positions_from_mask## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784680)](https://bugzilla.gnome.org/show_bug.cgi?id=784680)**
## Description
No amount of annotation tweaking seems enough to make
gst_audio_channel_positions_fr...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784680)](https://bugzilla.gnome.org/show_bug.cgi?id=784680)**
## Description
No amount of annotation tweaking seems enough to make
gst_audio_channel_positions_from_mask actually introspectable.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/363*decodebin: make it possible to disable max-size-*2021-09-24T13:22:48ZBugzilla Migration User*decodebin: make it possible to disable max-size-*## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784672)](https://bugzilla.gnome.org/show_bug.cgi?id=784672)**
## Description
decodebin considers max-size-* == 0 means "automatic", and
previously didn't expose ...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784672)](https://bugzilla.gnome.org/show_bug.cgi?id=784672)**
## Description
decodebin considers max-size-* == 0 means "automatic", and
previously didn't expose any value to mean "disable".
We now consider G_MAXUINT* to mean disable, and translate 0 to
G_MAXUINT* in uridecodebin, this in order not to break the API.
From the command-line, one can use -1.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/362tag: Extract unsynchronized lyrics from id32022-09-05T13:26:36ZBugzilla Migration Usertag: Extract unsynchronized lyrics from id3## Submitted by Christian Weiske
**[Link to original bug (#784634)](https://bugzilla.gnome.org/show_bug.cgi?id=784634)**
## Description
gst-discoverer-1.0 fails to show lyrics from .mp3 files that contain a USLT tag (Unsynchronized ...## Submitted by Christian Weiske
**[Link to original bug (#784634)](https://bugzilla.gnome.org/show_bug.cgi?id=784634)**
## Description
gst-discoverer-1.0 fails to show lyrics from .mp3 files that contain a USLT tag (Unsynchronized lyrics). Using the python bindings to extract the tag also fails.
I'm using gstreamer1.0-plugins-base-apps 1.12.1-1 on Ubuntu Artful (17.10) with all plugin categories (good, bad, ugly). MP3 support only came with -ugly.
Demo files can be found at http://cweiske.de/tagebuch/embedded-lyrics.htm#demo
ID3 specification of USLT tag: http://id3.org/id3v2.3.0#Unsychronised_lyrics.2Ftext_transcription
### Blocking
* [Bug 463978](https://bugzilla.gnome.org/show_bug.cgi?id=463978)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/361videorate: support frame-by-frame for multiview-mode2021-09-24T13:22:47ZBugzilla Migration Uservideorate: support frame-by-frame for multiview-mode## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#784372)](https://bugzilla.gnome.org/show_bug.cgi?id=784372)**
## Description
Recently I've worked for MVC encoding using vaapi.
Basically it's been successful with stat...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#784372)](https://bugzilla.gnome.org/show_bug.cgi?id=784372)**
## Description
Recently I've worked for MVC encoding using vaapi.
Basically it's been successful with static pipeline, but I found one issue when I test with encodebin.
My test pipeline is as the following:
> gst-launch-1.0 gltestsrc ! glviewconvert input-mode-override=mono output-mode-override=frame-by-frame ! glcolorconvert ! gldownload ! encodebin profile="video/mpegts, systemstream=true, packetsize=188:video/x-h264" ! filesink location=mvc_va.ts
I thought it's working fine but I realized it's not.
That is videorate drops one of two frames every time by comparing timestamp of each buffer, which is what videorate should be doing normally.
So I'm asking this question.
Do we need to implement something in videorate to support multiview-mode, especially for frame-by-frame?
Or is there another solution for doing this?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/360appsink hangs if sync is true2021-09-24T13:22:47ZBugzilla Migration Userappsink hangs if sync is true## Submitted by dashesy
**[Link to original bug (#784063)](https://bugzilla.gnome.org/show_bug.cgi?id=784063)**
## Description
This happens sporadically and in a slow VM (just connecting multifilesrc to appsink):
```
thread #...## Submitted by dashesy
**[Link to original bug (#784063)](https://bugzilla.gnome.org/show_bug.cgi?id=784063)**
## Description
This happens sporadically and in a slow VM (just connecting multifilesrc to appsink):
```
thread #6: tid = 41178, 0x00007fe29b600c21 libc.so.6`__GI_ppoll(fds=0x00007fe27c043ac0, nfds=1, timeout=<unavailable>, sigmask=0x0000000000000000) + 145 at ppoll.c:50, name = 'multifilesrc0:s', stop reason = signal SIGSTOP
frame #0: 0x00007fe29b600c21 libc.so.6`__GI_ppoll(fds=0x00007fe27c043ac0, nfds=1, timeout=<unavailable>, sigmask=0x0000000000000000) + 145 at ppoll.c:50
frame #1: 0x00007fe2a5e0e818 libgstreamer-1.0.so.0`gst_poll_wait + 1784
frame #2: 0x00007fe2a5e24eb1 libgstreamer-1.0.so.0`??? + 145
frame #3: 0x00007fe2a5dd3dfb libgstreamer-1.0.so.0`gst_clock_id_wait + 91
frame #4: 0x00007fe2a60dcadc libgstbase-1.0.so.0`gst_base_sink_wait_clock + 332
frame #5: 0x00007fe2a60ddf80 libgstbase-1.0.so.0`??? + 1824
frame #6: 0x00007fe2a60defb2 libgstbase-1.0.so.0`??? + 1938
frame #7: 0x00007fe2a60e0620 libgstbase-1.0.so.0`??? + 240
frame #8: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #9: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #10: 0x00007fe2a60ea47d libgstbase-1.0.so.0`??? + 397
frame #11: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #12: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #13: 0x00007fe2a5dea513 libgstreamer-1.0.so.0`gst_proxy_pad_chain_default + 179
frame #14: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #15: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #16: 0x00007fe2a3eab8df libgstvideo-1.0.so.0`??? + 3167
frame #17: 0x00007fe2a3eb2110 libgstvideo-1.0.so.0`gst_video_decoder_finish_frame + 512
frame #18: 0x00007fe2833f46d3 libgstjpeg.so
frame #19: 0x00007fe2a3eaa4c6 libgstvideo-1.0.so.0`??? + 422
frame #20: 0x00007fe2a3eaa97d libgstvideo-1.0.so.0`??? + 157
frame #21: 0x00007fe2a3ead173 libgstvideo-1.0.so.0`??? + 755
frame #22: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #23: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #24: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #25: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #26: 0x00007fe2a5dea513 libgstreamer-1.0.so.0`gst_proxy_pad_chain_default + 179
frame #27: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #28: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #29: 0x00007fe2a60e5da5 libgstbase-1.0.so.0`??? + 1013
frame #30: 0x00007fe2a5e2be71 libgstreamer-1.0.so.0`??? + 401
frame #31: 0x00007fe29ebfd55e libglib-2.0.so.0`??? + 158
frame #32: 0x00007fe29ebfcbc5 libglib-2.0.so.0`??? + 85
frame #33: 0x00007fe29ca936ba libpthread.so.0`start_thread + 202
frame #34: 0x00007fe29b60c82d libc.so.6`__clone + 109 at clone.S:109
```
If I set "sync=false" for appsink, the problem is resolved.
The error looks similar to this: https://lists.freedesktop.org/archives/gstreamer-bugs/2015-February/141581.html which specifies [Bug 737427](https://bugzilla.gnome.org/show_bug.cgi?id=737427)
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/357playbin:rtsp: Swicthing audio track fails2021-09-24T13:22:45ZBugzilla Migration Userplaybin:rtsp: Swicthing audio track fails## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#783436)](https://bugzilla.gnome.org/show_bug.cgi?id=783436)**
## Description
When trying to do audio track swicthing on RTSP streams, previous audio track is d...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#783436)](https://bugzilla.gnome.org/show_bug.cgi?id=783436)**
## Description
When trying to do audio track swicthing on RTSP streams, previous audio track is disabled, but the new one never gets started, playback keeps going, with no audio.
Reproduce (with the yet to be merged rtsp testsuite, but that will happen very soon):
gst-validate-launcher -t validate.rtsp.playback.switch_audio_track.tron_en_ge_aac_h264_ts
With playbin3, playing stream with several audio tracks never starts (ie. video prerolls, but the pipeline never plays)
Reproduce:
USE_PLAYBIN3=true gst-validate-launcher -t validate.rtsp.playback.switch_audio_track.tron_en_ge_aac_h264_ts
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/356Alsasink not playing BE PCM in LE Machine & vice versa2021-09-24T13:22:44ZBugzilla Migration UserAlsasink not playing BE PCM in LE Machine & vice versa## Submitted by vijay
**[Link to original bug (#782862)](https://bugzilla.gnome.org/show_bug.cgi?id=782862)**
## Description
Incase of LE machine alsasink is not listing the BE format even if Alsa deivce has the capability to play B...## Submitted by vijay
**[Link to original bug (#782862)](https://bugzilla.gnome.org/show_bug.cgi?id=782862)**
## Description
Incase of LE machine alsasink is not listing the BE format even if Alsa deivce has the capability to play BE PCM.
Root casuse:
Check added in ext/alsa/gstalsa.c function "format_supported"
if (GST_AUDIO_FORMAT_INFO_ENDIANNESS (finfo) != endianness
&& GST_AUDIO_FORMAT_INFO_ENDIANNESS (finfo) != 0)
Steps to verify:
Play any BE PCM/WAV file in LE machine
Working on Fix.
Thank you