gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:36:44Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/792Race condition in ipcpipelinesrc during flush2021-09-24T14:36:44ZBugzilla Migration UserRace condition in ipcpipelinesrc during flush## Submitted by Mike Dyer
**[Link to original bug (#797223)](https://bugzilla.gnome.org/show_bug.cgi?id=797223)**
## Description
Created attachment 373802
[PATCH] Fix race condition during flush
A race condition exists when h...## Submitted by Mike Dyer
**[Link to original bug (#797223)](https://bugzilla.gnome.org/show_bug.cgi?id=797223)**
## Description
Created attachment 373802
[PATCH] Fix race condition during flush
A race condition exists when handling flush-start and flush-stop events in intersrc.
When receiving a flush-start event, the event handler calls gst_inter_src_stop_loop() which sets the flag src->flushing. In the case of pausing the task, it does not wait for gst_inter_src_loop() to pause itself.
gst_inter_src_loop() reads the value of src->flushing while holding src->comm.mutex and stores it in a local variable. After releasing the mutex, gst_inter_src_loop() then proceeds to clear the queue and then set itself to paused, based on the value of the local variable.
During the queue clearing, it is possible that a flush-stop event could arrive. This will clear src->flushing and call gst_pad_start_task() to schedule gst_inter_src_loop(). However, the task hasn't paused yet, so this call does nothing. gst_inter_src_loop() finishes clearing the queue and sets itself to paused. Because this occurs after receipt of the flush-stop, the loop remains paused and is not restarted.
To prevent this, we can pause the task from gst_inter_src_stop_loop(). This will then wait for the gst_inter_src_loop() to complete. We can also clear the queue after it completes, removing the vulnerable period (gst_inter_src_cancel_queued() cannot be called from inside gst_inter_src_loop() with the mutex held, as it locks this mutex itself).
We must also propagate the flush-start event before attempting to pause gst_inter_src_loop() as it may be blocked pushing to downstream elements.
**Patch 373802**, "[PATCH] Fix race condition during flush":
[0001-ipcpipelinesrc-Fix-race-condition-during-flush.patch](/uploads/71340e5f4da8eb1c9e8788a5f15baf49/0001-ipcpipelinesrc-Fix-race-condition-during-flush.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/791h264parser: Should add a "unsupported" return value2021-09-24T14:36:43ZBugzilla Migration Userh264parser: Should add a "unsupported" return value## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797217)](https://bugzilla.gnome.org/show_bug.cgi?id=797217)**
## Description
Currently, our parser will return "broken data" whenever an unsupported type is met...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797217)](https://bugzilla.gnome.org/show_bug.cgi?id=797217)**
## Description
Currently, our parser will return "broken data" whenever an unsupported type is met. In some cases this is the correct thing to do, as it's forbidden by the spec, but in other case, this leads to data being dropped as if it was broken.
My suggestion would be to introduce an "unsupported" return value. This way, parser element can simply pass-through these NALs, as they are not proven to be invalid. This applies to non MVC slice entension types, for which we have a hack in h264parse element to avoid dropping.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/790h264/5parse: mark SEI Recovery Point as keyframes2018-12-02T02:13:36ZBugzilla Migration Userh264/5parse: mark SEI Recovery Point as keyframes## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#797216)](https://bugzilla.gnome.org/show_bug.cgi?id=797216)**
## Description
The AVC and HEVC spec states that "recovery point SEI message assists a decoder i...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#797216)](https://bugzilla.gnome.org/show_bug.cgi?id=797216)**
## Description
The AVC and HEVC spec states that "recovery point SEI message assists a decoder in determining when the decoding process will produce acceptable pictures for display after the decoder initiates random access or after the encoder indicates a broken link in the coded video sequence."
Mark those as keyframes so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/789h26xbasepasrse: Introduce base class for h264/h265 parse2021-09-24T14:36:43ZBugzilla Migration Userh26xbasepasrse: Introduce base class for h264/h265 parse## Submitted by Seungha Yang
**[Link to original bug (#797210)](https://bugzilla.gnome.org/show_bug.cgi?id=797210)**
## Description
Due to the structural similarity both h264 and h265 parse element have
common/duplicated implement...## Submitted by Seungha Yang
**[Link to original bug (#797210)](https://bugzilla.gnome.org/show_bug.cgi?id=797210)**
## Description
Due to the structural similarity both h264 and h265 parse element have
common/duplicated implementation and they could be unified by using
this base class.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/788amcvideodec: decoding fails on Mediatek tablet (API level 19)2021-09-24T14:36:42ZBugzilla Migration Useramcvideodec: decoding fails on Mediatek tablet (API level 19)## Submitted by Gregoire
**[Link to original bug (#797149)](https://bugzilla.gnome.org/show_bug.cgi?id=797149)**
## Description
Created attachment 373663
Log error on the mediatek tablet
I have a Mediatek tablet with API leve...## Submitted by Gregoire
**[Link to original bug (#797149)](https://bugzilla.gnome.org/show_bug.cgi?id=797149)**
## Description
Created attachment 373663
Log error on the mediatek tablet
I have a Mediatek tablet with API level 19 which fails to decode in hardware a video file with the a playbin3 pipeline.
I attach the log error.
If I use playbin instead, it uses openh264dec and the file plays but the performance is obviously bad as it's decoded in software.
If I use a Nexus 5X android 8.1.0 with the exact same app (based on playbin3), it's working and it decodes correctly in hardware.
Very last, and probably the most important test, I can use VLC on this Mediatek tablet and the file is correctly decoded in hardware.
**Attachment 373663**, "Log error on the mediatek tablet":
[log-amcvideodec.txt](/uploads/e23300e77c6cf390cf85c1fb89c01d61/log-amcvideodec.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/787Add dmss protocol plugins2021-09-24T14:36:42ZBugzilla Migration UserAdd dmss protocol plugins## Submitted by Felipe Magno de Almeida
**[Link to original bug (#797140)](https://bugzilla.gnome.org/show_bug.cgi?id=797140)**
## Description
Created attachment 373646
Patch of the implementation
DMSS protocol from DAHUA ip ...## Submitted by Felipe Magno de Almeida
**[Link to original bug (#797140)](https://bugzilla.gnome.org/show_bug.cgi?id=797140)**
## Description
Created attachment 373646
Patch of the implementation
DMSS protocol from DAHUA ip camera manufacturer source and demultiplexer.
~~**Patch 373646**~~, "Patch of the implementation":
[0001-Dahua-Camera-IP-protocol-DMSS-source-and-demuxer-plu.patch](/uploads/a6f7c5329f7b21fa3558e56c1e0ffb8f/0001-Dahua-Camera-IP-protocol-DMSS-source-and-demuxer-plu.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/786videoaggregator: Notify drained status of a videoaggregator pad2021-09-24T14:36:41ZBugzilla Migration Uservideoaggregator: Notify drained status of a videoaggregator pad## Submitted by Seungha Yang
**[Link to original bug (#797128)](https://bugzilla.gnome.org/show_bug.cgi?id=797128)**
## Description
Add GstVideoAggregatorPad::drained property and
GstVideoAggregator::pad-drained signal to help mon...## Submitted by Seungha Yang
**[Link to original bug (#797128)](https://bugzilla.gnome.org/show_bug.cgi?id=797128)**
## Description
Add GstVideoAggregatorPad::drained property and
GstVideoAggregator::pad-drained signal to help monitoring composing
status. Some complex use cases (such as dynamic add/remove composing
images), application might want to know when a stream is completely
consumed.
The issue is that EOS event cannot respect the consumed
status of a stream, because a buffer followed by the EOS might have
long duration and therefore the buffer will be alive until running time
of the other stream is reached to the buffer's running time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/785[soundtouch] pitch breaks lip sync in Chrome2021-09-24T14:36:41ZBugzilla Migration User[soundtouch] pitch breaks lip sync in Chrome## Submitted by Juan Navarro `@j1elo`
**[Link to original bug (#797125)](https://bugzilla.gnome.org/show_bug.cgi?id=797125)**
## Description
Created attachment 373606
Good and bad video recv delays (with scaletempo and pitch, resp...## Submitted by Juan Navarro `@j1elo`
**[Link to original bug (#797125)](https://bugzilla.gnome.org/show_bug.cgi?id=797125)**
## Description
Created attachment 373606
Good and bad video recv delays (with scaletempo and pitch, respectively)
It seems that the 'pitch' filter (in the soundtouch plugin, gst-plugins-bad) introduces some kind of wrong timestamp, clock skew, bad sequence, a combination of those, or maybe something different (but probably related).
I'm seeing an accumulative delay in Chrome between video and audio in a WebRTC call (_not_ using the new GStreamer's WebRTC element, yet) where the source is sending a video+audio stream, and the audio is filtered with the pitch element. Chrome is unable to perform the lip sync successfully, and for some reason deduces that somehow the audio is lagging behind the video (which is actually not), so it delays the video indefinitely until the delay gets to Chrome's maximum, 10 seconds.
The net effect of this issue is practically the same as what happened in this Chrome bug:
https://bugs.chromium.org/p/webrtc/issues/detail?id=5456 (just check the screenshots)
with 'googCurrentDelayMs' and 'goodMinPlayoutDelayMs' growing linearly. At that time it happened to be Chrome wrongly using the webcam's timestamp, which had a different clock rate than the system's timestamp.
But, in this case I don't think it's a Chrome bug; I have verified that this is caused by the GStreamer's 'pitch' filter, by sourcing this simple test pipeline to my custom WebRTC source element:
... -> (raw audio)
-> audioconvert -> audioresample -> pitch ->
-> audioconvert -> audioresample -> WebRTC
(Probably most, if not all of those audioconvert/audioresample elements are not needed, I added them just to fall on the safe side)
This generates the mentioned delay in the video presentation handled by Chrome.
However nothing of this happens if the 'pitch' element is removed and any other is used, e.g. an 'scaletempo' element:
... -> (raw audio)
-> audioconvert -> audioresample -> scaletempo ->
-> audioconvert -> audioresample -> WebRTC
This produces a normal lip sync result in Chrome. Delay (latency) stays at around 100, 150 ms.
Tried reading google's WebRTC code, wanting to know exactly what is the name of the value that is to blame:
https://cs.chromium.org/chromium/src/third_party/webrtc/video/stream_synchronization.cc
but finding out what is the correct function chain is difficult, and I'm still not sure of exactly *what* is making Chrome confused and wrongly assuming that the audio is behind the video, when it's not.
I have cherry-picked and applied all commits that touched the file './ext/soundtouch/gstpitch.cc' into a custom built version of gst-plugins-bad (based on GStreamer 1.8), but the issue persists so I don't think it's a matter of trying the latest code (after a lot of time without changes, the pitch filter received some patches in June 2018 so I wanted to test if those helped...)
I can provide any needed info (Chrome's webrtc-internals dump file, where the attached graphs are taken from; Chrome's diagnostic event and log captures, Wireshark capture, etc.)
Attached graphs taken by myself, to show the effect of a good (as expected) behavior and bad one.
I have been analyzing two issues with the pitch plugin; one is this, and the other is reported here and is possibly related:
https://bugzilla.gnome.org/show_bug.cgi?id=797124
**Attachment 373606**, "Good and bad video recv delays (with scaletempo and pitch, respectively)":
![video_recv_good_bad](/uploads/72a7f6367bbd7328cc6ce0be8e09f53e/video_recv_good_bad.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/784[soundtouch] pitch breaks RTP send/recv audio packet rate2021-09-24T14:36:41ZBugzilla Migration User[soundtouch] pitch breaks RTP send/recv audio packet rate## Submitted by Juan Navarro `@j1elo`
**[Link to original bug (#797124)](https://bugzilla.gnome.org/show_bug.cgi?id=797124)**
## Description
Created attachment 373605
Good and bad audio recv rates (with scaletempo and pitch, respe...## Submitted by Juan Navarro `@j1elo`
**[Link to original bug (#797124)](https://bugzilla.gnome.org/show_bug.cgi?id=797124)**
## Description
Created attachment 373605
Good and bad audio recv rates (with scaletempo and pitch, respectively)
Using the pitch element for WebRTC streaming, I've found out that the packet rate is affected enough to produce audible clicks and generally choppy sound on the receiver.
By comparing a pipeline with the pitch plugin, and the same pipeline with any other audio plugin for test purposes, it's evident that send packet rate, and especially receive packet rate, are affected in the former but are pretty good in the latter. Screenshots attached with graphs taken from Chrome's "chrome://webrtc-internals/" page.
Audio codec in use is Opus, with a 48000 KHz sampling rate, and it's expected to be sent/received at a rate of 50 packets per second. Interestingly, in the Chrome stats one can see that the audio receive rate drops to exactly 46 packets per second, so there is probably some time constant in play there.
The audio cracks and quality drops can be heard constantly in either Chrome or Firefox receiver browsers.
Sender test pipeline looks like this:
... -> (raw audio)
-> audioconvert -> audioresample -> pitch ->
-> audioconvert -> audioresample -> WebRTC output
I have cherry-picked and applied all commits that touched the file './ext/soundtouch/gstpitch.cc' into a custom built version of gst-plugins-bad (based on GStreamer 1.8), but the issue persists so I don't think it's a matter of trying the latest code (after a lot of time without changes, the pitch filter received some patches in June 2018 so I wanted to test if those helped...)
I can provide any needed info (Chrome's webrtc-internals dump file, where the attached graphs are taken from; Chrome's diagnostic event and log captures, Wireshark capture, etc.)
**Attachment 373605**, "Good and bad audio recv rates (with scaletempo and pitch, respectively)":
![audio_recv_good_bad](/uploads/f49def7bcb2d2cc168a6440579f1f023/audio_recv_good_bad.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/783debugutilsbad: Add timestamper element2021-09-24T14:36:40ZBugzilla Migration Userdebugutilsbad: Add timestamper element## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797117)](https://bugzilla.gnome.org/show_bug.cgi?id=797117)**
## Description
This is a simple element that simply set timestamp based on fixed duration.
The t...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797117)](https://bugzilla.gnome.org/show_bug.cgi?id=797117)**
## Description
This is a simple element that simply set timestamp based on fixed duration.
The timestamp method could be enhanced later base on needs. This was written
initially to verify if broken or bad timestamp was directly causing some issues
we where observing. It's also handy in some test when pulling some raw frames
from the disk (e.g. multifilesrc). Currently, there is one property "duration".https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/782rtmp: Don't set debug callback of librtmp depending on debug level2021-09-24T14:36:40ZBugzilla Migration Userrtmp: Don't set debug callback of librtmp depending on debug level## Submitted by Seungha Yang
**[Link to original bug (#797103)](https://bugzilla.gnome.org/show_bug.cgi?id=797103)**
## Description
When an application explicitly disable "rtmp" debug category,
don't hook debug callback of librtmp...## Submitted by Seungha Yang
**[Link to original bug (#797103)](https://bugzilla.gnome.org/show_bug.cgi?id=797103)**
## Description
When an application explicitly disable "rtmp" debug category,
don't hook debug callback of librtmp. The application might want
another debug callback instead of that of gstreamer.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/781hlsdemux: hang on deleted segment2021-09-24T14:36:40ZBugzilla Migration Userhlsdemux: hang on deleted segment## Submitted by Nicola `@drakkan`
**[Link to original bug (#797101)](https://bugzilla.gnome.org/show_bug.cgi?id=797101)**
## Description
Created attachment 373570
logs that show the issue
please take a look at the attached lo...## Submitted by Nicola `@drakkan`
**[Link to original bug (#797101)](https://bugzilla.gnome.org/show_bug.cgi?id=797101)**
## Description
Created attachment 373570
logs that show the issue
please take a look at the attached logs,
hlsdemux try download fragment 2632 that is no more present in the playlist again and again.
This is a "live" stream and fragments get deleted when old,
ffplay play this stream with no issue, please take a look at the ffplay logs, fragment 2632 is correctly downloaded,
please note that ffplay has less delay than hlsdemux and so it downloads that fragment before GStreamer
**Attachment 373570**, "logs that show the issue":
[hls_loop.log](/uploads/e23038df29fa4395ca1dba838ddd3c1a/hls_loop.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/780hls segfaults2021-09-24T14:36:39ZBugzilla Migration Userhls segfaults## Submitted by Nicola `@drakkan`
**[Link to original bug (#797075)](https://bugzilla.gnome.org/show_bug.cgi?id=797075)**
## Description
I see some crashs using playbin for an hls stream
- crash 1:
```
#0 0x00007fffef3cca...## Submitted by Nicola `@drakkan`
**[Link to original bug (#797075)](https://bugzilla.gnome.org/show_bug.cgi?id=797075)**
## Description
I see some crashs using playbin for an hls stream
- crash 1:
```
#0 0x00007fffef3cca26 in malloc () at /usr/lib/libc.so.6
#1 0x00007fffef453b0f in __vasprintf_chk () at /usr/lib/libc.so.6
#2 0x00007ffff7c54c5a in g_vasprintf () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff7c2e0de in g_strdup_vprintf () at /usr/lib/libglib-2.0.so.0
#4 0x00007ffff7c2e19a in g_strdup_printf () at /usr/lib/libglib-2.0.so.0
#5 0x00007fff657d504e in uri_join (uri1=<optimized out>, uri2=0x7ffed0017015 "3304.ts")
at ../subprojects/gst-plugins-bad/ext/hls/m3u8.c:1111
#6 0x00007fff657d583d in gst_m3u8_update (self=0x7ffed0016db0, data=<optimized out>)
at ../subprojects/gst-plugins-bad/ext/hls/m3u8.c:522
#7 0x00007fff657cf5c9 in gst_hls_demux_update_playlist (demux=demux@entry=0x7ffef00ceec0, update=update@entry=1, err=err@entry=0x0) at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1459
#8 0x00007fff657cfcdf in gst_hls_demux_change_playlist (demux=demux@entry=0x7ffef00ceec0, max_bitrate=<optimized out>, changed=changed@entry=0x7ffee67fb2e4) at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1599
#9 0x00007fff657d0edd in gst_hls_demux_select_bitrate (stream=<optimized out>, bitrate=<optimized out>)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1149
#10 0x00007fff657c0c99 in gst_adaptive_demux_stream_select_bitrate (bitrate=<optimized out>, stream=0x7fff1412d830, demux=0x7ffef00ceec0) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4280
#11 0x00007fff657c0c99 in gst_adaptive_demux_stream_advance_fragment_unlocked (duration=<optimized out>, stream=0x7fff1412d830, demux=0x7ffef00ceec0) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4232
#12 0x00007fff657c0c99 in gst_adaptive_demux_stream_advance_fragment (demux=demux@entry=0x7ffef00ceec0, stream=stream@entry=0x7fff1412d830, duration=<optimized out>) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4153
#13 0x00007fff657ce726 in gst_hls_demux_finish_fragment (demux=0x7ffef00ceec0, stream=0x7fff1412d830)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:953
#14 0x00007fff657b477f in gst_adaptive_demux_eos_handling (stream=stream@entry=0x7fff1412d830)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:2730
#15 0x00007fff657b4af9 in _src_event (pad=<optimized out>, parent=<optimized out>, event=0x7ffed4003d10)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:2748
#16 0x00007ffff7dee277 in gst_pad_send_event_unchecked (pad=pad@entry=0x7fff1412acd0, event=event@entry=0x7ffed4003d10, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5757
#17 0x00007ffff7dee7c4 in gst_pad_push_event_unchecked (pad=pad@entry=0x7fff1404f5b0, event=0x7ffed4003d10, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5402
#18 0x00007ffff7deec34 in push_sticky (pad=pad@entry=0x7fff1404f5b0, ev=ev@entry=0x7ffee67fb600, user_data=user_data@entry=0x7---Type <return> to continue, or q <return> to quit---
ffee67fb670) at ../subprojects/gstreamer/gst/gstevent.h:438
#19 0x00007ffff7dec548 in events_foreach (pad=pad@entry=0x7fff1404f5b0, func=func@entry=0x7ffff7deebe0 <push_sticky>, user_data=user_data@entry=0x7ffee67fb670) at ../subprojects/gstreamer/gst/gstpad.c:608
#20 0x00007ffff7df7b71 in check_sticky (event=0x7ffed4003d10, pad=0x7fff1404f5b0)
at ../subprojects/gstreamer/gst/gstpad.c:3977
#21 0x00007ffff7df7b71 in gst_pad_push_event (pad=pad@entry=0x7fff1404f5b0, event=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:5533
#22 0x00007ffff7df80f4 in event_forward_func (pad=pad@entry=0x7fff1404f5b0, data=data@entry=0x7ffee67fb770)
at ../subprojects/gstreamer/gst/gstevent.h:438
#23 0x00007ffff7df446e in gst_pad_forward (pad=pad@entry=0x555556151d00, forward=forward@entry=0x7ffff7df8030 <event_forward_func>, user_data=user_data@entry=0x7ffee67fb770) at ../subprojects/gstreamer/gst/gstpad.c:3004
#24 0x00007ffff7df45b5 in gst_pad_event_default (pad=0x555556151d00, parent=<optimized out>, event=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:3101
#25 0x00007ffff7dee277 in gst_pad_send_event_unchecked (pad=pad@entry=0x555556151d00, event=event@entry=0x7ffed4003d10, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5757
#26 0x00007ffff7dee7c4 in gst_pad_push_event_unchecked (pad=pad@entry=0x7fff1412a830, event=0x7ffed4003d10, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5402
#27 0x00007ffff7deec34 in push_sticky (pad=pad@entry=0x7fff1412a830, ev=ev@entry=0x7ffee67fb970, user_data=user_data@entry=0x7ffee67fb9e0) at ../subprojects/gstreamer/gst/gstevent.h:438
#28 0x00007ffff7dec548 in events_foreach (pad=pad@entry=0x7fff1412a830, func=func@entry=0x7ffff7deebe0 <push_sticky>, user_data=user_data@entry=0x7ffee67fb9e0) at ../subprojects/gstreamer/gst/gstpad.c:608
#29 0x00007ffff7df7b71 in check_sticky (event=0x7ffed4003d10, pad=0x7fff1412a830)
at ../subprojects/gstreamer/gst/gstpad.c:3977
#30 0x00007ffff7df7b71 in gst_pad_push_event (pad=0x7fff1412a830, event=event@entry=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:5533
#31 0x00007fff8806626b in gst_queue_push_one (queue=0x7ffee0016010)
at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1455
#32 0x00007fff8806626b in gst_queue_loop (pad=<optimized out>) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1537
#33 0x00007ffff7e24751 in gst_task_func (task=0x7fff1404c710) at ../subprojects/gstreamer/gst/gsttask.c:328
#34 0x00007ffff7c37bf6 in () at /usr/lib/libglib-2.0.so.0
#35 0x00007ffff7c371ea in () at /usr/lib/libglib-2.0.so.0
#36 0x00007fffef840a9d in start_thread () at /usr/lib/libpthread.so.0
```
crash 2:
```
#0 0x00007fffef4a6667 in __strlen_avx2 () at /usr/lib/libc.so.6
#1 0x00007ffff7c2df54 in g_strdup () at /usr/lib/libglib-2.0.so.0
#2 0x00007fff7d7cff10 in gst_hls_demux_update_fragment_info (stream=0x7ffed000e420)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1102
#3 0x00007fff7d7b3ba1 in gst_adaptive_demux_stream_update_fragment_info (demux=demux@entry=0x7fff141aa1f0, stream=stream@entry=0x7ffed000e420) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4303
#4 0x00007fff7d7bde74 in gst_adaptive_demux_stream_download_loop (stream=0x7ffed000e420)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:3716
#5 0x00007ffff7e24751 in gst_task_func (task=0x7ffee80c1dd0) at ../subprojects/gstreamer/gst/gsttask.c:328
#6 0x00007ffff7c37bf6 in () at /usr/lib/libglib-2.0.so.0
#7 0x00007ffff7c371ea in () at /usr/lib/libglib-2.0.so.0
#8 0x00007fffef840a9d in start_thread () at /usr/lib/libpthread.so.0
#9 0x00007fffef442a43 in clone () at /usr/lib/libc.so.6
```
the same stream works with no crash in ffplayhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/779waylandsink: Add DRM modifiers and linux-dmabuf version 3 support2021-09-24T14:36:39ZBugzilla Migration Userwaylandsink: Add DRM modifiers and linux-dmabuf version 3 support## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797071)](https://bugzilla.gnome.org/show_bug.cgi?id=797071)**
## Description
waylandsink need support linux-dmabuf version 3 to enable modifier handle
### Depends on
...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797071)](https://bugzilla.gnome.org/show_bug.cgi?id=797071)**
## Description
waylandsink need support linux-dmabuf version 3 to enable modifier handle
### Depends on
* [Bug 779146](https://bugzilla.gnome.org/show_bug.cgi?id=779146)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/778Add split-field interlacing to h265parse & interlace elements2020-03-31T15:17:55ZBugzilla Migration UserAdd split-field interlacing to h265parse & interlace elements## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace el...## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace elements.
These patches are not yet ready to be merged as the caps lack the needed feature, which will be added soon. The point of submitting them already was to already get opinions/suggestions on the main changes.
Also I'm not entirely sure if the (short-cut) approach I took for interlace is what we would want. Suggestions welcome.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/777nvdec: Add support VC1 decoding2021-09-24T14:36:39ZBugzilla Migration Usernvdec: Add support VC1 decoding## Submitted by Yeongjin Jeong
**[Link to original bug (#797049)](https://bugzilla.gnome.org/show_bug.cgi?id=797049)**
## Description
Created attachment 373504
nvdec: Add support VC1 decoding
NVIDIA video decoder supports VC1...## Submitted by Yeongjin Jeong
**[Link to original bug (#797049)](https://bugzilla.gnome.org/show_bug.cgi?id=797049)**
## Description
Created attachment 373504
nvdec: Add support VC1 decoding
NVIDIA video decoder supports VC1 decoding
e.q. )
gst-launch-1.0 filesrc location=(video file path) ! avidemux ! nvdec ! glimagesink
sample video. )
http://samples.mplayerhq.hu/V-codecs/WVC1/glitch-ffvc1.avi
**Patch 373504**, "nvdec: Add support VC1 decoding":
[0001-nvdec-Add-support-VC1-decoding.patch](/uploads/36a21de833f1ddc89ec652973455fd47/0001-nvdec-Add-support-VC1-decoding.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/776kmssink: Deprecate force-modesetting in favour of "mode" property2021-09-24T14:36:38ZBugzilla Migration Userkmssink: Deprecate force-modesetting in favour of "mode" property## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797047)](https://bugzilla.gnome.org/show_bug.cgi?id=797047)**
## Description
I think force-modesetting isn't great has a property. As the time goes, we find tha...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797047)](https://bugzilla.gnome.org/show_bug.cgi?id=797047)**
## Description
I think force-modesetting isn't great has a property. As the time goes, we find that most people uses kmssink in a way one would use decklinkvideosink. It's basically the "new" way, even though still a bit limited, to handle a video output. In this regard, the typical use case is to fix the output mode using well known names, like 1080p60, 1080i60, etc. Basically, the API exposed by decklinkvideosink.
So my proposal is to replace "force-modesetting" with a mode property. We could have special values to indicate "current", for the currently configured mode (our default), "automatic", to try and match the video resolution with the output, or an alternative of type "best-match". And then, a list of modes.
The decklinkvideosink just hardcodes a fixed list of modes, we could do that, but then we'd need to improve it everything a DRM driver introduce a new mode. Maybe we could find a compromise, keep "mode" as a string and match it to one of the enumerated modes for the connector.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/775bayer2rgb: does not copy meta data2021-09-24T14:36:38ZBugzilla Migration Userbayer2rgb: does not copy meta data## Submitted by Edgar Thier
**[Link to original bug (#797043)](https://bugzilla.gnome.org/show_bug.cgi?id=797043)**
## Description
GstMeta data added to a buffer is lost when bayer2rgb is used.
It would be preferable if this da...## Submitted by Edgar Thier
**[Link to original bug (#797043)](https://bugzilla.gnome.org/show_bug.cgi?id=797043)**
## Description
GstMeta data added to a buffer is lost when bayer2rgb is used.
It would be preferable if this data is copied instead.
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/774msdkh264dec: when playing 1080P 60fps it shows lots of frames dropped, compar...2021-09-24T14:36:38ZBugzilla Migration Usermsdkh264dec: when playing 1080P 60fps it shows lots of frames dropped, comparing vaapih264dec in same hardware## Submitted by lon..@..el.com
**[Link to original bug (#797040)](https://bugzilla.gnome.org/show_bug.cgi?id=797040)**
## Description
Created attachment 373489
GST_DEBUG log
When using msdkh264dec, fpsdisplaysink and glimages...## Submitted by lon..@..el.com
**[Link to original bug (#797040)](https://bugzilla.gnome.org/show_bug.cgi?id=797040)**
## Description
Created attachment 373489
GST_DEBUG log
When using msdkh264dec, fpsdisplaysink and glimagesink in pipeline, there are a few frames dropped when playing 1080P media by msdk, especially during the starting period.
Test command:
gst-launch-1.0 filesrc location=./1080P_HOBIT3_1920x1080_2700frames.yuv_cbr_bt2000_ipb.h264 ! h264parse ! msdkh264dec ! fpsdisplaysink video-sink=glimagesink
**Attachment 373489**, "GST_DEBUG log":
[msdk_45framesdropped.zip](/uploads/fbed3ec8f312b3760205975766c2ce49/msdk_45framesdropped.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/773openh264enc: cmInitParaError on EOS2021-09-24T14:36:37ZBugzilla Migration Useropenh264enc: cmInitParaError on EOS## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when r...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when receiving the EOS event:
GST_DEBUG=videoencoder:7,openh264enc:7 gst-launch-1.0 videotestsrc num-buffers=10 ! openh264enc ! fakesink
...
0:00:00.046820534 6897 0x55bb2aff0ca0 LOG openh264enc gstopenh264enc.cpp:989:gst_openh264enc_handle_frame:`<openh264enc0>` openh264 picture coded OK!
...
0:00:00.046936637 6897 0x55bb2aff0ca0 DEBUG videoencoder gstvideoencoder.c:1216:gst_video_encoder_sink_event:`<openh264enc0>` received event 28174, eos
[OpenH264] this = 0x0x7f0d4c009220, Error:CWelsH264SVCEncoder::EncodeFrame(), cmInitParaError.
Got EOS from element "pipeline0".