GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T11:03:29Zhttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/144Media pipeline for one of the rtsp streams is failed to prepare with "wait_pr...2021-09-24T11:03:29ZIohannes FolbortMedia pipeline for one of the rtsp streams is failed to prepare with "wait_preroll: failed to preroll pipeline"I have a server which listens for incoming rtp streams and provides rtsp media links for this streams.
For some reason i am experiencing the issue with connection to one of the media links. When connectiong to media rtsp server is not ab...I have a server which listens for incoming rtp streams and provides rtsp media links for this streams.
For some reason i am experiencing the issue with connection to one of the media links. When connectiong to media rtsp server is not able to preroll the pipeline within the timeout and next error is seen
```
bad_log:
...
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275167696 830 0xa9c680 WARN rtspmedia rtsp-media.c:3000:wait_preroll: failed to preroll pipeline
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275183383 830 0xa9c680 WARN rtspmedia rtsp-media.c:3304:gst_rtsp_media_prepare: failed to preroll pipeline
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275942045 830 0xa9c680 ERROR rtspclient rtsp-client.c:1044:find_media: client 0x7f5a7c02ee40: can't prepare media
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.276092339 830 0xa9c680 ERROR rtspclient rtsp-client.c:2955:handle_describe_request: client 0x7f5a7c02ee40: no media
...
```
Logs for good media link and bad media link are attached.
[bad_log](/uploads/b44b4e35d013fb5698eb7fcdd3eded94/bad_log)
[good_log](/uploads/c62f67cb357e40f33e322cc120c13aef/good_log)
The major difference between the pipeline construction is that in bad case caps creation event for `video/x-h264` is not arrived, thus the media pipeline is not created within a timeout.
In case of valid pipeline event is received and media pipeline is created sucessfully:
```
good_log:
...
0:13:59.694671471 2042 0x7f68fc004000 INFO GST_EVENT gstevent.c:814:gst_event_new_caps: creating caps event video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)01424032ffe1001167424032f40a0fd0800001f400003a984201000568ce01af20, level=(string)5, profile=(string)constrained-baseline
0:13:59.694783493 2042 0x7f68fc004000 INFO GST_EVENT gstevent.c:814:gst_event_new_caps: creating caps event application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)424032, sprop-parameter-sets=(string)"Z0JAMvQKD9CAAAH0AAA6mEI\=\,aM4BryA\=", payload=(int)96, ssrc=(uint)481514705, timestamp-offset=(uint)1030785127, seqnum-offset=(uint)21035
...
```
Can someone explain what can be a reason for this behavior? Why does media factory is able to create media for one link but is not able to create media for another one?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/161cargo_wrapper.py doesn't support --verbose2023-05-31T13:41:29ZJan Beichcargo_wrapper.py doesn't support --verboseTo facilitate debugging remote builds (e.g., on non-x86 archs downstream) it'd be nice if `--verbose` from Meson was propagated to cargo-c.
```
$ meson setup _build
$ meson compile -v -C _build
```
Related:<br/>
https://github.com/free...To facilitate debugging remote builds (e.g., on non-x86 archs downstream) it'd be nice if `--verbose` from Meson was propagated to cargo-c.
```
$ meson setup _build
$ meson compile -v -C _build
```
Related:<br/>
https://github.com/freebsd/freebsd-ports/commit/30a00f2227a3<br/>
https://github.com/freebsd/freebsd-ports/commit/7bec7b192cda<br/>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/724Pad activation failure related to typefind and ghost pads2021-09-24T11:08:16ZSebastian DrögePad activation failure related to typefind and ghost padsForwarded from https://gitlab.gnome.org/GNOME/gtk/-/issues/4062
[app.c](/uploads/c6f1d904524d4d5b6d2062477ca9a816/app.c) reproduces the issue. Just start it with `./app /path/to/some/media/file`.
It fails with
```
(app:183943): GStrea...Forwarded from https://gitlab.gnome.org/GNOME/gtk/-/issues/4062
[app.c](/uploads/c6f1d904524d4d5b6d2062477ca9a816/app.c) reproduces the issue. Just start it with `./app /path/to/some/media/file`.
It fails with
```
(app:183943): GStreamer-CRITICAL **: 18:23:22.243: getrange on pad source:src but it was not activated in pull mode
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Internal data stream error.
Additional debug info:
../plugins/elements/gsttypefindelement.c(1232): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
streaming stopped, reason error (-5)
(app:183943): GStreamer-CRITICAL **: 18:23:22.243: chain on pad decodebin0:sink but it was not in push mode
```
Just using a `giostreamsrc` in front of `decodebin` OTOH works fine (see commented out code).https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/310vaapisink triggers assert in theoradec2021-09-24T12:23:31Zlaknollvaapisink triggers assert in theoradecHi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-lau...Hi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-launch-1.0 filesrc location=~/Videos/ogg.ogg ! oggdemux ! theoradec ! videoconvert ! vaapisink
```
triggers the following assertion:
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
**
ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Bail out! ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Aborted
```
There are no issues when running the same pipeline using xvimagesink or glimagesink.
This happens using gstreamer-1.18.4, I couldn't try 1.19, as that has other (larger) issues when using vaapi elements on my HW.
Output of vainfo below:
```
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Mesa Gallium driver 21.1.0-devel for AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 5.4.0-80-generic, LLVM 12.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/932Gst_video_meta_set_alignment() passes argument by value2021-09-24T13:26:31ZStefanSalewskiGst_video_meta_set_alignment() passes argument by value https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. A... https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. At least I can currently not remember a function which passes structs by value. For language bindings one has to be a bit carefully in this case.
Comment of Sebastian Dröge GNOME Team:
>That seems like an oversight. It should really be passed by reference to make automated bindings happy. Please create an issue
References: https://discourse.gnome.org/t/gst-video-meta-set-alignment-passes-argument-by-value/7258https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/352`extern "C"` functions called from C code should guard against unwinding2021-08-11T09:10:24ZSimonas Kazlauskas`extern "C"` functions called from C code should guard against unwindingAs far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that hap...As far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that happens from the Rust end, therefore being (I believe) unsound especially with versions of Rust that don't mitigate this by introducing trampolines that abort in these kinds of situations.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1638SRT stats send-duration-us duplicated2021-09-24T14:39:33ZSektor van SkijlenSRT stats send-duration-us duplicatedThe `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is send...The `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is sending data (idle time exclusive) */
"send-duration-us", G_TYPE_INT64, stats.usSndDuration,
...
/* busy sending time (i.e., idle time exclusive) */
"send-duration-us", G_TYPE_UINT64, stats.usSndDuration,
"negotiated-latency-ms", G_TYPE_INT, stats.msSndTsbPdDelay, NULL);
```
Another minor problem is `*bytes += stats.byteSent;` for `is_sender` section, but `stats.byteRecvTotal` for else section. As you don't request clearing the stats in the `srt_bstats` call it shouldn't make a difference, but formally it's wrong.https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/60Struct bindings are broken when they iinclude a boxed type or a struct mapped...2021-09-24T10:46:35ZAndoni Morales AlastrueyStruct bindings are broken when they iinclude a boxed type or a struct mapped to a GLib.OpaqueGstVideoFrame's first field is a GstVideoInfo.
VideoFrame is bindinded like a struct and it's first field is generated as an IntPtr, because VideoInfo is binded using a GLib.Opaque class.
```
StructLayout(LayoutKind.Sequential)]
publi...GstVideoFrame's first field is a GstVideoInfo.
VideoFrame is bindinded like a struct and it's first field is generated as an IntPtr, because VideoInfo is binded using a GLib.Opaque class.
```
StructLayout(LayoutKind.Sequential)]
public partial struct VideoFrame : IEquatable<VideoFrame> {
private IntPtr _info;
public Gst.Video.VideoInfo Info {
get {
return _info == IntPtr.Zero ? null : (Gst.Video.VideoInfo) GLib.Opaque.GetOpaque (_info, typeof (Gst.Video.VideoInfo), false);
}
set {
_info = value == null ? IntPtr.Zero : value.Handle;
}
}
```
The memory layout of the VideoFrame class does not matches the one of GstVideoFrame, the first field will has the size of a pointer and not the one of a VideoInfo.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/929xvimagesink: X Error of failed request: BadAlloc on very basic example with ...2022-05-19T14:37:55ZChristoph Feinauerxvimagesink: X Error of failed request: BadAlloc on very basic example with gst-launch-1.0Hi,
I am trying to run the basic example from the tutorial `gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink` and it crashes:
```
$ gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink
Setting pipeline to PAUSED ...
Pip...Hi,
I am trying to run the basic example from the tutorial `gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink` and it crashes:
```
$ gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 150 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 66
Current serial number in output stream: 67
```
Same for `gst-launch-1.0 -v videotestsrc ! xvimagesink`. Changing to `gst-launch-1.0 -v videotestsrc ! ximagesink` works.
It seems to be a problem with X video extension: If I compile [this](http://bellet.info/XVideo/testxv.c), the same error appears. In that, code putting a `sleep` before `XvShmPutImage` fixes the problem.
I am on `5.7.14-1-MANJARO` with
```
gst-libav 1.16.2-2
gst-plugins-bad 1.16.2-13
gst-plugins-bad-libs 1.16.2-13
gst-plugins-base 1.16.2-2
gst-plugins-base-libs 1.16.2-2
gst-plugins-good 1.16.2-3
gst-plugins-ugly 1.16.2-4
gstreamer 1.16.2-2
lib32-gstreamer 1.16.2-1
```https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/49rust/janus: Switch to a more exact JSON message data type2021-09-24T22:43:59ZSebastian Drögerust/janus: Switch to a more exact JSON message data typeCurrently all messages sent out are created via the `json!` macro and all received messages could make use of more enums instead of using `Option`s all over the place.
I've created the below as part of another project (untested so far)....Currently all messages sent out are created via the `json!` macro and all received messages could make use of more enums instead of using `Option`s all over the place.
I've created the below as part of another project (untested so far). Just putting this here for comment. CC @philn
It's not complete with all possible messages (and also only videoroom), and also does not contain all possible fields, but should be sufficient.
```rust
use serde::{Deserialize, Serialize};
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "janus")]
#[serde(rename_all = "lowercase")]
pub enum Message {
Create {
transaction: String,
},
Destroy {
transaction: String,
session_id: u64,
},
Attach {
transaction: String,
session_id: u64,
plugin: String,
},
Detach {
transaction: String,
session_id: u64,
handle_id: u64,
},
Keepalive {
transaction: String,
session_id: u64,
#[serde(skip_serializing_if = "Option::is_none")]
handle_id: Option<u64>,
},
Trickle {
transaction: String,
session_id: u64,
#[serde(skip_serializing_if = "Option::is_none")]
handle_id: Option<u64>,
#[serde(flatten)]
candidates: IceCandidates,
},
Message {
transaction: String,
#[serde(skip_serializing_if = "Option::is_none")]
sender: Option<u64>,
session_id: u64,
handle_id: u64,
body: MessageBody,
#[serde(skip_serializing_if = "Option::is_none")]
jsep: Option<Jsep>,
},
Success {
transaction: String,
#[serde(skip_serializing_if = "Option::is_none")]
sender: Option<u64>,
#[serde(skip_serializing_if = "Option::is_none")]
session_id: Option<u64>,
data: Option<SuccessData>,
plugindata: Option<Plugindata>,
},
Error {
transaction: String,
error: ErrorMessage,
},
Event {
#[serde(skip_serializing_if = "Option::is_none")]
transaction: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
session_id: Option<u64>,
sender: u64,
plugindata: Plugindata,
#[serde(skip_serializing_if = "Option::is_none")]
jsep: Option<Jsep>,
},
Ack {
transaction: String,
#[serde(skip_serializing_if = "Option::is_none")]
session_id: Option<u64>,
#[serde(skip_serializing_if = "Option::is_none")]
sender: Option<u64>,
},
WebRTCUp {
session_id: Option<u64>,
sender: Option<u64>,
},
Media {
session_id: Option<u64>,
sender: Option<u64>,
#[serde(rename = "type")]
type_: String,
receiving: bool,
},
SlowLink {
session_id: Option<u64>,
sender: Option<u64>,
uplink: bool,
nacks: u64,
},
HangUp {
session_id: Option<u64>,
sender: Option<u64>,
reason: String,
},
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
pub struct ErrorMessage {
pub code: u32,
pub reason: String,
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
pub struct SuccessData {
pub id: u64,
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "plugin")]
#[serde(rename_all = "lowercase")]
pub enum Plugindata {
#[serde(rename = "janus.plugin.videoroom")]
VideoRoom { data: VideoRoomData },
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "type")]
#[serde(rename_all = "lowercase")]
pub enum Jsep {
Candidate(IceCandidates),
Offer {
sdp: String,
#[serde(skip_serializing_if = "Option::is_none")]
trickle: Option<bool>,
},
Answer {
sdp: String,
#[serde(skip_serializing_if = "Option::is_none")]
trickle: Option<bool>,
},
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
#[serde(rename_all = "lowercase")]
pub enum IceCandidates {
Candidate { candidate: IceCandidate },
Candidates { candidates: Vec<IceCandidate> },
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
#[serde(rename_all = "lowercase")]
pub enum IceCandidate {
Candidate {
candidate: String,
#[serde(rename = "sdpMLineIndex")]
sdp_mline_index: u32,
#[serde(skip_serializing_if = "Option::is_none")]
#[serde(rename = "sdpMid")]
sdp_mid: Option<String>,
},
Completed {
completed: bool,
},
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "videoroom")]
#[serde(rename_all = "lowercase")]
pub enum VideoRoomData {
Created {
room: u64,
permanent: bool,
},
Destroyed {
room: u64,
},
Joined {
room: u64,
#[serde(skip_serializing_if = "Option::is_none")]
description: Option<String>,
id: u64,
},
Attached {
room: u64,
},
Success {
room: Option<u64>,
},
Event(Event),
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "request")]
#[serde(rename_all = "lowercase")]
pub enum MessageBody {
Create {
#[serde(skip_serializing_if = "Option::is_none")]
description: Option<String>,
publishers: u32,
#[serde(skip_serializing_if = "Option::is_none")]
audiocodec: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
videocodec: Option<String>,
},
Destroy {
room: u64,
},
Join(Join),
Publish {
#[serde(skip_serializing_if = "Option::is_none")]
display: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
audiocodec: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
videocodec: Option<String>,
},
Unpublish,
Leave,
Start,
}
// FIXME: This is only for videoroom. How to distinguish the different plugins?
#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
#[serde(rename_all = "lowercase")]
pub enum Event {
Error {
error_code: u32,
error: String,
},
Joining {
room: u64,
joining: Joining,
},
Configured {
configured: String,
},
Unpublished {
#[serde(skip_serializing_if = "Option::is_none")]
room: Option<u64>,
unpublished: serde_json::Value,
},
Started {
started: String,
},
Leaving {
#[serde(skip_serializing_if = "Option::is_none")]
room: Option<u64>,
leaving: serde_json::Value,
},
Left {
left: String,
},
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(tag = "ptype")]
#[serde(rename_all = "lowercase")]
pub enum Join {
Publisher {
room: u64,
#[serde(skip_serializing_if = "Option::is_none")]
id: Option<u64>,
#[serde(skip_serializing_if = "Option::is_none")]
display: Option<String>,
},
Subscriber {
room: u64,
feed: u64,
streams: Vec<SubscriberStream>,
},
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
pub struct SubscriberStream {
pub feed_id: u64,
}
#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
pub struct Joining {
pub id: u64,
pub display: String,
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1635codecs: h264decoder: decoding performance regression in latest git2023-01-29T18:09:21ZRafał Dzięgielcodecs: h264decoder: decoding performance regression in latest gitWhile using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This ...While using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This does not happen if I use 1.19.1 or compile gst-plugins-bad from before !2373
Bisect indicated that f1df1207 and b4e38874 were the first 2 bad commits that introduced this bug.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/928gst_discoverer_info_get_duration() sometimes returns "0" without an error2021-09-24T13:26:29ZChris Tgst_discoverer_info_get_duration() sometimes returns "0" without an errorHello!
I amusing the following code in order to get the duration of an AMR-NB file on Pinephone, Mobian/Bullseye, GStreamer version 1.18.4-2, Pulseaudio:
```
discoverer = gst_discoverer_new (GST_SECOND, &error);
if (!discoverer...Hello!
I amusing the following code in order to get the duration of an AMR-NB file on Pinephone, Mobian/Bullseye, GStreamer version 1.18.4-2, Pulseaudio:
```
discoverer = gst_discoverer_new (GST_SECOND, &error);
if (!discoverer) {
g_print ("Error creating discoverer instance: %s\n", error->message);
error = NULL;
return NULL;
}
info = gst_discoverer_discover_uri(discoverer, attachment_uri, &error);
if (error != NULL) {
g_warning ("Error discovering file: %s", error->message);
self->duration_formatted = g_strdup ("??:??");
} else {
self->duration = gst_discoverer_info_get_duration (info);
self->minutes = (self->duration / (GST_SECOND * 60)) % 60;
self->seconds = GST_TIME_AS_SECONDS (self->duration) - self->minutes * 60;
self->duration_formatted = g_strdup_printf ("%02lu:%02lu", self->minutes, self->seconds);
}
```
[test.amr](/uploads/5bd95fe5c6be7d47da84e5f0a8db9a34/test.amr)
Every so often, `info` returns a duration of `0` and does not give me an error.
This code is intergrated here:
https://gitlab.com/kop316/vvmplayer/-/blob/main/src/vvmplayer-voicemail-window.c#L302https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1631Hanging in shmsink2023-06-28T15:18:11ZandrejlevkovitchHanging in shmsinkSometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, ...Sometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, because shmsink can't allocate new memory and blocks of shared memory (as GstBuffer-s) reuses by gstreamer. So producer freezes here:
https://github.com/GStreamer/gst-plugins-bad/blob/f9d7b708e12e5560759c585b44cfa3e523b61526/sys/shm/gstshmsink.c#L730-L742
I see this problem with gstreamer version 1.4 and 1.6
Looks like if we will ignore "need_new_memory" condition (just return from function and skip current frame) it fixes the problem. [Here](https://github.com/andrejlevkovitch/gst-shm-hanging-fix) you can find minimal example for bug reproducing and small fix that resolves the problem.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/720gst-launch-1.0 starts a wordpad input rather than processing stream request2021-09-24T11:08:16ZRod Sheffieldgst-launch-1.0 starts a wordpad input rather than processing stream requestGstreamer-launch-1.0 was working fine. I copied my input pipeline into a WordPad document and copied it to paste into the Command Prompt window. Now running the gst-launch-1.0 pipeline always opens a wordpad document, even when I type ...Gstreamer-launch-1.0 was working fine. I copied my input pipeline into a WordPad document and copied it to paste into the Command Prompt window. Now running the gst-launch-1.0 pipeline always opens a wordpad document, even when I type the command in by hand.
I have tried to launch gst-launch-1.0 via a WSL window, but that tells me that I have an erroneous pipeline element: rtspsrc, which I know is not true.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1630dvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()2021-09-24T14:39:31ZHarald Jennydvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This resul...Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This results in the error message "dvbsrc gstdvbsrc.c:2235:gst_dvbsrc_output_frontend_stats:<dvbsrc0> There were errors getting frontend status information: 'Unknown error 524'" (which means ENOTSUPP). Would it be possible to modify gst_dvbsrc_output_frontend_stats() to do the stats collection in a v5 compatible way like it is done for example in https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/dvbchannel.cpp?
Kind regards
Harald Jennyhttps://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/90Basic Tutorial 5 should use a bus sync handler2021-09-24T16:20:08ZDavid CharlapBasic Tutorial 5 should use a bus sync handlerBasic tutorial 5 (https://gstreamer.freedesktop.org/documentation/tutorials/basic/toolkit-integration.html?gi-language=c) calls `gst_video_overlay_set_window_handle` in the `realize_cb` function. While this works for the specific exampl...Basic tutorial 5 (https://gstreamer.freedesktop.org/documentation/tutorials/basic/toolkit-integration.html?gi-language=c) calls `gst_video_overlay_set_window_handle` in the `realize_cb` function. While this works for the specific example, it doesn't work in the general case.
For example, if you modify this example to use a pipeline that ends with an `ximagesink` (instead of a `playbin` element), the window will open, but no video will play in it.
The reason is that the call needs to be done at a later time. Code should register a bus sync handler, and call `gst_video_overlay_set_window_handle` when a video-overlay-prepare-window-handle message is received.
This is documented here: https://gstreamer.freedesktop.org/documentation/video/gstvideooverlay.html?gi-language=c
Basic Tutorial 5 should be updated to use this mechanism so it can serve as a template for developers writing new code.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1626hlsdemux: m3u8 forwarding to another single m3u8 uri don't play2021-11-24T13:14:31ZAndreas Frischhlsdemux: m3u8 forwarding to another single m3u8 uri don't playtrying to play
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/playlist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3e...trying to play
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/playlist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3eblRWtM55P7LcRQKDSFTbWCMHx4ej7fpyTiaY_0Iy0Xk2LDoqSuAuDw&domain=www.earthtv.com"
```
this will result in a `<souphttpsrc0> error: Forbidden (403)`
however, when directly playing the contained uri
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/chunklist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3eblRWtM55P7LcRQKDSFTbWCMHx4ej7fpyTiaY_0Iy0Xk2LDoqSuAuDw&domain=www.earthtv.com"
```
then playback starts as expected.
vlc and mpv can play directly from the playlist.m3u8 thoughhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1624codecparsers: h265: Broken code in parser is duplicated and fixed in the deco...2021-09-24T14:39:30ZNicolas Dufresnecodecparsers: h265: Broken code in parser is duplicated and fixed in the decoder classWe should fix the parser code and stop duplicating code in the H265 decoder. This code was copied from gstreamer-vaapi, which was doing so already.
The following discussion from !2414 should be addressed:
- [ ] @ndufresne started a [di...We should fix the parser code and stop duplicating code in the H265 decoder. This code was copied from gstreamer-vaapi, which was doing so already.
The following discussion from !2414 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2414#note_994696): (+1 comment)
> I notice also that gst_h265_decoder_prepare_rps() seems to duplicate what gst_h265_parser_parse_slice_hdr() is doing (wrongly, it forgot to reset the NumPicTotalCurr to zero as specified in the spec). The calculated values is needed in the parsing process, so it has to happen in the parser, duplicating it is just a bad friend, since we don't know how the parser may fail considering it has the wrong value.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/925Follow-up from "gl: wayland: Fix hiding the window on close()"2021-09-24T13:26:29ZNicolas DufresneFollow-up from "gl: wayland: Fix hiding the window on close()"The following discussion from !1226 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1226#note_993542): (+1 comment)
> Just as a note #815 was mo...The following discussion from !1226 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1226#note_993542): (+1 comment)
> Just as a note #815 was more targeted towards macos which may have a similar issue.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/717Using memory is increased continuously on h.264 file decoding2022-11-10T09:21:07ZHajime HatanakaUsing memory is increased continuously on h.264 file decodingWe are using the GStreamer V1.16.1 on yocto Linux of i.MX8M mini platform.
When h.264 video file is decoded with vpudec hardware codec engine, amount of memory allocated in the GStreamer
pipeline is sequentially increased. Memory usage i...We are using the GStreamer V1.16.1 on yocto Linux of i.MX8M mini platform.
When h.264 video file is decoded with vpudec hardware codec engine, amount of memory allocated in the GStreamer
pipeline is sequentially increased. Memory usage is investigated with the 'top' command.
VPUDEC version from i.MX8M mini platform is V4.5.5.
GStreamer pipeline we used is 'GST_DEBUG=3 gst-launch-1.0 filesrc location=./H264_1080i.ts ! tsdemux ! vpudec ! fakesink'.
We found this phenomenon is observed in case h.264 content as interlaced video, not progressive one.
Though we contacted NXP team about this issue, they commented this issue is in open source code gstvideodecoder.c and
the actual fix has to come from Opensource community.
Could you have any comment or information about this issue?
Though we searched for articles related to this issue, we couldn't find some helpful information.
For re-generating this issue, we can provide a sample content file like color bar video.
As the file size is large as 55MB, please tell us the mail address we notify the link url for downloading it.