gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2019-12-26T13:27:58Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1009Webrtcbin: Artefacts in received video from various sources, various codecs a...2019-12-26T13:27:58ZNeil YoungWebrtcbin: Artefacts in received video from various sources, various codecs after a while of no movement.I'm using the GStreamer plugin webrtcbin from a Java app. GStreamer version is 1.16.0. With various remote webrtc clients (web apps, native apps, Raspberry PI UV4L) I'm having the problem, that the received video on the webrtcbin side is...I'm using the GStreamer plugin webrtcbin from a Java app. GStreamer version is 1.16.0. With various remote webrtc clients (web apps, native apps, Raspberry PI UV4L) I'm having the problem, that the received video on the webrtcbin side is starting to show artefacts, which become more and more until the entire image is full of "coloured soap". This goes away after a while, if I e.g. "swipe" over the remote camera.
If I'm using a browser client from the same machine against all other targets, there are no such increasing artefacts.
I have checked the FIR rate but found, that practically neither the GST nor the browser is sending FIRs. It is also completely irrelevant, if the remote side delivers H.264 or VP8. After a while of no-movement at remote GStreamer shows these artefacts.
I know, a similar issue has already been raised a while ago, but I found no solution there:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/799
What can I do in order to approach the problem? At least for the Raspberry PI and the browser client at remote I would have all the debugging abilities, if somebody would like to know something. What I can exclude are major problems with the connectivity.
So again - reproducible artefacts if GStreamer webrtcbin is the receiver, nothing like this at all if a browser receives and displays the images.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1010SOLVED: Webrtcbin: Huge increasing memory leak while using appsink instead of...2019-07-08T10:46:05ZNeil YoungSOLVED: Webrtcbin: Huge increasing memory leak while using appsink instead of autovideosinkI'm referring to the Java sample app: https://github.com/centricular/gstwebrtc-demos/tree/master/sendrecv/gst-java
With respect to increasing memory consumption everything is fine and balanced if we are using this approach to display th...I'm referring to the Java sample app: https://github.com/centricular/gstwebrtc-demos/tree/master/sendrecv/gst-java
With respect to increasing memory consumption everything is fine and balanced if we are using this approach to display the received video in a pop-up window:
```
if (name.startsWith("video")) {
Element queue = ElementFactory.make("queue", "my-videoqueue");
Element videoconvert = ElementFactory.make("videoconvert", "my-videoconvert");
Element autovideosink = ElementFactory.make("osxvideosink", "my-autovideosink");
// Element autovideosink = ElementFactory.make("autovideosink", "my-autovideosink");
pipe.addMany(queue, videoconvert, autovideosink);
queue.syncStateWithParent();
videoconvert.syncStateWithParent();
autovideosink.syncStateWithParent();
pad.link(queue.getStaticPad("sink"));
queue.link(videoconvert);
videoconvert.link(autovideosink);
}
```
(autovideosink is replaced by osxvideosink for macOS)
If this sequence above is replaced by the following, the memory consumption of the Java app grows by 200 MB/s, which after a while leads to a complete crash of the app if not of the entire system:
```
if (name.startsWith("video")) {
Element queue = ElementFactory.make("queue", "my-videoqueue");
Element videoconvert = ElementFactory.make("videoconvert", "my-videoconvert");
AppSink sink = (AppSink) ElementFactory.make("appsink", "my-appsink");
sink.set("emit-signals", true);
sink.connect(new AppSink.NEW_SAMPLE() {
@Override
public FlowReturn newSample(AppSink elem) {
Sample sample = elem.pullSample();
Structure capsStruct = sample.getCaps().getStructure(0);
String format = capsStruct.getString("format");
int width = capsStruct.getInteger("width");
int height = capsStruct.getInteger("height");
ByteBuffer bytes = sample.getBuffer().map(false);
byte[] buffer = new byte[bytes.remaining()];
bytes.get(buffer);
dragonfly.onNextFrame(format, buffer, width, height);
sample.dispose();
return FlowReturn.OK;
}
});
sink.connect(new AppSink.NEW_PREROLL() {
@Override
public FlowReturn newPreroll(AppSink elem) {
Sample sample = elem.pullPreroll();
Structure capsStruct = sample.getCaps().getStructure(0);
String format = capsStruct.getString("format");
int width = capsStruct.getInteger("width");
int height = capsStruct.getInteger("height");
ByteBuffer bytes = sample.getBuffer().map(false);
byte[] buffer = new byte[bytes.remaining()];
bytes.get(buffer);
dragonfly.onNextFrame(format, buffer, width, height);
sample.dispose();
return FlowReturn.OK;
}
});
pipe.addMany(queue, videoconvert, sink);
queue.syncStateWithParent();
videoconvert.syncStateWithParent();
sink.syncStateWithParent();
pad.link(queue.getStaticPad("sink"));
queue.link(videoconvert);
videoconvert.link(sink);
}
```
Is there anything wrong with the sequence above, which could cause the leak?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1011GStreamer OpenGL renderer creates a new texture for each frame - highly ineff...2019-07-11T15:29:40ZAdvance SoftwareGStreamer OpenGL renderer creates a new texture for each frame - highly inefficient._new_texture in gst-build/subprojects/gst-plugins-base/gst-libs/gst/gl/gstglmemory.c
Is called once per frame. The configuration should be 2 textures of the same dimension as the video decoder output, decode into one, display from the o..._new_texture in gst-build/subprojects/gst-plugins-base/gst-libs/gst/gl/gstglmemory.c
Is called once per frame. The configuration should be 2 textures of the same dimension as the video decoder output, decode into one, display from the other, then swap. Repeat until done.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1012nvenc: occasional floating point exception during startup2019-08-21T07:21:19ZBilly Lindemannvenc: occasional floating point exception during startup```
Thread 15 "QuartzRemoteHoo" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fff9d7fe700 (LWP 62072)]
0x00007fffe2a2c301 in ?? () from /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
(gdb) back
#0 0x00007fffe2a2c301 i...```
Thread 15 "QuartzRemoteHoo" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fff9d7fe700 (LWP 62072)]
0x00007fffe2a2c301 in ?? () from /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
(gdb) back
#0 0x00007fffe2a2c301 in () at /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
#1 0x00007fffe2a3c65e in () at /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
#2 0x00007fffe2a3d128 in () at /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
#3 0x00007fffe80ab377 in () at /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
#4 0x00007fffe80a46e2 in () at /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
#5 0x00007fffe80afc09 in () at /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
#6 0x00007fffe85182d9 in gst_nv_base_enc_set_format (enc=<optimized out>, state=0x55555610fd20) at gstnvbaseenc.c:1263
#7 0x00007ffff56a464b in gst_video_encoder_setcaps (caps=0x7fff64004770, encoder=0x5555561ffb10) at gstvideoencoder.c:672
#8 0x00007ffff56a464b in gst_video_encoder_sink_event_default (encoder=0x5555561ffb10, event=0x7fff68006ab0) at gstvideoencoder.c:1027
#9 0x00007ffff5105d97 in gst_pad_send_event_unchecked (pad=pad@entry=0x555556343770, event=event@entry=0x7fff68006ab0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5772
#10 0x00007ffff510622b in gst_pad_push_event_unchecked (pad=pad@entry=0x555556343520, event=0x7fff68006ab0, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5417
#11 0x00007ffff5106659 in push_sticky (pad=pad@entry=0x555556343520, ev=ev@entry=0x7fff9d7fbc80, user_data=user_data@entry=0x7fff9d7fbcf0) at gstpad.c:3933
#12 0x00007ffff5103fe0 in events_foreach (pad=pad@entry=0x555556343520, func=func@entry=0x7ffff51065a0 <push_sticky>, user_data=user_data@entry=0x7fff9d7fbcf0) at gstpad.c:608
#13 0x00007ffff51109cf in check_sticky (event=0x7fff68006ab0, pad=0x555556343520) at gstpad.c:3992
#14 0x00007ffff51109cf in gst_pad_push_event (pad=0x555556343520, event=0x7fff68006ab0) at gstpad.c:5548
#15 0x00005555556a4bc8 in <O as gstreamer::pad::PadExtManual>::push_event (self=0x7fff9d7fc250, event=...) at /home/billy/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/6871e50/gstreamer/src/pad.rs:422
#16 0x00005555556def60 in gsttogglerecord::togglerecord::ToggleRecord::sink_event (self=0x5555560b62d0, pad=0x7fff9d7fd618, element=0x7fff9d7fd628, event=...) at /home/billy/.cargo/git/checkouts/gst-plugins-rs-2155d1592d6bb9f7/8b4f0f9/gst-plugin-togglerecord/src/togglerecord.rs:952
#17 0x00005555556d41c9 in gsttogglerecord::togglerecord::ToggleRecord::set_pad_functions::{{closure}}::{{closure}} (togglerecord=0x5555560b62d0, element=0x7fff9d7fd628) at /home/billy/.cargo/git/checkouts/gst-plugins-rs-2155d1592d6bb9f7/8b4f0f9/gst-plugin-togglerecord/src/togglerecord.rs:198
#18 0x00005555556b1d4a in <T as gstreamer::subclass::element::ElementImplExt>::catch_panic_pad_function::{{closure}} () at /home/billy/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/6871e50/gstreamer/src/subclass/element.rs:240
#19 0x00005555556c6e43 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=()) at /rustc/de7c4e42314c56528640e3b663aa10e0caa6bd9b/src/libstd/panic.rs:309
#20 0x00005555556ef4c7 in std::panicking::try::do_call (data=0x7fff9d7fcec0 "(\325\177\235\377\177") at /rustc/de7c4e42314c56528640e3b663aa10e0caa6bd9b/src/libstd/panicking.rs:294
#21 0x0000555555a6013a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:82
#22 0x00005555556eed67 in std::panicking::try (f=...) at /rustc/de7c4e42314c56528640e3b663aa10e0caa6bd9b/src/libstd/panicking.rs:273
#23 0x00005555556c78eb in std::panic::catch_unwind (f=...) at /rustc/de7c4e42314c56528640e3b663aa10e0caa6bd9b/src/libstd/panic.rs:388
#24 0x00005555556d16d5 in <T as gstreamer::subclass::element::ElementImplExt>::catch_panic_pad_function (parent=..., fallback=..., f=...) at /home/billy/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/6871e50/gstreamer/src/subclass/error.rs:29
#25 0x00005555556d422f in gsttogglerecord::togglerecord::ToggleRecord::set_pad_functions::{{closure}} (pad=0x7fff9d7fd618, parent=..., event=...) at /home/billy/.cargo/git/checkouts/gst-plugins-rs-2155d1592d6bb9f7/8b4f0f9/gst-plugin-togglerecord/src/togglerecord.rs:195
#26 0x00005555556c53f2 in gstreamer::pad::trampoline_event_function (pad=0x5555563432d0, parent=0x5555560b63d0, event=0x7fff68006ab0) at /home/billy/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/6871e50/gstreamer/src/pad.rs:1232
#27 0x00007ffff5105d97 in gst_pad_send_event_unchecked (pad=pad@entry=0x5555563432d0, event=event@entry=0x7fff68006ab0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5772
#28 0x00007ffff510622b in gst_pad_push_event_unchecked (pad=pad@entry=0x555556343080, event=0x7fff68006ab0, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5417
#29 0x00007ffff5106659 in push_sticky (pad=pad@entry=0x555556343080, ev=ev@entry=0x7fff9d7fd820, user_data=user_data@entry=0x7fff9d7fd890) at gstpad.c:3933
#30 0x00007ffff5103fe0 in events_foreach (pad=pad@entry=0x555556343080, func=func@entry=0x7ffff51065a0 <push_sticky>, user_data=user_data@entry=0x7fff9d7fd890) at gstpad.c:608
#31 0x00007ffff51109cf in check_sticky (event=0x7fff68006ab0, pad=0x555556343080) at gstpad.c:3992
#32 0x00007ffff51109cf in gst_pad_push_event (pad=0x555556343080, event=event@entry=0x7fff68006ab0) at gstpad.c:5548
#33 0x00007fffe999e0f3 in gst_queue_push_one (queue=0x555556340fe0) at gstqueue.c:1455
#34 0x00007fffe999e0f3 in gst_queue_loop (pad=<optimized out>) at gstqueue.c:1537
#35 0x00007ffff513cfe9 in gst_task_func (task=0x555556344dd0) at gsttask.c:328
#36 0x00007ffff5ca3b60 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#37 0x00007ffff5ca3195 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#38 0x00007ffff4a6a6db in start_thread (arg=0x7fff9d7fe700) at pthread_create.c:463
#39 0x00007ffff457b88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1013SRT missing from Ubuntu packages2019-07-14T16:22:22ZdanrossiSRT missing from Ubuntu packagesI was hoping for an easy install for SRT testing. I installed the packages as instructed but SRT is missing from this package.
```
WARNING: erroneous pipeline: no element "srtclientsrc"
```
```
gst-inspect-1.0 grep srt*
No such elemen...I was hoping for an easy install for SRT testing. I installed the packages as instructed but SRT is missing from this package.
```
WARNING: erroneous pipeline: no element "srtclientsrc"
```
```
gst-inspect-1.0 grep srt*
No such element or plugin 'srt*'
```
```
gst-launch-1.0 v4l2src ! video/x-raw, height=1080, width=1920 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtserversink uri=srt://:8888/
WARNING: erroneous pipeline: no element "srtserversink"
```
Install command
```
sudo apt-get install libgstreamer1.0-0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-libav gstreamer1.0-doc gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-alsa gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-qt5 gstreamer1.0-pulseaudio
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1014webrtcbin: h264 decoding problems with chrome/firefox2021-09-24T14:37:31ZXiaolin Zhangwebrtcbin: h264 decoding problems with chrome/firefoxHi, I got a strange h264 decoding issue. It seems it is not a proper issue board to discuss. But, the webrtcbin is a complex architect, I have to ask help here. Any suggestion will be appreciated. Thanks in advance!
My problem is:
We wr...Hi, I got a strange h264 decoding issue. It seems it is not a proper issue board to discuss. But, the webrtcbin is a complex architect, I have to ask help here. Any suggestion will be appreciated. Thanks in advance!
My problem is:
We write a python client(based on gst-python) to **subscribe**/**publish** from [janus-gateway](https://janus.conf.meetecho.com/). When we do publish from an firefox/chrome browser, and then do **subscribe** from janus-gateway. It will show many h.264 message like this:
```
0:00:30.279190215 24831 0x14c6ca0 ERROR libav :0:: non-existing PPS 2 referenced
0:00:30.279198476 24831 0x14c6ca0 ERROR libav :0:: decode_slice_header error
0:00:30.279202932 24831 0x14c6ca0 ERROR libav :0:: no frame!
0:00:30.279210819 24831 0x14c6ca0 WARN libav gstavviddec.c:1975:gst_ffmpegviddec_handle_frame:<avdec_h264-0> Failed to send data for decoding
```
More information are:
- Switch to `vp8 codec` works fine.
- Publishing from another python-client(which act as publisher) works fine. (we use testvideosrc)
- The full pipline diagram looks like ![tmp.svg](/uploads/0ae95efcd01d7ea6375ede3e6129884e/tmp.svg)
So, any comments for this? And my further questions are:
- Can I switch to `openh264` from `decodebin2`?
- Is there any potential issue from `h264parse`?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1016srtpdec pushes encrypted buffers out when crypto is not set yet2023-02-07T17:09:25ZFabrice Belletfabrice@bellet.infosrtpdec pushes encrypted buffers out when crypto is not set yetI noticed a problematic behavior with sipe-pidgin, its farstream backend, and the way the srtp audio stream is passed from libnice to the siren decoder.
When the element starts to receive encrypted buffers, and the keys are not setup ye...I noticed a problematic behavior with sipe-pidgin, its farstream backend, and the way the srtp audio stream is passed from libnice to the siren decoder.
When the element starts to receive encrypted buffers, and the keys are not setup yet, the buffers are pushed out undecoded in ``gst_srtp_dec_chain()``. the problem here is that the size of the rtp buffer is not the same when data are decoded (52 bytes) and undecoded (62 bytes), and the siren decoder in my case expects fixed-size (40 bytes + 12 bytes rtp header) buffers.
The first problem is that the siren decoder is not hardened enough to handle a random content (overflow in the huffman tables) but this can be worked around.
The second problem is more annoying, because the siren decoder has no mechanism to detect and resync on the beginning of "valid" data, when the crypto is finally installed and the buffers pushed out now have their correct size. The visible consequence is that siren decoder fails, and takes down the pipeline partially:
```
(23:05:10) mediamanager: gst pipeline error: Internal data stream error.
(23:05:10) mediamanager: Debug details: ../libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstBin:conf_0x6160000cf9d0/FsRtpConference:fsrtpconference1/GstBin:bin8/GstNiceSrc:nicesrc4:
streaming stopped, reason error (-5)
(23:05:10) backend-fs2: gst error Internal data stream error.
debugging: ../libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstBin:conf_0x6160000cf9d0/FsRtpConference:fsrtpconference1/GstBin:bin8/GstNiceSrc:nicesrc4:
streaming stopped, reason error (-5)
```
This is not systematic, since introducing several times a 10 bytes offsets in the 40-bytes chucked stream will resync successfully 1 time out of 4 on average :)
Would it make sense to just ``goto drop_buffer`` instead of push_out when crypto is not setup yet?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1017Webrtcbin: "do-nack" seems to have no effect2019-07-15T13:58:58ZNeil YoungWebrtcbin: "do-nack" seems to have no effectI admit, I might be wrong. Beforehand. To not be misunderstood.
Scenario:
- Java app based upon org.freedesktop.gstreamer:gst1-java-core:1.1.0, JDK 1.8
- Mac OS 10.14.5
- Java application just sends test-video, but fetches video from re...I admit, I might be wrong. Beforehand. To not be misunderstood.
Scenario:
- Java app based upon org.freedesktop.gstreamer:gst1-java-core:1.1.0, JDK 1.8
- Mac OS 10.14.5
- Java application just sends test-video, but fetches video from remote (no audio at all)
- Remote clients: Raspberry PI based on UV4L, browser app (Chrome, Firefox)
- Gstreamer 1.16.0 via brew
I was trying to harden the Java/Gstreamer implementation, since it has the problem, that it shows up artefacts which do not disappear, once there are packet losses downstream.
For that I was able to obtain the RTP statistics. My current solution is to issue a FIR request towards remote, once I see increasing packet losses inbound. But no more than one FIR per 5 seconds. These FIR requests are visible in the received video and counted in the remote statistics (not in a browser, but this might be a problem of the browser implementation) and basically this solution works for me.
I wanted to give the "do-nack" thing a try, which is disabled by default. I'm able to set and retrieve the value of do-nack, having done that on both streams now.
I was thinking, that a significant packet-loss on the inbound stream would force the Java/Gstreamer app to send NACKs, but I can't see them in the statistics of the remote side. And I could also not see any impact on the quality of the received video. Not sure if this expectation is true at all.
So my assumption is, that there is no effect of this setting at all.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1018webrtcbin: no profile-level-id in offer's SDP2019-07-16T07:35:41Zcodinhowebrtcbin: no profile-level-id in offer's SDPI was testing 1.17.0.1 release and found that 'profile-level-id' disappeared from offer's SDP, however, the 'packetization-mode' and 'sprop-parameter-sets' are there, this leads to stream is not playing with firefox.I was testing 1.17.0.1 release and found that 'profile-level-id' disappeared from offer's SDP, however, the 'packetization-mode' and 'sprop-parameter-sets' are there, this leads to stream is not playing with firefox.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1019Webrtcbin: Can it be possible that a YUV buffer delivered by GStreamer is big...2019-07-15T16:15:15ZNeil YoungWebrtcbin: Can it be possible that a YUV buffer delivered by GStreamer is bigger than 3*width*height/2?as subject saysas subject sayshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1020mxfdemux: Sometimes seeks from the seeking thread in pull mode2023-05-25T16:36:32ZThibault Sauniertsaunier@igalia.commxfdemux: Sometimes seeks from the seeking thread in pull modeSeeking demuxers in pull mode should happen in the demuxer sinkpad task thread, with mxfdemux it is generally the case, but then there are cases where it start pulling data from the seeking thread, for example in
[`validate.file.playbac...Seeking demuxers in pull mode should happen in the demuxer sinkpad task thread, with mxfdemux it is generally the case, but then there are cases where it start pulling data from the seeking thread, for example in
[`validate.file.playback.seek_forward.op2b-mpeg2-wave_hd_mxf`](/uploads/16e33bcbafe2c3d18b2c517e7c95b6ea/op2b-mpeg2-wave_hd_mxf.md) (only current -validate test where I saw that happen):
```
gst_debug_get_stack_trace (gstinfo.c:2908)
gst_validate_report_new (gst-validate-report.c:746)
gst_validate_report_valist (gst-validate-reporter.c:187)
gst_validate_report (gst-validate-reporter.c:320)
gst_validate_pad_monitor_get_range_func (gst-validate-pad-monitor.c:2494)
gst_pad_get_range_unchecked (gstpad.c:4798)
gst_pad_pull_range (gstpad.c:5039)
gst_mxf_demux_pull_range (mxfdemux.c:310)
gst_mxf_demux_pull_klv_packet (mxfdemux.c:2293)
gst_mxf_demux_find_essence_element (mxfdemux.c:2933)
gst_mxf_demux_src_event (mxfdemux.c:3913)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_multi_queue_src_event (gstmultiqueue.c:2656)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_parse_src_event_default (gstbaseparse.c:4520)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_video_decoder_src_event_default (gstvideodecoder.c:1473)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_input_selector_event (gstinputselector.c:1559)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_stream_synchronizer_src_event (gststreamsynchronizer.c:204)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_transform_src_eventfunc (gstbasetransform.c:1971)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_deinterlace_src_event (gstdeinterlace.c:3149)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_transform_src_eventfunc (gstbasetransform.c:1971)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_transform_src_eventfunc (gstbasetransform.c:1971)
gst_video_scale_src_event (gstvideoscale.c:1149)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_transform_src_eventfunc (gstbasetransform.c:1971)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_transform_src_eventfunc (gstbasetransform.c:1971)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2110)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
event_forward_func (gstpad.c:3054)
gst_pad_forward (gstpad.c:3008)
gst_pad_event_default (gstpad.c:3105)
gst_pad_send_event_unchecked (gstpad.c:5772)
gst_pad_push_event_unchecked (gstpad.c:5417)
gst_pad_push_event (gstpad.c:5554)
gst_base_sink_send_event (gstbasesink.c:4635)
gst_element_send_event (gstelement.c:1860)
gst_bin_send_event (gstbin.c:3146)
gst_element_send_event (gstelement.c:1860)
gst_bin_send_event (gstbin.c:3146)
gst_element_send_event (gstelement.c:1860)
gst_play_sink_send_event_to_sink (gstplaysink.c:4827)
gst_play_sink_send_event (gstplaysink.c:4871)
gst_element_send_event (gstelement.c:1860)
gst_element_send_event (gstelement.c:1860)
gst_validate_scenario_execute_seek (gst-validate-scenario.c:657)
_execute_seek (gst-validate-scenario.c:729)
gst_validate_execute_action (gst-validate-scenario.c:1811)
execute_next_action_full (gst-validate-scenario.c:2118)
?? (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4:0x7f8f3cfa1cff)
g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4:0x7f8f3cfa1281)
?? (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4:0x7f8f3cfa164c)
g_main_loop_run (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4:0x7f8f3cfa195e)
main (gst-validate.c:529)
__libc_start_main (libc-start.c:310)
_start (/home/thiblahute/devel/gstreamer/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-1.0:0x55791ab9f206)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1021Simple rtmpsrc ! queue ! rtmpsink not working2021-09-24T14:37:33ZNeil DwyerSimple rtmpsrc ! queue ! rtmpsink not workingHey all,
Trying to get a simple `rtmpsrc location=<my nginx server> ! queue ! rtmpsink location=<twitch.tv ingest>` and it doesn't seem like rtmpsink starts sending any media (i.e. my queue is filling up).
I've tested this on 1.14.4 an...Hey all,
Trying to get a simple `rtmpsrc location=<my nginx server> ! queue ! rtmpsink location=<twitch.tv ingest>` and it doesn't seem like rtmpsink starts sending any media (i.e. my queue is filling up).
I've tested this on 1.14.4 and latest master. I've also tested each half of the this pipeline and it works, I can send to twitch with videotestsrc + audiotestsrc + flvmux. I can read from my nginx server via rtmpsrc + filesink, but for whatever reason this simple pipeline doesn't make it to twitch.
Any ideas?
[rtmp__1_.log_](/uploads/e64e20198ba91166fa247142754f84b4/rtmp__1_.log_)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1022msdkh264dec: horizontal green translucent bar at top of image2023-10-10T21:08:13ZAaron Boxermsdkh264dec: horizontal green translucent bar at top of imageWhen decoding the image below using `msdkh264dec` element
[msdk_artifact.mkv](/uploads/00603b1784eef90b611ab24cc19b9e0d/msdk_artifact.mkv)When decoding the image below using `msdkh264dec` element
[msdk_artifact.mkv](/uploads/00603b1784eef90b611ab24cc19b9e0d/msdk_artifact.mkv)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1023msdkh264dec: large memory leak2020-01-29T19:34:06ZAaron Boxermsdkh264dec: large memory leak`gst-launch-1.0 -v rtspsrc location="rtsp://SOME_URL" !rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! d3dvideosink`
has stable memory allocation
`gst-launch-1.0 -v rtspsrc location="rtsp://SOME_URL" !rtph264depay ! h264parse !...`gst-launch-1.0 -v rtspsrc location="rtsp://SOME_URL" !rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! d3dvideosink`
has stable memory allocation
`gst-launch-1.0 -v rtspsrc location="rtsp://SOME_URL" !rtph264depay ! h264parse ! msdkh264dec ! videoconvert ! d3dvideosink`
shows rapid constant increase in memory.
Environment: windows 10, coffee lake CPU, gst-build on latest master, MSDK 2018 SDKJulien IsorceJulien Isorcehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1024webrtcbin: + Janus (AWS/NAT) issue2019-07-21T07:55:13ZJavier Morgadewebrtcbin: + Janus (AWS/NAT) issueI hope this is the right place to rise the issue.
I've developed a small webrtcbin wrapper (based on webrtc-sendrecv.c) for Janus-GW including basic janus stuff.
Everything works quite well whenever both Janus and webrtcbin client ru...I hope this is the right place to rise the issue.
I've developed a small webrtcbin wrapper (based on webrtc-sendrecv.c) for Janus-GW including basic janus stuff.
Everything works quite well whenever both Janus and webrtcbin client run on the same subnet. On the other hand, I cannot manage to make it work if there's any NAT in between. It doesn't look like a problem with Janus, as far as I can manage to run the js demos samples without any problem.
You can find here one gist with two logs (both situations)
1-trace_jaanus_local_NET_ok.log
2-trace_janus_aws_ko.log
https://gist.github.com/jmorgade/4e7716fd2b1c91ca6563336b22f5d567
I don't quite understand where is the problem ... trickle negation and main steps work exactly equally in both cases but it gets stacked at bellow stage when Janus is running on i.e AWS sever. Actually, it never starts the dtls handshake.
0:00:10.112729724 �[332m23713�[00m 0x1a0d5e0 �[37mTRACE �[00m �[00m webrtcbin gstwebrtcbin.c:884:_collate_peer_connection_states:<sendrecv>�[00m ICE connection state: 0x8. DTLS connection state: 0x1
0:00:10.112737291 �[332m23713�[00m 0x1a0d5e0 �[37mTRACE �[00m �[00m webrtcbin gstwebrtcbin.c:947:_collate_peer_connection_states:<sendrecv>�[00m returning new
I miss many details about gstreamer webrtc implementation so any hint or suggestion where to debug ... would be really welcomehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1025av1enc: AV1E_SET_ROW_MT not available since libaom 1.0.02019-07-27T08:47:22ZSebastian Drögeav1enc: AV1E_SET_ROW_MT not available since libaom 1.0.0CC @wonchul
We need to conditionally enable it based on the libaom version used.CC @wonchul
We need to conditionally enable it based on the libaom version used.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1026dtls: Documentation needs to be improved2021-09-24T14:37:34ZFurkan Davulcudtls: Documentation needs to be improvedCurrent documentation of dtls plugin is very insufficient to understand how this plugin can be used in an application. A clearer example with a detailed explanation would make this plugin much more accessible and usable.Current documentation of dtls plugin is very insufficient to understand how this plugin can be used in an application. A clearer example with a detailed explanation would make this plugin much more accessible and usable.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1027check.gst-plugins-bad.elements_netsim.netsim_stress_delayed: Sometimes fails ...2019-08-05T13:59:27ZSebastian Drögecheck.gst-plugins-bad.elements_netsim.netsim_stress_delayed: Sometimes fails with "Got data flow before stream-start event"See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/jobs/440022
> ``` bash
> GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plu...See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/jobs/440022
> ``` bash
> GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly:gst-libav:gst-plugins-bad@/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_CHECKS='netsim_stress_delayed' GST_REGISTRY='/builds/gstreamer/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim.registry' /builds/gstreamer/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim
> ```
>
> ## elements_netsim output
>
> ```
> Running suite(s): netsim
>
>
> Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4299:gst_pad_chain_data_unchecked:<bin0:sink> Got data flow before stream-start event
>
> Stack trace:
> gst_debug_get_stack_trace (gstinfo.c:2932)
> gst_check_log_critical_func (gstcheck.c:281)
> g_logv (gmessages.c:1350)
> g_log (gmessages.c:1413)
> gst_pad_push_data (gstpad.c:4297)
> gst_pad_push (gstpad.c:4708)
> gst_harness_stress_buffer_func (gstharness.c:2960)
> g_thread_proxy (gthread.c:784)
> start_thread (pthread_create.c:486)
> __clone (clone.S:93)
>
> 0%: Checks: 1, Failures: 1, Errors: 0
> ../subprojects/gstreamer/libs/gst/check/gstcheck.c:286:F:general:netsim_stress_delayed:0: Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4299:gst_pad_chain_data_unchecked:<bin0:sink> Got data flow before stream-start event
> Check suite netsim ran in 0.592s (tests failed: 1)
>
> ```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1028No sound when encoding video with H2642019-08-08T19:30:28ZAdrien RouhèteNo sound when encoding video with H264Hello,
I stumbled upon a problem when changing codec from VP8 to H264. With H264 no sound is sent, while it works as expected with VP8. Also I only got this bug with Gstreamer 1.15 and above. With Gstreamer 1.14.4, I have sound both wi...Hello,
I stumbled upon a problem when changing codec from VP8 to H264. With H264 no sound is sent, while it works as expected with VP8. Also I only got this bug with Gstreamer 1.15 and above. With Gstreamer 1.14.4, I have sound both with VP8 and H264.
In order to reproduce this, I modified the [webrtc demo](https://github.com/centricular/gstwebrtc-demos) (the rust one) and changed the video source.
Here is the changes I made:
```rust
fn add_h264_video_source(&self) -> Result<(), Error> {
let videotestsrc = gst::ElementFactory::make("videotestsrc", None).unwrap();
videotestsrc.set_property_from_str("pattern", "ball");
videotestsrc.set_property("is-live", &true).unwrap();
let videoconvert = gst::ElementFactory::make("videoconvert", None).unwrap();
let videoconvertcaps = gst::Caps::new_simple("video/x-raw", &[("format", &"NV12")]);
let queue = gst::ElementFactory::make("queue", None).unwrap();
let x264enc = gst::ElementFactory::make("x264enc", None).unwrap();
x264enc.set_property_from_str("tune", "zerolatency");
x264enc.set_property_from_str("speed-preset", "superfast");
x264enc.set_property_from_str("bitrate", &"3000");
x264enc.set_property_from_str("key-int-max", &"7");
x264enc.set_property_from_str("pass", "cbr");
let x264enc_caps = gst::Caps::new_simple("video/x-h264", &[("profile", &"constrained-baseline")]);
let queue2 = gst::ElementFactory::make("queue", None).unwrap();
let h264parse = gst::ElementFactory::make("h264parse", None).unwrap();
h264parse.set_property_from_str("config-interval", "-1");
let h264parse_caps = gst::Caps::new_simple("video/x-h264", &[("split-packetized", &true)]);
let rtph264pay = gst::ElementFactory::make("rtph264pay", None).unwrap();
let queue3 = gst::ElementFactory::make("queue", None).unwrap();
self.0
.pipeline
.add_many(&[
&videotestsrc,
&videoconvert,
&queue,
&x264enc,
&queue2,
&h264parse,
&rtph264pay,
&queue3,
])
.unwrap();
videotestsrc.link(&videoconvert).unwrap();
videoconvert.link_filtered(&queue, Some(&videoconvertcaps)).unwrap();
queue.link(&x264enc).unwrap();
x264enc.link_filtered(&queue2, Some(&x264enc_caps)).unwrap();
queue2.link(&h264parse).unwrap();
h264parse.link_filtered(&rtph264pay, Some(&h264parse_caps)).unwrap();
rtph264pay.link(&queue3).unwrap();
let rtp_caps_h264 = gst::Caps::new_simple(
"application/x-rtp",
&[
("media", &"video"),
("encoding-name", &"H264"),
("payload", &96i32),
("config-interval", &-1),
("mtu", &1468),
]
);
queue3.link_filtered(&self.0.webrtcbin, Some(&rtp_caps_h264))?;
Ok(())
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1030[HLS] Micro-freeze issue when refreshing live playlist2022-04-05T13:27:55ZJuan Ramírez[HLS] Micro-freeze issue when refreshing live playlistI am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments to...I am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments totaling between 10 and 15 seconds of video). It happens with most of the HLS streams I've tested with (a list is available below).
I tried adding buffering between hlsdemux and tsdemux and managed to increase performance, but the micro-freeze issue is still present. I also tried several property values (connection-speed for hlsdemux, sizes and thresholds of the queues etc) with no improvement.
I wrote to the mailing list and got this response from Charles Turner, which I think is worth quoting here:
> This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. I had a quick peek at what might be going wrong and one hunch is that adaptivedemux isn't giving itself enough time, or is somehow stalling in updates_loop during the playlist updating logic. Maybe the target_duration wait times and/or the update timer cond bits need some adjustments.
Some of the workflows I've tried are the following:
```sh
gst-launch-1.0 playbin uri=$URL
```
```sh
gst-launch-1.0 souphttpsrc location="$URL" ! hlsdemux ! queue ! tsdemux name=demux \
demux. ! queue ! aacparse ! avdec_aac ! audioconvert ! autoaudiosink \
demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
```
With `URL` being one of the following:
* http://video3.earthcam.com/fecnetwork/hdtimes10.flv/.m3u8
* http://video3.earthcam.com/fecnetwork/9974.flv/.m3u8
* http://dwstream4-lh.akamaihd.net/i/dwstream4_live@131329/master.m3u8 (DW)
* https://5c21f7ec1999d.streamlock.net/8054/8054/playlist.m3u8 (TC, Ecuador)
* http://video.oct.dc.gov/out/u/DCN.m3u8 (DCN, provides various streams, use connection-speed to stick to one)
* http://unlimited2-us.dps.live/nettv/nettv.smil/playlist.m3u8 (NETTV, Argentina)
Streams that are not live, for example, [the ones at bitmovin.com](https://bitmovin.com/mpeg-dash-hls-examples-sample-streams) work ok (in the worst case you just have to set the appropriate bit rate).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1031basetsmuxjpeg2000: first demuxed frame's j2k buffer size is always 8 bytes sh...2019-11-20T12:57:05ZAaron Boxerbasetsmuxjpeg2000: first demuxed frame's j2k buffer size is always 8 bytes shorter than specified size in elementary stream headerTest pipeline:
```
videotestsrc pattern=ball ! openjpegenc ! jpeg2000parse ! mpegtsmux ! rtpmp2tpay ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
```
This pipeline fails with error:
`Required size ...Test pipeline:
```
videotestsrc pattern=ball ! openjpegenc ! jpeg2000parse ! mpegtsmux ! rtpmp2tpay ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
```
This pipeline fails with error:
`Required size (2375) greater than remaining size in buffer (2367)`
This only happens for the very first frame that is demuxed. For all others, required size (as specified in elementary stream header) matches actual size.
Error comes from this code block:
```
/* Check if we have enough data to create a valid buffer */
if ((stream->current_size - data_location) < (AUF[0] + AUF[1])) {
GST_ERROR ("Required size (%d) greater than remaining size in buffer (%d)",
AUF[0] + AUF[1], (stream->current_size - data_location));
goto error;
}
```
cc @bilboedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1032mpegts: problems with generated and published descriptor document2021-09-24T14:37:35ZRussel Windermpegts: problems with generated and published descriptor documentIt appears there may be some problems with the generated and published descriptor documentation for the MPEG-TS library.
Many of the DVB related descriptors are being listed as relating to ATSC rather than DVB. For example, GstMpegtsDVB...It appears there may be some problems with the generated and published descriptor documentation for the MPEG-TS library.
Many of the DVB related descriptors are being listed as relating to ATSC rather than DVB. For example, GstMpegtsDVBLinkageEvent is a DVB descriptor not an ATSC descriptor – there are many others that should not be on the page https://gstreamer.freedesktop.org/documentation/mpegts/gst-atsc-descriptor.html?gi-language=c but should be on the page https://gstreamer.freedesktop.org/documentation/mpegts/gst-dvb-descriptor.html?gi-language=chttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1033mxfdemux: can't handle Canon XF705 H265 10bit MXF video2022-10-12T09:13:32ZDavid Manpearlmxfdemux: can't handle Canon XF705 H265 10bit MXF videoI have been unable to decode H265 10-bit formats from Canon XF705.
My goal is to transcode into H264 with a GStreamer pipeline something like this:
```
gst-launch-1.0 filesrc location=A003C002H1901045W_CANON.MXF ! qtdemux ! h265parse ! a...I have been unable to decode H265 10-bit formats from Canon XF705.
My goal is to transcode into H264 with a GStreamer pipeline something like this:
```
gst-launch-1.0 filesrc location=A003C002H1901045W_CANON.MXF ! qtdemux ! h265parse ! avdec_h265 ! videoconvert ! videoscale ! video/x-raw,width=1280,height=720 ! x264enc ! h264parse ! queue ! mp4mux ! filesink location=video.mp4
Setting pipeline to PAUSED, PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: This file is invalid and cannot be played.
Additional debug info:
qtdemux.c(747): gst_qtdemux_pull_atom (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0:
atom has bogus size 101591860
ERROR: pipeline doesn't want to preroll.
```
I have had similar errors with decodebin, qtdemux, mxfdemux, and avdemux_mxf.
Example file download: https://www.dropbox.com/sh/q5m7cxgneq5z5h3/AAAh-d3FdhouZ2bFv2FajR18a?dl=0
*(note: Adobe Premiere can decode this file. Quicktime and VLC cannot)*
Here are some stats on the file:
```
gst-launch-1.0 --version
gst-launch-1.0 version 1.14.4
GStreamer 1.14.4
```
**ffprobe**:
```
ffprobe -hide_banner -show_format -show_streams -print_format json A003C002H1901045W_CANON.MXF
Metadata:
uid : 3b6f6487-8405-4901-802e-242719000075
generation_uid : 3b6f6487-8405-4903-802e-242719000075
company_name : CANON
product_name : XF705
product_version : 1.00
product_uid : 060e2b34-0401-010d-0e15-005658460400
Duration: 00:00:16.02, start: 0.000000, bitrate: 157466 kb/s
Stream #0:0: Video: none, none(progressive), 3840x2160, SAR 1:1 DAR 16:9,
9.94 fps, 59.94 tbr, 59.94 tbn, 59.94 tbc
"codec_type": "video",
"codec_tag": "0x0000",
"width": 3840,
"height": 2160,
"has_b_frames": 0,
"r_frame_rate": "60000/1001",
```
**mediainfo**:
```
mediainfo A003C002H1901045W_CANON.MXF
Format : MXF
Format version : 1.3
Format profile : OP-1a
Writing application : CANON XF705 1.00
Codec ID : 0E15000402100001-0E15000500013000
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
```
**Tim Müller suggested**:
This is what I get:
```
$ gst-play-1.0 A003C002H1901045W_CANON.MXF
WARNING No decoder available for type 'video/x-mxf-
06.0e.2b.34.04.01.01.0c.0e.15.00.04.02.10.00.01-
06.0e.2b.34.04.01.01.0c.0e.15.00.05.00.01.30.00'.
WARNING debug information: gsturidecodebin.c(921): unknown_type_cb ():
/GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0
```
[TM] "I think we're just missing mappings for H265 in mxfdemux from the looks
of it."https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1034openjpeg: proposal to remove support for OpenJPEG 1.X2019-07-28T18:23:49ZAaron Boxeropenjpeg: proposal to remove support for OpenJPEG 1.XVersions before `2.2` in fact are quite buggy and have significant security vulnerabilities.
Also, lossless encoding can be lossy. 1.5 is ancient.Versions before `2.2` in fact are quite buggy and have significant security vulnerabilities.
Also, lossless encoding can be lossy. 1.5 is ancient.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1035d3d11videosink: 2-3 times slower than d3dvideosink when decoding to RGBA2019-12-05T03:20:24ZAaron Boxerd3d11videosink: 2-3 times slower than d3dvideosink when decoding to RGBATest file:
[test.mkv](/uploads/4cf4fa2efc0d5282a7da4719ec720822/test.mkv)
This pipeline:
`gst-launch-1.0.exe filesrc location=test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3d11videosink`
is significantly slower ...Test file:
[test.mkv](/uploads/4cf4fa2efc0d5282a7da4719ec720822/test.mkv)
This pipeline:
`gst-launch-1.0.exe filesrc location=test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3d11videosink`
is significantly slower than this one:
`gst-launch-1.0.exe filesrc location=c://temp//test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3dvideosink`
on Windows 10, on VM and Coffee Lake bare metal
cc @seungha.yanghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1036player: Deadlock in uri-loaded signal when no signal dispatcher is supplied t...2021-09-24T14:37:37ZPhilippe Normandplayer: Deadlock in uri-loaded signal when no signal dispatcher is supplied to GstPlayerI'm actually not entirely sure it's a bug, one could argue it's an application-side issue, but here it goes. Attaching a test-case.
```
(gdb) t a a bt
Thread 2 (Thread 0x7ffff7414700 (LWP 20949)):
#0 0x00007ffff7ab2f59 in syscall () a...I'm actually not entirely sure it's a bug, one could argue it's an application-side issue, but here it goes. Attaching a test-case.
```
(gdb) t a a bt
Thread 2 (Thread 0x7ffff7414700 (LWP 20949)):
#0 0x00007ffff7ab2f59 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007ffff7c3a62c in g_mutex_lock_slowpath (mutex=mutex@entry=0x5555557c6088) at ../../../glib/gthread-posix.c:1320
#2 0x00007ffff7c3ae82 in g_mutex_lock (mutex=mutex@entry=0x5555557c6088) at ../../../glib/gthread-posix.c:1344
#3 0x00007ffff7f71f8e in gst_player_pause (self=0x5555557c6000 [GstPlayer]) at gstplayer.c:3190
#4 0x000055555555520d in uri_loaded_cb (player=0x5555557c6000 [GstPlayer], uri=0x7ffff001d0d0 "file:///home/phil/Videos/Agent 327.mp4", user_data=0x0) at /home/phil/player-deadlock.c:8
#8 0x00007ffff7cef97f in <emit signal ??? on instance 0x5555557c6000 [GstPlayer]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../../../gobject/gsignal.c:3447
#5 0x00007ffff7cd2c8d in g_closure_invoke (closure=0x5555557c8b90, return_value=0x0, n_param_values=2, param_values=0x7ffff7413aa0, invocation_hint=0x7ffff7413a20) at ../../../gobject/gclosure.c:810
#6 0x00007ffff7ce6365 in signal_emit_unlocked_R (node=node@entry=0x55555558a300, detail=detail@entry=0, instance=instance@entry=0x5555557c6000, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffff7413aa0) at ../../../gobject/gsignal.c:3635
#7 0x00007ffff7cef2be in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffff7413c70) at ../../../gobject/gsignal.c:3391
#9 0x00007ffff7f7900d in gst_player_signal_dispatcher_dispatch (self=<optimized out>, player=<optimized out>, emitter=0x7ffff7f6f3b0 <uri_loaded_dispatch>, data=0x7ffff0002040, destroy=0x7ffff7f6f200 <uri_loaded_signal_data_free>) at gstplayer-signal-dispatcher.c:46
#10 0x00007ffff7f76924 in gst_player_set_uri_internal (user_data=0x5555557c6000) at gstplayer.c:599
#11 0x00007ffff7bf0dd8 in g_main_dispatch (context=0x5555557c5c10) at ../../../glib/gmain.c:3182
#12 0x00007ffff7bf0dd8 in g_main_context_dispatch (context=context@entry=0x5555557c5c10) at ../../../glib/gmain.c:3847
#13 0x00007ffff7bf11c8 in g_main_context_iterate (context=0x5555557c5c10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3920
#14 0x00007ffff7bf14c2 in g_main_loop_run (loop=0x5555557c3fd0) at ../../../glib/gmain.c:4116
#15 0x00007ffff7f76378 in gst_player_main (data=0x5555557c6000) at gstplayer.c:2970
#16 0x00007ffff7c19415 in g_thread_proxy (data=0x55555568d540) at ../../../glib/gthread.c:784
#17 0x00007ffff7b87fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#18 0x00007ffff7ab84cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7ffff7415b80 (LWP 20885)):
#0 0x00007ffff7aad819 in __GI___poll (fds=0x5555557c8ce0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007ffff7bf1136 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x5555557c8ce0, timeout=<optimized out>, context=0x555555565730) at ../../../glib/gmain.c:4221
#2 0x00007ffff7bf1136 in g_main_context_iterate (context=0x555555565730, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3915
#3 0x00007ffff7bf14c2 in g_main_loop_run (loop=0x555555566930) at ../../../glib/gmain.c:4116
#4 0x00005555555552bd in main (argc=2, argv=0x7fffffffe558) at /home/phil/player-deadlock.c:22
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1037HLS steams with many subtitle variants are broken2021-09-24T14:37:38ZCharles TurnerHLS steams with many subtitle variants are brokenTry loading `https://pubads.g.doubleclick.net/ondemand/hls/content/2503702/vid/KaitlynSadtler_2018U/CHS/streams/c158db81-3bf7-4d01-921b-0f0ef58e4879/master.m3u8`. You will notice that startup is *very* slow, since it's going through 27 s...Try loading `https://pubads.g.doubleclick.net/ondemand/hls/content/2503702/vid/KaitlynSadtler_2018U/CHS/streams/c158db81-3bf7-4d01-921b-0f0ef58e4879/master.m3u8`. You will notice that startup is *very* slow, since it's going through 27 subtitle tracks ahead-of-time and creating streams for them.
Then we miss a lot of data and start 10-15 seconds into the video. At which point desync between the audio and video has started and the video is hard to watch.
This was discovered in WebKit when browing TED.com. See also https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/585 for another issue in the TED HLS streams.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1038Improve X11 capture with nvenc2019-08-21T07:21:19ZDan IslaImprove X11 capture with nvencWhen capturing from ximagesrc and encoding with NVENC, the RGB buffers from ximagesrc need to be converted to I420 before they can be used as a sink for the nvh264enc plugin. From what I can tell, there is no way to do this without the v...When capturing from ximagesrc and encoding with NVENC, the RGB buffers from ximagesrc need to be converted to I420 before they can be used as a sink for the nvh264enc plugin. From what I can tell, there is no way to do this without the videoconvert plugin, which is quite CPU intensive when streaming at 1080p, 60fps or better.
It looks like the NVENC API supports [ARGB and ABGR formats](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/nvcodec/nvEncodeAPI.h#L341), is it possible to use those formats with ximagesrc and eliminate the need for videoconvert? Alternatively, is there any way to move the color-space conversion to the GPU?
NVIDIA also has a [frame buffer capture SDK (NVFBC)](https://developer.nvidia.com/capture-sdk) which can capture and encode to H.264. This would be another way to free up the CPU and possibly improve capture performance.
The capture SDK comes with an example C program, it would be great to see that functionality as a source plugin.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1039nvenc: build failure on msvc x862019-08-21T07:21:19ZTim-Philipp Müllertim@centricular.comnvenc: build failure on msvc x86Build on 32-bit MSVC fails like [this](https://gitlab.freedesktop.org/xclaesse/gst-ci/-/jobs/457499):
```
[3340/3809] Compiling C object subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.
FAILED: subprojects/gst-plu...Build on 32-bit MSVC fails like [this](https://gitlab.freedesktop.org/xclaesse/gst-ci/-/jobs/457499):
```
[3340/3809] Compiling C object subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.
FAILED: subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj
cl @subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.rsp
gstnvenc.c(53): error C2373: 'NvEncOpenEncodeSessionEx': redefinition; different type modifiers
nvEncodeAPI.h(3087): note: see declaration of 'NvEncOpenEncodeSessionEx'
gstnvenc.c(61): error C2373: 'NvEncDestroyEncoder': redefinition; different type modifiers
nvEncodeAPI.h(3024): note: see declaration of 'NvEncDestroyEncoder'
gstnvenc.c(68): error C2373: 'NvEncGetEncodeGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2001): note: see declaration of 'NvEncGetEncodeGUIDs'
gstnvenc.c(76): error C2373: 'NvEncGetEncodeProfileGUIDCount': redefinition; different type modifiers
nvEncodeAPI.h(2032): note: see declaration of 'NvEncGetEncodeProfileGUIDCount'
gstnvenc.c(85): error C2373: 'NvEncGetEncodeProfileGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2069): note: see declaration of 'NvEncGetEncodeProfileGUIDs'
gstnvenc.c(94): error C2373: 'NvEncGetInputFormats': redefinition; different type modifiers
nvEncodeAPI.h(2131): note: see declaration of 'NvEncGetInputFormats'
gstnvenc.c(102): error C2373: 'NvEncGetEncodePresetCount': redefinition; different type modifiers
nvEncodeAPI.h(2193): note: see declaration of 'NvEncGetEncodePresetCount'
gstnvenc.c(111): error C2373: 'NvEncGetEncodePresetGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2237): note: see declaration of 'NvEncGetEncodePresetGUIDs'
gstnvenc.c(120): error C2373: 'NvEncGetEncodePresetConfig': redefinition; different type modifiers
nvEncodeAPI.h(2276): note: see declaration of 'NvEncGetEncodePresetConfig'
gstnvenc.c(129): error C2373: 'NvEncGetEncodeCaps': redefinition; different type modifiers
nvEncodeAPI.h(2163): note: see declaration of 'NvEncGetEncodeCaps'
gstnvenc.c(137): error C2373: 'NvEncGetSequenceParams': redefinition; different type modifiers
nvEncodeAPI.h(2862): note: see declaration of 'NvEncGetSequenceParams'
gstnvenc.c(145): error C2373: 'NvEncInitializeEncoder': redefinition; different type modifiers
nvEncodeAPI.h(2361): note: see declaration of 'NvEncInitializeEncoder'
gstnvenc.c(152): error C2373: 'NvEncReconfigureEncoder': redefinition; different type modifiers
nvEncodeAPI.h(3182): note: see declaration of 'NvEncReconfigureEncoder'
gstnvenc.c(159): error C2373: 'NvEncRegisterResource': redefinition; different type modifiers
nvEncodeAPI.h(3117): note: see declaration of 'NvEncRegisterResource'
gstnvenc.c(166): error C2373: 'NvEncUnregisterResource': redefinition; different type modifiers
nvEncodeAPI.h(3148): note: see declaration of 'NvEncUnregisterResource'
gstnvenc.c(173): error C2373: 'NvEncMapInputResource': redefinition; different type modifiers
nvEncodeAPI.h(2959): note: see declaration of 'NvEncMapInputResource'
gstnvenc.c(180): error C2373: 'NvEncUnmapInputResource': redefinition; different type modifiers
nvEncodeAPI.h(2994): note: see declaration of 'NvEncUnmapInputResource'
gstnvenc.c(187): error C2373: 'NvEncCreateInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2392): note: see declaration of 'NvEncCreateInputBuffer'
gstnvenc.c(194): error C2373: 'NvEncLockInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2768): note: see declaration of 'NvEncLockInputBuffer'
gstnvenc.c(201): error C2373: 'NvEncUnlockInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2798): note: see declaration of 'NvEncUnlockInputBuffer'
gstnvenc.c(208): error C2373: 'NvEncDestroyInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2421): note: see declaration of 'NvEncDestroyInputBuffer'
gstnvenc.c(215): error C2373: 'NvEncCreateBitstreamBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2456): note: see declaration of 'NvEncCreateBitstreamBuffer'
gstnvenc.c(222): error C2373: 'NvEncLockBitstream': redefinition; different type modifiers
nvEncodeAPI.h(2704): note: see declaration of 'NvEncLockBitstream'
gstnvenc.c(229): error C2373: 'NvEncUnlockBitstream': redefinition; different type modifiers
nvEncodeAPI.h(2734): note: see declaration of 'NvEncUnlockBitstream'
gstnvenc.c(236): error C2373: 'NvEncDestroyBitstreamBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2485): note: see declaration of 'NvEncDestroyBitstreamBuffer'
gstnvenc.c(243): error C2373: 'NvEncEncodePicture': redefinition; different type modifiers
nvEncodeAPI.h(2665): note: see declaration of 'NvEncEncodePicture'
```
(paths trimmed)
@seungha.yang any ideas? :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1040Documentation sometimes incorrect after plugin renames2021-09-24T14:37:39ZLoïc YhuelDocumentation sometimes incorrect after plugin renamesIt seems there is a weird issue in the documentation due to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/9bc2b04d5c00874d01b9b906b149366271ce59ed and https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/0127...It seems there is a weird issue in the documentation due to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/9bc2b04d5c00874d01b9b906b149366271ce59ed and https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/012782239e0d11bf1e5b16641d543df7bf132aa3.
There are still pages with the old plugin names, mentioning older gstreamer versions.
The gmedec/neonhttpsrc element pages can link to (randomly ?) either the new or the old plugin pages.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-gmedec.html, links to https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-gmedec.html (version 1.12.0).
It should have linked to the correct https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-gme.html.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-neonhttpsrc.html correctly points to https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-neonhttpsrc.html.
But there is still https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-neon.html (version 1.9.0.1).
On Fedora, it leads to conflicts when trying to install multilib devel packages since the documentation is slightly different (see https://bugzilla.redhat.com/show_bug.cgi?id=1680233).
In this case, both packages contain the pages with old and new plugin names, but :
- in the i686 package, gmedec/neonhttpsrc element pages link to gme/neonhttpsrc plugin pages respectively (new plugin names)
- in the x86_64 package, gmedec/neonhttpsrc element pages link to gmedec/neon plugin pages respectively (old plugin names)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1041h265parse: fails to parse video for HEVC main still profile2021-09-24T14:37:39ZNvGIGABYTEJrh265parse: fails to parse video for HEVC main still profileIssue is coming from codecparser from gst-plugins-bad. Used the following command to decode the main still profile encoded stream.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! vaapih265dec ! ...Issue is coming from codecparser from gst-plugins-bad. Used the following command to decode the main still profile encoded stream.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! vaapih265dec ! filesink location=/storage/output/HoneyBee_3840x2160_MainStill.yuv
Also tried the following command just to make sure parser can read the stream properly and observed similar issue. We can confirm that this issue is not coming from gstvaapi decoder instead it's coming from h265 codec parser. Added the log observed when running GST_DEBUG for more information.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! filesink location=/storage/output/HoneyBee_3840x2160_MainStill.yuv
0:00:00.154077842 29689 0x8c6af0 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
Got context from element 'vaapidecode_h265-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
0:00:00.156583488 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:799:gst_h265_parser_parse_short_term_ref_pic_sets: value greater than max. value: 1, max 0
0:00:00.156632914 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:845:gst_h265_parser_parse_short_term_ref_pic_sets: error parsing "ShortTermRefPicSet Parameters"
0:00:00.156644478 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:1827:gst_h265_parse_sps: error parsing "Sequence parameter set"
0:00:00.156665437 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:799:gst_h265_parser_parse_short_term_ref_pic_sets: value greater than max. value: 1, max 0
0:00:00.156682636 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:845:gst_h265_parser_parse_short_term_ref_pic_sets: error parsing "ShortTermRefPicSet Parameters"
0:00:00.156692946 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:1827:gst_h265_parse_sps: error parsing "Sequence parameter set"
0:00:00.156707318 29689 0x7c3f70 WARN h265parse gsth265parse.c:624:gst_h265_parse_process_nal:<h265parse0> failed to parse SPS:
0:00:00.156735598 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 33 SPS, Size: 45 will be dropped
0:00:00.156823129 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 34 PPS, Size: 8 will be dropped
0:00:00.156897167 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 19 SLICE_IDR_W_RADL, Size: 36756 will be dropped
0:00:00.156966044 29689 0x7c3f70 WARN baseparse gstbaseparse.c:3626:gst_base_parse_loop:<h265parse0> error: No valid frames found before end of stream
ERROR: from element /GstPipeline:pipeline0/GstH265Parse:h265parse0: No valid frames found before end of stream
Additional debug info:
gstbaseparse.c(3626): gst_base_parse_loop (): /GstPipeline:pipeline0/GstH265Parse:h265parse0
ERROR: pipeline doesn't want to preroll.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1042webrtcbin: Incorrect demonstration of usage of promise in webrtcbidirectional.c2019-12-31T13:22:30ZAshutosh Bhattwebrtcbin: Incorrect demonstration of usage of promise in webrtcbidirectional.cIn the test example "webrtcbidirectional.c", inside the `_on_answer_received` API, it is mentioned that there are two ways to tell webrtcbin that we don't want to be notified when the task is complete.
The second way shows the usage by ...In the test example "webrtcbidirectional.c", inside the `_on_answer_received` API, it is mentioned that there are two ways to tell webrtcbin that we don't want to be notified when the task is complete.
The second way shows the usage by interrupting a promise. Although the promise is created and interrupted in the code, it is never passed as a parameter in the emitted signal.
Refer : https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/tests/examples/webrtc/webrtcbidirectional.c#L102https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1043webrtc video rtp packets not transmitted over SOCKS5 proxy with GStreamer 1.162021-03-30T08:05:40ZChakradharwebrtc video rtp packets not transmitted over SOCKS5 proxy with GStreamer 1.16Recently moving to GStreamer 1.16 setup, having setup as below
This works well, video plays fine on browser
**[192.168.1.171(Browser)]<----->[192.168.1.172(GStreamer webrtcbin)]**
This below setup does not work and no packets received...Recently moving to GStreamer 1.16 setup, having setup as below
This works well, video plays fine on browser
**[192.168.1.171(Browser)]<----->[192.168.1.172(GStreamer webrtcbin)]**
This below setup does not work and no packets received are shown on Chrome WebRTC Internals
**[192.168.43.140(Browser(Connects to same 192.168.1.172 via socks5 tunneling))]<----SOCKS5-PROXY--->[192.168.43.145 + 192.168.1.171 Dual network interface(SOCKS5 Proxy Server)]<----->[192.168.1.172(GStreamer webrtcbin)]**
With Same setup video plays fine on GStreamer 1.14, when running same code on GStreamer 1.16 setup this issue happens
Attached logs for first scenario with no proxy and also for second one with SOCKS5 proxy
[gst_debug_noproxy.log](/uploads/2da6d204762099143a02a1cdf7d57c44/gst_debug_noproxy.log)
[gst_debug_socks5.log](/uploads/18ae1906f760e66ebe5f11ad438afbb0/gst_debug_socks5.log)
Please let know if any more logs/details needed...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1044SRT srtsink with srtsrc fails locally with ":No room to store incoming packet"2022-04-04T06:50:29ZdanrossiSRT srtsink with srtsrc fails locally with ":No room to store incoming packet"I have communicated this elsewhere. I've been trying to do a test mpeg-ts send and receive locally, for testing ingesting into wowza remotely later. I am doing this test until OBS has SRT encoding support, as my UDP test via ffmpeg remot...I have communicated this elsewhere. I've been trying to do a test mpeg-ts send and receive locally, for testing ingesting into wowza remotely later. I am doing this test until OBS has SRT encoding support, as my UDP test via ffmpeg remotely barely functioned.
However the local transmission on the same machine fails as if there is not enough buffer to receive it. Using ffmpeg as a sender works, but delivering to a remote Wowza with too high bitrate produced the same errors.
Sender in a vmware or windows client. This chopmydata is required to work like pktsize in ffmpeg.
```
gst-launch-1.0 filesrc location=sintel_lang.ts ! tsparse set-timestamps=1 smoothing-latency=40000000 ! chopmydata step-size=188 min-size=188 max-size=1316 ! srtsink uri=srt://192.168.4.43:8088
```
```
12:18:07.499950/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 29 packets - lost delaying for 1024ms
12:18:07.508915/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 23 packets - lost delaying for 1024ms
12:18:07.517874/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 24 packets - lost delaying for 1023ms
12:18:07.526882/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 26 packets - lost delaying for 1023ms
12:18:07.536077/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1023ms
12:18:07.545959/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 26 packets - lost delaying for 1024ms
12:18:07.554756/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 25 packets - lost delaying for 1024ms
12:18:07.563901/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1024ms
12:18:07.572710/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 33 packets - lost delaying for 1023ms
12:18:07.581747/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 22 packets - lost delaying for 1023ms
12:18:07.590694/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 33 packets - lost delaying for 1023ms
12:18:07.600530/mpegtsparse2-0:*E: SRT.d: SND-DROPPED 18 packets - lost delaying for 1024ms
```
Receiver client on windows
```
gst-launch-1.0 -v srtsrc uri="srt://:8088" ! decodebin ! videoconvert ! autovideosink
```
```
994379595 rcv-remain=2691
12:18:10.406079*E: SRT.c: %849110327:No room to store incoming packet: offset=6901 avail=5503 ack.seq=994372726 pkt.seq=994379627 rcv-remain=2688
12:18:10.406567*E: SRT.c: %849110327:No room to store incoming packet: offset=6902 avail=5503 ack.seq=994372726 pkt.seq=994379628 rcv-remain=2688
12:18:10.415093*E: SRT.c: %849110327:No room to store incoming packet: offset=6923 avail=5503 ack.seq=994372726 pkt.seq=994379649 rcv-remain=2688
12:18:10.415430*E: SRT.c: %849110327:No room to store incoming packet: offset=6924 avail=5503 ack.seq=994372726 pkt.seq=994379650 rcv-remain=2688
12:18:10.424044*E: SRT.c: %849110327:No room to store incoming packet: offset=6956 avail=5503 ack.seq=994372726 pkt.seq=994379682 rcv-remain=2688
12:18:10.424442*E: SRT.c: %849110327:No room to store incoming packet: offset=6957 avail=5503 ack.seq=994372726 pkt.seq=994379683 rcv-remain=2688
handling interrupt.
```
Ffmpeg sender OK
```
ffmpeg -fflags +genpts -re -i sintel_lang_2000k.mp4 -acodec copy -vcodec copy -map 0:v:0 -map 0:a:0 -map 0:a:2 -strict -2 -y -f mpegts 'srt://192.168.4.43:8088?pkt_size=1316&mode=caller'
```
Reference here.
https://github.com/Haivision/srt/issues/659#issuecomment-517934242https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1045mpeg4videoparse: API change: config-interval changed from uint to int2019-08-05T13:17:20ZSebastian Drögempeg4videoparse: API change: config-interval changed from uint to intCC @ocrete @den_erpel
Commit in question is https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/f5e7b4bd7384c0957bfb7909580eb4e9d72e0c97 but there seems to be no MR related to it (why?).
Changing a property type is always a...CC @ocrete @den_erpel
Commit in question is https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/f5e7b4bd7384c0957bfb7909580eb4e9d72e0c97 but there seems to be no MR related to it (why?).
Changing a property type is always an API change, even if weakly typed languages like C don't care about that if the types are of the same size (unless you happen to use the `GValue` API).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1046wpesrc: Doesn't work with fakevideosink2019-10-17T09:07:34ZPhilippe Normandwpesrc: Doesn't work with fakevideosink```
** (gst-launch-1.0:27757): CRITICAL **: 14:36:32.296: gst_gl_base_memory_alloc: assertion 'GST_IS_GL_BASE_MEMORY_ALLOCATOR (allocator)' failed
Thread 3 "wpesrc0:src" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thre...```
** (gst-launch-1.0:27757): CRITICAL **: 14:36:32.296: gst_gl_base_memory_alloc: assertion 'GST_IS_GL_BASE_MEMORY_ALLOCATOR (allocator)' failed
Thread 3 "wpesrc0:src" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffeb342700 (LWP 27820)]
0x00007ffff7d68885 in _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
554 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7d68885 in _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
#1 0x00007ffff7d69b8d in g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffeb341af0) at ../../../glib/gmessages.c:1371
#2 0x00007ffff7d69d5f in g_log (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7db957c "%s: assertion '%s' failed")
at ../../../glib/gmessages.c:1413
#3 0x00007ffff7d6a559 in g_return_if_fail_warning
(log_domain=log_domain@entry=0x0, pretty_function=pretty_function@entry=0x7ffff718b4e0 <__func__.25340> "gst_gl_base_memory_alloc", expression=expression@entry=0x7ffff718b4a8 "GST_IS_GL_BASE_MEMORY_ALLOCATOR (allocator)") at ../../../glib/gmessages.c:2767
#4 0x00007ffff7155e14 in gst_gl_base_memory_alloc (allocator=0x0, params=0x7fffdc013650) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglbasememory.c:761
#5 0x00007ffff716918b in gst_gl_memory_setup_buffer
(allocator=<optimized out>, buffer=0x555555851900, params=params@entry=0x7fffdc013650, tex_formats=tex_formats@entry=0x7fffeb341c64, wrapped_data=wrapped_data@entry=0x7fffeb341c68, n_wrapped_pointers=n_wrapped_pointers@entry=1) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglmemory.c:1494
#6 0x00007ffff7e77ad2 in gst_wpe_src_create(GstPushSrc*, GstBuffer**) (psrc=<optimized out>, buffer=0x7fffeb341d20) at ../subprojects/gst-plugins-bad/ext/wpe/gstwpesrc.cpp:147
#7 0x00007ffff71ef8c9 in gst_base_src_get_range (src=src@entry=0x55555581b450 [GstWpeSrc], offset=offset@entry=18446744073709551615, length=<optimized out>, buf=buf@entry=0x7fffeb341df8)
at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2527
#8 0x00007ffff71f1964 in gst_base_src_loop (pad=0x55555581c080 [GstPad]) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2851
#9 0x00007ffff7f33d01 in gst_task_func (task=0x555555851050 [GstTask]) at ../subprojects/gstreamer/gst/gsttask.c:328
#10 0x00007ffff7d8c263 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../glib/gthreadpool.c:308
#11 0x00007ffff7d8b89d in g_thread_proxy (data=0x5555556f3370) at ../../../glib/gthread.c:805
#12 0x00007ffff7c9efa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#13 0x00007ffff7bcf4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```Philippe NormandPhilippe Normandhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1047irtspparse: got drained data when handle_frame() does nothing2019-08-13T16:30:43ZOleksandrKvlirtspparse: got drained data when handle_frame() does nothingCurrent implementation fails on some pcap files with:
```
ERROR:../subprojects/gst-plugins-bad/gst/pcapparse/gstirtspparse.c:195:gst_irtsp_parse_handle_frame: assertion failed: (map.size >= IRTSPParse->current_offset)
```
Log shows that ...Current implementation fails on some pcap files with:
```
ERROR:../subprojects/gst-plugins-bad/gst/pcapparse/gstirtspparse.c:195:gst_irtsp_parse_handle_frame: assertion failed: (map.size >= IRTSPParse->current_offset)
```
Log shows that handle_frame() gets drained data when it does nothing(no skip, no flush).
Several days ago I also created issue on baseparse [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/420) because I thought it's a baseparse bug.
What's interesting is that implementation based on using skipsize works for this case. So I think there are 3 possibilities:
1. Current approach of doing nothing until we get payload is wrong.
2. Bug in GstBaseParse.
3. Error somewhere before irtspparse(pcap file or pcapparse).
While I was preparing test pcap file, I encountered some magic. When I removed RTSP part it stopped failing in assertion. So maybe the problem is in pcapparse.
Here's my full cmd line, pcap file is attached:
```
/opt/gstreamer/gst-uninstalled.py gst-launch-1.0 -v filesrc location=cam_full_2_rtp.pcap ! tee name=t ! pcapparse src-ip=176.109.192.74 src-port=554 ! irtspparse channel_id=0 ! application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=99 ! rtpjitterbuffer ! rtph264depay ! video/x-h264, framerate=25/1 ! h264parse ! queue ! mux. t. ! pcapparse src-ip=176.109.192.74 src-port=554 ! irtspparse channel_id=2 ! application/x-rtp, media=audio, clock-rate=8000, encoding-name=PCMU, payload=0 ! rtpjitterbuffer ! rtppcmudepay ! queue! mux. avimux name=mux ! filesink location=865c352f9f0db354e0facfca28ed7259.avi
```[cam_full_2_rtp.pcap](/uploads/7fd8bf36d452ea7ca4c13ff9e8ee2f83/cam_full_2_rtp.pcap)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1048decklink: Mode enum order has changed since 1.162020-10-14T13:36:27ZSebastian Drögedecklink: Mode enum order has changed since 1.16The following discussion from !303 should be addressed:
- [ ] @raytiley started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/303#note_152961): (+7 comments)
> should these be added at the ...The following discussion from !303 should be addressed:
- [ ] @raytiley started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/303#note_152961): (+7 comments)
> should these be added at the end of the enum as to not break current implementations that set the mode by number? e.g decklinkvideosink mode=17
CC @tpm1.17.90Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1049msdkh264dec: Having issue with this specific H264 video clip2019-08-26T18:38:02ZLim Siew Hoonmsdkh264dec: Having issue with this specific H264 video clipCommand pipeline:
1) gst-launch-1.0 filesrc location=JTBC_E72.170422.720p-NEXT_short.mp4 ! qtdemux ! h264parse ! msdkh264dec ! glimagesink
2) gst-launch-1.0 filesrc location=JTBC_E72.170422.720p-NEXT_short.mp4 ! qtdemux ! h264parse ! avd...Command pipeline:
1) gst-launch-1.0 filesrc location=JTBC_E72.170422.720p-NEXT_short.mp4 ! qtdemux ! h264parse ! msdkh264dec ! glimagesink
2) gst-launch-1.0 filesrc location=JTBC_E72.170422.720p-NEXT_short.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! glimagesink
Environment:
Run this video on Yocto linux.
Only having issue on msdkh264dec plugin (1) command pipeline. No issue in avdec_h264 plugins using (2) command pipeline.
This is customer video clip.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1051msdkmjpegdec: 4k video transcode mjpeg to h264 will fail intermittently when ...2020-01-16T04:32:40ZLim Siew Hoonmsdkmjpegdec: 4k video transcode mjpeg to h264 will fail intermittently when using msdk plugins.Gstreamer framework version: 1.16.0
Media driver: intel-media-19.2.1
libva: 2.5.0
MSDK library: 19.2.1
OS: Yocto Linux
Platform: APL-I
Command: gst-launch-1.0 filesrc location=Puppies_3840x2160_165mbps_60fps_422.avi ! avidemux ! ...Gstreamer framework version: 1.16.0
Media driver: intel-media-19.2.1
libva: 2.5.0
MSDK library: 19.2.1
OS: Yocto Linux
Platform: APL-I
Command: gst-launch-1.0 filesrc location=Puppies_3840x2160_165mbps_60fps_422.avi ! avidemux ! jpegparse ! msdkmjpegdec ! msdkh264enc ! filesink location=output.h264
Error message:
0:00:00.216491111 27466 0x5617fa4b6c00 LOG msdkdec gstmsdkdec.c:111:gst_msdkdec_get_oldest_frame:<msdkmjpegdec0> Oldest frame is 3 0:00:00.049999998 and 0 frames left
0:00:00.257495720 27466 0x5617fa4b6c00 INFO msdkdec gstmsdkdec.c:911:gst_msdkdec_handle_frame:<msdkmjpegdec0> mfxBitStream=> DataLength:383526 DataOffset:0 MaxLength:383526
0:00:00.257599870 27466 0x5617fa4b6c00 LOG msdkdec gstmsdkdec.c:111:gst_msdkdec_get_oldest_frame:<msdkmjpegdec0> Oldest frame is 3 0:00:00.049999998 and 1 frames left
0:00:00.257619405 27466 0x5617fa4b6c00 ERROR msdkdec gstmsdkdec.c:614:gst_msdkdec_finish_task:<msdkmjpegdec0> Couldn't find the cached MSDK surface
0:00:00.257868759 27466 0x5617fa4b6c00 LOG msdkdec gstmsdkdec.c:111:gst_msdkdec_get_oldest_frame:<msdkmjpegdec0> Oldest frame is 3 0:00:00.049999998 and 0 frames left
0:00:00.257934089 27466 0x5617fa4b6c00 ERROR msdkdec gstmsdkdec.c:614:gst_msdkdec_finish_task:<msdkmjpegdec0> Couldn't find the cached MSDK surface
0:00:00.257958776 27466 0x5617fa4b6c00 WARN msdkdec gstmsdkdec.c:1323:gst_msdkdec_drain:<msdkmjpegdec0> failed to finish the task 0x7fa00016fb30, but keep draining for the remaining frames
0:00:00.257989835 27466 0x5617fa4b6c00 LOG msdkdec gstmsdkdec.c:111:gst_msdkdec_get_oldest_frame:<msdkmjpegdec0> Oldest frame is 3 0:00:00.049999998 and 0 frames left
ERROR: from element /GstPipeline:pipeline0/GstAviDemux:avidemux0: Internal data stream error.
Additional debug info:
../../../gst-plugins-good-1.16.0/gst/avi/gstavidemux.c(5780): gst_avi_demux_loop (): /GstPipeline:pipeline0/GstAviDemux:avidemux0:
streaming stopped, reason error (-5)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1052ext/wayland: libdrm_dep not defined in meson.build2019-08-20T16:16:28ZThomas Coldrickext/wayland: libdrm_dep not defined in meson.build`libdrm_dep` is not defined in `ext/wayland/meson.build`, and so the libdrm headers are not added to the include path. This causes builds to fail with `./ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h: No such file or direc...`libdrm_dep` is not defined in `ext/wayland/meson.build`, and so the libdrm headers are not added to the include path. This causes builds to fail with `./ext/wayland/wlvideoformat.h:29:10: fatal error: drm_fourcc.h: No such file or directory` (at least in [freedesktop-sdk](https://gitlab.com/freedesktop-sdk/freedesktop-sdk).)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1053webrtcbin incompatible with Gio::init()2019-08-19T10:43:33ZAnkur deep jaiswalwebrtcbin incompatible with Gio::init()Hi, if we are using gstreamermm and glibmm,
and call Gio:init();
tested on gst 1.14.5 on ubuntu 18.04
stack trace
```
Thread #44 [gst-pc-ops] 9375 [core: 5] (Suspended : Signal : SIGSEGV:Segmentation fault)
0x0
g_socket_control_mes...Hi, if we are using gstreamermm and glibmm,
and call Gio:init();
tested on gst 1.14.5 on ubuntu 18.04
stack trace
```
Thread #44 [gst-pc-ops] 9375 [core: 5] (Suspended : Signal : SIGSEGV:Segmentation fault)
0x0
g_socket_control_message_deserialize() at 0x7fffeb2e232d
0x7fffeb2d7f79
0x7fffeb2dbfee
g_socket_receive_message() at 0x7fffeb2dc5b6
0x7fff863e88ae
0x7fff863e8e46
0x7fffeb2da039
g_main_context_dispatch() at 0x7ffff3c83285
0x7ffff3c83650
g_main_loop_run() at 0x7ffff3c83962
0x7fff865f8c2e
0x7ffff3cab195
start_thread() at pthread_create.c:463 0x7ffff347e6db
clone() at clone.S:95 0x7ffff31a788f
```
example code to demonstrate this
##### in https://github.com/centricular/gstwebrtc-demos/blob/master/sendrecv/gst/webrtc-sendrecv.c
##### in main function just call as the first line
#### Gio:init();https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1054openjpegenc: image/jp2 caps encoded as image/x-jpc2019-08-17T14:05:43ZAaron Boxeropenjpegenc: image/jp2 caps encoded as image/x-jpcmaster branch gst-bad + openjpeg 2.3.1
```
-v videotestsrc ! openjpegenc ! "image/jp2" ! jpeg2000parse ! mpegtsmux ! rtpmp2tpay ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink sync=FALSE
```
Gives ...master branch gst-bad + openjpeg 2.3.1
```
-v videotestsrc ! openjpegenc ! "image/jp2" ! jpeg2000parse ! mpegtsmux ! rtpmp2tpay ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink sync=FALSE
```
Gives the following error:
```
../gst/videoparsers/gstjpeg2000parse.c(355): gst_jpeg2000_parse_handle_frame (): /GstPipeline:pipeline0/GstJPEG2000Parse:jpeg2000parse0:
Missing contiguous code stream box for j2c stream
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1055webrtcbin: not emitting on-negotiation-needed when set to playing, pipeline h...2023-05-16T03:41:56ZSid Sethupathiwebrtcbin: not emitting on-negotiation-needed when set to playing, pipeline halts (1.14.4)I'm working on a pipeline that will eventually take a UDP/RTP source and output into an HLS sink and a webrtc sink. For now, I am testing with a videotestsrc. This pipeline is based off the centricular examples. When a client signals to ...I'm working on a pipeline that will eventually take a UDP/RTP source and output into an HLS sink and a webrtc sink. For now, I am testing with a videotestsrc. This pipeline is based off the centricular examples. When a client signals to initiate a WebRTC connection, a new webrtcbin element is added to a tee element, and its state is set to match the entire pipeline.
Occasionally, when a client signals to initiate a connection, I see no SDP offer made by the pipeline. Inspecting the logs shows the webrtcbin setting to PLAYING (to match the parent) but no "on-negotation-needed" signal is emitted. At the same time, the HLS sink also stops producing .ts segments.
I still haven't found a reliable way to reproduce this, but turning on more verbose logging seems to make it happen more frequently, making me think there is some race condition.
**Debug logs when connection is made and video displays:**
```
0:00:28.217246380 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:216:gst_webrtc_bin_pad_new:<'':sink_0> new visible pad with direction sink
0:00:28.218300727 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: NULL => READY
0:00:28.220457754 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: READY => PAUSED
0:00:28.220824519 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: PAUSED => PLAYING
0:00:28.224727744 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: PLAYING => PLAYING
0:00:28.320867499 20401 0x562953d6c540 INFO webrtcbin gstwebrtcbin.c:2202:_create_sdp_task:<webrtcbin_100> creating offer sdp with options (NULL)
0:00:28.322086844 20401 0x562953d6c540 DEBUG webrtcbin gstwebrtcbin.c:1691:sdp_media_from_transceiver:<webrtcbin_100> Adding 0-th caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, sprop-parameter-sets=(string)"Z0LAINkAUAW7AWoCAgKAAAH0gADqYEeMGSQ\=\,aMuMsg\=\=", payload=(int)96, seqnum-offset=(uint)7036, timestamp-offset=(uint)2899585439, ssrc=(uint)1295048211, a-framerate=(string)59.940059940059939, rtcp-fb-nack-pli=(boolean)true to 0-th media
Sending offer:
v=0
o=- 509666236988773271 0 IN IP4 0.0.0.0
...
```
**Debug logs when error above happens:**
```
0:00:50.234836437 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:216:gst_webrtc_bin_pad_new:<'':sink_0> new visible pad with direction sink
0:00:50.235433167 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: NULL => READY
0:00:50.235758065 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: READY => PAUSED
0:00:50.236223956 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: PAUSED => PLAYING
0:00:50.237710978 20401 0x562953800d30 DEBUG webrtcbin gstwebrtcbin.c:3731:gst_webrtc_bin_change_state: changing state: PLAYING => PLAYING
<end of logging>
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1056mfx: full mfx file will not play2021-07-27T06:25:40ZAaron Boxermfx: full mfx file will not playFor this [mxf](https://www.dropbox.com/s/2277bd5njw9hnis/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV_01.mxf?dl=0) file, only the beginning of the clip will play:
```
gst-launch-1.0 playbin3 uri=file:///ECL01-SINGLE-CP...For this [mxf](https://www.dropbox.com/s/2277bd5njw9hnis/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV_01.mxf?dl=0) file, only the beginning of the clip will play:
```
gst-launch-1.0 playbin3 uri=file:///ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV_01.mxf
```
Compare with VLC or `ffplay`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1057v4l2src plugins with io-mode=3 (userptr) not working with msdkvpp plugin.2019-11-19T19:37:15ZLim Siew Hoonv4l2src plugins with io-mode=3 (userptr) not working with msdkvpp plugin.I'm USB camera with v4l2src and io-mode=3 is userptr is not working for msdkvpp. But it is working for vaapipostproc and videoconvert.
Environment : Yocto Linux, Gstreamer Framework 1.16.0/master branch,
Command pipeline:
export G...I'm USB camera with v4l2src and io-mode=3 is userptr is not working for msdkvpp. But it is working for vaapipostproc and videoconvert.
Environment : Yocto Linux, Gstreamer Framework 1.16.0/master branch,
Command pipeline:
export GST_GL_PLATFORM=egl
gst-launch-1.0 v4l2src io-mode=3 num-buffers=100 ! msdkvpp ! glimagesink --> not working
gst-launch-1.0 v4l2src io-mode=3 num-buffers=100 ! videoconvert ! glimagesink --> working
gst-launch-1.0 v4l2src io-mode=3 num-buffers=100 ! vaapipostproc ! glimagesink --> workinghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1058msdkvpp: deprecate mirror and rotation and use video-direction2020-01-16T04:32:37ZVíctor Manuel Jáquez Lealmsdkvpp: deprecate mirror and rotation and use video-directionmsdkvpp wrongly added a rotation property when video-direction property is commonly used in gstreamer. rotation shall be marked as deprecated and add video-directionmsdkvpp wrongly added a rotation property when video-direction property is commonly used in gstreamer. rotation shall be marked as deprecated and add video-directionhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1059msdkvpp: handle orientation and navigation events2021-09-24T14:37:41ZHaihao Xiangmsdkvpp: handle orientation and navigation eventsmsdkvpp should be able to handle the the orientation events from upstreammsdkvpp should be able to handle the the orientation events from upstreamhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1061msdk: msdkenc/dec with videoconvert causes crash2019-09-10T14:13:46ZSeungha Yangseungha@centricular.commsdk: msdkenc/dec with videoconvert causes crash- OS: CentOS Linux release 7.4.1708
- gst-version: master (1.16 also same)
command
` GST_DEBUG=msdk*:6 gst-launch-1.0 filesrc location=trailer.mp4 ! qtdemux ! h264parse ! msdkh264dec ! videoconvert ! videoscale ! videoconvert ! vide...- OS: CentOS Linux release 7.4.1708
- gst-version: master (1.16 also same)
command
` GST_DEBUG=msdk*:6 gst-launch-1.0 filesrc location=trailer.mp4 ! qtdemux ! h264parse ! msdkh264dec ! videoconvert ! videoscale ! videoconvert ! videorate ! video/x-raw,width=1920,height=1080,framerate=60/1 ! msdkh264enc bitrate=6000 gop-size=60 ! h264parse ! mp4mux ! filesink location=1080_avc.mp4`
The test file is well known sintel trailer https://www.w3.org/2010/05/video/mediaevents.html
callstack
```
#0 0x00007f30e1990279 in waitpid () at /lib64/libpthread.so.0
#1 0x00007f30e1e0d923 in g_on_error_stack_trace () at /lib64/libglib-2.0.so.0
#2 0x0000000000403885 in fault_spin ()
#3 0x0000000000403860 in fault_handler_sighandler (signum=11)
#4 0x00007f30e19906d0 in <signal handler called> () at /lib64/libpthread.so.0
#5 0x00007f30d83b4663 in gst_msdk_context_put_surface_available (context=0x2397850, resp=0x2382ee0, surface=0x7f30c4004320)
#6 0x00007f30d83c4630 in gst_msdk_video_memory_release_surface (mem=0x238e3a0)
#7 0x00007f30d83b338e in gst_msdk_buffer_pool_release_buffer (pool=0x7f30c424e4d0, buf=0x7f30c432da20)
#8 0x00007f30e21590c8 in gst_buffer_pool_release_buffer (pool=0x7f30c424e4d0, buffer=0x7f30c432da20) at ../subprojects/gstreamer/gst/gstbufferpool.c:1364
#9 0x00007f30e2151a44 in _gst_buffer_dispose (buffer=0x7f30c432da20)
#10 0x00007f30e219824a in gst_mini_object_unref (mini_object=0x7f30c432da20)
#11 0x00007f30d5327191 in gst_buffer_unref (buf=0x7f30c432da20)
#12 0x00007f30d5328e47 in gst_video_rate_swap_prev (videorate=0x237ded0, buffer=0x0, time=0)
#13 0x00007f30d53286eb in gst_video_rate_reset (videorate=0x237ded0)
#14 0x00007f30d532d1f1 in gst_video_rate_stop (trans=0x237ded0)
#15 0x00007f30da06bf92 in gst_base_transform_activate (trans=0x237ded0, active=0) at ../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2445
#16 0x00007f30da06bff9 in gst_base_transform_sink_activate_mode (pad=0x2339d30, parent=0x237ded0, mode=GST_PAD_MODE_PUSH, active=0)
#17 0x00007f30e219badc in activate_mode_internal (pad=0x2339d30, parent=0x237ded0, mode=GST_PAD_MODE_PUSH, active=0)
#18 0x00007f30e219b62e in gst_pad_set_active (pad=0x2339d30, active=0)
#19 0x00007f30e217b54a in activate_pads (vpad=0x7ffdd4f19f10, ret=0x7ffdd4f19f60, active=0x7ffdd4f19fa4) at ../subprojects/gstreamer/gst/gstelement.c:3121
#20 0x00007f30e218f2f2 in gst_iterator_fold (it=0x21d2da0, func=0x7f30e217b50b <activate_pads>, ret=0x7ffdd4f19f60, user_data=0x7ffdd4f19fa4)
#21 0x00007f30e217b5de in iterator_activate_fold_with_resync (iter=0x21d2da0, func=0x7f30e217b50b <activate_pads>, user_data=0x7ffdd4f19fa4)
#22 0x00007f30e217b722 in gst_element_pads_activate (element=0x237ded0, active=0) at ../subprojects/gstreamer/gst/gstelement.c:3189
#23 0x00007f30e217ba14 in gst_element_change_state_func (element=0x237ded0, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#24 0x00007f30e217b077 in gst_element_change_state (element=0x237ded0, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#25 0x00007f30e217ae16 in gst_element_set_state_func (element=0x237ded0, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2987
#26 0x00007f30e217aa04 in gst_element_set_state (element=0x237ded0, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2888
#27 0x00007f30e214a3a9 in gst_bin_element_set_state (bin=0x2390060, element=0x237ded0, base_time=0, start_time=0, current=GST_STATE_READY, next=GST_STATE_NULL)
#28 0x00007f30e214b99e in gst_bin_change_state_func (element=0x2390060, transition=GST_STATE_CHANGE_READY_TO_NULL)
#29 0x00007f30e21afceb in gst_pipeline_change_state (element=0x2390060, transition=GST_STATE_CHANGE_READY_TO_NULL)
#30 0x00007f30e217b077 in gst_element_change_state (element=0x2390060, transition=GST_STATE_CHANGE_READY_TO_NULL)
#31 0x00007f30e217ae16 in gst_element_set_state_func (element=0x2390060, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2987
#32 0x00007f30e217aa04 in gst_element_set_state (element=0x2390060, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2888
#33 0x0000000000406930 in main (argc=30, argv=0x7ffdd4f1aa18)
Spinning. Please run 'gdb gst-launch-1.0 23945' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
```
log
```
0:00:00.024847773 23945 0x2347d90 INFO msdk msdk.c:195:msdk_open_session: MSDK implementation: 0x0402 (HARDWARE)
0:00:00.024870468 23945 0x2347d90 INFO msdk msdk.c:196:msdk_open_session: MSDK version: 1.25
Setting pipeline to PAUSED ...
0:00:00.064192373 23945 0x2347d90 INFO msdk msdk.c:195:msdk_open_session: MSDK implementation: 0x0402 (HARDWARE)
0:00:00.064209180 23945 0x2347d90 INFO msdk msdk.c:196:msdk_open_session: MSDK version: 1.25
0:00:00.064401706 23945 0x2347d90 DEBUG msdkcontext gstmsdkcontext.c:108:get_device_id: Opened the drm device node /dev/dri/renderD128
libva info: VA-API version 1.0.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
0:00:00.066467509 23945 0x2347d90 INFO msdkenc gstmsdkenc.c:1444:gst_msdkenc_start:<msdkh264enc0> Creating new context <msdkcontext0>
0:00:00.066542038 23945 0x2347d90 INFO msdkdec gstmsdkdec.c:670:gst_msdkdec_start:<msdkh264dec0> Found context <msdkcontext0> from neighbour
Pipeline is PREROLLING ...
Got context from element 'msdkh264enc0': gst.msdk.Context=context, gst.msdk.Context=(GstMsdkContext)"\(GstMsdkContext\)\ msdkcontext0";
0:00:00.174898618 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:589:gst_msdkdec_set_latency:<msdkh264dec0> Updating latency to 0:00:00.041666667 (1 frames)
Redistribute latency...
0:00:00.175012739 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:812 DataOffset:0 MaxLength:812
0:00:00.175268762 23945 0x23704f0 DEBUG msdkdec gstmsdkdec.c:795:gst_msdkdec_negotiate:<msdkh264dec0> Start Negotiating caps, pool and Init the msdk decdoer subsystem
0:00:00.192905406 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:553:gst_msdkdec_set_src_caps:<msdkh264dec0> new alloc caps = video/x-raw, format=(string)NV12, width=(int)864, height=(int)480, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)24/1
0:00:00.203248266 23945 0x23704f0 INFO msdkenc gstmsdkenc.c:1067:gst_msdkenc_set_format:<msdkh264enc0> This MSDK encoder uses video memory
0:00:00.221997642 23945 0x23704f0 DEBUG msdkenc gstmsdkenc.c:489:gst_msdkenc_init_encoder:<msdkh264enc0> Required 5 surfaces (5 suggested), allocated 5
0:00:00.229276978 23945 0x23704f0 DEBUG msdkenc gstmsdkenc.c:898:gst_msdkenc_set_src_caps:<msdkh264enc0> output caps: video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)4.2
0:00:00.229426221 23945 0x23704f0 INFO msdkenc gstmsdkenc.c:837:gst_msdkenc_set_latency:<msdkh264enc0> Updating latency to 0:00:00.066666667 (4 frames)
Redistribute latency...
0:00:00.229607845 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:310:gst_msdkdec_init_decoder:<msdkh264dec0> This MSDK decoder uses video memory
0:00:00.229703490 23945 0x23704f0 DEBUG msdkdec gstmsdkdec.c:399:gst_msdkdec_init_decoder:<msdkh264dec0> Required 7 surfaces (14 suggested)
0:00:00.230351426 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:1257:gst_msdkdec_decide_allocation:<msdkh264dec0> create new MSDK bufferpool
0:00:00.230474752 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 0 frames left
0:00:00.230674675 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:30 DataOffset:0 MaxLength:30
0:00:00.230691207 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 1 frames left
0:00:00.230778104 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:35 DataOffset:0 MaxLength:35
0:00:00.230793250 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 2 frames left
0:00:00.231437782 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:36 DataOffset:0 MaxLength:36
0:00:00.231455619 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 3 frames left
0:00:00.231930375 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:36 DataOffset:0 MaxLength:36
0:00:00.231948098 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 4 frames left
0:00:00.232267638 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:37 DataOffset:0 MaxLength:37
0:00:00.232284756 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 5 frames left
0:00:00.232606543 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:37 DataOffset:0 MaxLength:37
0:00:00.232623230 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 6 frames left
0:00:00.232949722 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:37 DataOffset:0 MaxLength:37
0:00:00.232968456 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 7 frames left
0:00:00.233434851 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 0 0:00:00.083333333 and 7 frames left
0:00:00.519106425 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 1 0:00:00.125000000 and 6 frames left
0:00:00.519214227 23945 0x23704f0 INFO msdkdec gstmsdkdec.c:928:gst_msdkdec_handle_frame:<msdkh264dec0> mfxBitStream=> DataLength:37 DataOffset:0 MaxLength:37
0:00:00.519230819 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 1 0:00:00.125000000 and 7 frames left
0:00:00.519564589 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 1 0:00:00.125000000 and 7 frames left
0:00:00.830187724 23945 0x23704f0 ERROR default video-frame.c:168:gst_video_frame_map_id: failed to map video frame plane 0
0:00:00.830206053 23945 0x23704f0 ERROR msdkenc gstmsdkenc.c:1257:gst_msdkenc_get_surface_from_frame:<msdkh264enc0> failed to map the frame for source
0:00:00.830214028 23945 0x23704f0 ERROR msdkenc gstmsdkenc.c:1393:gst_msdkenc_handle_frame:<msdkh264enc0> Surface pool is full
0:00:00.830300617 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 2 0:00:00.166666666 and 5 frames left
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
../subprojects/gst-plugins-good/gst/isomp4/qtdemux.c(6657): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
0:00:00.830466323 23945 0x2347d90 DEBUG msdkenc gstmsdkenc.c:549:gst_msdkenc_close_encoder:<msdkh264enc0> Closing encoder with context <msdkcontext0>
Caught SIGSEGV
0:00:00.832103248 23945 0x23704f0 LOG msdkdec gstmsdkdec.c:116:gst_msdkdec_get_oldest_frame:<msdkh264dec0> Oldest frame is 2 0:00:00.166666666 and 5 frames left
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1062OpenJPEG instead of Jasper2019-08-26T09:41:56ZMichael VetterOpenJPEG instead of JasperHi,
Jasper has a bunch of security issues that are not fixed after quite some time.
Several distributions dropped (or are in the process of dropping) jasper from their repos (AFAIK: Debian, Gentoo, Alpine, openSUSE).
Do you consider sw...Hi,
Jasper has a bunch of security issues that are not fixed after quite some time.
Several distributions dropped (or are in the process of dropping) jasper from their repos (AFAIK: Debian, Gentoo, Alpine, openSUSE).
Do you consider switching to OpenJPEG instead of Jasper for JPEG2000 support?
For a bit more details about the Jasper drop you can read [this](https://github.com/mdadams/jasper/issues/208).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1063msdk: use GST_ELEMENT_WARNING instead of GST_WARNING_OBJECT for msdk warning2021-09-24T14:37:41ZHaihao Xiangmsdk: use GST_ELEMENT_WARNING instead of GST_WARNING_OBJECT for msdk warningSee the requirement at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/620#note_212577See the requirement at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/620#note_212577https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1064msdkvpp: gst_msdkvpp_close forgot to free up memory allocated by gst_msdk_fra...2019-09-17T07:49:52ZLim Siew Hoonmsdkvpp: gst_msdkvpp_close forgot to free up memory allocated by gst_msdk_frame_alloc function.gst_msdk_frame_alloc has been called in gst_msdkvpp_initialize. But after finished using vpp, gst_msdkvpp_close will be called it terminate. But found out that gst_msdk_frame_alloc has been allocate the memory never get free up.
Gstrea...gst_msdk_frame_alloc has been called in gst_msdkvpp_initialize. But after finished using vpp, gst_msdkvpp_close will be called it terminate. But found out that gst_msdk_frame_alloc has been allocate the memory never get free up.
Gstreamer Framework: 1.16.0
command pipeline:
valgrind --leak-check=yes --log-file=valgrind.txt gst-launch-1.0 videotestsrc num-buffers=10 ! video/x-raw,format=UYVY,widt h=720,height=576 ! msdkvpp ! glimagesink
Attached the patch: [0001-msdkvpp-fixed-missing-gst_msdk_frame_free-in-gst_msd.patch](/uploads/8e4eb1a8018550f20f5bed6a75523466/0001-msdkvpp-fixed-missing-gst_msdk_frame_free-in-gst_msd.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1065tsdemux: Add an automatic latency mode2021-09-24T14:37:41ZNicolas Dufresnetsdemux: Add an automatic latency modeQuoted from https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/652#note_213781 :
> tsdemux doesn't output data until it's seen a PCR and a DTS on at least 1 stream. PCR has to happen every 100ms, but DTS/PTS are onl...Quoted from https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/652#note_213781 :
> tsdemux doesn't output data until it's seen a PCR and a DTS on at least 1 stream. PCR has to happen every 100ms, but DTS/PTS are only required to appear every 700ms, which is where the 700ms comes from.
>
> However, by the time it's ready to output data it might be possible to calculate how much data has been skipped and report a more accurate actual latency. If the input has timestamps on the buffers I can see how that could be done. Without them, in live mode you might have to base the answer on how much clock time has passed since the base-time and base the answer on that?
So using this approach, we could update the latency at the end of the pre-roll based on observed latency for the specific stream. This has the side effect that latency may change each time we need to resync (e.g. on discont ?).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1066gst-player: mp3 audio fast rewind then fast forward will exit with eos directly2021-09-24T14:37:42ZQi Hougst-player: mp3 audio fast rewind then fast forward will exit with eos directlyFast rewind then fast forward when play one mp3 audio, audio will exit directly at the first seek's stop time.
audio:
[Mpeg2L3_22kHz_64kbps_s_18DaftPunk_mplayer.mp3](/uploads/3e7de3670feb8dfb52aba2d28e31e122/Mpeg2L3_22kHz_64kbps_s_18Daf...Fast rewind then fast forward when play one mp3 audio, audio will exit directly at the first seek's stop time.
audio:
[Mpeg2L3_22kHz_64kbps_s_18DaftPunk_mplayer.mp3](/uploads/3e7de3670feb8dfb52aba2d28e31e122/Mpeg2L3_22kHz_64kbps_s_18DaftPunk_mplayer.mp3)
Finally I find the root cause. gst-player set stop type as GST_SEEK_TYPE_NONE when generate seek event with rate>=0.0, and take the previous stop time which can be seen from below code in function gst_segment_do_seek().
/* stop can be -1 if we have not configured a stop. */
switch (stop_type) {
case GST_SEEK_TYPE_NONE:
stop = segment->stop;
update_stop = FALSE;
break;
case GST_SEEK_TYPE_SET:
/* stop holds required value */
break;
case GST_SEEK_TYPE_END:
if (segment->duration != -1) {
stop = segment->duration + stop;
} else {
stop = segment->stop;
update_stop = FALSE;
}
break;
}
So gst-player need to set stop type as GST_SEEK_TYPE_SET when generate seek event with rate>=0.0 to keep desired stop time to avoid such issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1067nvcodec: features are not detected2022-06-26T04:25:29ZNaresh Kumarnvcodec: features are not detectedHi There,
Newbie here, I'm trying to get gstreamer to work with nvidia gpu. I've build the gstreamer using meson (gst-build).
gst-inspect-1.0 does not recognise any features from nvcodec plugin, also when I use exists option using gst...Hi There,
Newbie here, I'm trying to get gstreamer to work with nvidia gpu. I've build the gstreamer using meson (gst-build).
gst-inspect-1.0 does not recognise any features from nvcodec plugin, also when I use exists option using gst-inspect-1.0 command it does not recognise nvcodec plugin
```
# gst-inspect-1.0 --plugin nvcodec
Plugin Details:
Name nvcodec
Description GStreamer NVCODEC plugin
Filename /gst-build/build/subprojects/gst-plugins-bad/sys/nvcodec/libgstnvcodec.so
Version 1.17.0.1
License LGPL
Source module gst-plugins-bad
Binary package GStreamer Bad Plug-ins git
Origin URL Unknown package origin
0 features:
# gst-inspect-1.0 --exists nvcodec
#
```
Also nvcodec plugin is not getting detected by gst-inspect-1.0, if we are outside uninstalled environment.
> System details: Ubuntu 18.04 CUDA 10.1 (NVIDIA 2080ti GPU)
Not sure, if this is an issue or I'm doing a mistake. Please help.
Thanks, <br>
Naresh Ganesanhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1068Gstreamer Delayed linking failed2019-08-30T06:46:54ZNaresh KumarGstreamer Delayed linking failedHi There,
I'm trying to reproduce the pipeline mentioned in [MR71](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/71#note_123987).
Gstreamer meson build with nvcodec.
```
# gst-inspect-1.0 --version
gst-inspec...Hi There,
I'm trying to reproduce the pipeline mentioned in [MR71](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/71#note_123987).
Gstreamer meson build with nvcodec.
```
# gst-inspect-1.0 --version
gst-inspect-1.0 version 1.17.0
GStreamer 1.17.0 (GIT)
Unknown package origin
```
```
# gst-launch-1.0 filesrc location=/SampleVideo_1280x720_2mb.mkv ! matroskademux ! h264parse ! nvh264dec ! queue ! "video/x-raw(memory:GLMemory)" ! nvh264enc ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'nvh264enc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvh264dec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayEGL\)\ gldisplayegl0";
WARNING: from element /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Delayed linking failed.
Additional debug info:
../subprojects/gstreamer/gst/parse/grammar.y(510): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
failed delayed linking some pad of GstMatroskaDemux named matroskademux0 to some pad of GstH264Parse named h264parse0
ERROR: from element /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Internal data stream error.
Additional debug info:
../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c(5810): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
streaming stopped, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
Please let me know, any pointers would be really helpful.
Thanks,
Naresh Ganesanhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1069RTSP streaming using nvcodec is not working2019-08-30T06:42:53ZNaresh KumarRTSP streaming using nvcodec is not workingHi There,
I'm trying to build rtsp streaming pipeline using nvcodec, have mentioned below the pipeline. The stream is h264 encoded, there are no errors though but the flv file is empty.
`gst-launch-1.0 rtspsrc location=rtsp://192.168....Hi There,
I'm trying to build rtsp streaming pipeline using nvcodec, have mentioned below the pipeline. The stream is h264 encoded, there are no errors though but the flv file is empty.
`gst-launch-1.0 rtspsrc location=rtsp://192.168.1.4/Streaming/Channels/101 ! rtpbin ! rtph264depay ! nvh264dec ! video/x-raw ! nvh264enc ! h264parse ! flvmux ! filesink location=xyz.flv`
Any help would be really helpful.
Thanks, <br>
Naresh Ganesanhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1071Multiple RTSP streaming using nvcodec fails2019-11-04T16:15:51ZNaresh KumarMultiple RTSP streaming using nvcodec failsHi There,
When I try to stream 3 RTSP stream using gst-rtsp-server/examples/test-launch.c, I get the following error, from the third streaming instance. First two instance of the same pipeline works fine, only from the thrid instance,...Hi There,
When I try to stream 3 RTSP stream using gst-rtsp-server/examples/test-launch.c, I get the following error, from the third streaming instance. First two instance of the same pipeline works fine, only from the thrid instance, I face the following error.
```
./test-launch --port=8561 "rtspsrc location=rtsp://192.168.x.x/ ! rtph264depay ! h264parse ! nvh264dec ! videoconvert ! videoscale ! video/x-raw,width=640,height=480 ! nvh264enc ! h264parse ! rtph264pay name=pay0 pt=96"
0:00:14.199917995 13 0x55aaeea80540 ERROR GST_PIPELINE grammar.y:816:priv_gst_parse_yyparse: no element "nvh264enc"
0:00:14.199937286 13 0x55aaeea80540 ERROR GST_PIPELINE grammar.y:901:priv_gst_parse_yyparse: link has no sink [source=@0x7f15cc0de8d0]
0:00:14.199955866 13 0x55aaeea80540 ERROR GST_PIPELINE grammar.y:901:priv_gst_parse_yyparse: link has no source [sink=@0x7f15cc5a56c0]
0:00:18.501516789 13 0x7f1588004d90 ERROR nvdec gstnvdec.c:1092:gst_nvdec_decide_allocation:<nvh264dec0> failed to create OpenGL context
0:00:34.218310984 13 0x55aaeea80540 ERROR rtspclient rtsp-client.c:1079:find_media: client 0x55aaeec25710: can't prepare media
0:00:34.235106546 13 0x55aaeea80540 ERROR rtspclient rtsp-client.c:3165:handle_describe_request: client 0x55aaeec25710: no media
```
Any pointers will be really helpful.
Thanks, <br>
Naresh Ganesanhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1072nvh264enc : "Requested stream size is larger than the maximum configured siz...2019-09-02T04:44:54ZErik De Rijckenvh264enc : "Requested stream size is larger than the maximum configured size" when encoding a stream who's resolution has increased.I'm trying to real-time encode an application output into a video stream using the following pipeline in nodejs.
```
const pipeline = new gstreamer.Pipeline(
// scale & convert to RGBA
`appsrc name=source caps=video/x-ra...I'm trying to real-time encode an application output into a video stream using the following pipeline in nodejs.
```
const pipeline = new gstreamer.Pipeline(
// scale & convert to RGBA
`appsrc name=source caps=video/x-raw,format=${gstBufferFormat},width=${width},height=${height},framerate=60/1 !
tee name=t ! queue !
glupload !
glcolorconvert !
glshader fragment="
#version 120
#ifdef GL_ES
precision mediump float;
#endif
varying vec2 v_texcoord;
uniform sampler2D tex;
uniform float time;
uniform float width;
uniform float height;
void main () {
vec4 pix = texture2D(tex, v_texcoord);
gl_FragColor = vec4(pix.a,pix.a,pix.a,0);
}
"
vertex = "
#version 120
#ifdef GL_ES
precision mediump float;
#endif
attribute vec4 a_position;
attribute vec2 a_texcoord;
varying vec2 v_texcoord;
void main() {
gl_Position = a_position;
v_texcoord = a_texcoord;
}
" !
glcolorconvert ! video/x-raw(memory:GLMemory),format=NV12 !
nvh264enc gop-size=-1 qp-max=32 preset=low-latency-hp rc-mode=constqp !
video/x-h264,profile=baseline,stream-format=byte-stream,alignment=au,framerate=60/1 !
appsink name=alphasink
t. ! queue !
glupload !
glcolorconvert ! video/x-raw(memory:GLMemory),format=NV12 !
nvh264enc gop-size=-1 qp-max=32 preset=low-latency-hp rc-mode=constqp !
video/x-h264,profile=baseline,stream-format=byte-stream,alignment=au,framerate=60/1 !
appsink name=sink`
)
```
When the application is resized (enlarged), I update the caps of the `appsrc` input element in the pipeline.
```
this._src.caps = `video/x-raw,format=${gstBufferFormat},width=${width},height=${height},framerate=60/1`
```
However I am greeted with this error, after which all encoding stops.
```
app-endpoint-server_1 | 0:00:10.365270221 26 0x40aee80 WARN nvenc gstnvbaseenc.c:1173:gst_nv_base_enc_set_format:<enc> error: Requested stream size is larger than the maximum configured size
app-endpoint-server_1 | 0:00:10.365384370 26 0x40aee80 WARN videoencoder gstvideoencoder.c:685:gst_video_encoder_setcaps:<enc> rejected caps video/x-raw(memory:GLMemory), format=(string)NV12, width=(int)853, height=(int)699, framerate=(fraction)60/1, interlace-mode=(string)progressive, texture-target=(string)2D
app-endpoint-server_1 | 0:00:10.365513626 26 0x40aee80 WARN nvenc gstnvbaseenc.c:1173:gst_nv_base_enc_set_format:<enc> error: Requested stream size is larger than the maximum configured size
app-endpoint-server_1 | 0:00:10.365561478 26 0x40aee80 WARN videoencoder gstvideoencoder.c:685:gst_video_encoder_setcaps:<enc> rejected caps video/x-raw(memory:GLMemory), format=(string)NV12, width=(int)853, height=(int)699, framerate=(fraction)60/1, interlace-mode=(string)progressive, texture-target=(string)2D
app-endpoint-server_1 | 0:00:10.365593936 26 0x40aee80 WARN GST_PADS gstpad.c:4230:gst_pad_peer_query:<capsfilter2:src> could not send sticky events
```
Using the x264enc this pipeline works just fine. What's going on? Am I doing something wrong and/or how can I work around this error?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1073webrtcdsp: voice activity event2021-04-19T16:16:53ZAbdul Rehmanwebrtcdsp: voice activity eventCurrently, webrtcdsp VAD sends voice activity on a bus as far as I know, is it possible to send voice activity event to the next linked element, or add voice activity status as GstBuffer meta data?Currently, webrtcdsp VAD sends voice activity on a bus as far as I know, is it possible to send voice activity event to the next linked element, or add voice activity status as GstBuffer meta data?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1074nvh264enc: "ERROR:gstnvbaseenc.c:1761:_map_gl_input_buffer: code should not b...2021-09-24T14:37:42ZErik De Rijckenvh264enc: "ERROR:gstnvbaseenc.c:1761:_map_gl_input_buffer: code should not be reached"Using latest master branch that fixes dynamic resolution changes, the following error is displayed after several resolution changes have taken place.
```
0:00:02.063400810 820 0x3d876f0 FIXME nvenc gstnvenc.c:418...Using latest master branch that fixes dynamic resolution changes, the following error is displayed after several resolution changes have taken place.
```
0:00:02.063400810 820 0x3d876f0 FIXME nvenc gstnvenc.c:418:gst_nvenc_get_supported_input_formats: unmapped input format: 0x04000000
0:00:02.362396517 820 0x3d876f0 FIXME nvenc gstnvenc.c:418:gst_nvenc_get_supported_input_formats: unmapped input format: 0x04000000
0:00:02.362648702 820 0x3d876f0 FIXME nvenc gstnvenc.c:418:gst_nvenc_get_supported_input_formats: unmapped input format: 0x04000000
0:00:02.364554741 820 0x3f48d90 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<source:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
0:00:04.420770201 820 0x7fbac4005d90 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<source:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
0:00:04.421136682 820 0x3d876f0 WARN appsrc gstappsrc.c:1800:gst_app_src_push_internal:<source> do-timestamp=TRUE but buffers are provided before reaching the PLAYING state and having a clock. Timestamps will not be accurate!
(node:820): GStreamer-CRITICAL **: 13:48:28.296: gst_segment_to_stream_time: assertion 'segment->format == format' failed
(node:820): GStreamer-CRITICAL **: 13:48:28.594: gst_segment_to_stream_time: assertion 'segment->format == format' failed
(node:820): GStreamer-CRITICAL **: 13:48:29.088: gst_segment_to_stream_time: assertion 'segment->format == format' failed
(node:820): GStreamer-CRITICAL **: 13:48:29.936: gst_segment_to_stream_time: assertion 'segment->format == format' failed
(node:820): GStreamer-CRITICAL **: 13:48:29.997: gst_segment_to_stream_time: assertion 'segment->format == format' failed
0:00:37.064959257 820 0x7fbae40046d0 WARN nvenc gstnvbaseenc.c:1758:_map_gl_input_buffer: CUDA call failed: CUDA_ERROR_INVALID_VALUE, invalid argument
0:00:37.064998691 820 0x7fbae40046d0 ERROR nvenc gstnvbaseenc.c:1760:_map_gl_input_buffer:<enc> failed to copy GL texture 9 into cuda ret :1
**
ERROR:gstnvbaseenc.c:1761:_map_gl_input_buffer: code should not be reached
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1075frei0r-mixer-difference gst_segment_to_running_time: assertion 'segment->for...2021-09-24T14:37:42ZCarl Karstenfrei0r-mixer-difference gst_segment_to_running_time: assertion 'segment->format == format'This works:
```
gst-launch-1.0 -e \
videotestsrc ! mix. \
videotestsrc pattern=ball ! mix. \
frei0r-mixer-difference name=mix ! \
videoconvert ! xvimagesink
```
This does not:
```
gst-launch-1.0 -e \
videotestsrc ! mix. \
...This works:
```
gst-launch-1.0 -e \
videotestsrc ! mix. \
videotestsrc pattern=ball ! mix. \
frei0r-mixer-difference name=mix ! \
videoconvert ! xvimagesink
```
This does not:
```
gst-launch-1.0 -e \
videotestsrc ! mix. \
videotestsrc pattern=ball ! mix. \
frei0r-mixer-difference name=mix ! \
videoconvert ! x264enc ! mpegtsmux ! filesink location=diff.ts
```
juser@pdp11:~/temp/gst$ ./gst_diff.sh
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
(gst-launch-1.0:2040): GStreamer-CRITICAL **: 18:34:32.390: gst_segment_to_running_time: assertion 'segment->format == format' failed
(gst-launch-1.0:2040): GStreamer-CRITICAL **: 18:34:32.395: gst_segment_to_running_time: assertion 'segment->format == format' failed
juser@pdp11:~/temp/gst$ gst-inspect-1.0 frei0r-mixer-difference
Factory Details:
Rank none (0)
Long-name difference
Klass Filter/Editor/Video
Description Perform an RGB[A] difference operation between the pixel sources.
Author Sebastian Dröge <sebastian.droege@collabora.co.uk>, Jean-Sebastien Senecal
Plugin Details:
Name frei0r
Description frei0r plugin library
Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstfrei0r.so
Version 1.15.90
License LGPL
Source module gst-plugins-bad
Source release date 2019-04-11
Binary package GStreamer Bad Plugins (Ubuntu)
Origin URL https://launchpad.net/distros/ubuntu/+source/gst-plugins-bad1.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1077nvh264enc: Preset files are missing.2021-09-24T14:37:43ZErik De Rijckenvh264enc: Preset files are missing.I've noticed that encoding is unacceptably slow ie. 20ms/frame for a single 1080p stream, even after explicitly setting all tuning options to low latency + performance. Further expirementing show that streaming quality + encoding speed h...I've noticed that encoding is unacceptably slow ie. 20ms/frame for a single 1080p stream, even after explicitly setting all tuning options to low latency + performance. Further expirementing show that streaming quality + encoding speed had no effect regardless of what preset was choosen.
gst-inspect with debug flags reveals preset files are missing:
```
0:00:00.946877553 81 0x55dc31d0ca00 INFO preset gstpreset.c:141:preset_get_paths:<nvh264enc0> element_name: 'nvh264enc'
0:00:00.946893946 81 0x55dc31d0ca00 INFO preset gstpreset.c:151:preset_get_paths:<nvh264enc0> user_preset_dir: '/root/.local/share/gstreamer-1.0/presets'
0:00:00.946902144 81 0x55dc31d0ca00 INFO preset gstpreset.c:155:preset_get_paths:<nvh264enc0> user_preset_path: '/root/.local/share/gstreamer-1.0/presets/nvh264enc.prs'
0:00:00.946952697 81 0x55dc31d0ca00 INFO preset gstpreset.c:200:preset_get_paths:<nvh264enc0> system_preset_dir: '/usr/local/share/gstreamer-1.0/presets'
0:00:00.946963257 81 0x55dc31d0ca00 INFO preset gstpreset.c:203:preset_get_paths:<nvh264enc0> system_preset_path: '/usr/local/share/gstreamer-1.0/presets/nvh264enc.prs'
0:00:00.947040516 81 0x55dc31d0ca00 INFO preset gstpreset.c:290:preset_open_and_parse_header:<nvh264enc0> Unable to read preset file /root/.local/share/gstreamer-1.0/presets/nvh264enc.prs: No such file or directory
0:00:00.947063359 81 0x55dc31d0ca00 INFO preset gstpreset.c:290:preset_open_and_parse_header:<nvh264enc0> Unable to read preset file /usr/local/share/gstreamer-1.0/presets/nvh264enc.prs: No such file or directory
0:00:00.947080383 81 0x55dc31d0ca00 INFO preset gstpreset.c:543:gst_preset_default_get_preset_names:<nvh264enc0> Empty preset file
```
Google also does not seem know where such a preset file can be found.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1078msdk: msdkh264enc with 1920x1280 resolution + preview not working but with 19...2019-09-18T08:48:56ZLim Siew Hoonmsdk: msdkh264enc with 1920x1280 resolution + preview not working but with 1920x1080 working properlyLinux: Yocto Linux
Platform: APL-I
Gstreamer framework: 1.16.0
Case 1: encoding with 1920x1280 and preview, it will stuck. But if 1920x1080 no issue at all.
command1:
gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=N...Linux: Yocto Linux
Platform: APL-I
Gstreamer framework: 1.16.0
Case 1: encoding with 1920x1280 and preview, it will stuck. But if 1920x1080 no issue at all.
command1:
gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=NV12, width=1920, height=1280 ! tee name=tt ! queue ! msdkvpp ! glimagesink tt. ! msdkh264enc ! h264parse ! filesink location=test.264
Command2: filesink with async=fase include it, this command below are working fine.
gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=NV12, width=1920, height=1280 ! tee name=tt ! queue ! msdkvpp ! glimagesink tt. ! msdkh264enc ! h264parse ! filesink location=test.264 async=falsehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1079Windows DVB source2021-09-24T14:37:43ZkevintkoiWindows DVB sourceI am unable to find **'dvbsrc'** plugin after installation of gstreamer on my **Windows 10** .I tried installing gstreamer from various packages[https://gstreamer.freedesktop.org/data/pkg/windows/] **1.2.0,1.2.4,1.6.4,1.10.0,1.16.0,1.13....I am unable to find **'dvbsrc'** plugin after installation of gstreamer on my **Windows 10** .I tried installing gstreamer from various packages[https://gstreamer.freedesktop.org/data/pkg/windows/] **1.2.0,1.2.4,1.6.4,1.10.0,1.16.0,1.13.90**, but none of them had the 'dvbsrc' plugin.Is it because the plugin is *missing in the windows* installation packages ?
Can someone help me to get the plugin for windows?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1080fps frames drops with msdkvpp ! glimagesink options.2021-09-24T14:37:44Zanuragrightfps frames drops with msdkvpp ! glimagesink options.We are running following pipelines.
gst-launch-1.0 icamerasrc device-name=ox03a10_ficosa scene-mode=hdr printfps=true ! video/x-raw,format=NV12,width=1920,height=1280 ! msdkvpp ! glimagesink sync=falseWe are running following pipelines.
gst-launch-1.0 icamerasrc device-name=ox03a10_ficosa scene-mode=hdr printfps=true ! video/x-raw,format=NV12,width=1920,height=1280 ! msdkvpp ! glimagesink sync=falsehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1081vulkan: build error on Ubuntu Xenial "VK_MEMORY_PROPERTY_PROTECTED_BIT undecl...2019-09-12T08:23:30ZU. Artie Eoffvulkan: build error on Ubuntu Xenial "VK_MEMORY_PROPERTY_PROTECTED_BIT undeclared here"On Ubuntu Xenial environment, the following compile errors occur:
```
../gst-libs/gst/vulkan/gstvkdebug.c:59:4: error: 'VK_MEMORY_PROPERTY_PROTECTED_BIT' undeclared here (not in a function)
{VK_MEMORY_PROPERTY_PROTECTED_BIT, "protecte...On Ubuntu Xenial environment, the following compile errors occur:
```
../gst-libs/gst/vulkan/gstvkdebug.c:59:4: error: 'VK_MEMORY_PROPERTY_PROTECTED_BIT' undeclared here (not in a function)
{VK_MEMORY_PROPERTY_PROTECTED_BIT, "protected"},
^
../gst-libs/gst/vulkan/gstvkdebug.c:73:4: error: 'VK_MEMORY_HEAP_MULTI_INSTANCE_BIT' undeclared here (not in a function)
{VK_MEMORY_HEAP_MULTI_INSTANCE_BIT, "multi-instance"},
^
../gst-libs/gst/vulkan/gstvkdebug.c:73:4: error: initializer element is not constant
../gst-libs/gst/vulkan/gstvkdebug.c:73:4: note: (near initialization for 'vk_memory_heap_flags_map[1].flag_bit')
../gst-libs/gst/vulkan/gstvkdebug.c:86:4: error: 'VK_QUEUE_PROTECTED_BIT' undeclared here (not in a function)
{VK_QUEUE_PROTECTED_BIT, "protected"},
^
../gst-libs/gst/vulkan/gstvkdebug.c:86:4: error: initializer element is not constant
../gst-libs/gst/vulkan/gstvkdebug.c:86:4: note: (near initialization for 'vk_queue_flags_map[4].flag_bit')
ninja: build stopped: subcommand failed.
```
The bad commit is 2b7050120ee78f091f59d0c8022e4c243a08bf6b:
```
commit 2b7050120ee78f091f59d0c8022e4c243a08bf6b
Author: Matthew Waters <matthew@centricular.com>
Date: Wed Sep 11 19:24:50 2019 +1000
vulkan: dump most of the device information
Dump anything that can be queried using the physical device like features,
limits, queue properties, memory properties.
```
My software stack:
```
...
gstreamer (master) heads/master-0-g4812c4087fe3
gst-plugins-base (master) heads/master-0-gc8d0edfea9ed
gst-plugins-bad (master) heads/master-0-g68a51abdcdd5
$ dpkg -s libvulkan-dev
Package: libvulkan-dev
Status: install ok installed
Version: 1.0.61.1+dfsg1-1ubuntu1~16.04.1
Depends: libvulkan1 (= 1.0.61.1+dfsg1-1ubuntu1~16.04.1)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1082gstopenh264enc.cpp:745:14: error: 'SEncParamExt' {aka 'struct TagEncParamExt'...2019-09-13T13:23:58ZTobias Muellergstopenh264enc.cpp:745:14: error: 'SEncParamExt' {aka 'struct TagEncParamExt'} has no member named 'bEnableSpsPpsIdAddition'I can't build gst-plugins-bad 1.16.0 due to a build failure.
I am not the only one as there is this report: http://buildlogs.pld-linux.org/index.php?dist=th&arch=x32&ok=0&name=gstreamer-plugins-bad&id=13caaf76-52a2-4dca-a8f8-00921a2c3f2b...I can't build gst-plugins-bad 1.16.0 due to a build failure.
I am not the only one as there is this report: http://buildlogs.pld-linux.org/index.php?dist=th&arch=x32&ok=0&name=gstreamer-plugins-bad&id=13caaf76-52a2-4dca-a8f8-00921a2c3f2b&action=tail showing the same error that I see in my build log:
https://flathub.org/builds/#/builders/28/builds/941
```
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I/app/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/libffi-3.2.1/include -pthread -I/app/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/libffi-3.2.1/include -pthread -DGST_USE_UNSTABLE_API -fno-strict-aliasing -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -Wall -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -g -fvisibility=hidden -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -MT libgstopenh264_la-gstopenh264dec.lo -MD -MP -MF .deps/libgstopenh264_la-gstopenh264dec.Tpo -c gstopenh264dec.cpp -fPIC -DPIC -o .libs/libgstopenh264_la-gstopenh264dec.o
gstopenh264enc.cpp: In function ‘gboolean gst_openh264enc_set_format(GstVideoEncoder*, GstVideoCodecState*)’:
gstopenh264enc.cpp:745:14: error: ‘SEncParamExt’ {aka ‘struct TagEncParamExt’} has no member named ‘bEnableSpsPpsIdAddition’
745 | enc_params.bEnableSpsPpsIdAddition = 0;
| ^~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [Makefile:917: libgstopenh264_la-gstopenh264enc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1083WebRTC stream getting stuck on limited network bandwidth2021-09-24T14:37:45ZLukas MahrWebRTC stream getting stuck on limited network bandwidthHi,
I would like to use GStreamer's WebRTCBin for live streaming video material.
When working with limited bandwidth, I discovered that the stream totally gets stuck if there's not enough bandwidth for the whole stream.
Interestingly, w...Hi,
I would like to use GStreamer's WebRTCBin for live streaming video material.
When working with limited bandwidth, I discovered that the stream totally gets stuck if there's not enough bandwidth for the whole stream.
Interestingly, when setting the bandwidth limit the frame rate decreases over a few seconds before getting stuck.
After increasing the available bandwidth again, the stream resumes.
Based on my experiences from other WebRTC-based solutions, my expectation would have been that the stream won't completely get stuck if there's just a little too less bandwidth available for the whole stream.
Instead, I expected that I would just recognize a small drop in frame rate compared to the full stream.
Here's a small example of GStreamer WebRTCBin's behavior when streaming with 2000 Kbit/s.
|Bandwidth Limit|Result|
|---|---|
|2050 Kbit/s|Stream is running without issues|
|1950 Kbit/s|Stream gets completely stuck|
|2000 Kbit/s|Randomly switching between video getting played and video stuck with an interval of 2-15 seconds|
I tried GStreamer Version 1.14.5 and 1.16.
For bandwidth limitation I used wondershaper: https://github.com/magnific0/wondershaper
Using the same setup with Kurento or the WebRTC implementation of Chromium browser instead of GStreamer WebRTCBin resulted in a noticeably better behavior that is not getting stuck.
Can someone explain this behavior and tell how to reach the expected behavior with frames getting dropped instead of the whole video getting stuck?
Thank you very much in advance<br>
Lukas Mahrhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1084icamerasrc dmabuf export is not working with msdkvpp2021-09-24T14:37:46ZLim Siew Hoonicamerasrc dmabuf export is not working with msdkvppThis issue is submit to track in gst-msdk plugins first.
Platform: APL-I
OS: Yocto Linux
Gstreamer Framework : 1.16.0
Currently I'm using icamerasrc with camera sensor ov10635 that support with dmabuf export implementation.
I found o...This issue is submit to track in gst-msdk plugins first.
Platform: APL-I
OS: Yocto Linux
Gstreamer Framework : 1.16.0
Currently I'm using icamerasrc with camera sensor ov10635 that support with dmabuf export implementation.
I found out step inside until media driver why vaCreateSurface is failing to map to dmabuf import to msdkvpp plugins is due to
DdiMediaUtil_AllocateSurface: gmmSize=2064384 > bo->size=2052096.
If I comment out check the condition for gmmSize > bo->size, it is working.
This is information I retrieve it before calling to vaCreateSurfaces in gst_msdk_export_dmabuf_to_vaSurface function.
Color format = UYVY
width=1280
height=800
data_size pass in from camera is 2050560.
Pitches[0] = 2560
Feedback from Carl:
For YUV packed surface,
You need add 2 extra line, then align with page size
2560 x 802 = 2053120 , then align with page size , it should be 2056192, still smaller than 2064384
But the value still smaller than gmmSize. Try to get from Prashanth feedback but he still not yet feedback.
Gst-command:
gst-launch-1.0 -v icamerasrc num-vc=1 device-name=ov10635-vc io-mode=2 ! video/x-raw,format=UYVY,width=1280,height=800 ! msdkvpp ! glimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1085rtpsrc sets non-existent 'host' property on dynudpsink2019-09-20T15:36:55ZJan Schmidtrtpsrc sets non-existent 'host' property on dynudpsinkrtpsrc uses dynudpsink for the RTCP output, but tries to set a non-existent 'host' property on it.
```
gst-launch-1.0 rtpsrc ! fakesink
Setting pipeline to PAUSED ...
(gst-launch-1.0:5146): GLib-GObject-WARNING **: 04:13:19.121: g_obje...rtpsrc uses dynudpsink for the RTCP output, but tries to set a non-existent 'host' property on it.
```
gst-launch-1.0 rtpsrc ! fakesink
Setting pipeline to PAUSED ...
(gst-launch-1.0:5146): GLib-GObject-WARNING **: 04:13:19.121: g_object_set_is_valid_property: object class 'GstDynUDPSink' has no property named 'host'
```
Removing the property setting is easy, but I'm not sure if it points at a deeper problem.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1086tsdemux over tcpclientsrc shouts THIS SHOULD NOT HAPPEN!2021-09-24T14:37:46ZVivia Nikolaidoutsdemux over tcpclientsrc shouts THIS SHOULD NOT HAPPEN!`gst-launch-1.0 videotestsrc ! queue ! x264enc ! h264parse ! queue ! mpegtsmux ! queue ! tcpserversink host=127.0.0.1 port=7777`
in another shell
```
$ env GST_DEBUG=3 gst-launch-1.0 tcpclientsrc host=127.0.0.1 port=7777 ! queue ! tspa...`gst-launch-1.0 videotestsrc ! queue ! x264enc ! h264parse ! queue ! mpegtsmux ! queue ! tcpserversink host=127.0.0.1 port=7777`
in another shell
```
$ env GST_DEBUG=3 gst-launch-1.0 tcpclientsrc host=127.0.0.1 port=7777 ! queue ! tsparse ! tsdemux ! queue ! h264parse ! avdec_h264 ! queue ! videoconvert ! autovideosink 2>&1 |grep HAPPEN
0:00:00.159897926 22701 0x5574894f99e0 WARN tsdemux tsdemux.c:2227:check_pending_buffers: THIS SHOULD NOT HAPPEN !
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1087dashdemux mpd seek doesn't allow for manifest-update-with-missing segment (ts...2021-10-20T07:20:22ZMike Fletcherdashdemux mpd seek doesn't allow for manifest-update-with-missing segment (ts less than start-time)We have a project where we use a dash demux from 1.16.0 reading from Shaka Packager which is producing a continuous output stream with timelines, but the continuous output stream may fail and recover such that the MPD will have say 30 se...We have a project where we use a dash demux from 1.16.0 reading from Shaka Packager which is producing a continuous output stream with timelines, but the continuous output stream may fail and recover such that the MPD will have say 30 segments at time T and then 1 segment at time T+1 where the segment at T+1 will have a start-time greater than the end-time of the segments at time T.
```
0:11:00.646132674 ESC[332m20869ESC[00m 0xc16de0 ESC[37mDEBUG ESC[00m ESC[00m dashdemux gstmpdparser.c:4857:gst_mpd_client_stream_seek:ESC[00m ts = 35:31:34.969765555 start=35:31:35.001755555
0:11:00.646150376 ESC[332m20869ESC[00m 0xc16de0 ESC[37mDEBUG ESC[00m ESC[00m dashdemux gstmpdparser.c:4862:gst_mpd_client_stream_seek:ESC[00m delta -31990000 duration 5000000000 produced repeat_index of -605618482
```
Because ts is less than the end-time of the segment (as well as the start-time), we use the calculation:
```
repeat_index = (ts - segment->start) / segment->duration;
```
which results in a large negative repeat_index. I don't know what the *correct* behaviour should be at a higher level, but there definitely seems to be an edge case in this calculation that should be addressed.
Possibly ts should be set to start-of-segment `if ts < segment->start`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1088camerabin: 'start-capture' signal freezes program2022-03-04T21:52:40ZTim Williamscamerabin: 'start-capture' signal freezes program(first posted this as an issue on [msys2/MINGW-packages](https://github.com/msys2/MINGW-packages/issues/5816) )
I'm trying to use gstreamer in a python program I have. I have eveything running fine using python3.4 and pygbject/gstream...(first posted this as an issue on [msys2/MINGW-packages](https://github.com/msys2/MINGW-packages/issues/5816) )
I'm trying to use gstreamer in a python program I have. I have eveything running fine using python3.4 and pygbject/gstreamer installed using [PyGObject for Windows](https://sourceforge.net/projects/pygobjectwin32/). The problem with this is I'd like to update to a newer python (from 3.4) and gstreamer (from 1.12)
I installed msys2 (x86_64) along with all the packages I needed for gstreamer. My program works just fine, in that I can connect to a camera and set the state to PLAYING. The problem comes when I try to capture the video using camerabin. As soon as I emit the 'start-capture' signal from my pipeline, my program locks up. I have to kill the python process.
I installed older versions of gstreamer on my msys2 environment, and found that I could capture frames with v1.12, but not 1.14.Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1089meson build fails on ubuntu 18.04: OpenEXR needs C++11 mode2020-07-10T11:23:49ZCarlos Alberto Lopez Perezmeson build fails on ubuntu 18.04: OpenEXR needs C++11 modeTrying to build gstreamer-plugins-bad 1.16.1 on Ubuntu 18.04 fails with:
```
# apt-cache policy libopenexr-dev
libopenexr-dev:
Installed: 2.2.0-11.1ubuntu1.1
Candidate: 2.2.0-11.1ubuntu1.1
Version table:
*** 2.2.0-11.1ubuntu1.1 ...Trying to build gstreamer-plugins-bad 1.16.1 on Ubuntu 18.04 fails with:
```
# apt-cache policy libopenexr-dev
libopenexr-dev:
Installed: 2.2.0-11.1ubuntu1.1
Candidate: 2.2.0-11.1ubuntu1.1
Version table:
*** 2.2.0-11.1ubuntu1.1 500
500 http://pt.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
2.2.0-11.1ubuntu1 500
500 http://pt.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
```
```
[478/638] Compiling C++ object 'ext/openexr/ee97218@@gstopenexr@sha/gstopenexrdec.cpp.o'.
FAILED: ext/openexr/ee97218@@gstopenexr@sha/gstopenexrdec.cpp.o
ccache c++ -Iext/openexr/ee97218@@gstopenexr@sha -Iext/openexr -I../../Source/gst-plugins-bad-1.16.1/ext/openexr -I. -I../../Source/gst-plugins-bad-1.16.1/ -Igst-libs -I../../Source/gst-plugins-bad-1.16.1/gst-libs -I/opt/webkitgtk/nightly/build/WebKitBuild/DependenciesGTK/Root/include/orc-0.4 -I/opt/webkitgtk/nightly/build/WebKitBuild/DependenciesGTK/Root/include/gstreamer-1.0 -I/opt/webkitgtk/nightly/build/WebKitBuild/DependenciesGTK/Root/include/glib-2.0 -I/opt/webkitgtk/nightly/build/WebKitBuild/DependenciesGTK/Root/lib/glib-2.0/include -I/usr/include/OpenEXR -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -O2 -g -Wno-non-virtual-dtor -fno-strict-aliasing -Wformat-nonliteral -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -Wno-error -O2 -g1 -fPIC -pthread -DHAVE_CONFIG_H -std=c++98 -MD -MQ 'ext/openexr/ee97218@@gstopenexr@sha/gstopenexrdec.cpp.o' -MF 'ext/openexr/ee97218@@gstopenexr@sha/gstopenexrdec.cpp.o.d' -o 'ext/openexr/ee97218@@gstopenexr@sha/gstopenexrdec.cpp.o' -c ../../Source/gst-plugins-bad-1.16.1/ext/openexr/gstopenexrdec.cpp
In file included from /usr/include/c++/7/cstdint:35:0,
from /usr/include/OpenEXR/ImfFrameBuffer.h:55,
from /usr/include/OpenEXR/ImfRgbaFile.h:51,
from ../../Source/gst-plugins-bad-1.16.1/ext/openexr/gstopenexrdec.cpp:30:
/usr/include/c++/7/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^~~~~
```
It seems Ubuntu has backported this patch https://github.com/openexr/openexr/commit/119eb2d4672e5c77a79929758f7e4c566f47c794 into openexr 2.2.0 with the include of `cstdint` inside `ImfFrameBuffer.h`
`cstdint` is a C++11 header, so C++11 support is required, but the Meson config file for this plugin is forcing C++98https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1090device providers: add Local to the provider's Klass when appropriate2021-09-24T14:37:47ZMathieu Duponchelledevice providers: add Local to the provider's Klass when appropriateIn !721 , a new device provider is added that monitors devices on the network. Some applications may care about those, some not, and appropriate classifying will let them filter the devices they're interested in with `gst_device_monitor_...In !721 , a new device provider is added that monitors devices on the network. Some applications may care about those, some not, and appropriate classifying will let them filter the devices they're interested in with `gst_device_monitor_add_filter()`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1091msdk: BRGx support in vpp2021-09-24T14:37:48Zanuragrightmsdk: BRGx support in vpp
Hi
I am working on BGRx Support into Msdkvpp.My testing pipeline.I am using icamerasrc.This pipeline failed pass msdkvpp through BRGx format.its works fine with videoconvert ! ximagesink options.
DISPLAY=:0 gst-launch-1.0 -m icameras...
Hi
I am working on BGRx Support into Msdkvpp.My testing pipeline.I am using icamerasrc.This pipeline failed pass msdkvpp through BRGx format.its works fine with videoconvert ! ximagesink options.
DISPLAY=:0 gst-launch-1.0 -m icamerasrc printfps=false num-buffers=100 device-name=mondello interlace-mode=alternate deinterlace_method=sw_bob ! "video/x-raw, format=BGRx, width=1920, height=1080" ! tee name=t ! queue ! msdkvpp ! glimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1092nvh265enc delta QP map support2021-09-24T14:37:49ZAlexandrenvh265enc delta QP map supportHello,
I am working on a project where I will need NVIDIA's NVENC to run with gstreamer on NVIDIA Jetson AGX. I need the [QP Delta Map](http://developer.download.nvidia.com/assets/cuda/files/NVENC_DA-06209-001_v07.pdf) function and this...Hello,
I am working on a project where I will need NVIDIA's NVENC to run with gstreamer on NVIDIA Jetson AGX. I need the [QP Delta Map](http://developer.download.nvidia.com/assets/cuda/files/NVENC_DA-06209-001_v07.pdf) function and this is not in the current version (it is in the vaapi plugin but I have a Nvidia card).
How I can get started on adding this to the [plugin](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/nvcodec/gstnvh265enc.c) as I am relatively new to gstreamer plugin writing? I suspect I will need to associate the API calls described in the [document](http://developer.download.nvidia.com/assets/cuda/files/NvEncodeAPI_v.6.0.pdf) with some sort of gstreamer syntax, prehaps uint32_t NV_ENC_RC_PARAMS::enableExtQPDeltaMap. For now a static implementation would be sufficient bue eventually a frame by frame input would be great.
Any help would be greatly appreciated.
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1093mpegvideoparse: Issues when playing an MPEG Video stream over http2021-09-24T14:37:49ZNicolas Dufresnempegvideoparse: Issues when playing an MPEG Video stream over httpWhile investigating gst-plugins-base#677, I found that playing http://samples.mplayerhq.hu/MPEG2/dothack2.mpg over http rather then from file yields broken output. I currently this is an issue in the parser itself.
With FFMPEG:
```
0:0...While investigating gst-plugins-base#677, I found that playing http://samples.mplayerhq.hu/MPEG2/dothack2.mpg over http rather then from file yields broken output. I currently this is an issue in the parser itself.
With FFMPEG:
```
0:00:00.364840116 18709 0x7f358c41fb70 ERROR libav :0:: Warning MVs not available
```
And VAAPI it's a bit worst:
```
Redistribute latency...
0:00:02.581879156 18412 0x7f1ddc38b770 ERROR vaapi gstvaapidecoder_mpeg2.c:908:parse_picture: failed to parse picture header
0:00:03.340900740 18412 0x7f1ddc38b770 ERROR vaapi gstvaapidecoder_mpeg2.c:1152:parse_slice: failed to parse slice header
0:00:01.9 / 0:00:17.9
** (gst-play-1.0:18412): CRITICAL **: 01:37:17.059: gst_video_codec_frame_unref: assertion 'frame->ref_count > 0' failed
```
cc @vjaquez for this onehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1094Failed to get android.media.MediaCodecInfo.CodecCapabilities2019-10-16T05:39:01ZSirius WuFailed to get android.media.MediaCodecInfo.CodecCapabilitiesI'm using master branch of gst-plugins-bad.
my program encounters the following error:
```
./sys/androidmedia/jni/gstamc-codeclist-jni.c:177:gst_amc_codeclist_static_init Failed to get android.media.MediaCodecInfo.CodecCapabilities cla...I'm using master branch of gst-plugins-bad.
my program encounters the following error:
```
./sys/androidmedia/jni/gstamc-codeclist-jni.c:177:gst_amc_codeclist_static_init Failed to get android.media.MediaCodecInfo.CodecCapabilities class: Failed to find class android/media/MediaCodecInfo/CodecCapabilities
```
Comparing gstamc-codeclist-jni.c with google's source code, google's source code uses `android/media/MediaCodecInfo$CodecCapabilities`, that is, `$` instread of `/`.
Maybe `android/media/MediaCodecInfo/CodecProfileLevel` also needs to be changed to `android/media/MediaCodecInfo$CodecProfileLevel`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1095getCodecCount and getCodecInfoAt are static methods.2019-10-16T05:41:55ZSirius WugetCodecCount and getCodecInfoAt are static methods.in /sys/androidmedia/jni/gstamc-codeclist-jni.c, getCodecCount and getCodecInfoAt are static methods.
What I've changed:
```
media_codeclist.get_codec_count =
- gst_amc_jni_get_method_id (env, &err, media_codeclist.klass,
+ ...in /sys/androidmedia/jni/gstamc-codeclist-jni.c, getCodecCount and getCodecInfoAt are static methods.
What I've changed:
```
media_codeclist.get_codec_count =
- gst_amc_jni_get_method_id (env, &err, media_codeclist.klass,
+ gst_amc_jni_get_static_method_id (env, &err, media_codeclist.klass,
"getCodecCount", "()I");
if (!media_codeclist.get_codec_count) {
GST_ERROR ("Failed to get android.media.MediaCodecList getCodecCount(): %s",
@@ -94,7 +95,7 @@ gst_amc_codeclist_static_init (void)
}
media_codeclist.get_codec_info_at =
- gst_amc_jni_get_method_id (env, &err, media_codeclist.klass,
+ gst_amc_jni_get_static_method_id (env, &err, media_codeclist.klass,
"getCodecInfoAt", "(I)Landroid/media/MediaCodecInfo;");
if (!media_codeclist.get_codec_count) {
GST_ERROR
@@ -104,6 +105,17 @@ gst_amc_codeclist_static_init (void)
return FALSE;
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1096Android tutorial 5 crashed while playing HLS link.2021-09-24T14:37:50ZSirius WuAndroid tutorial 5 crashed while playing HLS link.Hi,
I've modified Android tutorial 5 to play an HLS link using an RK3229 Android set top box.
I'm using the master branch with the newest patch which fixed codeclist jni. Before the patch the modified tutorial 5 can run but cannot use ...Hi,
I've modified Android tutorial 5 to play an HLS link using an RK3229 Android set top box.
I'm using the master branch with the newest patch which fixed codeclist jni. Before the patch the modified tutorial 5 can run but cannot use androidmedia, after the patch it crashes.
I've attached the log file. The following messages are extracted from the log.
* W/GStreamer+tsdemux: 0:00:05.893841961 0x8cb8f8c0 ../gst/mpegtsdemux/tsdemux.c:2266:check_pending_buffers THIS SHOULD NOT HAPPEN !
* W/libOpenSLES: Leaving Object::GetInterface (SL_RESULT_FEATURE_UNSUPPORTED)
* E/libEGL: validate_display:99 error 3008 (EGL_BAD_DISPLAY)
* E/libEGL: called unimplemented OpenGL ES API
* E/GLib: gst_amc_codec_configure: assertion 'GST_IS_AMC_SURFACE_TEXTURE_JNI (surface)' failed
* E/GStreamer+amcaudiodec: 0:00:06.161166419 0x8b7b8b50 ../sys/androidmedia/gstamcaudiodec.c:968:gst_amc_audio_dec_set_format:<amcaudiodec-omxgoogleaacdecoder0> Failed to configure codec
* E/GLib+stderr: ERROR:../sys/androidmedia/gstamcaudiodec.c:969:gst_amc_audio_dec_set_format: assertion failed: (err != NULL)
* A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 10850 (Thread-3)
I'm not sure which one causes the crash.
I'll test the modified tutorial 5 with another set top box tomorrow.
[amc.log](/uploads/7680687e9c2f0537557d9893f4890348/amc.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1097msdkvpp: add crop support2019-10-24T13:55:57ZU. Artie Eoffmsdkvpp: add crop supportmsdkvpp should allow users to specify cropping via properties: crop-left, crop-right, crop-top and crop-bottom.msdkvpp should allow users to specify cropping via properties: crop-left, crop-right, crop-top and crop-bottom.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1098ksvideosrc: MS Surface cameras capture green images and at low frame rate2021-04-07T17:01:06ZJeffksvideosrc: MS Surface cameras capture green images and at low frame rateRelatively recent Microsoft Surface cameras (near as I can tell, any of the models with integrated "Windows Hello" support) do not work well when providing video data to ksvideosrc. Though reported seemingly okay to the device provider, ...Relatively recent Microsoft Surface cameras (near as I can tell, any of the models with integrated "Windows Hello" support) do not work well when providing video data to ksvideosrc. Though reported seemingly okay to the device provider, these cameras produce images with strong green tint and at one frame per second, delayed by about three seconds. I attached a screen shot showing the green tint: ![green](/uploads/af89fdef278e8dbb5e8ae1b47fe13d52/green.PNG)
Using GStreamer 32-bit build (downloaded from Freedesktop) for 1.16.1, I run simply:
gst-launch-1.0.exe ksvideosrc ! autovideosink
Video streams just fine with the native camera app or when setup through graphedt (the WDK tool) or even via Chrome at https://webrtc.github.io/samples/src/content/getusermedia/resolution/.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1099Error received from element source: Could not get/set settings from/on resource.2021-09-24T14:37:50ZDhanvarsh DhanvarshError received from element source: Could not get/set settings from/on resource.Video is being played and then I am the getting the below error quite often
'Error received from element source: Could not get/set settings from/on resource.'
The above error I am getting and I am using Gstreamer version 1.16.0
Can an...Video is being played and then I am the getting the below error quite often
'Error received from element source: Could not get/set settings from/on resource.'
The above error I am getting and I am using Gstreamer version 1.16.0
Can any one tell me why I am getting the above error.?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1100GstTranscode gir can't be cross compiled because it tries to access target ha...2019-10-19T19:37:32ZAlistair BuxtonGstTranscode gir can't be cross compiled because it tries to access target hardwareI have previously been able to cross compile gir for gstreamer, base, good, bad, ugly, and rtsp-server using 1.16.1 and hacking the meson.build to skip the cross compile check. The need to hack the meson.build was fixed recently - see ht...I have previously been able to cross compile gir for gstreamer, base, good, bad, ugly, and rtsp-server using 1.16.1 and hacking the meson.build to skip the cross compile check. The need to hack the meson.build was fixed recently - see https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/381
So I updated all my repos to use the new commits, and found that plugins-bad can no longer cross compile gir. I bisected the problem to the addition of GstTranscode in 7a66b16d976468fcf72c2d1398fd637bdb4e348c which happened after 1.16.1.
The problem appears to be that gir correctly builds the introspection binary and then runs it, but the binary then attempts to open vchiq hardware, which is only present on the real target hardware. qemu cant emulate that, so the binary crashes out and introspection fails. Notably, this does not happen with plugins-base, which also uses the rpi libraries.
The message "* failed to open vchiq instance" comes from the RPi's /opt/vc/lib libraries themselves, not from gstreamer.
Here is the build output:
```
[7/7] packages.gstreamer:build_repo_meson:62: ninja -C /home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad -j 8
ninja: Entering directory `/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad'
[136/481] Generating GstTranscoder-1.0.gir with a custom command.
FAILED: gst-libs/gst/transcoder/GstTranscoder-1.0.gir
/home/al/Source/rpi-ramdisk/sysroot/wrappers/g-ir-scanner -pthread -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/include/gobject-introspection-1.0 -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/include/glib-2.0 -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf/glib-2.0/include --no-libtool --namespace=GstTranscoder --nsversion=1.0 --warn-all --output gst-libs/gst/transcoder/GstTranscoder-1.0.gir '--add-init-section=extern gboolean gst_init(gint *argc, gchar **argv); gst_init(NULL,NULL);' -I/home/al/Source/rpi-ramdisk/packages/gstreamer/gst-plugins-bad/gst-libs/gst/transcoder -I/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/gst-libs/gst/transcoder -I./. -I../../gst-plugins-bad/. -I./gst-libs -I../../gst-plugins-bad/gst-libs --filelist=/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/gst-libs/gst/transcoder/93e7ff3@@gsttranscoder-1.0@sha/GstTranscoder_1.0_gir_filelist --include=GObject-2.0 --include=Gst-1.0 --include=GstPbutils-1.0 --symbol-prefix=gst_ --identifier-prefix=Gst --cflags-begin -fvisibility=hidden -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes -Wdeclaration-after-statement -Wold-style-definition -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -I./. -I../../gst-plugins-bad/. -I./gst-libs -I../../gst-plugins-bad/gst-libs -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/include/glib-2.0 -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/gstreamer/include/gstreamer-1.0 --cflags-end --add-include-path=/opt/gstreamer/share/gir-1.0 --library gsttranscoder-1.0 -L/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/gst-libs/gst/transcoder -L/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf -L/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/gstreamer/lib --extra-library=gstreamer-1.0 --extra-library=gobject-2.0 --extra-library=glib-2.0 --extra-library=gstpbutils-1.0 --extra-library=gstaudio-1.0 --extra-library=gstvideo-1.0 --extra-library=gstbase-1.0 --sources-top-dirs /home/al/Source/rpi-ramdisk/packages/gstreamer/gst-plugins-bad/subprojects/ --sources-top-dirs /home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/subprojects/
g-ir-scanner: link: arm-linux-gnueabihf-gcc --sysroot=/home/al/Source/rpi-ramdisk/sysroot/sysroot -o /home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/tmp-introspectfh716ncv/GstTranscoder-1.0 /home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/tmp-introspectfh716ncv/GstTranscoder-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/gst-libs/gst/transcoder -Wl,-rpath,/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/gst-libs/gst/transcoder -L/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf -Wl,-rpath,/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf -L/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/gstreamer/lib -Wl,-rpath,/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/gstreamer/lib -lgsttranscoder-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstpbutils-1.0 -lgstaudio-1.0 -lgstvideo-1.0 -lgstbase-1.0 -L/home/al/Source/rpi-ramdisk/sysroot/sysroot/usr/lib/arm-linux-gnueabihf -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 --sysroot=/home/al/Source/rpi-ramdisk/sysroot/sysroot -Wl,--rpath-link=/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/vc/lib -Wl,--rpath-link=/home/al/Source/rpi-ramdisk/sysroot/sysroot/opt/gstreamer/lib -Wl,--rpath=/opt/vc/lib -Wl,--rpath=/opt/gstreamer/lib
(GstTranscoder-1.0:3356): GStreamer-WARNING **: 22:35:27.339: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
* failed to open vchiq instance
Command '['/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/tmp-introspectfh716ncv/GstTranscoder-1.0', '--introspect-dump=/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/tmp-introspectfh716ncv/functions.txt,/home/al/Source/rpi-ramdisk/packages/gstreamer/build/gst-plugins-bad/tmp-introspectfh716ncv/dump.xml']' returned non-zero exit status 255.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1101wpe: Internal thread racy-deadlocks when receiving frameComplete2019-10-24T10:33:44ZPhilippe Normandwpe: Internal thread racy-deadlocks when receiving frameComplete```
Thread 20 (Thread 0x7febbf7f6700 (LWP 23256)):
#0 0x00007fec089720c9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007fec09684fac in g_mutex_lock_slowpath (mutex=mutex@entry=0x7febe0040588) at ../../../glib...```
Thread 20 (Thread 0x7febbf7f6700 (LWP 23256)):
#0 0x00007fec089720c9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007fec09684fac in g_mutex_lock_slowpath (mutex=mutex@entry=0x7febe0040588) at ../../../glib/gthread-posix.c:1331
#2 0x00007fec09685832 in g_mutex_lock (mutex=mutex@entry=0x7febe0040588) at ../../../glib/gthread-posix.c:1355
#3 0x00007febffd57d9a in GMutexHolder::GMutexHolder(_GMutex&) (mutex=..., this=<synthetic pointer>) at ../subprojects/gst-plugins-bad/ext/wpe/WPEThreadedView.cpp:501
#4 0x00007febffd57d9a in WPEThreadedView::handleExportedImage(void*) (this=0x7febe0040510, image=<optimized out>) at ../subprojects/gst-plugins-bad/ext/wpe/WPEThreadedView.cpp:501
#5 0x00007febffd37948 in (anonymous namespace)::ClientBundleEGL::exportImage(wpe_fdo_egl_exported_image*) () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#6 0x00007febffd37873 in (anonymous namespace)::ClientBundleEGL::exportBuffer(linux_dmabuf_buffer const*) () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#7 0x00007febffd312da in ViewBackend::exportLinuxDmabuf(linux_dmabuf_buffer const*) () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#8 0x00007febffd31f50 in WS::{lambda(wl_client*, wl_resource*)#10}::operator()(wl_client*, wl_resource*) const () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#9 0x00007febffd31fa2 in WS::{lambda(wl_client*, wl_resource*)#10}::_FUN(wl_client*, wl_resource*) () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#10 0x00007fec0872e8ee in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#11 0x00007fec0872e2bf in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#12 0x00007febffe8ac2d in () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#13 0x00007febffe87689 in () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#14 0x00007febffe88c42 in wl_event_loop_dispatch () at /usr/lib/x86_64-linux-gnu/libwayland-server.so.0
#15 0x00007febffd31b1f in WS::ServerSource::{lambda(_GSource*, int (*)(void*), void*)#3}::operator()(_GSource*, int (*)(void*), void*) const () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#16 0x00007febffd31b86 in WS::ServerSource::{lambda(_GSource*, int (*)(void*), void*)#3}::_FUN(_GSource*, int (*)(void*), void*) () at /home/phil/prefix-wpe/lib/libWPEBackend-fdo-1.0.so.1
#17 0x00007fec0963a9ee in g_main_dispatch (context=0x7feb88000b20) at ../../../glib/gmain.c:3189
#18 0x00007fec0963a9ee in g_main_context_dispatch (context=context@entry=0x7feb88000b20) at ../../../glib/gmain.c:3854
--Type <RET> for more, q to quit, c to continue without paging--
#19 0x00007fec0963ac88 in g_main_context_iterate (context=0x7feb88000b20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3927
#20 0x00007fec0963af82 in g_main_loop_run (loop=0x7feb88001440) at ../../../glib/gmain.c:4123
#21 0x00007febffd56b72 in WPEThreadedView::s_viewThread(void*) (data=0x7febe0040510) at ../subprojects/gst-plugins-bad/ext/wpe/WPEThreadedView.cpp:143
#22 0x00007fec0966389d in g_thread_proxy (data=0x7febe0002c50) at ../../../glib/gthread.c:805
#23 0x00007fec08a61fb7 in start_thread (arg=<optimized out>) at pthread_create.c:486
#24 0x00007fec089772ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
...
Thread 7 (Thread 0x7febe68a9700 (LWP 23240)):
#0 0x00007fec089720c9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007fec0968595f in g_cond_wait (cond=cond@entry=0x7febe0040518, mutex=mutex@entry=0x7febe0040510) at ../../../glib/gthread-posix.c:1413
#2 0x00007febffd57597 in WPEThreadedView::frameComplete() (this=0x7febe0040510) at ../subprojects/gst-plugins-bad/ext/wpe/WPEThreadedView.cpp:350
#3 0x00007febffd576e3 in WPEThreadedView::image() (this=0x7febe0040510) at ../subprojects/gst-plugins-bad/ext/wpe/WPEThreadedView.cpp:291
#4 0x00007febffd5860e in gst_wpe_src_fill_memory(GstGLBaseSrc*, GstGLMemory*) (bsrc=<optimized out>, memory=0x7feb940149b0) at ../subprojects/gst-plugins-bad/ext/wpe/gstwpesrc.cpp:142
#5 0x00007fec044d5f38 in _fill_gl (context=<optimized out>, src=<optimized out>) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglbasesrc.c:328
#6 0x00007fec044fdf43 in _run_message_sync (message=0x7febc2ffc4d0) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:588
#7 0x00007fec044fdee2 in _run_message_async (message=0x55f43fafff80) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:655
#8 0x00007fec0963a898 in g_main_dispatch (context=0x55f43fcb6140) at ../../../glib/gmain.c:3189
#9 0x00007fec0963a898 in g_main_context_dispatch (context=context@entry=0x55f43fcb6140) at ../../../glib/gmain.c:3854
#10 0x00007fec0963ac88 in g_main_context_iterate (context=0x55f43fcb6140, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3927
#11 0x00007fec0963af82 in g_main_loop_run (loop=0x55f43fcb6230) at ../../../glib/gmain.c:4123
#12 0x00007fec044fdfc5 in gst_gl_window_default_run (window=0x55f43fc771f0 [GstGLWindowWaylandEGL]) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:514
#13 0x00007fec044e0b97 in gst_gl_context_create_thread (context=0x7febf8009850 [GstGLContextEGL]) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglcontext.c:1320
#14 0x00007fec0966389d in g_thread_proxy (data=0x55f43fa546d0) at ../../../glib/gthread.c:805
#15 0x00007fec08a61fb7 in start_thread (arg=<optimized out>) at pthread_create.c:486
#16 0x00007fec089772ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
...
```Philippe NormandPhilippe Normandhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1102bug of gst_amc_codec_configure2020-02-09T08:20:50ZSirius Wubug of gst_amc_codec_configureI'm using the master branch gst-plugins-bad on Android 7.1.2, the cpu is RK3229.
I notice something wrong in the `gst_amc_code_configure()`, it does not accept a NULL value for its surface argument.
But according to Android's MediaCode...I'm using the master branch gst-plugins-bad on Android 7.1.2, the cpu is RK3229.
I notice something wrong in the `gst_amc_code_configure()`, it does not accept a NULL value for its surface argument.
But according to Android's MediaCodec document, surface should be null for audio codec.
```
gst_amc_codec_configure (GstAmcCodec * codec, GstAmcFormat * format,
GstAmcSurfaceTexture * surface, GError ** err)
{
JNIEnv *env;
gint flags = 0;
g_return_val_if_fail (codec != NULL, FALSE);
g_return_val_if_fail (format != NULL, FALSE);
g_return_val_if_fail (GST_IS_AMC_SURFACE_TEXTURE_JNI (surface), FALSE); <-- HERE RETURNS FALSE IMMEDIATELY.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1104pnmdec: SIGSEGV when parsing .pbm file2019-10-24T12:01:54ZTérence Clastrespnmdec: SIGSEGV when parsing .pbm fileInvestigating a crash from [track-miners](https://gitlab.gnome.org/GNOME/tracker-miners/issues/85) led to a segfault from gstreamer when parsing a .bpm file: [curs10.pbm](/uploads/c3ea3ef627dd8bc12ebfffc41efb1eaf/curs10.pbm)
Here is w...Investigating a crash from [track-miners](https://gitlab.gnome.org/GNOME/tracker-miners/issues/85) led to a segfault from gstreamer when parsing a .bpm file: [curs10.pbm](/uploads/c3ea3ef627dd8bc12ebfffc41efb1eaf/curs10.pbm)
Here is what parsing with `GST_DEBUG=*:2 gst-launch-1.0 playbin uri=file:///curs10.pbm` gives:
```
Setting pipeline to PAUSED ...
0:00:00.012303015 395253 0x55ba79419560 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<source> pad not activated yet
0:00:00.012468004 395253 0x55ba79419560 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<source> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.032713681 395253 0x55ba792d1ed0 WARN videodecoder gstvideodecoder.c:2423:gst_video_decoder_chain:<pnmdec0> Received buffer without a new-segment. Assuming timestamps start from 0.
0:00:00.032726820 395253 0x55ba792d1ed0 WARN typefind gsttypefindelement.c:1228:gst_type_find_element_loop:<typefind> error: Internal data stream error.
0:00:00.032730950 395253 0x55ba792d1ed0 WARN typefind gsttypefindelement.c:1228:gst_type_find_element_loop:<typefind> error: streaming stopped, reason error (-5)
Caught SIGSEGV
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Internal data stream error.
Additional debug info:
../gstreamer/plugins/elements/gsttypefindelement.c(1228): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
```
- ArchLinux
- gstreamer and gst-plugins-bad 1.16.1
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1105Cast with GST_AMC_SURFACE_TEXTURE_JNI crashes?2019-10-25T15:39:33ZSirius WuCast with GST_AMC_SURFACE_TEXTURE_JNI crashes?Hi,
I'm using master branch on a Rk3229 Android box. My program crashs in the following line of gstamcsurfacetexture-jni.c.
```
GstAmcSurfaceTextureJNI *self = GST_AMC_SURFACE_TEXTURE_JNI (base);
```
If I changed the above line, using...Hi,
I'm using master branch on a Rk3229 Android box. My program crashs in the following line of gstamcsurfacetexture-jni.c.
```
GstAmcSurfaceTextureJNI *self = GST_AMC_SURFACE_TEXTURE_JNI (base);
```
If I changed the above line, using no cast, my program runs.
```
GstAmcSurfaceTextureJNI *self = base;
```
When I look at struct _GstAmcSurfaceTextureJNI, I found it has no parent_instance?
```
struct _GstAmcSurfaceTextureJNI
{
jobject jobject;
gint texture_id;
jobject listener;
jmethodID set_context_id;
GstAmcSurfaceTextureOnFrameAvailableCallback callback;
gpointer user_data;
};
```
I do not know GObject good enough to know if it's the cause of the crash.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1106vtdec: memory leak2020-07-17T08:24:14ZRoman Shpuntovvtdec: memory leakvtdec does not release `format_description` on `gst_vtdec_stop`: `CFRelease (vtdec->format_description);`vtdec does not release `format_description` on `gst_vtdec_stop`: `CFRelease (vtdec->format_description);`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1107msdk: check the native color formats supported by encoders2021-09-24T14:37:50ZHaihao Xiangmsdk: check the native color formats supported by encodersAccording to the comments in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/766, we may try to get the supported native color formats instead of hacked list.According to the comments in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/766, we may try to get the supported native color formats instead of hacked list.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1108decklink: Add support for extracting/embedding KLV metadata in HD-SDI2021-09-24T14:37:51ZJoshua M. Doedecklink: Add support for extracting/embedding KLV metadata in HD-SDIThis is an upcoming need, but thought I'd document it here. HD-SDI (SMPTE 292M) can include KLV metadata in the VANC/VBI (and sometimes HANC), as described in SMPTE ST 291 and RP 214. This would need a GstMeta for KLV, for which there is...This is an upcoming need, but thought I'd document it here. HD-SDI (SMPTE 292M) can include KLV metadata in the VANC/VBI (and sometimes HANC), as described in SMPTE ST 291 and RP 214. This would need a GstMeta for KLV, for which there is already a [merge request](gst-plugins-base!124).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1109WebRTC recvonly when answering with audio to Chrome/Firefox2021-03-07T17:53:19ZPieter JordaanWebRTC recvonly when answering with audio to Chrome/FirefoxWhen adjusting the gstwebrtc-demo project to allow browser to make the offer, webrtcbin answers with recvonly for audio. This only happens when creating an answer to the browser. When the gstreamer side generates an offer, the browser an...When adjusting the gstwebrtc-demo project to allow browser to make the offer, webrtcbin answers with recvonly for audio. This only happens when creating an answer to the browser. When the gstreamer side generates an offer, the browser answers with sendrecv and both sides work.
Here is a pastebin of an audio-only session log (`GST_DEBUG="*webrtc*:7"`), where the gstreamer side answers to the browser with recvonly.
https://pastebin.com/xdWk0ZKA
What is clear from the log is that webrtcbin notices the VP8 and OPUS caps on its sink pads. However, no audio is negotiated to send to the browser.
I have forked the demos here: https://github.com/Climax777/gstwebrtc-demos/tree/recvonlybug in the recvonlybug branch. I've only used the sendrecv demo at this stage since it involves the browser.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1110wasapisrc: unable to change state from PLAYING to NULL and back to PLAYING2021-09-21T18:21:11ZIgnaziowasapisrc: unable to change state from PLAYING to NULL and back to PLAYINGUnable to start and stop multiple times audio grabbing pipeline using wasapisrc.
Using directsoundsrc it is possible to restart it multiple times without any error.
When the pipeline is started and stopped multiple times (due to audio r...Unable to start and stop multiple times audio grabbing pipeline using wasapisrc.
Using directsoundsrc it is possible to restart it multiple times without any error.
When the pipeline is started and stopped multiple times (due to audio restart) this error is raised:
``
WARN audio - gstreamer error from element '/GstPipeline:pipeline1/GstWasapiSrc:audiosrc' when grabbing: Could not open resource for reading.
WARN audio - Additional debug information:
../gst-plugins-bad/sys/wasapi/gstwasapisrc.c(407): gst_wasapi_src_open (): /GstPipeline:pipeline1/GstWasapiSrc:audiosrc
``
If you try to run the attached test code it will fail.
[wasapi_restart_test.c](/uploads/b8b77d8f18e839e2010b33b41ffd9bd4/wasapi_restart_test.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1111hlsdemux: send packet failed, could not drain decoder after switching bitrate...2019-11-14T14:04:53ZSirius Wuhlsdemux: send packet failed, could not drain decoder after switching bitrate while using a libav aac decoderHi,
I'm modifying Android tutorial 5 for a HLS player. The branch used is 1.16.1.
I encountered the issue in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/189, so I do not use omx.google.aac.decoder. I use decoder...Hi,
I'm modifying Android tutorial 5 for a HLS player. The branch used is 1.16.1.
I encountered the issue in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/189, so I do not use omx.google.aac.decoder. I use decoder from libav instead.
Now the player plays HLS links with a constant connection-speed perfectly. But if hlsdemux switches bitrate, buffering drops under 10% immediately.
I examined the following logs, it seams that gstavauddec cannot drain decoder after switching bitrate, which leads to the buffering problem.
I'm not sure whether this is a bug of hlsdemux or a bug of gst-libav.
---- Logs starts here ----
```
19:04:03.201 V [InulPlayer] setMessage: Buffering 98%
19:04:03.204 V [InulPlayer] setMessage: Buffering 99%
19:04:03.961 V [InulPlayer] setMessage: State changed to PLAYING
...
19:04:09.139 I ┌ 0:00:38.359795268 0x8a66ab80 ../ext/hls/gsthlsdemux.c:1601:gst_hls_demux_
19:04:09.139 I ├ change_playlist:<hlsdemux0> Client was on 1500000bps, max allowed is 1134
19:04:09.139 I └ 260bps, switching to bitrate 800000bps
...
19:04:14.177 W ┌ 0:00:43.397305312 0x7cbf4db0 ../ext/libav/gstavauddec.c:628:gst_ffmpegaud
19:04:14.177 W └ dec_drain:<avdec_aac0> send packet failed, could not drain decoder
19:04:14.957 I Rkvpu_SendInputData(449): send eos
19:04:15.361 V [InulPlayer] setMessage: Buffering 5%
19:04:15.362 V [InulPlayer] setMessage: Buffering 10%
19:04:15.362 V [InulPlayer] setMessage: Buffering 11%
19:04:15.363 V [InulPlayer] setMessage: Buffering 12%
19:04:15.383 I ┌ 0:00:44.601697021 0x7cb9c980 ../gst/playback/gstplaybin2.c:3779:no_more_p
19:04:15.383 I └ ads_cb:<playbin0> setting custom audio sink <openslessink0>
19:04:15.383 I ┌ 0:00:44.603441188 0x7cb9c980 ../gst/playback/gstplaybin2.c:3786:no_more_p
19:04:15.383 I └ ads_cb:<playbin0> setting custom video sink <glimagesinkbin0>
19:04:15.384 V [InulPlayer] setMessage: Buffering 13%
19:04:15.402 V [InulPlayer] setMessage: Buffering 14%
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1112Default fluiddec volume (gain) is too low2021-09-24T14:37:51ZJavierDefault fluiddec volume (gain) is too lowTo reproduce: `gst-launch-1.0 souphttpsrc location=https://upload.wikimedia.org/wikipedia/commons/5/55/MIDI_sample.mid ! midiparse ! fluiddec ! autoaudiosink`
The MIDI file is correctly played but at a very low volume. On my system at l...To reproduce: `gst-launch-1.0 souphttpsrc location=https://upload.wikimedia.org/wikipedia/commons/5/55/MIDI_sample.mid ! midiparse ! fluiddec ! autoaudiosink`
The MIDI file is correctly played but at a very low volume. On my system at least this is significantly lower than every other sound/music, meaning I have to manually raise the volume of the corresponding Gstreamer process/stream at pulseaudio.
Forcing synth-gain property to be 1 fixes the issue:
`gst-launch-1.0 souphttpsrc location=https://upload.wikimedia.org/wikipedia/commons/5/55/MIDI_sample.mid ! midiparse ! fluiddec synth-gain=1.0 ! autoaudiosink`
Now the sound is played at a volume similar to my other streams.
However, to the best of my knowledge, it is impossible to forcefully override the default property of an element when using decodebin/playbin, which means that e.g. Totem and other gstreamer programs will always play MIDI files at a very low volume.
The default gain value for the fluidsynth decoder is currently set by the gstreamer element at 0.2 (which is indeed the default value for fluidsynth).
However, I understand that this default value is set for "safety" reasons, but it is not useful as a permanent, not-user-modifiable value.
For example, Qsynth (a fluidsynth GUI) sets the default gain to 1.0 .
Please consider raising the default synth-gain value to 1.0, or at least provide a way to override it without having to patch every downstream program.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1113webrtcbin: browser generated offer, never connects2020-05-23T10:13:56ZNicholas Mitchellwebrtcbin: browser generated offer, never connectsWhen having the browser generate an offer to webrtcbin, it never connects. Not sure if has to do with the ice candidates gathered from webrtbin or chrome, but i am noticing a difference. I have also set both bundle policies in javascript...When having the browser generate an offer to webrtcbin, it never connects. Not sure if has to do with the ice candidates gathered from webrtbin or chrome, but i am noticing a difference. I have also set both bundle policies in javascript and webrtcbin to max-compat.
```
g_object_set(G_OBJECT (webrtc1), "bundle-policy", GST_WEBRTC_BUNDLE_POLICY_MAX_COMPAT, NULL);
```
```
var rtc_configuration = {
bundlePolicy: "max-compat",
iceServers: [
{urls: "stun:stun.services.mozilla.com"},
{urls: "stun:stun.l.google.com:19302"}]
};
```
Offer from chrome:
```
type: offer, sdp: v=0
o=- 8526353313636209923 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS 2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:XLt3
a=ice-pwd:dO2KZDZ7d4jWnlTHwkau1xTc
a=ice-options:trickle
a=fingerprint:sha-256 CC:FF:1A:03:3C:F1:E2:6D:7C:0C:14:CE:FC:1D:45:46:AD:D9:D8:6E:DB:57:CA:DD:ED:E4:ED:90:BB:9F:7C:93
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65 24a2b846-f871-44dd-bd05-d0a0cd1723e4
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:597766518 cname:UU+xprSXlOQDwEs5
a=ssrc:597766518 msid:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65 24a2b846-f871-44dd-bd05-d0a0cd1723e4
a=ssrc:597766518 mslabel:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65
a=ssrc:597766518 label:24a2b846-f871-44dd-bd05-d0a0cd1723e4
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:XLt3
a=ice-pwd:dO2KZDZ7d4jWnlTHwkau1xTc
a=ice-options:trickle
a=fingerprint:sha-256 CC:FF:1A:03:3C:F1:E2:6D:7C:0C:14:CE:FC:1D:45:46:AD:D9:D8:6E:DB:57:CA:DD:ED:E4:ED:90:BB:9F:7C:93
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65 053e2550-9e02-4754-81be-438a16d5b231
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=ssrc-group:FID 2783684097 198025116
a=ssrc:2783684097 cname:UU+xprSXlOQDwEs5
a=ssrc:2783684097 msid:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65 053e2550-9e02-4754-81be-438a16d5b231
a=ssrc:2783684097 mslabel:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65
a=ssrc:2783684097 label:053e2550-9e02-4754-81be-438a16d5b231
a=ssrc:198025116 cname:UU+xprSXlOQDwEs5
a=ssrc:198025116 msid:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65 053e2550-9e02-4754-81be-438a16d5b231
a=ssrc:198025116 mslabel:2Ux9exk6xnv0TmzrHIVrHh2buiGdr4Y88Y65
a=ssrc:198025116 label:053e2550-9e02-4754-81be-438a16d5b231
```
Answer from webrtcbin:
```
type: answer, sdp: v=0
o=- 8526353313636209923 0 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=ice-ufrag:icLqNHKqynKMh++LgDdQmfX3ICKlhqbU
a=ice-pwd:Ok7x2uLQBIZ1btJdLS1p0Erq41SgQdoE
a=mid:0
a=rtcp-mux
a=setup:active
a=rtpmap:111 OPUS/48000/2
a=fmtp:111 minptime=10;useinbandfec=1;sprop-maxcapturerate=48000;sprop-stereo=0
a=ssrc:3019496707 msid:user2364208917@host-61050609 webrtctransceiver1
a=ssrc:3019496707 cname:user2364208917@host-61050609
a=sendrecv
a=fingerprint:sha-256 B1:D3:4A:07:7E:28:6A:95:C7:9F:87:75:CC:16:2E:49:BE:8D:4D:01:3E:6F:14:F7:2E:AC:A5:D9:1B:4E:0B:BD
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=ice-ufrag:icLqNHKqynKMh++LgDdQmfX3ICKlhqbU
a=ice-pwd:Ok7x2uLQBIZ1btJdLS1p0Erq41SgQdoE
a=mid:1
a=rtcp-mux
a=setup:active
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=framerate:30
a=ssrc:3372002750 msid:user2364208917@host-61050609 webrtctransceiver0
a=ssrc:3372002750 cname:user2364208917@host-61050609
a=sendrecv
a=fingerprint:sha-256 B1:D3:4A:07:7E:28:6A:95:C7:9F:87:75:CC:16:2E:49:BE:8D:4D:01:3E:6F:14:F7:2E:AC:A5:D9:1B:4E:0B:BD
```
Ice From Chrome:
```
sdpMid: 0, sdpMLineIndex: 0, candidate: candidate:892418806 1 udp 2122260223 xxxx 51602 typ host generation 0 ufrag XLt3 network-id 1 network-cost 10
sdpMid: 1, sdpMLineIndex: 1, candidate: candidate:892418806 1 udp 2122260223 xxxxx 51352 typ host generation 0 ufrag XLt3 network-id 1 network-cost 10
sdpMid: 0, sdpMLineIndex: 0, candidate: candidate:2075313670 1 tcp 1518280447 xxxxx 9 typ host tcptype active generation 0 ufrag XLt3 network-id 1 network-cost 10
sdpMid: 1, sdpMLineIndex: 1, candidate: candidate:2075313670 1 tcp 1518280447 xxxxx 9 typ host tcptype active generation 0 ufrag XLt3 network-id 1 network-cost 10
sdpMid: 0, sdpMLineIndex: 0, candidate: candidate:3027844162 1 udp 1686052607 xxxxx 51602 typ srflx raddr xxxxx rport 51602 generation 0 ufrag XLt3 network-id 1 network-cost 10
sdpMid: 1, sdpMLineIndex: 1, candidate: candidate:3027844162 1 udp 1686052607 xxxxx 51352 typ srflx raddr xxxxx rport 51352 generation 0 ufrag XLt3 network-id 1 network-cost 10
```
Ice From Webrtbin:
```
sdpMid: , sdpMLineIndex: 0, candidate: candidate:5 1 UDP 1677722111 xxxx 57066 typ srflx raddr xxxxx rport 57066
sdpMid: , sdpMLineIndex: 0, candidate: candidate:1 1 UDP 2013266431 xxxxx 46402 typ host
sdpMid: , sdpMLineIndex: 0, candidate: candidate:2 1 TCP 1015021823 xxxxx 9 typ host tcptype active
sdpMid: , sdpMLineIndex: 0, candidate: candidate:3 1 TCP 1010827519 xxxxx 40341 typ host tcptype passive
sdpMid: , sdpMLineIndex: 0, candidate: candidate:1 2 UDP 2013266430 xxxxx 58574 typ host
sdpMid: , sdpMLineIndex: 0, candidate: candidate:2 2 TCP 1015021822 xxxxx 9 typ host tcptype active
sdpMid: , sdpMLineIndex: 0, candidate: candidate:3 2 TCP 1010827518 xxxxx 40305 typ host tcptype passive
sdpMid: , sdpMLineIndex: 0, candidate: candidate:6 1 TCP 847249663 xxxxx 9 typ srflx raddr xxxxx rport 9 tcptype active
sdpMid: , sdpMLineIndex: 0, candidate: candidate:7 1 TCP 843055359 xxxxx 40341 typ srflx raddr xxxxx rport 40341 tcptype passive
sdpMid: , sdpMLineIndex: 0, candidate: candidate:5 2 UDP 1677722110 xxxxx 65006 typ srflx raddr xxxxx rport 65006
sdpMid: , sdpMLineIndex: 0, candidate: candidate:6 2 TCP 847249662 xxxxx 9 typ srflx raddr xxxxx rport 9 tcptype active
```
Logs from webrtcbin:
```
0:00:04.584602200 13190 0x7fffe80cb300 DEBUG webrtcbin gstwebrtcbin.c:267:gst_webrtc_bin_pad_new:<'':sink_0> new visible pad with direction sink
0:00:04.584963300 13190 0x7fffe80cb300 DEBUG webrtcbin gstwebrtcbin.c:267:gst_webrtc_bin_pad_new:<'':sink_1> new visible pad with direction sink
0:00:04.585054500 13190 0x7fffe80cb300 DEBUG webrtcbin gstwebrtcbin.c:4662:gst_webrtc_bin_change_state: changing state: NULL => READY
0:00:04.586651900 13190 0x7fffe80cb300 LOG webrtcbin gstwebrtcbin.c:1175:_check_if_negotiation_is_needed:<sendrecv> checking if negotiation is needed
0:00:04.586703800 13190 0x7fffe80cb300 LOG webrtcbin gstwebrtcbin.c:1180:_check_if_negotiation_is_needed:<sendrecv> no negotiation possible until caps have been received on all sink pads
0:00:04.586928500 13190 0x7fffe80cb300 DEBUG webrtcbin gstwebrtcbin.c:4662:gst_webrtc_bin_change_state: changing state: READY => PAUSED
Starting pipeline
0:00:04.595033600 13190 0x7fffe80b9d40 LOG webrtcbin gstwebrtcbin.c:1175:_check_if_negotiation_is_needed:<sendrecv> checking if negotiation is needed
0:00:04.595100400 13190 0x7fffe80b9d40 LOG webrtcbin gstwebrtcbin.c:1180:_check_if_negotiation_is_needed:<sendrecv> no negotiation possible until caps have been received on all sink pads
0:00:04.597268000 13190 0x7fffe80cb300 DEBUG webrtcbin gstwebrtcbin.c:4662:gst_webrtc_bin_change_state: changing state: PAUSED => PLAYING
0:00:04.608960300 13190 0x7fffe80b9d40 LOG webrtcbin gstwebrtcbin.c:4709:pad_block:<sendrecv:sink_0> blocking pad with data buffer: 0x7fffe80b7d80, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 0:00:00.033333333, size 1400, offset none, offset_end none, flags 0x4000
0:00:04.611096500 13190 0x7fffe80b9c50 LOG webrtcbin gstwebrtcbin.c:1175:_check_if_negotiation_is_needed:<sendrecv> checking if negotiation is needed
0:00:04.611146000 13190 0x7fffe80b9c50 LOG webrtcbin gstwebrtcbin.c:1195:_check_if_negotiation_is_needed:<sendrecv> no local description set
0:00:04.611508400 13190 0x7fffe80b9c50 LOG webrtcbin gstwebrtcbin.c:4709:pad_block:<sendrecv:sink_1> blocking pad with data buffer: 0x7fffcc0385a0, pts 0:00:00.000000000, dts 0:00:00.000000000, dur 0:00:00.013500000, size 172, offset none, offset_end none, flags 0x4000
0:00:05.599494000 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:3531:_set_description_task:<sendrecv> Attempting to set remote offer in the stable state
0:00:05.878420300 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:2744:_create_sdp_task:<sendrecv> creating answer sdp with options (NULL)
0:00:05.878782900 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:1330:_find_codec_preferences:<sendrecv> retreiving codec preferences from <webrtctransceiver0>
0:00:05.878926400 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:1330:_find_codec_preferences:<sendrecv> retreiving codec preferences from <webrtctransceiver1>
0:00:05.879039200 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:2591:_create_answer_task:<sendrecv> found compatible transceiver (NULL) for offer media 0
0:00:05.879952600 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:1330:_find_codec_preferences:<sendrecv> retreiving codec preferences from <webrtctransceiver0>
0:00:05.880002500 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:2591:_create_answer_task:<sendrecv> found compatible transceiver (NULL) for offer media 1
0:00:05.880644200 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:1052:_update_ice_gathering_state_task:<sendrecv> ICE gathering state change from new(0) to complete(2)
0:00:05.881310000 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:3531:_set_description_task:<sendrecv> Attempting to set local answer in the have-remote-offer state
0:00:05.882983000 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:4350:on_rtpbin_request_aux_sender:<sendrecv> requesting aux sender for stream <transportstream0> with transport <webrtctransceiver0> and pt map application/x-rtp-pt-map;
0:00:05.883502100 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3021:_update_transport_ptmap_from_media:<sendrecv> mapping sdp session level attributes to caps
0:00:05.883564300 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3023:_update_transport_ptmap_from_media:<sendrecv> mapping sdp media level attributes to caps
0:00:05.883708400 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3036:_update_transport_ptmap_from_media:<sendrecv> looking at 0 pt: 111
0:00:05.883763100 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3021:_update_transport_ptmap_from_media:<sendrecv> mapping sdp session level attributes to caps
0:00:05.883866300 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3023:_update_transport_ptmap_from_media:<sendrecv> mapping sdp media level attributes to caps
0:00:05.883904400 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3036:_update_transport_ptmap_from_media:<sendrecv> looking at 0 pt: 96
0:00:05.884466900 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3163:_update_transceiver_from_sdp_media:<sendrecv> found existing send pad <sendrecv:sink_0> for transceiver <webrtctransceiver0>
0:00:05.884617100 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3188:_update_transceiver_from_sdp_media:<sendrecv> creating new receive pad for transceiver <webrtctransceiver0>
0:00:05.884687300 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:267:gst_webrtc_bin_pad_new:<'':src_0> new visible pad with direction src
0:00:05.887341200 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3163:_update_transceiver_from_sdp_media:<sendrecv> found existing send pad <sendrecv:sink_1> for transceiver <webrtctransceiver1>
0:00:05.887386900 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:3188:_update_transceiver_from_sdp_media:<sendrecv> creating new receive pad for transceiver <webrtctransceiver1>
0:00:05.887431100 13190 0x7fffe80b9cf0 DEBUG webrtcbin gstwebrtcbin.c:267:gst_webrtc_bin_pad_new:<'':src_1> new visible pad with direction src
0:00:05.887450200 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:2954:_connect_output_stream:<sendrecv> linking output stream 0
0:00:05.887595700 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:4407:on_rtpbin_request_aux_receiver:<sendrecv> requesting aux receiver for stream <transportstream0> with pt red:0 rtx:0
0:00:05.887850400 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:2895:_connect_input_stream:<sendrecv:sink_0> linking input stream 0
0:00:05.888120800 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:2895:_connect_input_stream:<sendrecv:sink_1> linking input stream 1
0:00:05.888372300 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:1175:_check_if_negotiation_is_needed:<sendrecv> checking if negotiation is needed
0:00:05.888806500 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:1279:_check_if_negotiation_is_needed:<sendrecv> no negotiation needed
0:00:05.889100000 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:2992:_add_ice_candidate:<sendrecv> adding ICE candidate with mline:0, a=candidate:892418806 1 udp 2122260223 xxxx 51602 typ host generation 0 ufrag XLt3 network-id 1 network-cost 10
0:00:05.889459700 13190 0x7fffe80b9cf0 WARN webrtcbin gstwebrtcbin.c:2988:_add_ice_candidate:<sendrecv> Unknown mline 1, ignoring
0:00:05.889516400 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:2992:_add_ice_candidate:<sendrecv> adding ICE candidate with mline:0, a=candidate:2075313670 1 tcp 1518280447 xxxx 9 typ host tcptype active generation 0 ufrag XLt3 network-id 1 network-cost 10
0:00:05.889559300 13190 0x7fffe80b9cf0 WARN webrtcbin gstwebrtcbin.c:2988:_add_ice_candidate:<sendrecv> Unknown mline 1, ignoring
0:00:05.889580500 13190 0x7fffe80b9cf0 LOG webrtcbin gstwebrtcbin.c:2992:_add_ice_candidate:<sendrecv> adding ICE candidate with mline:0, a=candidate:3027844162 1 udp 1686052607 xxxx 51602 typ srflx raddr xxxx rport 51602 generation 0 ufrag XLt3 network-id 1 network-cost 10
0:00:05.889712300 13190 0x7fffe80b9cf0 WARN webrtcbin gstwebrtcbin.c:2988:_add_ice_candidate:<sendrecv> Unknown mline 1, ignoring
0:00:05.890073100 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:1052:_update_ice_gathering_state_task:<sendrecv> ICE gathering state change from complete(2) to gathering(1)
0:00:05.890229400 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:1086:_update_ice_connection_state_task:<sendrecv> ICE connection state change from new(0) to checking(1)
0:00:05.890403300 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:1121:_update_peer_connection_state_task:<sendrecv> Peer connection state change from new(0) to connecting(1)
0:00:06.110273500 13190 0x7fffe80b9cf0 INFO webrtcbin gstwebrtcbin.c:1052:_update_ice_gathering_state_task:<sendrecv> ICE gathering state change from gathering(1) to complete(2)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1114sdpdemux throws a critical assertion error2022-06-24T17:51:38ZFunkyBobysdpdemux throws a critical assertion errorHi GStreamer devs,
I have stumbled upon an issue when trying out the sdpsrc and sdpdemux plugins. I have started working on it under LMDE 3, which is based on Debian 9 stable, which provides GStreamer 1.10.4. I was able to listen to an ...Hi GStreamer devs,
I have stumbled upon an issue when trying out the sdpsrc and sdpdemux plugins. I have started working on it under LMDE 3, which is based on Debian 9 stable, which provides GStreamer 1.10.4. I was able to listen to an audio RTP stream just fine by using the following pipeline :
```
$ gst-launch-1.0 sdpsrc location=sdp://test.sdp ! decodebin ! autoaudiosink
```
I then tried it out on a Debian Sid VM, which provides GStreamer 1.16.1. The same pipeline with the same SDP file throws the following error :
```
$ gst-launch-1.0 sdpsrc location=sdp://test.sdp ! decodebin ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
** (gst-launch-1.0:602): CRITICAL **: 16:59:26.470: gst_sdp_media_get_connection: assertion 'idx < media->connections->len' failed
ERROR: from element /GstPipeline:pipeline0/GstSdpSrc:sdpsrc0/GstSDPDemux:sdpdemux0: Could not read from resource.
Additional debug info:
gstsdpdemux.c(982): gst_sdp_demux_handle_message (): /GstPipeline:pipeline0/GstSdpSrc:sdpsrc0/GstSDPDemux:sdpdemux0:
Could not receive any UDP packets for 10.0000 seconds, maybe your firewall is blocking it.
Execution ended after 0:00:10.014706472
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
```
After looking at the debug output, I understand that `sdpsrc` internally uses `sdpdemux`, so I tried the following and got the exact same output :
```
$ gst-launch-1.0 filesrc location=test.sdp ! sdpdemux ! decodebin ! autoaudiosink
```
Logs and SDP file are available here :
[gstreamer_sdpdemux_bug.zip](/uploads/7fdcc7ebe6d25d732e84504dbd8ff5c1/gstreamer_sdpdemux_bug.zip)
Did I do something wrong, considering that my pipeline only works with an outdated version ?
Thanks for your time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1115d3d11videosink: stack overflow2019-11-14T02:14:21ZAaron Boxerd3d11videosink: stack overflowWith a single sink, and `gst_video_overlay_set_window_handle` API used to display video in
specified window, if I start, stop, start, and then stop the sink, I get a stack overflow in this method:
```
static LRESULT FAR PASCAL
sub_class...With a single sink, and `gst_video_overlay_set_window_handle` API used to display video in
specified window, if I start, stop, start, and then stop the sink, I get a stack overflow in this method:
```
static LRESULT FAR PASCAL
sub_class_proc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
WNDPROC external_window_proc = GetProp (hWnd, EXTERNAL_PROC_PROP_NAME);
GstD3D11Window *self =
(GstD3D11Window *) GetProp (hWnd, D3D11_WINDOW_PROP_NAME);
```