gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:33:32Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/278dashdemux: index uri is not set when only the index range is provided2021-09-24T14:33:32ZBugzilla Migration Userdashdemux: index uri is not set when only the index range is provided## Submitted by Florin Apostol
**[Link to original bug (#752721)](https://bugzilla.gnome.org/show_bug.cgi?id=752721)**
## Description
For the index@SegmentURL attribute, the standard mentions:
"If not present and the @indexRang...## Submitted by Florin Apostol
**[Link to original bug (#752721)](https://bugzilla.gnome.org/show_bug.cgi?id=752721)**
## Description
For the index@SegmentURL attribute, the standard mentions:
"If not present and the @indexRange present, then the @media attribute is mapped to the @index. If the @media attribute is not present either, then any BaseURL element is mapped to the @index attribute and the @indexRange attribute shall be present."
The implementation does not set the index uri in this scenario. The code is at the end of gst_mpd_client_get_next_fragment function:
if (indexURL != NULL) {
frag_url = gst_uri_make_writable (gst_uri_from_string_with_base (base_url,
indexURL));
gst_uri_set_query_string (frag_url, stream->queryURL);
fragment->index_uri = gst_uri_to_string (frag_url);
gst_uri_unref (frag_url);
g_free (indexURL);
} else if (indexURL == NULL && (fragment->index_range_start
|| fragment->index_range_end != -1)) {
/* index has no specific URL but has a range, we should only use this if
* the media also has a range, otherwise we are serving some data twice
* (in the media fragment and again in the index) */
if (!(fragment->range_start || fragment->range_end != -1)) {
GST_WARNING ("Ignoring index ranges because there isn't a media range "
"and URIs would be the same");
/* removing index information */
fragment->index_range_start = 0;
fragment->index_range_end = -1;
}
}
The "else if" checks to see if it will retrieve the same data for index and media segment. But it fails to set the fragment->index_uri in case it wants the segment index to be downloaded. Because fragment->index_uri remains null, no segment index will be downloaded.
On the other hand, in chapter "5.3.9.5.4 Index Segment information" the standard mentions:
"The @indexRange attribute may also be used to provide the byte range for an index within a Media Segment, where this is allowed by the Media Segment format. In this case the @index attribute shall not be present and the range specified shall lie completely within any byte range specified for the Media Segment."
So, in this case the index will be completely inside the media segment. If we really do not want to download and provide the same data twice (in index and in media segment) the whole "else if" should be removed and an appropriate comment describing the situation should be added instead.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/280hlsdemux doesn't maintain extra-headers2021-09-24T14:33:32ZBugzilla Migration Userhlsdemux doesn't maintain extra-headers## Submitted by Stefano
**[Link to original bug (#752732)](https://bugzilla.gnome.org/show_bug.cgi?id=752732)**
## Description
hlsdemux doesn't maintain extra-headers params when retrieving segments in m3u8.
### See also
* [Bug...## Submitted by Stefano
**[Link to original bug (#752732)](https://bugzilla.gnome.org/show_bug.cgi?id=752732)**
## Description
hlsdemux doesn't maintain extra-headers params when retrieving segments in m3u8.
### See also
* [Bug 752858](https://bugzilla.gnome.org/show_bug.cgi?id=752858)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/281dashdemux: index segment url generated from template is not properly used2021-09-24T14:33:33ZBugzilla Migration Userdashdemux: index segment url generated from template is not properly used## Submitted by Florin Apostol
**[Link to original bug (#752770)](https://bugzilla.gnome.org/show_bug.cgi?id=752770)**
## Description
According to the standard:
5.3.9.5.4 Index Segment information
"The presence of explicit Index...## Submitted by Florin Apostol
**[Link to original bug (#752770)](https://bugzilla.gnome.org/show_bug.cgi?id=752770)**
## Description
According to the standard:
5.3.9.5.4 Index Segment information
"The presence of explicit Index Segment information is indicated
...
- by the presence of SegmentTemplate@index attribute. If either $Number$ or $Time$ are present the Template-based Segment URL construction in 5.3.9.4.4 shall be applied with number set to the number of the corresponding Media Segment. If not present, the SegmentTemplate@index attribute constitutes a reference to Representation Index."
So, depending on the presence of $Number$ or $Time$ in the template, the resulting url should be interpreted differently: if one of them is present, the url points to a index segment for a media segment and thus should be downloaded every time the corresponding media segment is downloaded. If $Number$ or $Time$ are not present, the generated url points to a RepresentationIndex which contains the IndexSegment for the entire representation, so it should be downloaded only once at the beginning.
But the function gst_mpdparser_build_URL_from_template does not indicate to the caller if $Number$ or $Time$ were used, so the caller is unable to differentiate between the 2 situations.
Currently the index segment is downloaded by the gst_adaptive_demux_stream_download_header_fragment based on information provided by gst_dash_demux_stream_update_headers_info which calls gst_mpd_client_get_next_header_index. But this function will generate an index segment uri by forcing number and time to 0, which is obvious wrong and will generate a wrong index url.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/282tsdemux: doesn't handle streams without PCR2021-09-24T14:33:33ZBugzilla Migration Usertsdemux: doesn't handle streams without PCR## Submitted by dka..@..il.com
**[Link to original bug (#752843)](https://bugzilla.gnome.org/show_bug.cgi?id=752843)**
## Description
Hi,
I'm trying to make GoPro 4 live preview (mpegts stream) to work with GStreamer and faced ...## Submitted by dka..@..il.com
**[Link to original bug (#752843)](https://bugzilla.gnome.org/show_bug.cgi?id=752843)**
## Description
Hi,
I'm trying to make GoPro 4 live preview (mpegts stream) to work with GStreamer and faced with an issue, that tsdemux doesn't push packet further, because it expects PTS/DTS timestamps. On iOS.
The problem is, GoPro 4 doesn't set those in PES header. I'm not quite sure why or whether it is correct behaviour for mpeg ts stream broadcaster. But the thing is, I was able to play this stream with ffplay. I dind't go further in comparing ffmpeg mpegts demux with tsdemux. Maybe there's some well know limitation in GStreamer.
I would really appriciate any help on this. I'll attach everything I have:
1. gopro.pcap - mpegts UDP steam from GoPro Hero 4 Silver
2. gopro_stream_conf - mpegst stream config (from ffprobe)
https://www.dropbox.com/s/vjrsiapwq4goyqk/gopro_stream_conf?dl=0
3. gopro_gst_log - filtered debug log for tsdemux and mpegtsbase
https://www.dropbox.com/s/4e9r5hiziim4sb5/gopro_gst_log?dl=0
As for Pipeline, it doesn't really matter, I was testing the simpliest:
udpsrc port=8554 buffer-size=5000 ! tsdemux name=demux demux.video_1011 ! queue ! decodebin ! autovideosink demux.video_0200 ! fakesink demux.audio_1100 ! fakesink
How to simulate GoPro mpegts:
1. Install http://tcpreplay.synfin.net/
2. Download gopro.pcap
3. Get sMAC of source (machine which is going to stream) and destination dMAC (who's going to receive stream). For test purpose it is going to be the same machine (loopback test):
> tcprewrite --enet-smac=e4:ce:8f:3c:63:b2 --enet-dmac=e4:ce:8f:3c:63:b2 --infile=gopro.pcap --outfile=output.pcap
--enet-smac our sMAC
--enet-dmac our dMAC
4. Generate cache:
> tcpprep --auto=bridge --pcap=output.pcap --cachefile=input.cache
5. Replays IPs. Again we need sIP (machine which is going to stream) and dIP who's going to receive stream. For test purpose it is going to be the same machine (loopback test):
> tcprewrite --endpoints=192.168.14.137:192.168.14.137 --cachefile=input.cache --infile=output.pcap --outfile=output2.pcap --skipbroadcast
formats for IPs: sIP:dIP
6. Now we have output2.pcap which is ready to playback
7. sudo tcpreplay --intf1=en1 output2.pcap
en1 - network interface
8. Finaly. You could verify the stream with: ffplay udp://:8554https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/283Add encoder/decoder elements for Thor codec2021-09-24T14:33:33ZBugzilla Migration UserAdd encoder/decoder elements for Thor codec## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752849)](https://bugzilla.gnome.org/show_bug.cgi?id=752849)**
## Description
See https://github.com/cisco/thor and https://tools.ietf.org/html/draft-fuldseth-netvc-t...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752849)](https://bugzilla.gnome.org/show_bug.cgi?id=752849)**
## Description
See https://github.com/cisco/thor and https://tools.ietf.org/html/draft-fuldseth-netvc-thor-00https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/285hlssink: max-files deletes old files without removing them from m3u8 index2021-09-24T14:33:34ZBugzilla Migration Userhlssink: max-files deletes old files without removing them from m3u8 index## Submitted by min..@..arp.fm
**[Link to original bug (#752863)](https://bugzilla.gnome.org/show_bug.cgi?id=752863)**
## Description
When an attempt is made to use the max-files option to limit the number of files on disk, the firs...## Submitted by min..@..arp.fm
**[Link to original bug (#752863)](https://bugzilla.gnome.org/show_bug.cgi?id=752863)**
## Description
When an attempt is made to use the max-files option to limit the number of files on disk, the first file in the index is deleted too early and is missing:
hlssink max-files=5 location=/var/www/stream/segment%05d.ts playlist-location=/var/www/stream/output.m3u8 playlist-root=http://192.168.225.2/stream/
root@raspberrypi:/var/www/stream# ls -al; cat output.m3u8
total 1960
drwxrwxrwt 2 root root 160 Jul 25 14:47 .
drwxr-xr-x 3 root root 4096 Jul 25 10:48 ..
-rw-r--r-- 1 pi pi 381 Jul 25 14:47 output.m3u8
-rw-r--r-- 1 pi pi 423940 Jul 25 14:46 segment00066.ts
-rw-r--r-- 1 pi pi 460788 Jul 25 14:46 segment00067.ts
-rw-r--r-- 1 pi pi 408712 Jul 25 14:47 segment00068.ts
-rw-r--r-- 1 pi pi 526024 Jul 25 14:47 segment00069.ts
-rw-r--r-- 1 pi pi 172032 Jul 25 14:47 segment00070.ts
#EXTM3U
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:66
#EXT-X-TARGETDURATION:17
#EXTINF:17,ciao
http://192.168.225.2/stream/segment00065.ts
#EXTINF:17,ciao
http://192.168.225.2/stream/segment00066.ts
#EXTINF:17,ciao
http://192.168.225.2/stream/segment00067.ts
#EXTINF:17,ciao
http://192.168.225.2/stream/segment00068.ts
#EXTINF:17,ciao
http://192.168.225.2/stream/segment00069.ts
In the above example the file segment00065.ts is listed in the index, but does not exist on disk any more. This leads to spurious 404 errors from the webserver.
Version: 1.2.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/286avfvideosrc: external session2021-09-24T14:33:34ZBugzilla Migration Useravfvideosrc: external session## Submitted by Ilya Konstantinov
**[Link to original bug (#752867)](https://bugzilla.gnome.org/show_bug.cgi?id=752867)**
## Description
I've implemented a 'session' property which allows both:
- getting the internal AVCaptureSes...## Submitted by Ilya Konstantinov
**[Link to original bug (#752867)](https://bugzilla.gnome.org/show_bug.cgi?id=752867)**
## Description
I've implemented a 'session' property which allows both:
- getting the internal AVCaptureSession used by avfvideosrc
- giving avfvideosrc an external (already inited) AVCaptureSession; in such case, it avoids configuration, startRunning and stopRunning, assuming it'll be done externally
See my commit (which I'm dogfooding on iOS and OS X for the past 2 months):
https://github.com/ikonst/gst-plugins-bad/commit/dfd399ae3c33756434ff5708d73b5585b71cc79c
It's useful for attaching additional AVCaptureOutputs to the session, externally to GStreamer.
One thing it's essential for, is to use AVCaptureVideoPreviewLayer, which is a high performance video primitive on OS X and iOS which can display a preview of the video input. It's a standard UI element, whose composition is performed by the system (out of process) and has better performance than any other option.
An alternative to support AVVideoCapturePreviewLayer specifically, which could be also nice, is to add a "preview-layer" property, accepting an AVVideoCapturePreviewLayer whose 'session' property will be set once we initialize the session.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/287vtdec: expose kVTDecodeFrame_1xRealTimePlayback2021-09-24T14:33:35ZBugzilla Migration Uservtdec: expose kVTDecodeFrame_1xRealTimePlayback## Submitted by Ilya Konstantinov
**[Link to original bug (#752882)](https://bugzilla.gnome.org/show_bug.cgi?id=752882)**
## Description
In an RTC pipeline, it might be beneficial to set the kVTDecodeFrame_1xRealTimePlayback flag on...## Submitted by Ilya Konstantinov
**[Link to original bug (#752882)](https://bugzilla.gnome.org/show_bug.cgi?id=752882)**
## Description
In an RTC pipeline, it might be beneficial to set the kVTDecodeFrame_1xRealTimePlayback flag on the decoded frames.
From the VT headers:
"kVTDecodeFrame_1xRealTimePlayback -- A hint to the video decoder that it would be OK to use a low-power mode that can not decode faster than 1x realtime."
If this cannot be inferred from the incoming GstVideoCodecFrame (I don't suppose elements with is-live=1 leave any hints on the GstBuffers they produce), this could be at the very least be configurable through a property.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/288vtdec: error on returning from iOS background2021-09-24T14:33:36ZBugzilla Migration Uservtdec: error on returning from iOS background## Submitted by Ilya Konstantinov
**[Link to original bug (#752883)](https://bugzilla.gnome.org/show_bug.cgi?id=752883)**
## Description
Upon returning from iOS background during a running "vtdec" pipeline, we get:
GST_VIDEO_...## Submitted by Ilya Konstantinov
**[Link to original bug (#752883)](https://bugzilla.gnome.org/show_bug.cgi?id=752883)**
## Description
Upon returning from iOS background during a running "vtdec" pipeline, we get:
GST_VIDEO_DECODER_ERROR (vtdec, 1, STREAM, DECODE, (NULL),
("VTDecompressionSessionDecodeFrame returned %d", (int) status), ret);
where status == kVTInvalidSessionErr == -12903.
This produces a pipeline error and causes the source to stop. This is highly undesirable everywhere, and in particular in an RTC app where stopping the source task causes data loss.
There's a similar Chromium bug. We can see what they did.
https://code.google.com/p/chromium/issues/detail?id=477895https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/290Compositor doesn't show input video at correct scale2021-09-24T14:33:36ZBugzilla Migration UserCompositor doesn't show input video at correct scale## Submitted by Mathieu Hinderyckx
**[Link to original bug (#752913)](https://bugzilla.gnome.org/show_bug.cgi?id=752913)**
## Description
When using the compositor to display videos with the width parameter, compositor doesn't lead ...## Submitted by Mathieu Hinderyckx
**[Link to original bug (#752913)](https://bugzilla.gnome.org/show_bug.cgi?id=752913)**
## Description
When using the compositor to display videos with the width parameter, compositor doesn't lead to correct displaying (videomixer does)
VIDEOMIXER (correct):
gst-launch-1.0 videomixer name=mix sink_1::xpos=1920 sink_2::ypos=1080 sink_3::xpos=1920 sink_3::ypos=1080 ! videoconvert ! xvimagesink \
videotestsrc pattern=1 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1920,height=1080 ! \
timeoverlay text="Lossless:" shaded-background=true ! queue ! \
mix.sink_0 \
videotestsrc pattern=5 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1920,height=1080 ! \
timeoverlay text="1080p " shaded-background=true ! queue ! \
mix.sink_1 \
videotestsrc pattern=9 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1280,height=720 ! \
videoscale ! video/x-raw,width=1920 ! \
timeoverlay text="720p" shaded-background=true ! queue ! \
mix.sink_2 \
videotestsrc pattern=1 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=960,height=540 ! \
videoscale ! video/x-raw,width=1920 ! \
timeoverlay text="540p" shaded-background=true ! queue ! \
mix.sink_3
COMPOSITOR (wrong):
gst-launch-1.0 compositor name=mix sink_1::xpos=1920 sink_2::ypos=1080 sink_3::xpos=1920 sink_3::ypos=1080 ! videoconvert ! xvimagesink \
videotestsrc pattern=1 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1920,height=1080 ! \
timeoverlay text="Lossless:" shaded-background=true ! queue ! \
mix.sink_0 \
videotestsrc pattern=5 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1920,height=1080 ! \
timeoverlay text="1080p " shaded-background=true ! queue ! \
mix.sink_1 \
videotestsrc pattern=9 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=1280,height=720 ! \
videoscale ! video/x-raw,width=1920 ! \
timeoverlay text="720p" shaded-background=true ! queue ! \
mix.sink_2 \
videotestsrc pattern=1 ! \
video/x-raw,format=I420,framerate=\(fraction\)10/1,width=960,height=540 ! \
videoscale ! video/x-raw,width=1920 ! \
timeoverlay text="540p" shaded-background=true ! queue ! \
mix.sink_3
The compositor adds a gray area to the right and does not show the correct height for the lowest 2 videos. When adding the height=1080 as parameter to the last 2 videoscale elements, displaying is correct.
Version: 1.5.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/291osxaudiosink: Pitch element causes pipeline failures and crashes when used wi...2021-09-24T14:33:37ZBugzilla Migration Userosxaudiosink: Pitch element causes pipeline failures and crashes when used with autoaudiosink## Submitted by Sjors Gielen
**[Link to original bug (#753147)](https://bugzilla.gnome.org/show_bug.cgi?id=753147)**
## Description
Created attachment 308627
Output of the Address Sanitizer
The pitch element, part of the soun...## Submitted by Sjors Gielen
**[Link to original bug (#753147)](https://bugzilla.gnome.org/show_bug.cgi?id=753147)**
## Description
Created attachment 308627
Output of the Address Sanitizer
The pitch element, part of the soundtouch plugin in gst-plugins-bad, seems to be causing pipeline failures and even crashes in some pipelines on Mac OS X when used together directly with the autoaudiosink. Address Sanitizer detects "heap use after free" or segmentation fault on various addresses in some pipelines as well. I have not yet extensively debugged the issue, but have tried to grasp the scope of it below.
This is tested using GStreamer 1.4.5 on Mac OS X 10.10.4. The GStreamer core package and gst-plugins-bad were built by Homebrew, with two manual changes, one to build Soundtouch and one to enable Address Sanitizer by building with GCC 5.2.0 and adding -fsanitize=address. I have yet to rebuild gst-plugins-{base,good} with ASAN and will also enable debugging symbols so I can provide more debugging information.
I believe the simplest command that should succeed but causes an internal data flow error is the following:
----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
---->8----
This command succeeds on my Linux test machine (a test sound is audible). On OS X, the problem seems gone when adding an audioconvert as well:
----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! audioconvert ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
[...]
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
Redistribute latency...
[...]
---->8----
Also, the following similar command without audioconvert does succeed on this OS X machine:
----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! filesink location=/dev/null
(similar output to above)
---->8----
The simplest command that should succeed but instead triggers the Address Sanitizer is the following (ASAN output replaced with output from asan_symbolize). Note that it does not trigger this exact error in all cases; in others, it causes a pipeline error similar to the above one, or a different kind of ASAN error, which leads me to suspect a race condition...
----8<----
$ gst-launch-1.0 filesrc location=../jg.mp3 ! mad ! audioconvert ! pitch ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
=================================================================
==90797==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200002bef0 at pc 0x000108abc405 bp 0x00010ed86bc0 sp 0x00010ed86370
[...]
---->8----
The full output of the ASAN symbolizer is attached to this bug report for brevity. Like above, this error does not occur when adding an audioconvert, or when using a filesink or fakesink.
----8<----
$ gst-launch-1.0 filesrc location=../jg.mp3 ! mad ! audioconvert ! pitch ! audioconvert ! autoaudiosink
(similar output to succesful runs above)
---->8----
I will try to add information to this bug report as I go. I would appreciate it if others could repeat my experiments and confirm my findings. Thank you!
**Attachment 308627**, "Output of the Address Sanitizer":
[asan_output.txt](/uploads/0e573ee571880dbcb8dd20aeb5d5a5a3/asan_output.txt)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/292adaptivedemux: doesn't answer duration queries for live streams2021-09-24T14:33:38ZBugzilla Migration Useradaptivedemux: doesn't answer duration queries for live streams## Submitted by mariuszb
**[Link to original bug (#753879)](https://bugzilla.gnome.org/show_bug.cgi?id=753879)**
## Description
For duration queries on live streams adaptivedemux ignores the query. The problem then is that the query...## Submitted by mariuszb
**[Link to original bug (#753879)](https://bugzilla.gnome.org/show_bug.cgi?id=753879)**
## Description
For duration queries on live streams adaptivedemux ignores the query. The problem then is that the query is answered by qtdemux downstream for with the values valid for the currently passing fragment.
I think adaptivedemux should be the final authority on stream duration and should return valid duration with GST_CLOCK_TIME_NONE set as a value for live streams.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/293jifmux: add "streamable" property2021-09-24T14:33:38ZBugzilla Migration Userjifmux: add "streamable" property## Submitted by min..@..arp.fm
**[Link to original bug (#753964)](https://bugzilla.gnome.org/show_bug.cgi?id=753964)**
## Description
Created attachment 309863
0001-Add-support-for-the-streamable-property-which-allows.patch
B...## Submitted by min..@..arp.fm
**[Link to original bug (#753964)](https://bugzilla.gnome.org/show_bug.cgi?id=753964)**
## Description
Created attachment 309863
0001-Add-support-for-the-streamable-property-which-allows.patch
By default jifmux uses the GST_TAG_MERGE_KEEP mode on incoming tag events, meaning that only the first attempt to set a tag counts.
This patch adds the streamable parameter, which if set to "true" will use GST_TAG_MERGE_REPLACE instead on tags.
This allows tags to be set on multiple JPEGs.
Patch is modelled on the flvmux element, which has identical behaviour.
~~**Patch 309863**~~, "0001-Add-support-for-the-streamable-property-which-allows.patch":
[file_753964.txt](/uploads/be95792fee02334a5ab88b911a103037/file_753964.txt)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/294gdp: Fails payloading of custom event types2021-09-24T14:33:38ZBugzilla Migration Usergdp: Fails payloading of custom event types## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754119)](https://bugzilla.gnome.org/show_bug.cgi?id=754119)**
## Description
GDP uses a 16 bit integer to store payload type, payload type for events is the event ty...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754119)](https://bugzilla.gnome.org/show_bug.cgi?id=754119)**
## Description
GDP uses a 16 bit integer to store payload type, payload type for events is the event type + 64. All custom event types have event types > 69120.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/295h264/h265parse: Negotiation could fail earlier2021-09-24T14:33:39ZBugzilla Migration Userh264/h265parse: Negotiation could fail earlier## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#754127)](https://bugzilla.gnome.org/show_bug.cgi?id=754127)**
## Description
In these parsers negotiation function, we do get_allowed_caps(). This this returns ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#754127)](https://bugzilla.gnome.org/show_bug.cgi?id=754127)**
## Description
In these parsers negotiation function, we do get_allowed_caps(). This this returns empty caps, we could fail immediately. Note that this may require a little more work because of the flushing special case. We need not to return not-negotiated if some element downstream fails due to FLOW_FLUSHING. Also, as this call is recursive, I'm unsure if we can check the peer pad flushing flag only as we usually do to handle this special case.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/296tsdemux: Problem with playing some HLS links2021-09-24T14:33:40ZBugzilla Migration Usertsdemux: Problem with playing some HLS links## Submitted by Om Prakash
**[Link to original bug (#754546)](https://bugzilla.gnome.org/show_bug.cgi?id=754546)**
## Description
Below HLS links are unable to play:
http://stmw.rthk.hk/aod/_definst_/radio/archive/radio1/Free_a...## Submitted by Om Prakash
**[Link to original bug (#754546)](https://bugzilla.gnome.org/show_bug.cgi?id=754546)**
## Description
Below HLS links are unable to play:
http://stmw.rthk.hk/aod/_definst_/radio/archive/radio1/Free_as_the_wind/mp3/mp3:20140221.mp3/playlist.m3u8
http://stmw2.rthk.hk/aod/_definst_/radio/archive/radio1/hkfootpath/mp3/mp3:20140330.mp3/playlist.m3u8
http://test.live.net.il/glz-a-zixief.m3u8
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/297opusparse: overwrites upstream timestamps2021-09-24T14:33:40ZBugzilla Migration Useropusparse: overwrites upstream timestamps## Submitted by Tim Müller `@tpm`
**[Link to original bug (#754669)](https://bugzilla.gnome.org/show_bug.cgi?id=754669)**
## Description
Opusparse seems to just make up its own timestamps by starting from 0 and adding the frame dura...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#754669)](https://bugzilla.gnome.org/show_bug.cgi?id=754669)**
## Description
Opusparse seems to just make up its own timestamps by starting from 0 and adding the frame durations. This probably means it does not take into account any upstream timestamps in case where we're not reading straight from a file but there's a demuxer or depayloader upstream.
Just came across this whilst investigating follow-ups to [bug 752106](https://bugzilla.gnome.org/show_bug.cgi?id=752106), did not look in detail, just filing it here for now before I forget.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/298Implement new VC2 encoder/decoder around BBC reference implementation2021-09-24T14:33:40ZBugzilla Migration UserImplement new VC2 encoder/decoder around BBC reference implementation## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754775)](https://bugzilla.gnome.org/show_bug.cgi?id=754775)**
## Description
See https://github.com/bbc/vc2-reference
Different to Dirac/schroedinger this only ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754775)](https://bugzilla.gnome.org/show_bug.cgi?id=754775)**
## Description
See https://github.com/bbc/vc2-reference
Different to Dirac/schroedinger this only seems to support VC2, but additionally it supports the HQ profilehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/299vtdec: iOS stream freezes2021-09-24T14:33:41ZBugzilla Migration Uservtdec: iOS stream freezes## Submitted by Nikolin Dmitriy
**[Link to original bug (#755043)](https://bugzilla.gnome.org/show_bug.cgi?id=755043)**
## Description
sender raspberry pipeline: raspivid -t 0 -w 960 -h 540 -fps 30 -b 1500000 -pf baseline -o - | gst...## Submitted by Nikolin Dmitriy
**[Link to original bug (#755043)](https://bugzilla.gnome.org/show_bug.cgi?id=755043)**
## Description
sender raspberry pipeline: raspivid -t 0 -w 960 -h 540 -fps 30 -b 1500000 -pf baseline -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-interval=2 pt=96 mtu=1380 ! udpsink host=192.168.0.103 port=6000
receiver iphone pipeline : udpsrc port=6000 ! application/x-rtp, payload=96 ! rtph264depay ! h264parse ! vtdec ! glimagesink
With vtdec. No more broken colors or latency but have new bug. Avery 1-2 maybe 3 seconds get 1ms freeze. Test on iPhone 4s, iPhone 5 and iPad Retina. changes of frame size or bitrate does not help. 40-50% CPU usage.
If use decodebin - 90-100% CPU usage but no freezes.
GST_LEVEL_WARNING - https://www.dropbox.com/s/czb0etk1j2wapme/warnings_log.txt?dl=0
GST_LEVEL_DEBUG - https://www.dropbox.com/s/sd1igl9b6y83cr5/debug_log.txt?dl=0
GST_LEVEL_DEBUG iphone can't start stream. black screen and infinity log.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/300dashdemux: relate wall clock time to timestamps for live streams2021-09-24T14:33:41ZBugzilla Migration Userdashdemux: relate wall clock time to timestamps for live streams## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#755115)](https://bugzilla.gnome.org/show_bug.cgi?id=755115)**
## Description
Currently dashdemux uses the availabilityStartTime to match timestamps of a ...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#755115)](https://bugzilla.gnome.org/show_bug.cgi?id=755115)**
## Description
Currently dashdemux uses the availabilityStartTime to match timestamps of a live stream with the real world clock. It seems this is not a requirement. See "http://live.unified-streaming.com/loop/loop.isml/loop.mpd?format=mp4&session_id=50375".
This stream fails to play because it tries to play from the first segment that would correspond to 'now' in the wall clock but the mapping is completely wrong so it never finds such segment.
Is there an official way to match timestamps to real world time? Or should we invent a way to do it? Like get the last segment end as 'now' at the beginning of the stream and use that as a base?
Ideas?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/301teletextdec: add property to show/hide hidden content2021-09-24T14:33:41ZBugzilla Migration Userteletextdec: add property to show/hide hidden content## Submitted by Thomas Löwe
**[Link to original bug (#755523)](https://bugzilla.gnome.org/show_bug.cgi?id=755523)**
## Description
Created attachment 312033
add conceal property
At the moment it is not possible to show hidden...## Submitted by Thomas Löwe
**[Link to original bug (#755523)](https://bugzilla.gnome.org/show_bug.cgi?id=755523)**
## Description
Created attachment 312033
add conceal property
At the moment it is not possible to show hidden content of a page (for example question & answer pages).
This patch adds a property "concealed" to enable/disable this feature.
~~**Patch 312033**~~, "add conceal property":
[gstteletextdec_conceal_0.10.patch](/uploads/42e5c3480c2acb01d57f551ccf02c121/gstteletextdec_conceal_0.10.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/302decklinkvideosrc: video fails to restart in auto mode2021-09-24T14:33:43ZBugzilla Migration Userdecklinkvideosrc: video fails to restart in auto mode## Submitted by Jeff
**[Link to original bug (#755641)](https://bugzilla.gnome.org/show_bug.cgi?id=755641)**
## Description
The pipeline containing the decklinkvideosrc fails to return to GST_STATE_PLAYING when following the sequenc...## Submitted by Jeff
**[Link to original bug (#755641)](https://bugzilla.gnome.org/show_bug.cgi?id=755641)**
## Description
The pipeline containing the decklinkvideosrc fails to return to GST_STATE_PLAYING when following the sequence of state changes Null->Playing -> Ready -> Playing, when the mode is set to auto. This is related to [Bug 755426](https://bugzilla.gnome.org/show_bug.cgi?id=755426).
Version: 1.5.91https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/303decklinkvideosrc: video fails to restart in ntsp-p mode2021-09-24T14:33:43ZBugzilla Migration Userdecklinkvideosrc: video fails to restart in ntsp-p mode## Submitted by Jeff
**[Link to original bug (#755642)](https://bugzilla.gnome.org/show_bug.cgi?id=755642)**
## Description
Created attachment 312162
log output from application
The pipeline fails to start when the decklinkvi...## Submitted by Jeff
**[Link to original bug (#755642)](https://bugzilla.gnome.org/show_bug.cgi?id=755642)**
## Description
Created attachment 312162
log output from application
The pipeline fails to start when the decklinkvideosrc mode is set to ntsp-p. Code to reproduce
#include <gst/gst.h>
#include <glib.h>
static gboolean
bus_call (GstBus *bus,
GstMessage *msg,
gpointer data)
{
GMainLoop *loop = (GMainLoop *) data;
switch (GST_MESSAGE_TYPE (msg)) {
case GST_MESSAGE_EOS:
g_print ("End of stream\n");
g_main_loop_quit (loop);
break;
case GST_MESSAGE_ERROR: {
gchar *debug;
GError *error;
gst_message_parse_error (msg, &error, &debug);
g_free (debug);
g_printerr ("Error: %s\n", error->message);
g_error_free (error);
g_main_loop_quit (loop);
break;
}
default:
break;
}
return TRUE;
}
void printStateChange(GstStateChangeReturn value) {
switch(value) {
case GST_STATE_CHANGE_FAILURE:
g_print("GST_STATE_CHANGE_FAILURE\n");
break;
case GST_STATE_CHANGE_SUCCESS:
g_print("GST_STATE_CHANGE_SUCCESS\n");
break;
case GST_STATE_CHANGE_ASYNC:
g_print("GST_STATE_CHANGE_ASYNC\n");
break;
case GST_STATE_CHANGE_NO_PREROLL:
g_print("GST_STATE_CHANGE_NO_PREROLL\n");
break;
default:
g_print("Unknown state\n");
break;
return;
}
}
GstStateChangeReturn handleAsync(GstElement *element) {
GstState *currentState = NULL, *pendingState = NULL;
GstClockTime timeout = GST_CLOCK_TIME_NONE;
GstStateChangeReturn result;
g_print("handeling state\n");
result = gst_element_get_state(element, currentState, pendingState, timeout);
printStateChange(result);
return result;
}
int
main (int argc,
char *argv[])
{
GMainLoop *loop;
GstElement *pipeline, *source, *conv, *sink;
GstBus *bus;
guint bus_watch_id;
GstStateChangeReturn result;
gst_init (&argc, &argv);
loop = g_main_loop_new (NULL, FALSE);
pipeline = gst_pipeline_new ("test");
source = gst_element_factory_make ("decklinkvideosrc", "source");
conv = gst_element_factory_make ("autovideoconvert", "converter");
sink = gst_element_factory_make ("xvimagesink", "sink");
if (!pipeline || !source || !conv || !sink) {
g_printerr ("One element could not be created. Exiting.\n");
return -1;
}
// gst_util_set_object_arg (G_OBJECT(source), "mode", "auto");
gst_util_set_object_arg (G_OBJECT(source), "mode", "ntsc-p");
gst_util_set_object_arg (G_OBJECT(source), "connection", "hdmi");
bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
bus_watch_id = gst_bus_add_watch (bus, bus_call, loop);
gst_object_unref (bus);
gst_bin_add_many (GST_BIN (pipeline), source, conv, sink, NULL);
gst_element_link_many (source, conv, sink, NULL);
int delay = 2;
g_print ("setting state: GST_STATE_PLAYING\n");
result = gst_element_set_state (pipeline, GST_STATE_PLAYING);
printStateChange(result);
if(result == GST_STATE_CHANGE_ASYNC) {
if(handleAsync(pipeline) == GST_STATE_CHANGE_FAILURE){
return 0;
}
}
g_print ("Returned, stopping playback\n");
result = gst_element_set_state (pipeline, GST_STATE_NULL);
printStateChange(result);
if(result == GST_STATE_CHANGE_ASYNC) {
if(handleAsync(pipeline) == GST_STATE_CHANGE_FAILURE){
return 0;
}
}
g_print ("Deleting pipeline\n");
gst_object_unref (GST_OBJECT (pipeline));
g_source_remove (bus_watch_id);
g_main_loop_unref (loop);
return 0;
}
**Attachment 312162**, "log output from application":
[test.out](/uploads/d8f7fe0c6562dff9939e02912f792090/test.out)
Version: 1.5.91https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/305Add support for rolling headers and clock update in the teletext decoder2021-09-24T14:33:44ZBugzilla Migration UserAdd support for rolling headers and clock update in the teletext decoder## Submitted by Daniel Kamil Kozar
**[Link to original bug (#755665)](https://bugzilla.gnome.org/show_bug.cgi?id=755665)**
## Description
Created attachment 312204
Add support for rolling headers and clock updates in teletextdec ...## Submitted by Daniel Kamil Kozar
**[Link to original bug (#755665)](https://bugzilla.gnome.org/show_bug.cgi?id=755665)**
## Description
Created attachment 312204
Add support for rolling headers and clock updates in teletextdec
This patch adds support for rolling headers and clock updates in the teletext decoder's RGBA output mode. Thus, the behaviour is now quite similar to what can be seen with analogue TVs :
* Right after turning on the decoder, only the rolling header is displayed, while the page content is blank.
* After finding the page, only the clock is updated.
* When changing the requested page, the content of the old page is still displayed, but the header shows rolling page numbers.
The patch requires applying the patch porting the teletextdec element to 1.0, which I posted previously.
**Patch 312204**, "Add support for rolling headers and clock updates in teletextdec":
[0002-add-support-for-header-refresh-in-RGBA-mode.patch](/uploads/6841605c138865eba1f12d59112c67a2/0002-add-support-for-header-refresh-in-RGBA-mode.patch)
### Depends on
* [Bug 733819](https://bugzilla.gnome.org/show_bug.cgi?id=733819)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/306rtmpsrc: Slow teardown of connection when pipeline is interrupted2021-09-24T14:33:44ZBugzilla Migration Userrtmpsrc: Slow teardown of connection when pipeline is interrupted## Submitted by John Slade
**[Link to original bug (#755732)](https://bugzilla.gnome.org/show_bug.cgi?id=755732)**
## Description
The RTMP plugin can be slow to stop when interrupted (with SIGINT) as it waits for the network socket ...## Submitted by John Slade
**[Link to original bug (#755732)](https://bugzilla.gnome.org/show_bug.cgi?id=755732)**
## Description
The RTMP plugin can be slow to stop when interrupted (with SIGINT) as it waits for the network socket to timeout before stopping. librtmp has this timeout set by default at 30 seconds.
Here is an example output with timestamps:
Sep 25 16:38:13 Setting pipeline to PAUSED ...
Sep 25 16:38:13 Pipeline is PREROLLING ...
Sep 25 16:38:15 Redistribute latency...
Sep 25 16:38:15 Pipeline is PREROLLED ...
Sep 25 16:38:15 Setting pipeline to PLAYING ...
Sep 25 16:38:15 New clock: GstSystemClock
Sep 25 16:38:16 handling interrupt. <-------------- interrupt with SIGINT
Sep 25 16:38:16 Interrupt: Stopping pipeline ...
Sep 25 16:38:16 Execution ended after 0:00:00.951296656
Sep 25 16:38:16 Setting pipeline to PAUSED ...
Sep 25 16:38:16 Setting pipeline to READY ...
Sep 25 16:38:46 Setting pipeline to NULL ... <-------------- 30 seconds delay
Sep 25 16:38:46 Freeing pipeline ...
The log shows going from READY->NULL took 30 seconds.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/307h264parse: sets incomplete srccaps first2021-09-24T14:33:44ZBugzilla Migration Userh264parse: sets incomplete srccaps first## Submitted by Maroš Ondrášek
**[Link to original bug (#755885)](https://bugzilla.gnome.org/show_bug.cgi?id=755885)**
## Description
Created attachment 312435
h264parse log 1.5.1 and 1.6.0 comparison
I noticed changed behavi...## Submitted by Maroš Ondrášek
**[Link to original bug (#755885)](https://bugzilla.gnome.org/show_bug.cgi?id=755885)**
## Description
Created attachment 312435
h264parse log 1.5.1 and 1.6.0 comparison
I noticed changed behaviour of h264parse from 1.5.1 to 1.6.0:
testing pipeline:
GST_DEBUG_NO_COLOR=1 GST_DEBUG=basesink:5,h264parse:5 gst-launch-1.0 souphttpsrc location='http://f24hls-i.akamaihd.net/hls/live/221192/F24_FR_LO_HLS/master_900.m3u8' ! hlsdemux ! queue ! tsdemux ! h264parse ! fakesink
1.5.1:
received one caps event with complete caps, before rendering starts
gstbasesink.c:3170:gst_base_sink_event:`<fakesink0>` received event 0x7f2b54014c00 caps event: 0x7f2b54014c00, time 99:99:99.999999999, seq-num 69, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";
1.6.0:
recieved two caps events
1. incomplete caps in caps event before rendering starts:
gstbasesink.c:3232:gst_base_sink_event:`<fakesink0>` received event 0x7f090c014dc0 caps event: 0x7f090c014dc0, time 99:99:99.999999999, seq-num 68, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ parsed\=\(boolean\)true";
2. complete caps in caps event after rendering starts:
gstbasesink.c:3232:gst_base_sink_event:`<fakesink0>` received event 0x7f090c015010 caps event: 0x7f090c015010, time 99:99:99.999999999, seq-num 86, GstEventCaps, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)nal\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ width\=\(int\)1024\,\ height\=\(int\)576\,\ framerate\=\(fraction\)25/1\,\ parsed\=\(boolean\)true\,\ profile\=\(string\)main\,\ level\=\(string\)3.1";
If I revert these two commits, then I have same behaviour as in 1.5.1:
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=e8908f5aeef952566f6bccde743c7735d3f8c6ef
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=48a1f2792316d01c4ea4c6baa27188ffae73c543
In e8908f5aeef952566f6bccde743c7735d3f8c6ef, I can see that we are updating src caps even if sps is not yet available.
Is this correct behaviour to update src caps with incomplete caps, first?
Thank you
**Attachment 312435**, "h264parse log 1.5.1 and 1.6.0 comparison":
[h264parse_151_160.tar.gz](/uploads/5fb5455df49e6006e088f8595949a964/h264parse_151_160.tar.gz)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/309vtdec: "Error decoding frame -12909" on iOS2021-09-24T14:33:45ZBugzilla Migration Uservtdec: "Error decoding frame -12909" on iOS## Submitted by Andrey
**[Link to original bug (#756073)](https://bugzilla.gnome.org/show_bug.cgi?id=756073)**
## Description
I have cloned this repo http://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/xcode%...## Submitted by Andrey
**[Link to original bug (#756073)](https://bugzilla.gnome.org/show_bug.cgi?id=756073)**
## Description
I have cloned this repo http://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/xcode%20iOS and run Tutorial 5 in XCode 7. Wowza rtsp sample video works fine. But my IP camera shows only first frame of video and fire PAUSED state.
Similar IP camera rtsp links works fine in VLC and Android version of GStreamer.
I have implemented tutorial sample in my application and have got similar behavior.
Here is log of GStreamer http://pastebin.com/9N54vQUb captured from my application.
Logs have a lot of
"0:01:05.669427000 [335m 178[00m 0x183559e0 [32;01mFIXME [00m [00;01m bin gstbin.c:4070:gboolean gst_bin_query(GstElement *, GstQuery *):[00m implement duration caching in GstBin again"
and
"733:gst_vtdec_session_output_callback:`<vtdec0>`[00m Error decoding frame -12909
0:00:09.393987000 [336m 5105[00m 0x159570a0 [31;01mERROR [00m [00m"
messages.
How can I fix it?
Thanks for advance!
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/310New webvideosrc source element2021-09-24T14:33:45ZBugzilla Migration UserNew webvideosrc source element## Submitted by Yannick Inizan
**[Link to original bug (#756110)](https://bugzilla.gnome.org/show_bug.cgi?id=756110)**
## Description
Created attachment 312713
plugin patch
Please find as attachment webvideosrc source element...## Submitted by Yannick Inizan
**[Link to original bug (#756110)](https://bugzilla.gnome.org/show_bug.cgi?id=756110)**
## Description
Created attachment 312713
plugin patch
Please find as attachment webvideosrc source element.
This element can retrieve video links from web video URI and rank these links by quality. This source element is based on GFileInputStream created from current link (set by 'quality' webvideosrc property).
**Patch 312713**, "plugin patch":
[0001-webvideosrc-Source-element-for-web-video-services.patch](/uploads/97471a0f99a0866ab9186da52b1bbc9b/0001-webvideosrc-Source-element-for-web-video-services.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/311compositor/glvideomixer: Add support for cropping and aspect-ratio preserving...2021-09-24T14:33:45ZBugzilla Migration Usercompositor/glvideomixer: Add support for cropping and aspect-ratio preserving scaling## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#756276)](https://bugzilla.gnome.org/show_bug.cgi?id=756276)**
## Description
We have width/height properties for scaling, but additional properties for cropping woul...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#756276)](https://bugzilla.gnome.org/show_bug.cgi?id=756276)**
## Description
We have width/height properties for scaling, but additional properties for cropping would be useful to have.
On top of that, having the width/height properties to automatically preserve the aspect-ratio would be great. E.g. by only setting one of width or height, and having the other be calculated by compositor/glvideomixerhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/314hlsdemux: fix race condition while changing bitrate and seeking2021-09-24T14:33:46ZBugzilla Migration Userhlsdemux: fix race condition while changing bitrate and seeking## Submitted by Philip Murphy
**[Link to original bug (#756913)](https://bugzilla.gnome.org/show_bug.cgi?id=756913)**
## Description
- Changed GST_M3U8_CLIENT_LOCK to a recursive mutex
- This was needed as a race condition was p...## Submitted by Philip Murphy
**[Link to original bug (#756913)](https://bugzilla.gnome.org/show_bug.cgi?id=756913)**
## Description
- Changed GST_M3U8_CLIENT_LOCK to a recursive mutex
- This was needed as a race condition was present in gst_hls_demux_change_playlist, while switching
variant it was possible for a seek to occur because the mutex was unlocked. This seek would fail at this point because
client->current->endlist would not have been set to true yet. Changing GST_M3U8_CLIENT_LOCK to a recursive mutex prevents
a seek occurring while switching variant.
- This fix only applies to 1.4.5
- I understand that changing GST_M3U8_CLIENT_LOCK to a recursive mutex may not be an ideal solution, so I am open to suggestions on a more appropriate solution.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/315avfvideosrc should implement Gstphotography interface2021-09-24T14:33:46ZBugzilla Migration Useravfvideosrc should implement Gstphotography interface## Submitted by Shahab
**[Link to original bug (#756945)](https://bugzilla.gnome.org/show_bug.cgi?id=756945)**
## Description
We would expect avfvideosrc would implement the GstPhotography interface for properties like (Focus mode, ...## Submitted by Shahab
**[Link to original bug (#756945)](https://bugzilla.gnome.org/show_bug.cgi?id=756945)**
## Description
We would expect avfvideosrc would implement the GstPhotography interface for properties like (Focus mode, Exposure mode, White balance mode)
There are two Exposure modes:
AVCaptureExposureModeContinuousAutoExposure and
AVCaptureExposureModeLocked
There are three focus modes:
AVCaptureFocusModeLocked
AVCaptureFocusModeAutoFocus
AVCaptureFocusModeContinuousAutoFocus
There are two white balance modes:
AVCaptureWhiteBalanceModeLocked
AVCaptureWhiteBalanceModeContinuousAutoWhiteBalance
It would be great if we could set the enum values in respected modes. Till now we can not set the modes in gst-plugins-bad/edit/master/sys/applemedia/avfvideosrc.m file
Thank you.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/316hlsdemux: Fix switching between I-frame and normal playlists when seeking2021-09-24T14:33:47ZBugzilla Migration Userhlsdemux: Fix switching between I-frame and normal playlists when seeking## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757009)](https://bugzilla.gnome.org/show_bug.cgi?id=757009)**
## Description
See commit message## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757009)](https://bugzilla.gnome.org/show_bug.cgi?id=757009)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/317amcviddec: zerocopy does not work with decodebin2021-09-24T14:33:47ZBugzilla Migration Useramcviddec: zerocopy does not work with decodebin## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757134)](https://bugzilla.gnome.org/show_bug.cgi?id=757134)**
## Description
See summary, problem is that autoplug-query is not used and context query does not go to...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757134)](https://bugzilla.gnome.org/show_bug.cgi?id=757134)**
## Description
See summary, problem is that autoplug-query is not used and context query does not go to sink. Only works in playbin and static pipelines at this pointhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/318GstPhotography: add writability capabilities2021-09-24T14:33:47ZBugzilla Migration UserGstPhotography: add writability capabilities## Submitted by Carlos Rafael Giani
**[Link to original bug (#757352)](https://bugzilla.gnome.org/show_bug.cgi?id=757352)**
## Description
Currently, the GstPhotography interface has a bitmask returned by the get_capabilities() vfun...## Submitted by Carlos Rafael Giani
**[Link to original bug (#757352)](https://bugzilla.gnome.org/show_bug.cgi?id=757352)**
## Description
Currently, the GstPhotography interface has a bitmask returned by the get_capabilities() vfunc which specifies which features are implemented and which ones aren't. However, with some hardware platforms, features may exist but be read only. It is therefore useful to add another bitmask which indicates whether or not a feature is read-only or read-write.
### Blocking
* [Bug 774779](https://bugzilla.gnome.org/show_bug.cgi?id=774779)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/319openh264enc: add support for cabac entropy coding2021-09-24T14:33:48ZBugzilla Migration Useropenh264enc: add support for cabac entropy coding## Submitted by Nicola `@drakkan`
**[Link to original bug (#757419)](https://bugzilla.gnome.org/show_bug.cgi?id=757419)**
## Description
Created attachment 314569
initial patch
openh264 introduced support for cabac entropy co...## Submitted by Nicola `@drakkan`
**[Link to original bug (#757419)](https://bugzilla.gnome.org/show_bug.cgi?id=757419)**
## Description
Created attachment 314569
initial patch
openh264 introduced support for cabac entropy coding.
Initial patch to add support for cabac to openh264enc plugin, please review
~~**Patch 314569**~~, "initial patch":
[0001-openh264enc-add-support-for-cabac-entropy-coding.patch](/uploads/76204339cfed4a79a0caf1ef2573500b/0001-openh264enc-add-support-for-cabac-entropy-coding.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/320tsdemux: Implement keyframe scanning for MPEG2/42021-09-24T14:33:48ZBugzilla Migration Usertsdemux: Implement keyframe scanning for MPEG2/4## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757459)](https://bugzilla.gnome.org/show_bug.cgi?id=757459)**
## Description
We currently implement this for h264 only, while it's much simpler for MPEG2/4. I once i...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757459)](https://bugzilla.gnome.org/show_bug.cgi?id=757459)**
## Description
We currently implement this for h264 only, while it's much simpler for MPEG2/4. I once implemented that in MXF, code can be found here:
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mxf/mxfmpeg.c#n436
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mxf/mxfmpeg.c#n487https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/321mpegtsmux: Add support for aggregating multiple ES packets for one PES packet2021-09-24T14:33:49ZBugzilla Migration Usermpegtsmux: Add support for aggregating multiple ES packets for one PES packet## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757567)](https://bugzilla.gnome.org/show_bug.cgi?id=757567)**
## Description
See summary, this is especially useful for audio where packets are usually very small an...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757567)](https://bugzilla.gnome.org/show_bug.cgi?id=757567)**
## Description
See summary, this is especially useful for audio where packets are usually very small and we can otherwise easily get 100% or more overhead caused by the PES/MPEG-TS packetization.
ffmpeg does this for audio, and has a parameter to configure how much at most should be aggregated per PES packethttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/323splitmuxsink with mpegtsmux, curlftpsink generates only the first fragment a...2021-09-24T14:33:49ZBugzilla Migration Usersplitmuxsink with mpegtsmux, curlftpsink generates only the first fragment and pipeline exits with a timeout error.## Submitted by Raghavendra
**[Link to original bug (#758160)](https://bugzilla.gnome.org/show_bug.cgi?id=758160)**
## Description
splitmuxsink with mpegtsmux and curlftpsink is generating only one fragment and pipeline exits after ...## Submitted by Raghavendra
**[Link to original bug (#758160)](https://bugzilla.gnome.org/show_bug.cgi?id=758160)**
## Description
splitmuxsink with mpegtsmux and curlftpsink is generating only one fragment and pipeline exits after displaying a timeout error with gst_poll_wait API.
After lots of experiments, I tried disabling the portion of code in the function "handle_transfer" of the file gstcurlbasesink.c of gst-plugins-bad where gst_poll_wait API is being used and GST_FLOW_ERROR is returned if no activity is found the concerned fd.
By disabling this, I could see the pipeline moving ahead and the fragments being generated at the target location.
I want to understand what gstcurlbasesink is exactly trying to do and why is it only after disabling this portion of code fragments are being generated.
Also, I observed one more thing. If I use mp4mux instead of mpegtsmux the pipeline just exits.
Please help me to resolve these issues. Any quick response is greatly appreciated.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/324uvch264src freezes when using its "vidsrc"2021-09-24T14:33:49ZBugzilla Migration Useruvch264src freezes when using its "vidsrc"## Submitted by Bence Varga
**[Link to original bug (#758219)](https://bugzilla.gnome.org/show_bug.cgi?id=758219)**
## Description
Created attachment 315732
Output of using both sources.
When starting the following chain:
...## Submitted by Bence Varga
**[Link to original bug (#758219)](https://bugzilla.gnome.org/show_bug.cgi?id=758219)**
## Description
Created attachment 315732
Output of using both sources.
When starting the following chain:
gst-launch-1.0 -v -e uvch264src device=/dev/video1 name=src auto-start=true \
src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false \
src.vidsrc ! queue ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false
the sresult is only the viewfinder (vfsrc) emitting a single frame. If I remove the vidsrc part, the result is (as expected) a live preview of the camera:
gst-launch-1.0 -v -e uvch264src device=/dev/video1 name=src auto-start=true \
src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false
1st machine tested:
Linux 3.16.7-ckt11
GStreamer 1.7.0 (GIT)
Logitec C920-C
2nd machine:
Linux 3.16.0-4-amd64
GStreamer 1.4.4
Logitec C930
I attached the file with the output of:
gst-launch-1.0 -vvv --gst-debug=uvch264src:5 -e uvch264src device=/dev/video1 name=src auto-start=true src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false src.vidsrc ! queue ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false
Already described here: http://gstreamer-devel.966125.n4.nabble.com/uvch264src-Only-broken-examples-td4665446.html
I just noticed this issue is already flagged as invalid in https://bugzilla.gnome.org/show_bug.cgi?id=756776 -- but no, 1.4.5 did not fix it as I'm experiencing it with 1.7.
**Attachment 315732**, "Output of using both sources.":
[gst.txt](/uploads/ef0136132af3ea1eb49cb552ed2bb6a4/gst.txt)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/326h264parse: marks every buffer as header in dash stream2021-09-24T14:33:50ZBugzilla Migration Userh264parse: marks every buffer as header in dash stream## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#758419)](https://bugzilla.gnome.org/show_bug.cgi?id=758419)**
## Description
The stream: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-sep...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#758419)](https://bugzilla.gnome.org/show_bug.cgi?id=758419)**
## Description
The stream: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-separate_init.mpd
*every* buffer coming out of h264parse is marked as a header.
Easily seen with a debug log 6 of playbin on that file and then grepping:
cat gst.log | grep "avdec_h264-0:sink>" |grep calling |less -RS
Note the flags at the end always contain 0x400https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/328adaptivedemux: start of play is delayed for live streams2021-09-24T14:33:51ZBugzilla Migration Useradaptivedemux: start of play is delayed for live streams## Submitted by Florin Apostol
**[Link to original bug (#758539)](https://bugzilla.gnome.org/show_bug.cgi?id=758539)**
## Description
When identifying the current segment to be played for a live stream, the gst_dash_demux_setup_stre...## Submitted by Florin Apostol
**[Link to original bug (#758539)](https://bugzilla.gnome.org/show_bug.cgi?id=758539)**
## Description
When identifying the current segment to be played for a live stream, the gst_dash_demux_setup_streams will use the now moment (adjusted with presentationDelay). The gst_mpd_client_seek_to_time function will compute ts_microseconds = g_date_time_difference (time, start) and gst_mpd_client_stream_seek will search the segment corresponding to this ts_microseconds in the presentation timeline.
But the standards defines the availabilityStartTime for a media segment to be at the end of the segment:
"For services with MPD@type='dynamic', the Segment availability start time of a Media Segment is the sum of the value of the MPD@availabilityStartTime, the PeriodStart time of the containing Period as defined in 5.3.2.1, the MPD start time and the MPD duration of the Media Segment."
This leads to adaptive demux waiting for the identified segment to be available.
For a visual scenario, let's consider the following data:
MPD@availabilityStartTime = 12:00:00
suggestedPresentationDelay = 0
Segment templates are uses, there are several segments, each having a duration of 1s. Segment numbers start at 1, so segment 1 is between 12:00:00 and 12:00:01, etc.
Now is 12:00:05.3
Based on now value, ts_microseconds = 5.3 * 1000 * 1000, choosing segment 6 (which is between 12:00:05 and 12:00:06). When trying to play it, the gst_adaptive_demux_stream_download_loop function will use gst_adaptive_demux_stream_get_fragment_waiting_time to determine how much to wait for the segment to be available. In our case, it will be 6-5.3=0.7s
The longer the segment duration, the longer the initial wait period when starting to play a live stream.
Question: shouldn't gst_dash_demux_setup_streams function try to choose the latest available segment (the segment previous to the one it currently identifies)? That would save the waiting time.
Also, do notice that if suggestedPresentationDelay is not 0, the identified segment is already available on the server so gst_adaptive_demux_stream_download_loop will not wait and playback will start immediately, violating the suggestedPresentationDelay which is not observed entirely.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/329Using vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 p...2021-09-24T14:33:52ZBugzilla Migration UserUsing vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 profile results in timestamp problems## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758640)](https://bugzilla.gnome.org/show_bug.cgi?id=758640)**
## Description
When testing low frame rates like 1/1 in our RTSP server code using vtenc_h264, we...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758640)](https://bugzilla.gnome.org/show_bug.cgi?id=758640)**
## Description
When testing low frame rates like 1/1 in our RTSP server code using vtenc_h264, we have observed time stamp problems in the client, which are likely due to some timestamp problems already on the server side. This can be reproduced as follows:
Use gst-rtsp-server's test-launch example with the following launch line:
./test-launch "videotestsrc is-live=true ! vtenc_h264 allow-frame-reordering=false realtime=true max-keyframe-interval=1 bitrate=6000 ! video/x-h264,profile=main,width=1920,height=1080,framerate=1/1 ! rtph264pay name=pay0 pt=96"
Then simply play back the stream using gst-play-1.0. This will result in the client complaining about timestamps problems ("warning: There may be a timestamping problem, or this computer is too slow.", etc).
Now, simply changing the above launch line to use profile=baseline instead of profile=main, makes the example work flawlessly:
./test-launch "videotestsrc is-live=true ! vtenc_h264 allow-frame-reordering=false realtime=true max-keyframe-interval=1 bitrate=6000 ! video/x-h264,profile=baseline,width=1920,height=1080,framerate=1/1 ! rtph264pay name=pay0 pt=96"
My knowledge about the h264/RTSP specific parts is too little that I can make a lot of sense out of this, but I did a little bit of digging, and here are some facts I found which might be relevant:
(1) using profile=main works with x264enc, although x264 seems to fall back to constrained-baseline, when being configured to not use any B frames and use intra encoding only
(2) Changing between profile=main and profile=baseline doesn't change the latency
introduced by vtenc (which is unnecessarily high here, but that's another story), i.e. the timing of the buffers being emitted out of vtenc is the same
(3) Changing the frame rate to 2/1 (instead of 1/1) makes it also work with profile=main.
I was able to narrow our bug down so far and make it reproducible using standard GST tools, but I need help to further narrow it down. Especially, we can't say for sure whether this is (a) a bug of vtenc/VT toolbox (b) a bug in rtph264pay or (c) a bug somewhere further down in the RTSP server. Any ideas?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/330h264parse: failed to encode MVC h264 streams in GStreamer-1.62021-09-24T14:33:52ZBugzilla Migration Userh264parse: failed to encode MVC h264 streams in GStreamer-1.6## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#758656)](https://bugzilla.gnome.org/show_bug.cgi?id=758656)**
## Description
MVC encoding is failing when adding a videoparser element in the pipeline.
Seems ...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#758656)](https://bugzilla.gnome.org/show_bug.cgi?id=758656)**
## Description
MVC encoding is failing when adding a videoparser element in the pipeline.
Seems to be a regression with recent MVC specific patches landed in upstream h264parser (>= 1.5).
Encode(run with out any error):
GST_DEBUG=3 gst-launch-1.0 videotestsrc num-buffers=900 ! vaapiencode_h264 num-views=2 ! h264parse ! filesink location=enc_mvc.h264
Decoding will fail:
GST_DEBUG=3 gst-launch-1.0 filesrc location= enc_mvc.h264 ! h264parse ! "video/x-h264, stream-format=(string)byte-stream" ! vaapidecode ! vaapisink
### Blocking
* [Bug 758397](https://bugzilla.gnome.org/show_bug.cgi?id=758397)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/331Assume unknown OMX color formats are similar to YUV4202021-09-24T14:33:52ZBugzilla Migration UserAssume unknown OMX color formats are similar to YUV420## Submitted by Mathias Hasselmann `@hasselmm`
**[Link to original bug (#758699)](https://bugzilla.gnome.org/show_bug.cgi?id=758699)**
## Description
Android hardware decoders usually report undocumented OMX color formats resulting ...## Submitted by Mathias Hasselmann `@hasselmm`
**[Link to original bug (#758699)](https://bugzilla.gnome.org/show_bug.cgi?id=758699)**
## Description
Android hardware decoders usually report undocumented OMX color formats resulting in the accelerated pipeline not building up. I believe it's safe to assume that those unknown color formats are similar to COLOR_FormatYUV420Planar and only print a warning without bailing out. 99.5% this will produce happy users with proper video, remaining 0.5% hopefully file a bug report.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/332issue about intel(x86) does not provide slice_height and otherwise.2021-09-24T14:33:53ZBugzilla Migration Userissue about intel(x86) does not provide slice_height and otherwise.## Submitted by ji su
**[Link to original bug (#758933)](https://bugzilla.gnome.org/show_bug.cgi?id=758933)**
## Description
Created attachment 316637
patch file, original gstamc.c, modified gstamc.c, logs about amc
Hello
...## Submitted by ji su
**[Link to original bug (#758933)](https://bugzilla.gnome.org/show_bug.cgi?id=758933)**
## Description
Created attachment 316637
patch file, original gstamc.c, modified gstamc.c, logs about amc
Hello
I'm trying to build a movie player based on gstreamer android, x86 processor (Intel Z3835F).
I want to play an mp4 media file whose video codec is h264/avc but gstreamer printed below:
"Error received from element amcvideodec-omxintelhwvdh264-n: Gstreamer encountered a general supporting library error "
So, I modified ${SDK}/gst-plugins-bad-1.0-static-1.5/sys/androidmedia/gstamc.c like below:
gboolean
gst_amc_color_format_info_set (GstAmcColorFormatInfo * color_format_info,
const GstAmcCodecInfo * codec_info, const gchar * mime, gint color_format,
gint width, gint height, gint stride, gint slice_height, gint crop_left,
gint crop_right, gint crop_top, gint crop_bottom)
{
...
if (g_str_has_prefix (codec_info->name, "OMX.Intel.")) {
// added OMX.Intel. part
slice_height = height;
}
...
Then just play (never seek) was well but when i jumped to any position of media, gstreamer printed below:
"Error received from element amcvideodec-omxintelhwvdh264-n: No valid frames decoded before end of stream"
Unfortunately, I couldn't find any information about x86-based plugins.
How could i play a .mp4 media file (h264/avc)?
What did I miss?
Thank you for reading.
**Attachment 316637**, "patch file, original gstamc.c, modified gstamc.c, logs about amc":
[intelpatch.zip](/uploads/f7ad44ca18a7c2c699ad42954ce5c64b/intelpatch.zip)
Version: 1.6.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/334adaptivedemux: tests: do not sleep with the GST_TEST_LOCK taken2021-09-24T14:33:56ZBugzilla Migration Useradaptivedemux: tests: do not sleep with the GST_TEST_LOCK taken## Submitted by Florin Apostol
**[Link to original bug (#758961)](https://bugzilla.gnome.org/show_bug.cgi?id=758961)**
## Description
All the test callbacks are called with GST_TEST_LOCK taken. The callbacks
should release this lo...## Submitted by Florin Apostol
**[Link to original bug (#758961)](https://bugzilla.gnome.org/show_bug.cgi?id=758961)**
## Description
All the test callbacks are called with GST_TEST_LOCK taken. The callbacks
should release this lock if they want to sleep. Seek test currently
sleeps in callback, so it must temporarily release the GST_TEST_LOCKhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/335hlsdemux/others: Bad drift compensation for live streams2021-09-24T14:33:56ZBugzilla Migration Userhlsdemux/others: Bad drift compensation for live streams## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759333)](https://bugzilla.gnome.org/show_bug.cgi?id=759333)**
## Description
Currently with live streams we will just fall behind more and more based on clock drift ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759333)](https://bugzilla.gnome.org/show_bug.cgi?id=759333)**
## Description
Currently with live streams we will just fall behind more and more based on clock drift and also because of rebuffering due to BUFFERING messages.
The only time when we resync (in hls to the 3rd newest fragment, no idea for the others) is when we fall off the Manifest completely. If the Manifest is huge (I have one here that has about 1 hour of fragments), we would get up to one hour behind.
Instead we should probably start resyncing earlier. Like once we are 3 or 6 or $number fragments behind the one we would resync to, or 1 minute or whatever worth of fragments behind the fragment that we would resync to.
It doesn't seem a good idea to have live streams go that far away from being live.
I'll provide a patch for HLS later, but unfortunately the same work has to be redone for DASH and the others individually.
DASH fortunately has an optional extension that allows to compensate for this based on the server clock, but if that is not available we should also do something like I proposed above.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/336pnmdec stalls when queue with min-threshold-buffers>1 is used2021-09-24T14:33:57ZBugzilla Migration Userpnmdec stalls when queue with min-threshold-buffers>1 is used## Submitted by Marianna S. Buschle
**[Link to original bug (#759338)](https://bugzilla.gnome.org/show_bug.cgi?id=759338)**
## Description
A pipeline using multifilesrc + pnmdec + queue with min-threshold-buffers>1 stalls after/duri...## Submitted by Marianna S. Buschle
**[Link to original bug (#759338)](https://bugzilla.gnome.org/show_bug.cgi?id=759338)**
## Description
A pipeline using multifilesrc + pnmdec + queue with min-threshold-buffers>1 stalls after/during reading the second file.
This pipeline (using pngdec) runs fine:
gst-launch-1.0 --gst-debug=*:3,multifilesrc:5,pnmdec:5 multifilesrc index=0 name=filesrc location=\"/tmp/frame%04d.png\" caps=\"image/png, framerate=10/1\" ! pngdec ! queue min-threshold-buffers=2 ! fakesink async=0 sync=1
if however we swapt to PNM files (pnmdec) it stalls after reading the first image:
gst-launch-1.0 --gst-debug=*:3,multifilesrc:5,pnmdec:5 multifilesrc index=0 name=filesrc location=\"frame%04d.ppm\" caps=\"image/x-portable-graymap, framerate=10/1\" ! pnmdec ! queue min-threshold-buffers=2 ! fakesink async=0 sync=1
...
0:00:00.029443520 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:388:gst_multi_file_src_get_filename: 0
0:00:00.029504276 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:421:gst_multi_file_src_create:`<filesrc>` reading from file "frame0000.ppm".
0:00:00.030860164 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:463:gst_multi_file_src_create:`<filesrc>` read file "frame0000.ppm".
0:00:00.031033479 6172 0x6d3140 WARN videodecoder gstvideodecoder.c:2479:gst_video_decoder_chain:`<pnmdec0>` Received buffer without a new-segment. Assuming timestamps start from 0.
0:00:00.033083984 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:388:gst_multi_file_src_get_filename: 1
0:00:00.033214362 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:421:gst_multi_file_src_create:`<filesrc>` reading from file "frame0001.ppm".
0:00:00.034374941 6172 0x6d3140 DEBUG multifilesrc gstmultifilesrc.c:463:gst_multi_file_src_create:`<filesrc>` read file "frame0001.ppm".
if we set min-threshold-buffers to 1 it runs fine:
gst-launch-1.0 --gst-debug=*:3,multifilesrc:5,pnmdec:5 multifilesrc index=0 name=filesrc location=\"frame%04d.ppm\" caps=\"image/x-portable-graymap, framerate=10/1\" ! pnmdec ! queue min-threshold-buffers=1 ! fakesink async=0 sync=1
I imagine the problem is in pnmdec since it runs fine with pngdec.
I get no errors or any hints of the problem with the debug levels used...
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/339shmsink: gst_allocator_alloc fail during playback2021-09-24T14:33:59ZBugzilla Migration Usershmsink: gst_allocator_alloc fail during playback## Submitted by Eunhae Choi
**[Link to original bug (#759803)](https://bugzilla.gnome.org/show_bug.cgi?id=759803)**
## Description
When we test ... - avdec_h264 - shmsink pipeline, avdec try to alloc too many buffers(upto 32 buffers...## Submitted by Eunhae Choi
**[Link to original bug (#759803)](https://bugzilla.gnome.org/show_bug.cgi?id=759803)**
## Description
When we test ... - avdec_h264 - shmsink pipeline, avdec try to alloc too many buffers(upto 32 buffers) with buffer pool even we set shm-size on shmsink.
If we try to play FHD movie on our target, the operation is stopped after a while by lack of memory.
We thisnk the max size of buffer pool needs to be set to avoid this issue.
You can check the issue with below lauch cmd.
# gst-launch-1.0 filesrc location=./s.mp4 ! qtdemux ! h264parse ! queue ! avdec_h264 ! shmsink socket-path='/tmp/mused_gst.5' wait-for-connection=false sync=true perms=0777https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/340Input selector hangs with tee element and live rtspsrc2021-09-24T14:34:00ZBugzilla Migration UserInput selector hangs with tee element and live rtspsrc## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759862)](https://bugzilla.gnome.org/show_bug.cgi?id=759862)**
## Description
Created attachment 317876
dummy program to reproduce this bug easily
Steps to reproduce:...## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759862)](https://bugzilla.gnome.org/show_bug.cgi?id=759862)**
## Description
Created attachment 317876
dummy program to reproduce this bug easily
Steps to reproduce:
write a program for pipeline like
audio rtspsrc ----------------------->|
| |--->live_queue-->rtmpsink
ip cam1 --------->| |-flvmux-->mixing_queue->tee--|
ip cam2 --------->| | |--->record_queue-->fakesink
ip cam3 --------->|--inputselector--->|
ip cam4 --------->|
ip cam5 --------->|
It always hangs after switching ip cameras for 2-3 times.
Error message comes as "RTMP send error". Please note that we are using rtmpsink with sync=true and async=true.
However, The pipeline works in following cases:
1) if I don't use "tee" and connect mixing_queue to rtmpsink directly then pipeline works fine.
2) if replace rtmpsink with filesink and fakesink with shmsrc in above pipeline then it works fine.
I attached a dummy program which can help you to reproduce this bug on your side.
**Attachment 317876**, "dummy program to reproduce this bug easily":
[file_759862.txt](/uploads/11c49ee0cfb6ba0ff7eb61b901deb98b/file_759862.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/341OpenCV face detection does not work with OpenCV newer than 2.4.112021-09-24T14:34:00ZBugzilla Migration UserOpenCV face detection does not work with OpenCV newer than 2.4.11## Submitted by Vanessa Chipirrás Navalón
Assigned to **Vanessa Chipirrás Navalón**
**[Link to original bug (#760473)](https://bugzilla.gnome.org/show_bug.cgi?id=760473)**
## Description
When I compile the module "gstreamer1.0-plu...## Submitted by Vanessa Chipirrás Navalón
Assigned to **Vanessa Chipirrás Navalón**
**[Link to original bug (#760473)](https://bugzilla.gnome.org/show_bug.cgi?id=760473)**
## Description
When I compile the module "gstreamer1.0-plugins-bad" in my pc, I get this error:
fatal error: opencv2/legacy/legacy.hpp: No such file or directory
compilation terminated.
But this also happens with files: contrib.hpp, core_c.h, types_c.h.
I have 3.0.0 version of OpenCV, and I looked inside folders Opencv and I don't find this files.
Maybe OpenCV 3.0.0 was deleted it or modified, I try to find out what happened.
Version: 1.6.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/342dash, mpdparser: Implement the flow to check invalid adaption sets or repres...2021-09-24T14:34:01ZBugzilla Migration Userdash, mpdparser: Implement the flow to check invalid adaption sets or representations according to ISO/IEC 23009-1 : section 8.3## Submitted by WeiChungChang
**[Link to original bug (#760837)](https://bugzilla.gnome.org/show_bug.cgi?id=760837)**
## Description
Created attachment 319348
patch to fix the issue
According to ISO/IEC 23009-1 : section 8.3,...## Submitted by WeiChungChang
**[Link to original bug (#760837)](https://bugzilla.gnome.org/show_bug.cgi?id=760837)**
## Description
Created attachment 319348
patch to fix the issue
According to ISO/IEC 23009-1 : section 8.3, there are several checks should be executed to filter out the adaption sets or representations which are not in correct form.
For example, if it is a ISO BASE media file format On Demand profile with URN ="urn:mpeg:dash:profile:isoff-on-demand:2011" & AdaptationSet@subsegmentAlignment does not present,the adaption set should be ignored.
However, current MPD parser does not fully comply with this rule.
Hence when I played the MPD as attached TestSuit.mpd, the playback will stuck
by requesting an invalid URL link.
In the attached patch it tries to implement the flow to check the claimed rules within ISO/IEC 23009-1 : section 8.3.
**Patch 319348**, "patch to fix the issue":
[0001-Create-the-flow-to-do-check-according-to-ISO-IEC-230.patch](/uploads/fc955f9e2cb690892126a5acc84e6077/0001-Create-the-flow-to-do-check-according-to-ISO-IEC-230.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/343adaptivedemux: stream can pause for a long time when server errors encountered2021-09-24T14:34:01ZBugzilla Migration Useradaptivedemux: stream can pause for a long time when server errors encountered## Submitted by David Waring
**[Link to original bug (#760930)](https://bugzilla.gnome.org/show_bug.cgi?id=760930)**
## Description
During testing dashdemux/adaptivedemux with live streams we noticed the
playback cease and wait fo...## Submitted by David Waring
**[Link to original bug (#760930)](https://bugzilla.gnome.org/show_bug.cgi?id=760930)**
## Description
During testing dashdemux/adaptivedemux with live streams we noticed the
playback cease and wait for a long time before attempting to carry on.
This was caused by an unexpected 503 error from the DASH server, which
caused the adaptivedemux element to immediately wait for the next MPD
update. The MPD used had a 1 hour update period, meaning that the stream
could remain frozen for up to 1 hour after encountering an HTTP server
error. We believe that this a less than ideal situation for playback of
a live stream.
We propose that the error recovery logic in
gst_adaptive_demux_download_fragment and
gst_adaptive_demux_download_loop be changed. We believe, for a live
stream, a better error recovery scenario would be achieved by:
1. retry the current media fragment first, up to the retry limit.
2. once the retry limit is reached for the current media fragment it
should be abandoned and the stream resynchronised to the fragment that should
be at the current running time (i.e. bring back up to date with what
should be playing out had the stream continued and not encountered an
error).
3. if there is no new fragment to resynchronise to, only then wait for a
manifest update.
Step 2 could also just skip to the next fragment should one be available.
If this logic seems sound I'll try and produce a patch to implement it.
Can any of the maintainers foresee any problems with these proposed changes
to adaptivedemux?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/345video crc generator for video decoder verification2021-09-24T14:34:02ZBugzilla Migration Uservideo crc generator for video decoder verification## Submitted by Rajesh
**[Link to original bug (#761167)](https://bugzilla.gnome.org/show_bug.cgi?id=761167)**
## Description
Created attachment 319809
videocrc patch
Its a new development of videocrc plugin, which can be hig...## Submitted by Rajesh
**[Link to original bug (#761167)](https://bugzilla.gnome.org/show_bug.cgi?id=761167)**
## Description
Created attachment 319809
videocrc patch
Its a new development of videocrc plugin, which can be highly useful for video decoder verification in embedded domain for HW decoder verification.
videocrc is a passthrough element which generates a CRC for
each video frame. the CRC is emitted through a GstMessage
that application must handle. Uses the standard CRC algorithm
to compute CRC values for every video frame. This element accepts
selected YUV planar formats NV12, I420 and YV12. The element computes
32 bit CRC of luma and chroma for every video frame.
Uses the standard CRC algorithm to compute CRC values for every video frame.
Implements table based optimized CRC computation algorithm available in public domain.
This element accepts selected YUV planar formats NV12, I420 and YV12.
The element computes 32 bit CRC of luma and chroma for every video frame.
Generated CRC can be used to validate the decoded video frames to a exisiting database of pre-computed CRC files.
CRC is sent as messsage to application, so these messages should be processed in application to generate CRC file.
CRC message to application can be switched off by setting crc-message property to FALSE.
The default polynomial used is 0X04c11db7U but it can be changed before processing using crc-mask property.
CRC values can also be printed on terminal using --gst-debug=videocrc:5
~~**Patch 319809**~~, "videocrc patch":
[0001-videocrc-video-crc-generator-for-video-decoder-verif.patch](/uploads/033610c4c06d81b216336a7704abc82c/0001-videocrc-video-crc-generator-for-video-decoder-verif.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/346v4l2src + compositor: can't negotiate caps after going from PLAYING->READY2021-09-24T14:34:03ZBugzilla Migration Userv4l2src + compositor: can't negotiate caps after going from PLAYING->READY## Submitted by Marianna S. Buschle
**[Link to original bug (#761454)](https://bugzilla.gnome.org/show_bug.cgi?id=761454)**
## Description
When using the compositor together with a v4l2src the pipeline will run fine the first time i...## Submitted by Marianna S. Buschle
**[Link to original bug (#761454)](https://bugzilla.gnome.org/show_bug.cgi?id=761454)**
## Description
When using the compositor together with a v4l2src the pipeline will run fine the first time it changes from READY->PLAYING. But if the pipeline is put back to READY and then to PLAYING it will fail to negotiate the caps.
I have encapsulated (using gst_parse_launch) the following pipelines in a simple GTK application which gives me 2 buttons: PLAY and STOP, which respectively set the state to PLAYING and to READY
The following pipeline works all the time:
(I can use the PLAY and STOP buttons as much as I want)
"videotestsrc ! tee name=t1 ! queue ! videoconvert ! compositor name=mux ! videoconvert ! fakesink t1. ! queue ! videoconvert ! gtksink name=sink t1. ! queue ! videoconvert ! mux."
If I then change the videotestsrc to a v4l2src.
It will run fine the first time I click PLAY. But it fails (Internal data flow error) after clicking STOP and then trying PLAY again.
"v4l2src ! tee name=t1 ! queue ! videoconvert ! compositor name=mux ! videoconvert ! fakesink t1. ! queue ! videoconvert ! gtksink name=sink t1. ! queue ! videoconvert ! mux."
At first glance it only shows a Internal data flow error and reason not-negotiated (-4):
Error received from element v4l2src0: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/libs/gst/base/gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Error received from element queue0: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/plugins/elements/gstqueue.c(968): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue0:
streaming task paused, reason not-negotiated (-4)
Error received from element queue2: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/plugins/elements/gstqueue.c(968): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue2:
streaming task paused, reason not-negotiated (-4)
Then by setting the debug levels it seems it is something with caps being NULL on the videoaggregator:
0:00:09.029054344 16712 0x7faf40002050 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_0> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.029535582 16712 0x7faf40002050 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_0> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.029782526 16712 0x7faf40002050 WARN GST_PADS gstpad.c:3989:gst_pad_peer_query:<videoconvert0:src> could not send sticky events
0:00:09.030124577 16712 0x7faf3c001ed0 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_1> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.030581896 16712 0x7faf3c001ed0 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_1> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.030675138 16712 0x7faf3c001ed0 WARN GST_PADS gstpad.c:3989:gst_pad_peer_query:<videoconvert3:src> could not send sticky events
0:00:09.030266606 16712 0x7faf3c002230 WARN v4l2 gstv4l2object.c:3712:gst_v4l2_object_decide_allocation:`<v4l2src0>` decide allocation
0:00:09.031489911 16712 0x7faf3c002230 WARN v4l2bufferpool gstv4l2bufferpool.c:749:gst_v4l2_buffer_pool_start:<v4l2src0:pool:src> Uncertain or not enough buffers, enabling copy threshold
0:00:09.056940651 16712 0x7faf40002050 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_0> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.057781339 16712 0x7faf3c001ed0 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_1> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.059067764 16712 0x7faf40002050 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_0> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.059970677 16712 0x7faf3c001ed0 ERROR videoaggregator gstvideoaggregator.c:856:gst_videoaggregator_pad_sink_setcaps:<mux:sink_1> got input caps video/x-raw, width=(int)320, height=(int)200, framerate=(fraction)100/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, format=(string)RGBx, but current caps are (NULL)
0:00:09.065392758 16712 0x7faf3c002230 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:`<v4l2src0>` error: Internal data flow error.
0:00:09.065443831 16712 0x7faf3c002230 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:`<v4l2src0>` error: streaming task paused, reason not-negotiated (-4)
0:00:09.065583363 16712 0x7faf3c002230 WARN queue gstqueue.c:968:gst_queue_handle_sink_event:`<queue0>` error: Internal data flow error.
0:00:09.065619824 16712 0x7faf3c002230 WARN queue gstqueue.c:968:gst_queue_handle_sink_event:`<queue0>` error: streaming task paused, reason not-negotiated (-4)
0:00:09.065687791 16712 0x7faf3c002230 WARN queue gstqueue.c:968:gst_queue_handle_sink_event:`<queue2>` error: Internal data flow error.
0:00:09.065706444 16712 0x7faf3c002230 WARN queue gstqueue.c:968:gst_queue_handle_sink_event:`<queue2>` error: streaming task paused, reason not-negotiated (-4)
Error received from element v4l2src0: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/libs/gst/base/gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Error received from element queue0: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/plugins/elements/gstqueue.c(968): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue0:
streaming task paused, reason not-negotiated (-4)
Error received from element queue2: Internal data flow error.
Debugging information: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/gstreamer1.0/git-r0/git/plugins/elements/gstqueue.c(968): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue2:
streaming task paused, reason not-negotiated (-4)
Since it works with videotestsrc and it doesnt with v4l2src Im not sure if the issue is in the v4l2src or in the compositor
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/347basedrm: a base class based on CENC common encryption scheme for DRM playback2021-09-24T14:34:04ZBugzilla Migration Userbasedrm: a base class based on CENC common encryption scheme for DRM playback## Submitted by Rajesh
**[Link to original bug (#761700)](https://bugzilla.gnome.org/show_bug.cgi?id=761700)**
## Description
Created attachment 320610
basedrm patch
short_description: Base class for DRM using ISOBMFF CENC co...## Submitted by Rajesh
**[Link to original bug (#761700)](https://bugzilla.gnome.org/show_bug.cgi?id=761700)**
## Description
Created attachment 320610
basedrm patch
short_description: Base class for DRM using ISOBMFF CENC common encryption and 'piff' (PSSH box)
Common encryption (CENC) in ISO base media file format files (ISOBMFF) ISO/IEC 23001-7 standard
Common encryption (CENC) of MPEG-2 transport streams (MPEG-2 TS) ISO/IEC 23001-9 standard
This basedrm class does license management and other common activities to enable DRM management systems to decrypt the encrypted audio / video samples.
The subclass is responsible for providing pad template caps for
source and sink pads. The pads need to be named "sink" and "src".
DRM subsystem should do in place decryption so that input and output buffer are same.
gstbasedrm class will not implement any default methods therefore all necessary methods required for DRM management should be implemented by derived class.
We have developed and tested this plugin in STMicroelectronics for DRM playback on our HW platform. This class has been tested on STB platform using latest gstreamer baseline for DASH / MSS and HLS streaming playback of PlayReady protected data. gstreamer patches for CENC support in gstreamer for MSS and HLS (in mpegts ) have been developed in ST for CENC encrypted PlayReady streams.
This BaseDRM class has also been tested using clear key DRM in native gstreamer with CENC encrypted DASH streams with clearkey mechanism.
~~**Patch 320610**~~, "basedrm patch":
[0001-basedrm-base-drm-class-based-on-CENC-common-encrypti.patch](/uploads/f6a8304277dfb4133d6a7e80583d2e6e/0001-basedrm-base-drm-class-based-on-CENC-common-encrypti.patch)
### See also
* https://bugs.webkit.org/show_bug.cgi?id=154235https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/348dashdemux: tests: added tests for live streams2021-09-24T14:34:04ZBugzilla Migration Userdashdemux: tests: added tests for live streams## Submitted by Florin Apostol
**[Link to original bug (#762149)](https://bugzilla.gnome.org/show_bug.cgi?id=762149)**
## Description
Add various tests for testing dash demux behavior while playing live streams## Submitted by Florin Apostol
**[Link to original bug (#762149)](https://bugzilla.gnome.org/show_bug.cgi?id=762149)**
## Description
Add various tests for testing dash demux behavior while playing live streamshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/349dashdemux: tests: add tests for clock drift compensation2021-09-24T14:34:06ZBugzilla Migration Userdashdemux: tests: add tests for clock drift compensation## Submitted by Florin Apostol
**[Link to original bug (#762150)](https://bugzilla.gnome.org/show_bug.cgi?id=762150)**
## Description
add several tests to check the clock drift compensation support from dashdemux## Submitted by Florin Apostol
**[Link to original bug (#762150)](https://bugzilla.gnome.org/show_bug.cgi?id=762150)**
## Description
add several tests to check the clock drift compensation support from dashdemuxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/350[PLUGIN-MOVE] chromaprint from -bad to -good2021-09-24T14:34:06ZBugzilla Migration User[PLUGIN-MOVE] chromaprint from -bad to -good## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#762452)](https://bugzilla.gnome.org/show_bug.cgi?id=762452)**
## Description
What is needed in order to move this plugin to -good?## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#762452)](https://bugzilla.gnome.org/show_bug.cgi?id=762452)**
## Description
What is needed in order to move this plugin to -good?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/353dashdemux: fails to download initialisation segment when switching bitrates2021-09-24T14:34:07ZBugzilla Migration Userdashdemux: fails to download initialisation segment when switching bitrates## Submitted by A Ashley
**[Link to original bug (#762933)](https://bugzilla.gnome.org/show_bug.cgi?id=762933)**
## Description
Occasionally dashdemux switches bitrates but fails to download the initialisation segment for the new bi...## Submitted by A Ashley
**[Link to original bug (#762933)](https://bugzilla.gnome.org/show_bug.cgi?id=762933)**
## Description
Occasionally dashdemux switches bitrates but fails to download the initialisation segment for the new bitrate. This typically causes the decoder that is downstream of dashdemux to produce numerous decode errors.
As an example, here is part of an HTTP access log:
2016-02-12T16:08:54.623Z/dash2/dash-multi-clear/video6/Header.m4s
2016-02-12T16:08:54.769Z/dash2/dash-multi-clear/audio1/4001040.m4s
2016-02-12T16:08:54.999Z/dash2/dash-multi-clear/video6/4001040.m4s
2016-02-12T16:08:57.831Z/dash2/dash-multi-clear/manifest.mpd
2016-02-12T16:08:58.952Z/dash2/dash-multi-clear/audio1/4001041.m4s
2016-02-12T16:09:02.151Z/dash2/dash-multi-clear/manifest.mpd
2016-02-12T16:09:02.754Z/dash2/dash-multi-clear/video4/4001041.m4s
2016-02-12T16:09:03.162Z/dash2/dash-multi-clear/audio1/4001042.m4s
2016-02-12T16:09:06.012Z/dash2/dash-multi-clear/video4/4001042.m4s
When switching from "video6" representation to the "video4" representation, it is not downloading video4/Header.m4s.
I have managed to produce a unit test that reproduces the problem, which I will attach to this ticket. I have not yet managed to work out why it is going wrong, but I suspect it is related to the manifest refresh, which is set to happen after every segment.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/354checksumsink: Add ability to checksum video planes2021-09-24T14:34:08ZBugzilla Migration Userchecksumsink: Add ability to checksum video planes## Submitted by Scott D Phillips `@scott-ph`
**[Link to original bug (#763006)](https://bugzilla.gnome.org/show_bug.cgi?id=763006)**
## Description
Enhance checksumsink to optionally generate checksums of individual video planes. Th...## Submitted by Scott D Phillips `@scott-ph`
**[Link to original bug (#763006)](https://bugzilla.gnome.org/show_bug.cgi?id=763006)**
## Description
Enhance checksumsink to optionally generate checksums of individual video planes. These per-plane checksums can be used as a validation aid with H.265 streams which contain decoded_picture_hash SEI messages.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/355avfvideosrc: h264 support, optimize latency2021-09-24T14:34:08ZBugzilla Migration Useravfvideosrc: h264 support, optimize latency## Submitted by Joe Gorse
**[Link to original bug (#763011)](https://bugzilla.gnome.org/show_bug.cgi?id=763011)**
## Description
I would like to add h264 output support to the avfvidesrc element (i.e. the AVFoundation Session within...## Submitted by Joe Gorse
**[Link to original bug (#763011)](https://bugzilla.gnome.org/show_bug.cgi?id=763011)**
## Description
I would like to add h264 output support to the avfvidesrc element (i.e. the AVFoundation Session within it) in order to improve the encode/decode latency. When using vtenc_h264 and vtdec_hw, the total pipeline latency is increased 200 ms (~6 frames). I am still new to how GStreamer manages buffers and all this, though in a direct application using native API's I'd expect 2-4 frames of additional latency for h.264 encoding and decoding for real-time streaming.
The following pipelines were used for these measurements:
# With vtenc/vtdec and realtime settings
gst-launch-1.0 avfvideosrc device-index=0 ! "video/x-raw(memory:GLMemory),width=1280,height=720" ! gldownload qos=true ! vtenc_h264 realtime=true allow-frame-reordering=false ! vtdec_hw ! glimagesink
latency = 366 ms
# Without vtenc/vtdec
gst-launch-1.0 avfvideosrc device-index=0 ! "video/x-raw(memory:GLMemory),width=1280,height=720" ! glimagesink
latency = 166 mshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/356Fix the bug when live streaming a MPD consists of multiple periods2021-09-24T14:34:08ZBugzilla Migration UserFix the bug when live streaming a MPD consists of multiple periods## Submitted by WeiChungChang
**[Link to original bug (#763205)](https://bugzilla.gnome.org/show_bug.cgi?id=763205)**
## Description
Created attachment 323233
patch to fix claimed issue
Dear all:
I found that currently i...## Submitted by WeiChungChang
**[Link to original bug (#763205)](https://bugzilla.gnome.org/show_bug.cgi?id=763205)**
## Description
Created attachment 323233
patch to fix claimed issue
Dear all:
I found that currently if a "live" DASH streaming with a MPD consists of "multiple periods", it cannot advance to next period once the we have completed the first period.
For example, in attached MPD there are 2 periods. Once we have done the first period (have played out 5 minutes content), we can never arrive the 2nd period.
It is because we never call gst_adaptive_demux_advance_period()。
[Solution]:
Once all streams have reached the end of current period & there is a next period, we should advance to next period instead of merely waiting for manifest's update.
Patch is as attached, please kindly refer to it.
Thank you~
~~**Patch 323233**~~, "patch to fix claimed issue":
[0001-Fix-the-issue-of-live-streaming-with-multiple-period.patch](/uploads/c12b06ba9a0802b7d3a313c60c3b8d6f/0001-Fix-the-issue-of-live-streaming-with-multiple-period.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/357ahcsrc: failed to run repeated playing and paused actions2021-09-24T14:34:09ZBugzilla Migration Userahcsrc: failed to run repeated playing and paused actions## Submitted by Justin Kim `@joykim`
**[Link to original bug (#763308)](https://bugzilla.gnome.org/show_bug.cgi?id=763308)**
## Description
When "sync" property is set as "false", the pipeline seems to work well.
However, if sync ...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#763308)](https://bugzilla.gnome.org/show_bug.cgi?id=763308)**
## Description
When "sync" property is set as "false", the pipeline seems to work well.
However, if sync is true on sink element, the pipeline including ahcsrc fails to change state to PLAYING.
Reproducible sequence:
- Run android camera example apps (#760963) - need to confirm sync property is true
- Repeat click paused and play
Then
- Cannot transit to playing state
Tested on Nexus 5x and LG V410 (I am not sure if this error is occurred in other devices)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/359dash: Fix the bug when inheriting segmentbase, segmentTemplate or segmentList...2021-09-24T14:34:09ZBugzilla Migration Userdash: Fix the bug when inheriting segmentbase, segmentTemplate or segmentList from grandparent## Submitted by WeiChungChang
**[Link to original bug (#763454)](https://bugzilla.gnome.org/show_bug.cgi?id=763454)**
## Description
Created attachment 323611
proposed solution
Fix the bug when inheriting SegmentBase, Segment...## Submitted by WeiChungChang
**[Link to original bug (#763454)](https://bugzilla.gnome.org/show_bug.cgi?id=763454)**
## Description
Created attachment 323611
proposed solution
Fix the bug when inheriting SegmentBase, SegmentTemplate and SegmentList from upper layer.
The detail is given in the attached = report.
The issued MPD is also given in the attached.
Also a proposed patch is given.
A brief description is as below but for the detail, please refer to report.
From the attached MPD, it is expected to generate resource URLs by the SegmentTemplate table below. Unfortunately, it is not so now. For current Gstmpdparser we will get illegal address & make playback fail.
The root cause is:
Firstly We call gst_mpdparser_parse_period_node() and store the result in struct GstSegmentTemplateNode by calling gst_mpdparser_parse_segment_template_node().
Then we parse the children node and call gst_mpdparser_parse_adaptation_set_node().
At this time "SegmentTemplate" DOES NOT appear. So we have no chance to call gst_mpdparser_parse_segment_template_node(). As the result, the adaption set carries no info about "SegmentTemplate".
Finally, we parse the representation node but parent->SegmentTemplate is NULL (parent = adaption set). So representation node’s SegmentTemplate inherits nothing and only with timescale from itself.
As the result, the generated stream->cur_seg_template will only have timescale as the logic below. It misses the attribute of @index and @ initialization so we CANNOT generate a legal URL address.
[Proposed solution]
From the description above, the root cause is that we only do inherit from “parent”. However, if the desired attribute exists at the grandparent (as period’s role to representation), we will get miss.
The spec says:
“…SegmentBase, SegmentTemplate and SegmentList shall inherit attributes and elements from the same element on a higher level. If the same attribute or element is present on both levels, the one on the lower level shall take precedence over the one on the higher level. …”
According to the spec, the proposed solution is:
When we parse an adaption set and find that either one of the three elements = [ SegmentBase, SegmentTemplate and SegmentList ] DOES NOT exist but the parent (period node) holds one, we FORCE to inherit the element from period node.
**Patch 323611**, "proposed solution":
[0001-Fix-the-issue-of-inheriting-segmentbase-segmentTempl.patch](/uploads/cfa18e66c55be94f2a49498f228d7bc6/0001-Fix-the-issue-of-inheriting-segmentbase-segmentTempl.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/360gst_element_query_position doesn't always return the right frame number2021-09-24T14:34:10ZBugzilla Migration Usergst_element_query_position doesn't always return the right frame number## Submitted by Gregoire
**[Link to original bug (#763522)](https://bugzilla.gnome.org/show_bug.cgi?id=763522)**
## Description
Created attachment 323743
Log amc*:6
This might not be a bug, I don't know. It seems that on some...## Submitted by Gregoire
**[Link to original bug (#763522)](https://bugzilla.gnome.org/show_bug.cgi?id=763522)**
## Description
Created attachment 323743
Log amc*:6
This might not be a bug, I don't know. It seems that on some rare occasions, gst_element_query_position returns the real frame number+1 or the real frame number-1.
My pipeline on Android 6.0.1 with gstreamer-1.7.90 is:
filesrc location=path ! queue ! decodebin ! queue ! identity ! glimagesink
On the identity element, I have a pad callback:
GstPad *pad = gst_element_get_static_pad(identity, "sink");
gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BUFFER, (GstPadProbeCallback)cb_have_data_0, data, NULL);
in which I do:
frameNbInc++;
gst_element_query_position(pipeline, GST_FORMAT_DEFAULT, &frameNb);
GST_DEBUG("%lld %lld %lld", frameNb, frameNbInc, frameNb - frameNbInc);
The debug log of amc*6 is attached.
On line 53 and 138, I have frameNb - frameNbInc == 1 while the delta between an internal incremental counter frameNbInc and the frame number returned by gst_element_query_position should be 2 and is 2 almost all the time.
The delta of -1 always happens after the "Queueing buffer", for instance lines 41 to 52, or lines 123 to 137.
Sometimes, the delta is +1 like on line 264. It seems that there was a race condition between line 263 and 264.
Is this a bug? Or how can I be sure to have gst_element_query_position to return the equivalent of an incremental number with the condition that the system is not late, aka. everything runs smoothly like in this trace.
**Attachment 323743**, "Log amc*:6":
[log](/uploads/16b9064192a204a87f76af817bc4a140/log)
Version: 1.7.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/361Internal dataflow error on GStreamer Android release 1.7.91 (Playing Avatar t...2021-09-24T14:34:10ZBugzilla Migration UserInternal dataflow error on GStreamer Android release 1.7.91 (Playing Avatar trailer L/R SBS from youtube)## Submitted by Barun Kumar Singh
**[Link to original bug (#763884)](https://bugzilla.gnome.org/show_bug.cgi?id=763884)**
## Description
Created attachment 324290
*:4 debug log
Playback using playbin failed due to internal da...## Submitted by Barun Kumar Singh
**[Link to original bug (#763884)](https://bugzilla.gnome.org/show_bug.cgi?id=763884)**
## Description
Created attachment 324290
*:4 debug log
Playback using playbin failed due to internal data flow error (Possibly hardware codec failed) on Android 4.1.3 Samsung phone.
**Attachment 324290**, "*:4 debug log":
[gst.log](/uploads/bad25fa3a4cce0170cb3671222bdbcbd/gst.log)
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/362dvb: Requires unescaped, invalid URIs2021-09-24T14:34:10ZBugzilla Migration Userdvb: Requires unescaped, invalid URIs## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#763910)](https://bugzilla.gnome.org/show_bug.cgi?id=763910)**
## Description
See https://lists.freedesktop.org/archives/gstreamer-devel/2016-March/057311.html
U...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#763910)](https://bugzilla.gnome.org/show_bug.cgi?id=763910)**
## Description
See https://lists.freedesktop.org/archives/gstreamer-devel/2016-March/057311.html
URIs should always be escaped, i.e. spaces become` %20`, e.g. with the GstUri API. dvbsrc should convert them to whatever format it needs then.
For backwards compat reasons we should probably still allow broken URIs in dvb, but also handle proper ones.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/364h264parse removes padding from byte streams2021-09-24T14:34:11ZBugzilla Migration Userh264parse removes padding from byte streams## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding ...## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding bytes from the original h264 stream. Producing a real constant bitrate is then not possible anymore.
This can be reproduced with the following command line (you need 10Bit libx264):
# gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080,format=I422_10LE,framerate=25/1 ! x264enc trellis=false option-string=avcintra-class=100 ! video/x-h264,stream-format=byte-stream ! h264parse ! mpegtsmux ! filesink location=test.ts
Every frame should then have exactly 568832 bytes. But checking the file test.ts with ffprobe gives different frame sizes for every frame. The frames sizes can be checked with:
# ffprobe -show_frames test.ts | grep pkt_size
Removing the "h264parse" element from the above pipeline and checking the frame sizes gives the expected size of 568832 bytes for every frame.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/365RTMP send error 32 on Android2021-09-24T14:34:11ZBugzilla Migration UserRTMP send error 32 on Android## Submitted by Mimmo Grottoli
**[Link to original bug (#764471)](https://bugzilla.gnome.org/show_bug.cgi?id=764471)**
## Description
I'm trying to broadcast video and audio via rtmp from different Android devices, and I'm always ge...## Submitted by Mimmo Grottoli
**[Link to original bug (#764471)](https://bugzilla.gnome.org/show_bug.cgi?id=764471)**
## Description
I'm trying to broadcast video and audio via rtmp from different Android devices, and I'm always getting the following errors:
GStreamer+rtmp E 0:00:05.353780468 0x9f9496f0 :0: WriteN, RTMP send error 32 (136 bytes)
E 0:00:05.353919322 0x9f9496f0 :0: WriteN, RTMP send error 32 (54 bytes)
E 0:00:05.354330259 0x9f9496f0 :0: WriteN, RTMP send error 9 (42 bytes)
GStreamer+rtmpsink W 0:00:05.354410363 0x9f9496f0 gstrtmpsink.c:286:gst_rtmp_sink_render:`<rtmpsink0>` error: Failed to write data
I've tried using wowza and youtube as endpoint, but the error is exactly the same.
The pipeline is:
ahcsrc name=cam ! video/x-raw, width=1280, height=720, framerate=(fraction)24/1 \
! videoconvert \
! amcvidenc-omxqcomvideoencoderavc i-frame-interval=24 \
! h264parse \
! tee name=videoTee \
openslessrc ! audioconvert ! queue ! voaacenc \
! tee name=audioTee \
flvmux streamable=true name=flvmux \
! rtmpsink location=\"rtmp://RTMP_HOST:PORT\" \
videoTee. ! queue ! flvmux. \
audioTee. ! queue ! flvmux.
Note:
1) The issue does not happen when I use audiotestsrc instead of openslessrc as audiosource
2) If I remove the audio part from the pipeline the result is good too
3) If I replace flvmux + rtmpsink with mpegtsmux + udpsink I can publish the stream
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/366dashdemux: apply suggestedPresentationDelay to seek and seek range2021-09-24T14:34:11ZBugzilla Migration Userdashdemux: apply suggestedPresentationDelay to seek and seek range## Submitted by Wojciech Przybyl
**[Link to original bug (#764728)](https://bugzilla.gnome.org/show_bug.cgi?id=764728)**
## Description
When seeking or querying a range of seek on a live stream,
suggestedPresentationDelay has to b...## Submitted by Wojciech Przybyl
**[Link to original bug (#764728)](https://bugzilla.gnome.org/show_bug.cgi?id=764728)**
## Description
When seeking or querying a range of seek on a live stream,
suggestedPresentationDelay has to be taken into account. Currently
it is only used in streams setup. As a result seeking to live position
discards suggestedPresentationDelay and seeks to earlier time than allowed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/367decklink: Make audio bit depth configurable by property2021-09-24T14:34:12ZBugzilla Migration Userdecklink: Make audio bit depth configurable by property## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765248)](https://bugzilla.gnome.org/show_bug.cgi?id=765248)**
## Description
+++ This bug was initially created as a clone of [Bug 742878](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765248)](https://bugzilla.gnome.org/show_bug.cgi?id=765248)**
## Description
+++ This bug was initially created as a clone of [Bug 742878](https://bugzilla.gnome.org/show_bug.cgi?id=742878) +++
Same story as for 8 vs 10 bits / RGB vs YUV, etc.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/368player: Add support for (multiple) external subtitles2021-09-24T14:34:12ZBugzilla Migration Userplayer: Add support for (multiple) external subtitles## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765305)](https://bugzilla.gnome.org/show_bug.cgi?id=765305)**
## Description
See https://github.com/sdroege/gst-player/issues/86
This can probably be implemente...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765305)](https://bugzilla.gnome.org/show_bug.cgi?id=765305)**
## Description
See https://github.com/sdroege/gst-player/issues/86
This can probably be implemented easier with decodebin3/playbin3.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/369player: Add support for navigation interface (switching DVD angles, etc)2021-09-24T14:34:12ZBugzilla Migration Userplayer: Add support for navigation interface (switching DVD angles, etc)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765306)](https://bugzilla.gnome.org/show_bug.cgi?id=765306)**
## Description
See https://github.com/sdroege/gst-player/issues/87## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765306)](https://bugzilla.gnome.org/show_bug.cgi?id=765306)**
## Description
See https://github.com/sdroege/gst-player/issues/87https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/370player: Add support for chapters / TOC2021-09-24T14:34:13ZBugzilla Migration Userplayer: Add support for chapters / TOC## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765307)](https://bugzilla.gnome.org/show_bug.cgi?id=765307)**
## Description
See https://github.com/sdroege/gst-player/issues/88## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765307)](https://bugzilla.gnome.org/show_bug.cgi?id=765307)**
## Description
See https://github.com/sdroege/gst-player/issues/88https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/371player: Add streaming/download streaming support2021-09-24T14:34:14ZBugzilla Migration Userplayer: Add streaming/download streaming support## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765308)](https://bugzilla.gnome.org/show_bug.cgi?id=765308)**
## Description
See https://github.com/sdroege/gst-player/issues/89## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765308)](https://bugzilla.gnome.org/show_bug.cgi?id=765308)**
## Description
See https://github.com/sdroege/gst-player/issues/89https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/372player: Handle rotation2021-09-24T14:34:13ZBugzilla Migration Userplayer: Handle rotation## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765309)](https://bugzilla.gnome.org/show_bug.cgi?id=765309)**
## Description
See https://github.com/sdroege/gst-player/issues/90
### Depends on
* [Bug 768687](htt...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765309)](https://bugzilla.gnome.org/show_bug.cgi?id=765309)**
## Description
See https://github.com/sdroege/gst-player/issues/90
### Depends on
* [Bug 768687](https://bugzilla.gnome.org/show_bug.cgi?id=768687)
* [Bug 769147](https://bugzilla.gnome.org/show_bug.cgi?id=769147)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/373player: Handle zoom/crop & forced aspect ratio2021-09-24T14:34:15ZBugzilla Migration Userplayer: Handle zoom/crop & forced aspect ratio## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765310)](https://bugzilla.gnome.org/show_bug.cgi?id=765310)**
## Description
See https://github.com/sdroege/gst-player/issues/91 and https://github.com/sdroege/gst-p...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765310)](https://bugzilla.gnome.org/show_bug.cgi?id=765310)**
## Description
See https://github.com/sdroege/gst-player/issues/91 and https://github.com/sdroege/gst-player/issues/92https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/374player: Provide better error messages and error handling2021-09-24T14:34:15ZBugzilla Migration Userplayer: Provide better error messages and error handling## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765311)](https://bugzilla.gnome.org/show_bug.cgi?id=765311)**
## Description
See https://github.com/sdroege/gst-player/issues/93 and https://bugzilla.gnome.org/show_...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765311)](https://bugzilla.gnome.org/show_bug.cgi?id=765311)**
## Description
See https://github.com/sdroege/gst-player/issues/93 and https://bugzilla.gnome.org/show_bug.cgi?id=756806
### Depends on
* [Bug 756806](https://bugzilla.gnome.org/show_bug.cgi?id=756806)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/375player: Handle authentication2021-09-24T14:34:16ZBugzilla Migration Userplayer: Handle authentication## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765312)](https://bugzilla.gnome.org/show_bug.cgi?id=765312)**
## Description
See https://github.com/sdroege/gst-player/issues/94
This probably also should get s...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765312)](https://bugzilla.gnome.org/show_bug.cgi?id=765312)**
## Description
See https://github.com/sdroege/gst-player/issues/94
This probably also should get some API improvements in the lower layers, like an authentication interface.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/376player: Provide more control over deinterlacing2021-09-24T14:34:16ZBugzilla Migration Userplayer: Provide more control over deinterlacing## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765313)](https://bugzilla.gnome.org/show_bug.cgi?id=765313)**
## Description
See https://github.com/sdroege/gst-player/issues/95
### Depends on
* [Bug 675305](htt...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765313)](https://bugzilla.gnome.org/show_bug.cgi?id=765313)**
## Description
See https://github.com/sdroege/gst-player/issues/95
### Depends on
* [Bug 675305](https://bugzilla.gnome.org/show_bug.cgi?id=675305)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/377player: Add logo mode2021-09-24T14:34:16ZBugzilla Migration Userplayer: Add logo mode## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765316)](https://bugzilla.gnome.org/show_bug.cgi?id=765316)**
## Description
See https://github.com/sdroege/gst-player/issues/99
This seems useful as it's a com...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765316)](https://bugzilla.gnome.org/show_bug.cgi?id=765316)**
## Description
See https://github.com/sdroege/gst-player/issues/99
This seems useful as it's a common requirement for players and other not too trivial to implement.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/378player: Add micro-libraries with GTK/Qt/QML/Android/iOS/OSX/Windows integration2021-09-24T14:34:17ZBugzilla Migration Userplayer: Add micro-libraries with GTK/Qt/QML/Android/iOS/OSX/Windows integration## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765318)](https://bugzilla.gnome.org/show_bug.cgi?id=765318)**
## Description
For QML there is code here: https://github.com/sdroege/gst-player/tree/master/qt
Fo...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765318)](https://bugzilla.gnome.org/show_bug.cgi?id=765318)**
## Description
For QML there is code here: https://github.com/sdroege/gst-player/tree/master/qt
For GTK there is code here: https://github.com/sdroege/gst-player/tree/master/gtk
For Android there are JNI bindings here: https://github.com/sdroege/gst-player/tree/master/android but these would ideally be autogenerated (see https://github.com/sdroege/gst-player/issues/39 )
This is more of a tracker bug and finding a general plan for handling these, specific platforms should be handled in new bugs.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/379h264parse: Fails to parse HRD parameters in SPS that ffmpeg accepts just fine2021-09-24T14:34:17ZBugzilla Migration Userh264parse: Fails to parse HRD parameters in SPS that ffmpeg accepts just fine## Submitted by Nicola `@drakkan`
**[Link to original bug (#765365)](https://bugzilla.gnome.org/show_bug.cgi?id=765365)**
## Description
Please try this pipeline using the provided public url
gst-launch-1.0 -vmt rtspsrc locatio...## Submitted by Nicola `@drakkan`
**[Link to original bug (#765365)](https://bugzilla.gnome.org/show_bug.cgi?id=765365)**
## Description
Please try this pipeline using the provided public url
gst-launch-1.0 -vmt rtspsrc location="rtspt://admin:q1w2e3r4t5y6@93.63.189.11:45433/onvif/profile5/media.smp" ! rtph264depay ! h264parse ! matroskamux ! fakesink silent=false
you'll get a not negotiated error from rtspsrc
if you remove matroskamux h264parse probably works in passthrough mode and the stream can be playedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/381x265enc: problem with framerate=0/1 when re-encoding from rtp2021-09-24T14:34:19ZBugzilla Migration Userx265enc: problem with framerate=0/1 when re-encoding from rtp## Submitted by jav..@..il.com
**[Link to original bug (#765549)](https://bugzilla.gnome.org/show_bug.cgi?id=765549)**
## Description
Hello!
I'm receiving a raw RTP stream as an input and I wanted to encode it and streaming it...## Submitted by jav..@..il.com
**[Link to original bug (#765549)](https://bugzilla.gnome.org/show_bug.cgi?id=765549)**
## Description
Hello!
I'm receiving a raw RTP stream as an input and I wanted to encode it and streaming it again through RTP.
I was using this command to do it encoding to h264 and it was working just great:
gst-launch-1.0 udpsrc port=9001 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)1280, height=(string)960, framerate=25/1, payload=(int)111" ! rtpvrawdepay ! x264enc bitrate=16384 ! rtph264pay ! udpsink host=127.0.0.1 port=1234
Now, i'm trying to encode to h265 and everything just stopped working. The command i'm using is:
gst-launch-1.0 udpsrc port=9001 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)4096, height=(string)2048, framerate=30/1, payload=(int)111" ! rtpvrawdepay ! x265enc bitrate=16384 ! rtph265pay ! udpsink host=127.0.0.1 port=1234
But now everything just stopped working and it returns:
"Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = "application/x-rtp\,\ media\=\(string\)video\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)RAW\,\ sampling\=\(string\)YCbCr-4:2:0\,\ depth\=\(string\)8\,\ width\=\(string\)4096\,\ height\=\(string\)2048\,\ framerate\=\(fraction\)30/1\,\ payload\=\(int\)111"
Setting pipeline to PLAYING ...
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)4096\,\ height\=\(int\)2048\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt709\,\ framerate\=\(fraction\)0/1"
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstX265Enc:x265enc0: Can not initialize x265 encoder.
Additional debug info:
gstx265enc.c(700): gst_x265_enc_init_encoder (): /GstPipeline:pipeline0/GstX265Enc:x265enc0
Execution ended after 0:00:00.000055373
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ..."
Everything looks okay appart the framerate that is set to 0 (variable). Do you have any idea of what could be happening?
Thanks.
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/383sdpdemux/src: Add property for specifying multicast-interface2021-09-24T14:34:19ZBugzilla Migration Usersdpdemux/src: Add property for specifying multicast-interface## Submitted by Julien Paixao
**[Link to original bug (#765925)](https://bugzilla.gnome.org/show_bug.cgi?id=765925)**
## Description
Created attachment 327199
SDP file
On a server RTP multicast streaming can be started, and t...## Submitted by Julien Paixao
**[Link to original bug (#765925)](https://bugzilla.gnome.org/show_bug.cgi?id=765925)**
## Description
Created attachment 327199
SDP file
On a server RTP multicast streaming can be started, and the information about the stream are inside an SDP file.
This file is available for HTTP downloading and contains the following information:
- multicast RTP stream using G711u (see attachment).
On a client the following pipeline is used for playback:
gst-launch-1.0 -vv souphttpsrc location=http://`<ip>`:`<port>`/test.sdp ! sdpdemux ! decodebin ! audioconvert ! alsasink
On client side there is only one network device/interface (eth0).
The pipeline ends up with an error linked to the fact that the multicast IP could not be set correctly. Please find in attachment the debug log with GST_DEBUG=udpsrc:6.
**Attachment 327199**, "SDP file":
[test.sdp](/uploads/efa9e33eb2a0fa44e0f5837f376daa3b/test.sdp)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/384player: Add missing-plugin API2021-09-24T14:34:20ZBugzilla Migration Userplayer: Add missing-plugin API## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765934)](https://bugzilla.gnome.org/show_bug.cgi?id=765934)**
## Description
See https://github.com/sdroege/gst-player/pull/11## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765934)](https://bugzilla.gnome.org/show_bug.cgi?id=765934)**
## Description
See https://github.com/sdroege/gst-player/pull/11https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/385adaptivedemux: Provide API for being able to set properties on internal HTTP ...2021-09-24T14:34:20ZBugzilla Migration Useradaptivedemux: Provide API for being able to set properties on internal HTTP (and other) sources## Submitted by pot..@..ty.com
**[Link to original bug (#765986)](https://bugzilla.gnome.org/show_bug.cgi?id=765986)**
## Description
I hope you will forgive me that I'm not good at English.
I have been using the version 1.8.0 ...## Submitted by pot..@..ty.com
**[Link to original bug (#765986)](https://bugzilla.gnome.org/show_bug.cgi?id=765986)**
## Description
I hope you will forgive me that I'm not good at English.
I have been using the version 1.8.0 of gstreamer.
Now, I am building a pipeline to play the Http Live Streaming(HLS) video.
the http protocol can play on this pipeline.
gst-launch-1.0 souphttpsrc location=http://path/to/hls.m3u8 ! decodebin ! videoconvert ! autovideosink
but, https protocol can't play.
gst-launch-1.0 souphttpsrc ssl-strict=false location=https://path/to/hls.m3u8 ! decodebin ! videoconvert ! autovideosink
By the way, in the case of the mp4 can be played on http protocol.
gst-launch-1.0 souphttpsrc ssl-strict=false location=https://path/to/movie.mp4 ! decodebin ! videoconvert ! autovideosink
Please pointed out if there is a mistake to building a pipeline.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/386jifmux fails to find EOI if it's not within the last 5 bytes2021-09-24T14:34:21ZBugzilla Migration Userjifmux fails to find EOI if it's not within the last 5 bytes## Submitted by Mohammed Sameer
**[Link to original bug (#766010)](https://bugzilla.gnome.org/show_bug.cgi?id=766010)**
## Description
The attached image makes jifmux barf with the following pipeline:
GST_DEBUG='*:2' gst-launch...## Submitted by Mohammed Sameer
**[Link to original bug (#766010)](https://bugzilla.gnome.org/show_bug.cgi?id=766010)**
## Description
The attached image makes jifmux barf with the following pipeline:
GST_DEBUG='*:2' gst-launch-1.0 filesrc num-buffers=1 blocksize=4299656 location=1462395350.jpg ! 'image/jpeg' ! jifmux ! filesink location=foo.jpg
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
0:00:00.027655752 10721 0x872c290 WARN jifmux gstjifmux.c:341:gst_jif_mux_parse_image:`<jifmux0>` Couldn't find an EOI marker
0:00:00.027717421 10721 0x872c290 WARN jifmux gstjifmux.c:371:gst_jif_mux_parse_image:`<jifmux0>` Error parsing image header (need more that 0 bytes available)
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
It seems EOI marker is not present within the last 5 bytes thus jifmux fails to find it.
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/387android: Implement a video sink that provides an android.view.View2021-09-24T14:34:23ZBugzilla Migration Userandroid: Implement a video sink that provides an android.view.View## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#766044)](https://bugzilla.gnome.org/show_bug.cgi?id=766044)**
## Description
Similar to gtk(gl)sink, caopengllayersink, qmlvideosink. This could provide a simple sub...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#766044)](https://bugzilla.gnome.org/show_bug.cgi?id=766044)**
## Description
Similar to gtk(gl)sink, caopengllayersink, qmlvideosink. This could provide a simple subclass of android.opengl.GLSurfaceView (which can create the GL context and everything for us), and then share its own GL context with the pipeline context.
As it requires some Java/JNI code, this should be in the androidmedia plugin.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/388video decoding issue with mp4 container (Android playback)2021-09-24T14:34:23ZBugzilla Migration Uservideo decoding issue with mp4 container (Android playback)## Submitted by Gregoire
**[Link to original bug (#766201)](https://bugzilla.gnome.org/show_bug.cgi?id=766201)**
## Description
Summary: The presence of audio in an mp4 audio/video file confused typefind and decodebin to the point t...## Submitted by Gregoire
**[Link to original bug (#766201)](https://bugzilla.gnome.org/show_bug.cgi?id=766201)**
## Description
Summary: The presence of audio in an mp4 audio/video file confused typefind and decodebin to the point that the pipeline can't find the video decoder plugin.
I have two videos generated by gstreamer-0.10 on an embedded device. The same video encoder is used in both cases:
[1] video/videov.mp4 has only a h264 track. mp4info video/videov.mp4 reports:
videov.mp4:
Track Type Info
1 video H264 Baseline@4, 7.716 secs, 16614 kbps, 1280x1440 @ 50.155521 fps
[2] videoaudio/videov.mp4 has a h264 track and a mp3 track. mp4info videoaudio/videov.mp4 reports:
videov.mp4:
Track Type Info
1 video H264 Baseline@4, 7.199 secs, 16614 kbps, 1280x1440 @ 50.145854 fps
2 audio MPEG-1 Audio (11172-3), 7.176 secs, 48 kbps, 24000 Hz
The two files are provided here: http://gentil.com/tmp/samples.zip
I play both files on a PixelC Android 6.x tablet with gstreamer 1.7.91. Note that I have the same issue on Nexus 5x. The two pipeplines are:
[1] video/videov.mp4
filesrc location=/storage/emulated/0/aiTennis3D/video/videov.mp4 ! qtdemux name=q q.video_0 ! queue ! decodebin name=forhwgl ! queue ! identity name=forhalffps ! glimagesink force-aspect-ratio=false
[2] videoaudio/videov.mp4
filesrc location=/storage/emulated/0/aiTennis3D/videoaudio/videov.mp4 ! qtdemux name=q q.video_0 ! queue ! decodebin name=forhwgl ! queue ! identity name=forhalffps ! glimagesink force-aspect-ratio=false q.audio_0 ! queue ! decodebin ! queue ! autoaudiosink
When playing the video only file, there is no problem. log log-video.zip is attached.
When playing the video/audio file, gstreamer can't find the video decoder plugin. The log log-videoaudio.zip is attached.
A few additional notes:
- amcviddec-omxnvidiah264decode doesn't seem to be instantiated in the second case.
- The problem is the same with a simple playbin pipeline.
- If I replace decodebin by "h264parse ! amcviddec-omxnvidiah264decode", it's working.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/389kmssink: add libdrm in gst-libs/ext2021-09-24T14:34:24ZBugzilla Migration Userkmssink: add libdrm in gst-libs/ext## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#766468)](https://bugzilla.gnome.org/show_bug.cgi?id=766468)**
## Description
It would be nice to add libdrm/libkms in gst-libs/ext so the users won't nee...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#766468)](https://bugzilla.gnome.org/show_bug.cgi?id=766468)**
## Description
It would be nice to add libdrm/libkms in gst-libs/ext so the users won't need to have installed it in their systems (small embedded systems), also we could add particular hacks there for specific SoCs.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/391androidmedia: Reverse Play2021-09-24T14:34:24ZBugzilla Migration Userandroidmedia: Reverse Play## Submitted by Andy Devar
**[Link to original bug (#766514)](https://bugzilla.gnome.org/show_bug.cgi?id=766514)**
## Description
Reverse play (negative rates) do not work with androidmedia.
Application: https://cgit.freede...## Submitted by Andy Devar
**[Link to original bug (#766514)](https://bugzilla.gnome.org/show_bug.cgi?id=766514)**
## Description
Reverse play (negative rates) do not work with androidmedia.
Application: https://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/android-tutorial-5
To change to reverse direction, I added the following code:
/* Send seek event to change rate */
static void send_seek_event (CustomData *data) {
gint64 position;
GstEvent *seek_event;
/* Obtain the current position, needed for the seek event */
if (!gst_element_query_position (data->pipeline, GST_FORMAT_TIME, &position)) {
GST_DEBUG ("Unable to retrieve current position.\n");
return;
}
/* Get video sink */
if (data->video_sink == NULL) {
// If we have not done so, obtain the sink through which we will send the seek events
g_object_get (data->pipeline, "video-sink", &data->video_sink, NULL);
}
/* Create the seek event */
if (data->rate > 0) {
gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE,
GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_NONE, 0);
} else {
gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE | GST_SEEK_FLAG_TRICKMODE_KEY_UNITS | GST_SEEK_FLAG_TRICKMODE_NO_AUDIO,
GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_SET, position);
}
GST_DEBUG ("Current rate: %g\n", data->rate);
}
static void gst_native_change_direction (JNIEnv* env, jobject thiz) {
CustomData *data = GET_CUSTOM_DATA (env, thiz, custom_data_field_id);
if (!data) return;
data->rate *= -1.0;
send_seek_event (data);
}
As in the original tutorial-5, I use playbin:
data->pipeline = gst_parse_launch("playbin", &error);
Results:
1. With androidmedia:
a) Forward play (rate=1):
Videos play smoothly (tried up to 1980x800) regardless of GOP size.
b) Reverse play (rate=-1):
A new frame is displayed only every few seconds. Eventually, video stops to play.
Same behavior regardless of resolution (even with 320x132) and GOP size (tried dynamic, 5 and 1).
CPU utilisation is no higher than with forward play, so I assume hardware acceleration is also used with reverse play.
2. Without androidmedia (commented out in plugins.mk):
(just for comparison - meets my expectation)
a) Forward play (rate=1):
1280x532, dynamic GOP size: Smooth
1280x532, GOP size 1: Smooth
640x266, dynamic GOP size: Smooth
640x266, GOP size 1: Smooth
b) Reverse play (rate=-1):
1280x532, dynamic GOP size: Choppy
1280x532, GOP size 1: Choppy
640x266, GOP size 1: Smooth
640x266, dynamic GOP size: Choppy
The video I used can be downloaded here:
http://www.dvdloc8.com/clip.php?movieid=12167&clipid=3
To create other resolutions/GOP sizes, I used FFMPEG.
Example (GOP size 1, resolution 640x266):
ffmpeg -i "The Simpsons Movie - 1080p Trailer.mp4" -g 1 scale=640:266 "The Simpsons Movie - 1080p Trailer_GOP0001_640.mp4"
Hardware: Lenovo Tab2 A10/30
Qualcomm APQ8009
Android 5.1.1
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/393opencv: add cvclahe element to apply adaptive histogram equalization2021-09-24T14:34:25ZBugzilla Migration Useropencv: add cvclahe element to apply adaptive histogram equalization## Submitted by Joshua M. Doe
**[Link to original bug (#766865)](https://bugzilla.gnome.org/show_bug.cgi?id=766865)**
## Description
Created attachment 328507
patch adding cvclahe element
Patch attached which adds cvclahe, an...## Submitted by Joshua M. Doe
**[Link to original bug (#766865)](https://bugzilla.gnome.org/show_bug.cgi?id=766865)**
## Description
Created attachment 328507
patch adding cvclahe element
Patch attached which adds cvclahe, an OpenCV element which applies contrast limited adaptive histogram equalization (https://en.wikipedia.org/wiki/Adaptive_histogram_equalization) to RGB, GRAY8, and GRAY16_LE video.
This is useful to bring out detail in high dynamic range scenes. While it provides interesting results in RGB and GRAY8, it is most useful in GRAY16_LE video.
**Patch 328507**, "patch adding cvclahe element":
[0001-opencv-add-new-element-cvclahe-to-apply-CLAHE-to-16-.patch](/uploads/7638c1babee8919a4f75b0757e5765d8/0001-opencv-add-new-element-cvclahe-to-apply-CLAHE-to-16-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/395openslessink: unconditionnally exposes volume and mute properties even if not...2021-09-24T14:34:25ZBugzilla Migration Useropenslessink: unconditionnally exposes volume and mute properties even if not supported## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767066)](https://bugzilla.gnome.org/show_bug.cgi?id=767066)**
## Description
I have openslessink element in my android app, but setting the "mute" property does ...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767066)](https://bugzilla.gnome.org/show_bug.cgi?id=767066)**
## Description
I have openslessink element in my android app, but setting the "mute" property does nothing. It is probably not always supported by the hw? Or it's just simply broken?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/396mpegtsmux: Set DTS on generated buffers2021-09-24T14:34:25ZBugzilla Migration Usermpegtsmux: Set DTS on generated buffers## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767332)](https://bugzilla.gnome.org/show_bug.cgi?id=767332)**
## Description
+++ This bug was initially created as a clone of [Bug 765926](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767332)](https://bugzilla.gnome.org/show_bug.cgi?id=767332)**
## Description
+++ This bug was initially created as a clone of [Bug 765926](https://bugzilla.gnome.org/show_bug.cgi?id=765926) +++
Currently we only forward PTS
Version: 1.8.1
### Depends on
* [Bug 765926](https://bugzilla.gnome.org/show_bug.cgi?id=765926)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/397vtdec: Renegotiation from GL to sysmem to GL with playbin2021-09-24T14:34:26ZBugzilla Migration Uservtdec: Renegotiation from GL to sysmem to GL with playbin## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767429)](https://bugzilla.gnome.org/show_bug.cgi?id=767429)**
## Description
+++ This bug was initially created as a clone of [Bug 766611](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767429)](https://bugzilla.gnome.org/show_bug.cgi?id=767429)**
## Description
+++ This bug was initially created as a clone of [Bug 766611](https://bugzilla.gnome.org/show_bug.cgi?id=766611) +++
### Depends on
* [Bug 766611](https://bugzilla.gnome.org/show_bug.cgi?id=766611)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/398h264parse: Does not provide complete caps for alignment=nal in the beginning2021-09-24T14:34:26ZBugzilla Migration Userh264parse: Does not provide complete caps for alignment=nal in the beginning## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767778)](https://bugzilla.gnome.org/show_bug.cgi?id=767778)**
## Description
When h264parse e.g. reads a raw bytestream h264 file, and as output alignment=nal is req...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767778)](https://bugzilla.gnome.org/show_bug.cgi?id=767778)**
## Description
When h264parse e.g. reads a raw bytestream h264 file, and as output alignment=nal is requested, it will first provide caps like video/x-h264,stream-format=... but without width/height/profile/etc.
It seems like it does not wait until it received the PPS/SPS in this mode before providing caps and outputting data, which it probably should.
In practice this is causing negotiation errors if there is an element that wants nal alignment but also requires width/height to be known in caps.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/399decklinkvideosink: Add support for mixed interlace-mode2021-09-24T14:34:26ZBugzilla Migration Userdecklinkvideosink: Add support for mixed interlace-mode## Submitted by Dave
**[Link to original bug (#767779)](https://bugzilla.gnome.org/show_bug.cgi?id=767779)**
## Description
Decklinkvideosink will reject interlace-mode=mixed when set to an interlaced mode even if actual source file...## Submitted by Dave
**[Link to original bug (#767779)](https://bugzilla.gnome.org/show_bug.cgi?id=767779)**
## Description
Decklinkvideosink will reject interlace-mode=mixed when set to an interlaced mode even if actual source file is interleaved.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/400mxfdemux/mux: Add support for the sampling field in JPEG2000 caps2021-09-24T14:34:27ZBugzilla Migration Usermxfdemux/mux: Add support for the sampling field in JPEG2000 caps## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767904)](https://bugzilla.gnome.org/show_bug.cgi?id=767904)**
## Description
The MXF metadata contains all we need to know, we just need to expose/use it.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#767904)](https://bugzilla.gnome.org/show_bug.cgi?id=767904)**
## Description
The MXF metadata contains all we need to know, we just need to expose/use it.