GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-10T09:21:14Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1299souphttpsrc unable to parse response2022-11-10T09:21:14ZSzymon Mikuliczsouphttpsrc unable to parse response### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse respo...### Describe your issue
I am unable to open any http stream using souphttpsrc (I noticed it while trying to use mopidy)
#### Expected Behavior
The stream starts to play
#### Observed Behavior
With proxy ON: I get "Unable to parse response"<br>
With proxy OFF: Crash (SIGABRT)
#### Setup
- **Operating System:** Fedora 36
- **Device:** Computer
- **GStreamer Version:** 1.20
### Steps to reproduce the bug
`gst-launch-1.0 -v souphttpsrc method='get' location='https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3' ! decodebin ! audioconvert ! autoaudiosink`
### How reproducible is the bug?
Always
### Additional Information
Logs attached for proxy/noproxy cases
[gst_proxy.log](/uploads/e42233bfc73b4c7190b6bd3aa4544bdc/gst_proxy.log)
[gst_noproxy.log](/uploads/5714bd0016800ac61408fb1f24fc49ab/gst_noproxy.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1298gst-rtsp-server: not able to send big frames for 2 clients both using rtsp ov...2023-03-09T10:26:07ZBruce Lianggst-rtsp-server: not able to send big frames for 2 clients both using rtsp over tcp in low bandwidth networkHi,
I'm using gstreamer 1.20.2. and come across a problem about rtsp over tcp.
I add a shared media factory to rtsp-server for a h.264 stream.
And there are 2 clients that will access the stream by rtsp over tcp and the network has lo...Hi,
I'm using gstreamer 1.20.2. and come across a problem about rtsp over tcp.
I add a shared media factory to rtsp-server for a h.264 stream.
And there are 2 clients that will access the stream by rtsp over tcp and the network has low bandwidth(100Mbps network).
When the first client accesses the stream from the server choosing rtsp over tcp, it works correctly.
Then the second client accesses the same stream by rtsp over tcp, it will work correctly only while the frame size is not big.
When there is a large I frame that has size over 200KB sent to both clients, the following log shows:
`0:10:04.842062023 420 0x1a5a790 DEBUG rtspclient rtsp-client.c:4908:do_send_messages:<GstRTSPClient at 0x7574c430> wait for message 1, channel 0`
And the server stops sending frames to second client after the large I frame sent, while the server continues to send frames to the first client.
After investigation, I found that:
When rtsp server send rtp/rtcp data over tcp, the tcp send thread(created in handle_new_sample()) calls send_tcp_message().
It will push rtp/rtcp buffer to each transport's backlog and then calls check_transport_backlog() to pop buffer from backlog queue and push buffer to client.
If the buffer can't be sent completely in a single push_data() call, the buffer will be queued and continued to send in client watch thread.
And if the transport is still sending the buffer in client thread, next time calling push_data() in the tcp send thread will get return value false.
Then the transport will be removed and the rtp/rtcp data will not be able to be sent thereafter.
Also I found that when the backlog queue mechanism was introduced, in send_tcp_message(), the backpressure is checked using gst_rtsp_stream_transport_check_back_pressure() before calling push_data().
If there is a buffer queued in client watch(the backlog), the new buffer will not be pushed to client and will be pushed into backlog queue.
According to my understanding, the check mechanism might be the possible solution to this situation.
But I am not sure the reason why it is removed now.
Would you please help to take a look and advise the next step?
Thank you.
related commit:
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/commit/dd32924eb020b01fdec511c9f10a283383312488https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1297gst-rtsp-server: different media will be created for URL rtsp://<IP>:<PORT> a...2022-07-20T07:01:11ZBruce Lianggst-rtsp-server: different media will be created for URL rtsp://<IP>:<PORT> and URL rtsp://<IP>:<PORT>/Hi,
I'm using gstreamer 1.20.2 and come across a problem about mount point "/".
When using shared media factory and mount it at mount point "/", the factory can be accessed by both the URL forms `rtsp://<IP>:<PORT>` and `rtsp://<IP>:...Hi,
I'm using gstreamer 1.20.2 and come across a problem about mount point "/".
When using shared media factory and mount it at mount point "/", the factory can be accessed by both the URL forms `rtsp://<IP>:<PORT>` and `rtsp://<IP>:<PORT>/`.
But I found that the media created by the factory can't be shared between the 2 URL forms.
After the media is created by accessing URL `rtsp://<IP>:<PORT>/`, accessing URL `rtsp://<IP>:<PORT>` will match the same factory but create another new media.
The result of accessing URL `rtsp://<IP>:<PORT>` first and then accessing URL `rtsp://<IP>:<PORT>/` is the same, 2 media created while factory is shared.
After investigation, I found that:
When DESCRIBE request is handled for an URL, the default_make_path() will normalize URL `rtsp://<IP>:<PORT>` to `rtsp://<IP>:<PORT>/` to generate path.
And the path is passed to find_media().
According to my understanding, if the media factory is shared and is attached to mount point "/", the media should be shared for both URL forms.
The default_gen_key() is used to generated key for caching media in gst_rtsp_media_factory_construct().
However, the key is generated by the following line in default_gen_key():
`result = g_strdup_printf ("%u%s%s%s", port, url->abspath, pre_query, query);`
url->abspath is not normalized, so the key will be different and therefore different media will be created for URL `rtsp://<IP>:<PORT>` and URL `rtsp://<IP>:<PORT>/`.
According to my understanding, the possible solution to this situation might be the url could either be normalized before it is passed to gst_rtsp_media_factory_construct() or be normalized in default_gen_key() directly.
Would you please help to take a look and advise the next step?
Thank you.
related commit
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/commit/e9555d1539643f7861a80a7d1333876e90d05134https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/329Vaapih264enc encoded ts segments do not play on AVPlayer2022-06-22T12:21:32ZGuru GovindanVaapih264enc encoded ts segments do not play on AVPlayerThe ts segments generated by `vaapih264enc` elements do not play in AVplayer(quicktime or IOS).
For example the ts segment generated by the following pipeline does not play in quicktime player.
```
gst-launch-1.0 rtspsrc location=rtsp:...The ts segments generated by `vaapih264enc` elements do not play in AVplayer(quicktime or IOS).
For example the ts segment generated by the following pipeline does not play in quicktime player.
```
gst-launch-1.0 rtspsrc location=rtsp://admin:pass@10.10.0.233:554/ name=rtpsrc0 rtpsrc0. ! rtph264depay ! queue ! decodebin ! vaapih264enc ! mpegtsmux name=mux ! filesink location=mymux.ts rtpsrc0. ! decodebin ! queue ! fdkaacenc ! mux.
```
However if I use a SW encoder `x264enc`, it plays fine.
Another weird scenario is it plays fine when the original stream from the rtsp is H265.
If I wrap this over with an ffmpeg copy that would just work fine
eg: doing the following will just work fine
```
ffmpeg -i mymux.ts -vcodec copy -acodec copy mymux_ffmpeg.ts
```
I appreciate any help with this. Please let me know if you need me to attach the ts segments.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1295qtdemux: Unexpected segment end detected (EOS) in push mode (live stream, fmp4)2022-06-21T08:59:01ZAndrzej Surdejqtdemux: Unexpected segment end detected (EOS) in push mode (live stream, fmp4)### Describe your issue
The original issue comes from Vevo application live video playback that is interrupted by unexpected EOS (end of segment) detected from qtdemux. The issue exists with push mode only (pull mode doesn't detect EOS i...### Describe your issue
The original issue comes from Vevo application live video playback that is interrupted by unexpected EOS (end of segment) detected from qtdemux. The issue exists with push mode only (pull mode doesn't detect EOS in my case).
The init segment contains duration of 1min(60sec) and with each moof it is extended with "timestamp" (from qtdemux_parse_trun() func) that is fragment decode time (tfdt) or sample dts and the sum of all samples duration. With such calculations the segment stop time is expressed in dts timeline.
Then processing the data (gst_qtdemux_process_adapter() -> QTDEMUX_STATE_MOVIE) tries to detect the end of segment based on PTS value for each frame that is higher value than dts and passes segment stop time:
` /* check for segment end */
if (G_UNLIKELY (demux->segment.stop != -1
&& demux->segment.stop <= pts && stream->on_keyframe)
&& !(demux->upstream_format_is_time && demux->segment.rate < 0)) {
GST_DEBUG_OBJECT (demux, "we reached the end of our segment.");
stream->time_position = GST_CLOCK_TIME_NONE; /* this means EOS */
`
The issue is barely visible because of additional "on_keyframe" check that suppose to cut segment on keyframes only (so the decoder has all data needed).
The difference why I hit this issue is that my stream has more keyframes (couple in single fragment/moof/mdat) and the EOS is thrown before reaching the end acutually (like 3 samples earlier, depending on dts<->pts shift)
#### Expected Behavior
Video playback should continue without EOS detected
#### Observed Behavior
EOS is thrown from qtdemux and the playback is stopped.
#### Setup
- **Operating System:** Ubuntu 20.04
- **Device:** Computer
- **GStreamer Version:** GStreamer 1.16.2 and GStreamer 1.21.0 (GIT)
- **Command line:** GST_DEBUG="qtdemux:5,2" gst-launch-1.0 pushfilesrc location=<path>/video_8 ! qtdemux ! appsink
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
0. Fetch attached video sample (dump from VEVO live channel): [video_8](/uploads/7a80e18f1686084f21cafb6578ef3bf8/video_8)
1. open terminal
3. type `GST_DEBUG="qtdemux:5,2" gst-launch-1.0 pushfilesrc location=<path>/video_8 ! qtdemux ! appsink`
4. Parsing ends with EOS thrown from qtdemux -> segment end detected
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
The solution for this case would be to replace PTS with DTS when checking for the segment stop. It would make EOS detection more reliable and based on the same timestamp values. This however may interrupt seeking with stop time set (as it's PTS based I believe).
### Related non-duplicate issues
### Additional Information
I have more dumps from the same content if neededhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1294rtsp-client/rtsp-media: Adjust error code before sending request response2022-10-11T09:17:42Zspluyyytrtsp-client/rtsp-media: Adjust error code before sending request responseIssue: There is no way for an application to control what response is sent to a request when rtsp-client encounters an error while setting up the pipeline.
Solution: Store the errors reported from the medias pipeline in rtsp-media. Also...Issue: There is no way for an application to control what response is sent to a request when rtsp-client encounters an error while setting up the pipeline.
Solution: Store the errors reported from the medias pipeline in rtsp-media. Also add a virtual function in rtsp-client which, if overriden by the application will be called before sending the error response. There should be no change in todays behaviour unless this method is overriden.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1293nvcodec has 0 features in gstreamer docker image 1.202022-08-03T14:47:07ZElliott Velasconvcodec has 0 features in gstreamer docker image 1.20Hello,
I'm relatively new in trying to get the nvcodec plugin working in a docker image. When I perform a a gst-inspect-1.0 on the nvcodec plugin I get this output:
Plugin Details:
Name nvcodec
Description ...Hello,
I'm relatively new in trying to get the nvcodec plugin working in a docker image. When I perform a a gst-inspect-1.0 on the nvcodec plugin I get this output:
Plugin Details:
Name nvcodec
Description GStreamer NVCODEC plugin
Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstnvcodec.so
Version 1.20.2.1
License LGPL
Source module gst-plugins-bad
Binary package GStreamer Bad Plug-ins git
Origin URL Unknown package origin
0 features:
I was wondering how I can get the nvcodec elements loaded in? And I followed this old thread with a similar issue https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1067 but I couldn't get it working following this solution.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1292HDR10 CLL metadata is allowed to change2022-06-20T13:30:23ZValZapodHDR10 CLL metadata is allowed to changeContrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to cha...Contrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to change in mp4. As ffmpeg mail says (right now [last HDR metadata patches](https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3373) are being accepted):
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg108319.html
> in that some formats allow use to set it on frame,
> some on the stream, some on the container
> I notice that color data can be set per frame and per stream already
> and I don’t fully understand how these interact if converting between data in
> frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
> HEVC SEI in hvc1 format).
And this is correct. Free CTA-861-G (and now -H) standard mandate that and I quote:
> If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it
> determines that the Sink is capable of receiving that information, the Source shall send the Dynamic
> Range and Mastering InfoFrame **once per Video Field**
What that means is that it is allowed to change and display should be fast enough to change it on the fly.
In fact there is a sample from "In the Heart of the Sea" movie https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4 that utilizes that.
It can cause all kind of issues for you. mpv does support it and so does MadVR.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1291tsdemux: tsdemux produces buffers with no PTS/DST when ignoring PCR.2022-10-20T06:20:12Zazerowalltsdemux: tsdemux produces buffers with no PTS/DST when ignoring PCR.GStreaemer version: 1.20.2
File: [euronews.ts](/uploads/226e3c7b9622e4d43eacc0fa11f3e04c/euronews.ts)
Pipeline:
```
filesrc location=euronews.ts ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpeg...GStreaemer version: 1.20.2
File: [euronews.ts](/uploads/226e3c7b9622e4d43eacc0fa11f3e04c/euronews.ts)
Pipeline:
```
filesrc location=euronews.ts ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpegvideoparse ! mux. \
mux. ! filesink location=out.ts sync=false
```
But if I stream the same file via UDP, then timestamps exist:
```
udpsrc uri=udp://239.1.1.1:1234 do-timestamp=false ! tsdemux ignore-pcr=true name=dem \
mpegtsmux name=mux \
dem. ! queue ! video/mpeg ! mpegvideoparse ! mux. \
mux. ! filesink location=out.ts sync=false
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1290gstreamer-sharp: Gst.Application requires WebRTC (gst-plugins-bad) by default2022-06-17T23:28:41ZPedro Castrogstreamer-sharp: Gst.Application requires WebRTC (gst-plugins-bad) by defaultThe static constructor in Gst.Application registers WebRTC by default:
```csharp
GLib.GType.Register(Gst.WebRTC.WebRTCSessionDescription.GType, typeof(Gst.WebRTC.WebRTCSessionDescription));
```
This implies that `gst-plugins-bad`, whic...The static constructor in Gst.Application registers WebRTC by default:
```csharp
GLib.GType.Register(Gst.WebRTC.WebRTCSessionDescription.GType, typeof(Gst.WebRTC.WebRTCSessionDescription));
```
This implies that `gst-plugins-bad`, which contains WebRTC, will be required to run gstreamer-sharp.
Wondering if this was a design decision. I've switched to gstreamer-sharp in Gnome Subtitles and WebRTC isn't used, so would rather prefer not to force users to install plugins-bad unnecessarily.https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/63gstreamer-sharp: An unhandled exception of type 'System.Exception' occurred i...2022-06-20T15:13:19ZConnor Hawesgstreamer-sharp: An unhandled exception of type 'System.Exception' occurred in GLibSharp.dll Unknown type GstRTSPMessageCurrently trying to handle the before-send rtspsrc signal in order to add headers to RTSP messages.
Upon the handler being triggered the titular message is thrown.
Here is my current handler:
`
private void BeforeSendCb(object s...Currently trying to handle the before-send rtspsrc signal in order to add headers to RTSP messages.
Upon the handler being triggered the titular message is thrown.
Here is my current handler:
`
private void BeforeSendCb(object sender, SignalArgs args)
{
Gst.Rtsp.RTSPMessage message = (Gst.Rtsp.RTSPMessage)args.Args[0];
message.AddHeader(Gst.Rtsp.RTSPHeaderField.CompanyId, "CONNOR HAWES");
Trace.WriteLine("BREAK HERE");
}
`
And the subscription:
`
_rtspsrc.Connect("before-send", BeforeSendCb);
`
I was wondering if I was doing anything wrong or if there is a workaround?
Thanks in advancehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1289iOS GstPlay - Can't receive any signal2022-06-17T14:17:41ZbudainiOS GstPlay - Can't receive any signal### Describe your issue
I would like to receive some signal from `GstPlay`: [see documentation](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstplay-types.html?gi-language=c#GstPlaySignalAdapter::state-changed)
...### Describe your issue
I would like to receive some signal from `GstPlay`: [see documentation](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstplay-types.html?gi-language=c#GstPlaySignalAdapter::state-changed)
#### Expected Behavior
My function should be call and print my logs
#### Setup
- **Operating System:** iOS
- **Device:** Mobile
- **GStreamer Version:** 1.20.2
- **Command line:** `g_signal_connect (adapter, "state-changed", G_CALLBACK(stateChangedCb), NULL);`
### Steps to reproduce the bug
```
static GstPlay *player;
static GstPlaySignalAdapter *adapter;
-(instancetype)init {
self = [super init];
if (!player) {
[self configurePlayer];
}
return self;
}
-(void)configurePlayer {
GstreamerConfiguration(); // Like gst_ios_init
player = gst_play_new(NULL);
adapter = gst_play_signal_adapter_new(player);
gst_play_config_set_seek_accurate(gst_play_get_config(player), true);
[self configureCallBacks];
}
-(void)configureCallBacks {
NSLog(@"---- callllled");
g_signal_connect (adapter, "state-changed", G_CALLBACK(stateChangedCb), NULL);
}
void stateChangedCb (GstPlaySignalAdapter *adapter, GstPlayState *state, void *data) {
NSLog(@"---- NEW STATE");
}
```
The log `---- NEW STATE` should be print .
Do you have any idea ?https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/104iOS GstPlay - Can't receive any signal2022-06-17T09:42:18ZbudainiOS GstPlay - Can't receive any signalI would like to use `GstPlay` to play some audio file from a remote URL. I can `play`, `pause`, `seek`..
I want to listen some event: `state_changed` ([see doc](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstpl...I would like to use `GstPlay` to play some audio file from a remote URL. I can `play`, `pause`, `seek`..
I want to listen some event: `state_changed` ([see doc](https://gstreamer.freedesktop.org/documentation/play/gst-libs/gst/play/gstplay-types.html?gi-language=c#GstPlaySignalAdapter::state-changed))
I don't understand why don't receive any signal:
My code:
```
static GstPlaySignalAdapter *adapter;
-(instancetype)init {
self = [super init];
if (!monoPlayer) {
[self configurePlayer];
}
return self;
}
-(void)configurePlayer {
GstreamerConfiguration(); // Like gst_ios_init
player = gst_play_new(NULL);
adapter = gst_play_signal_adapter_new(player);
gst_play_config_set_seek_accurate(gst_play_get_config(player), true);
[self configureCallBacks];
}
-(void)configureCallBacks {
NSLog(@"---- callllled");
g_signal_connect (adapter, "state-changed", G_CALLBACK(stateChangedCb), NULL);
}
void stateChangedCb (GstPlaySignalAdapter *adapter, GstPlayState *state, void *data) {
NSLog(@"---- NEW STATE");
// gst_print ("State changed: %s\n", gst_play_state_get_name (state));
}
```
I use GStreamer `1.20.2`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1288Unsafe eglimage cache usage in gstglupload.c in combination with tee2022-06-17T06:57:29ZErik De RijckeUnsafe eglimage cache usage in gstglupload.c in combination with tee`gstglupload.c` with tee calls `_set_cached_eglimage` and potentially frees the previously stored eglimage pointer, and later triggers critical warnings when the eglimage is unreffed again & potentially causes segfaults.
From gstreamer ...`gstglupload.c` with tee calls `_set_cached_eglimage` and potentially frees the previously stored eglimage pointer, and later triggers critical warnings when the eglimage is unreffed again & potentially causes segfaults.
From gstreamer irc:
```
00:55 < ndufresne> zubzub: ah, the cache is still not tee safe?
00:56 < ndufresne> We've fixed many cache over the time, so I can't remember if that one is still broken... But you can't cache on the buffer itself, that's not safe
```
Tested on gstreamer 1.20.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/971SIGSEGV in subprojects/gst-plugins-base/gst/playback/gstparsebin.c during HLS...2022-06-16T22:41:38ZBill HofmannSIGSEGV in subprojects/gst-plugins-base/gst/playback/gstparsebin.c during HLS stream using souphttpsrcUprev'd from 1.20.1 with two local changes in kms to 1.20.3, now 100% reproducible SIGSEGV while playing graph that works extremely reliably in 1.20.1. First sign was my python impl getting buffering messages (which it never had before)...Uprev'd from 1.20.1 with two local changes in kms to 1.20.3, now 100% reproducible SIGSEGV while playing graph that works extremely reliably in 1.20.1. First sign was my python impl getting buffering messages (which it never had before), but followed by crash. Repro'd outside my program, with reduced M3U8 file.
Build/Env:
- Ubuntu 21.10
- `meson -Dvaapi=enabled -Dbad=enabled -Dugly=enabled builddir`
Command (after ninja -C builddir devenv)
```
GST_DEBUG_FILE=./crash.txt GST_DEBUG=6 gdb --args gst-launch-1.0 \
souphttpsrc location="http://127.0.0.1/1D2E355A-BD2C-4807-91EA-4C2236D2DBED/0/short.m3u8" ! parsebin name=pb ! queue ! vaapih265dec ! \
video/x-raw,format=P010_10LE ! queue max-size-bytes=100663300 ! kmssink connector-id=78 plane-id=55
```
I set a `catch signal SIGSEGV` and here is the tail of the GDB output:
```
[New Thread 0x7fffbd7fa640 (LWP 1624)]
Pipeline is PREROLLING ...
[New Thread 0x7fffbcff9640 (LWP 1625)]
Got context from element 'vaapidecode_h265-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1", gst.vaapi.Display.GObject=(GstObject)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(GstSoupSession)NULL;
[New Thread 0x7fff9ffff640 (LWP 1626)]
[New Thread 0x7fff9f7fe640 (LWP 1627)]
[New Thread 0x7fff9effd640 (LWP 1628)]
[New Thread 0x7fff9e7fc640 (LWP 1629)]
[New Thread 0x7fff9dffb640 (LWP 1630)]
[New Thread 0x7fff9d7fa640 (LWP 1631)]
[Switching to Thread 0x7fff9d7fa640 (LWP 1631)]
Thread 60 "task3" hit Catchpoint 1 (signal SIGSEGV), gst_parse_chain_expose (chain=chain@entry=0x7fff88047ae0, endpads=endpads@entry=0x7fff9d7f9340, missing_plugin=missing_plugin@entry=0x7fff9d7f932c, missing_plugin_details=missing_plugin_details@entry=0x7fff80002c00, last_group=last_group@entry=0x7fff9d7f9330, uncollected_streams=uncollected_streams@entry=0x7fff9d7f9334) at ../subprojects/gst-plugins-base/gst/playback/gstparsebin.c:3777
3777 if (p->active_stream && p->active_collection == NULL
(gdb) frame
#0 gst_parse_chain_expose (chain=chain@entry=0x7fff88047ae0, endpads=endpads@entry=0x7fff9d7f9340, missing_plugin=missing_plugin@entry=0x7fff9d7f932c,
missing_plugin_details=missing_plugin_details@entry=0x7fff80002c00, last_group=last_group@entry=0x7fff9d7f9330, uncollected_streams=uncollected_streams@entry=0x7fff9d7f9334)
at ../subprojects/gst-plugins-base/gst/playback/gstparsebin.c:3777
3777 if (p->active_stream && p->active_collection == NULL
(gdb) up
#1 0x00007ffff4c3a8e6 in gst_parse_chain_expose (chain=<optimized out>, endpads=endpads@entry=0x7fff9d7f9340, missing_plugin=missing_plugin@entry=0x7fff9d7f932c,
missing_plugin_details=missing_plugin_details@entry=0x7fff80002c00, last_group=last_group@entry=0x7fff9d7f9330, uncollected_streams=uncollected_streams@entry=0x7fff9d7f9334)
at ../subprojects/gst-plugins-base/gst/playback/gstparsebin.c:3788
3788 ret |= gst_parse_chain_expose (childchain, endpads, missing_plugin,
(gdb)
```
Output of GST is attached: [ourcrash.txt](/uploads/b880eb7237fd738f6b0ebea8155d6749/ourcrash.txt).
Note this version runs just fine using filesrc of a different MP4 instead of the souphttpsrc.
Just for jollies, here's the M3U8: [short.m3u8](/uploads/12aaaa568f4294cd313cea4ee0857f10/short.m3u8)
I can provide the TS files, but they're kinda big. Happy to attach if desired.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1286videorate: gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed2024-01-31T18:19:04ZJames Hilliardvideorate: gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failedI'm hitting this failure locally on main, not sure why it's not showing up in CI.
```c
1..1
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/fl...I'm hitting this failure locally on main, not sure why it's not showing up in CI.
```c
1..1
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-sink-expected'**
**-> Checking expectations file: '/home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-src-expected'**
**-> Pipeline: 'videotestsrc ! video/x-raw,format=I420,framerate=10/1,width=320,height=240 ! videorate name=videorate ! fakesink sync=true qos=true'**
**-> Running scenario /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback.validatetest on pipeline pipeline0**
**-> Starting pipeline**
Prerolling...
**-> Pipeline started**
Executing `seek` at change_rate_reverse_playback.validatetest:14 (
- start=0
- stop=5
- flags=accurate+flush
- rate=-1
)
? Action `seek` at change_rate_reverse_playback.validatetest:14 done 'ASYNC' (duration: 0:00:00.018481721)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:17 (
- expected-time=0
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:17 done 'OK' (duration: 0:00:00.000120623)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=0/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [0/4] (duration: 0:00:00.001369976)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=1/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [1/4] (duration: 0:00:00.002062006)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=2/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [2/4] (duration: 0:00:00.001979757)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:18 [repeat=3/4] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:18 done 'OK' [3/4] (duration: 0:00:00.002117339)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:19 (
- expected-time=0.5
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:19 done 'OK' (duration: 0:00:00.002002966)
Executing `wait` at change_rate_reverse_playback.validatetest:22 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:22 done 'OK' (duration: 0:00:00.001861676)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:25 (
- text="Setting\ videorate.rate\=0.5"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:25 done 'OK' (duration: 0:00:00.000022958)
Executing `set-property` at change_rate_reverse_playback.validatetest:26 (
- playback-time=99
- target-element-name=videorate
- property-name=rate
- property-value=0.5
)
? Action `set-property` at change_rate_reverse_playback.validatetest:26 done 'OK' (duration: 0:00:00.000215330)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=0/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [0/5] (duration: 0:00:00.000138289)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=1/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [1/5] (duration: 0:00:00.001905134)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=2/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [2/5] (duration: 0:00:00.002039256)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=3/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [3/5] (duration: 0:00:00.000112581)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:29 [repeat=4/5] (
- expected-elapsed-time=0.10000000000000001
)
? Action `crank-clock` at change_rate_reverse_playback.validatetest:29 done 'OK' [4/5] (duration: 0:00:00.000130706)
Executing `wait` at change_rate_reverse_playback.validatetest:30 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:30 done 'OK' (duration: 0:00:00.002011840)
Executing `check-position` at change_rate_reverse_playback.validatetest:31 (
- expected-position=4
)
? Action `check-position` at change_rate_reverse_playback.validatetest:31 done 'OK' (duration: 0:00:00.000578406)
Executing `set-vars` at change_rate_reverse_playback.validatetest:33 (
- rate=0.1
)
? Action `set-vars` at change_rate_reverse_playback.validatetest:33 done 'OK' (duration: 0:00:00.000022166)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:34 (
- text="Setting\ videorate.rate\=0.1"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:34 done 'OK' (duration: 0:00:00.000021125)
Executing `set-property` at change_rate_reverse_playback.validatetest:35 (
- playback-time=99
- target-element-name=videorate
- property-name=rate
- property-value=0.10000000000000001
)
? Action `set-property` at change_rate_reverse_playback.validatetest:35 done 'OK' (duration: 0:00:00.000198079)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=0/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [0/20] (duration: 0:00:00.000066373)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=1/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [1/20] (duration: 0:00:00.005746609)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=2/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [2/20] (duration: 0:00:00.000084790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=3/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [3/20] (duration: 0:00:00.000069874)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=4/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [4/20] (duration: 0:00:00.000064666)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=5/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [5/20] (duration: 0:00:00.000061832)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=6/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [6/20] (duration: 0:00:00.000067416)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=7/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [7/20] (duration: 0:00:00.002028132)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=8/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [8/20] (duration: 0:00:00.000062790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=9/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [9/20] (duration: 0:00:00.000063249)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=10/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [10/20] (duration: 0:00:00.000069082)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=11/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [11/20] (duration: 0:00:00.000064582)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=12/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [12/20] (duration: 0:00:00.000063957)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=13/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [13/20] (duration: 0:00:00.000062999)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=14/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [14/20] (duration: 0:00:00.000081790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=15/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [15/20] (duration: 0:00:00.000063624)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=16/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [16/20] (duration: 0:00:00.000063165)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=17/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [17/20] (duration: 0:00:00.002091464)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=18/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [18/20] (duration: 0:00:00.000066790)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:36 [repeat=19/20] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:36 done 'OK' [19/20] (duration: 0:00:00.000064624)
Executing `wait` at change_rate_reverse_playback.validatetest:37 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:37 done 'OK' (duration: 0:00:00.000021791)
Executing `check-position` at change_rate_reverse_playback.validatetest:38 (
- expected-position=2
)
? Action `check-position` at change_rate_reverse_playback.validatetest:38 done 'OK' (duration: 0:00:00.000578365)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:41 (
- text="Setting\ videorate.rate\=2.0"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:41 done 'OK' (duration: 0:00:00.000022958)
Executing `set-property` at change_rate_reverse_playback.validatetest:42 (
- playback-time=-1
- target-element-name=videorate
- property-name=rate
- property-value=2
)
? Action `set-property` at change_rate_reverse_playback.validatetest:42 done 'OK' (duration: 0:00:00.000194496)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=0/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [0/10] (duration: 0:00:00.000058749)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=1/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [1/10] (duration: 0:00:00.027939974)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=2/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [2/10] (duration: 0:00:00.035776879)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=3/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [3/10] (duration: 0:00:00.007801448)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=4/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [4/10] (duration: 0:00:00.007349206)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=5/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [5/10] (duration: 0:00:00.006430972)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=6/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [6/10] (duration: 0:00:00.003889225)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=7/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [7/10] (duration: 0:00:00.003849100)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=8/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [8/10] (duration: 0:00:00.003219236)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:43 [repeat=9/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:43 done 'OK' [9/10] (duration: 0:00:00.003205403)
Executing `wait` at change_rate_reverse_playback.validatetest:44 (
- on-clock=true
)
? Action `wait` at change_rate_reverse_playback.validatetest:44 done 'OK' (duration: 0:00:00.001707720)
Executing `checkpoint` at change_rate_reverse_playback.validatetest:47 (
- text="Filling\ up\ segment\ with\ last\ buffer"
)
? Action `checkpoint` at change_rate_reverse_playback.validatetest:47 done 'OK' (duration: 0:00:00.000100665)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=0/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [0/10] (duration: 0:00:00.000188997)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=1/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [1/10] (duration: 0:00:00.005131411)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=2/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [2/10] (duration: 0:00:00.002966824)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=3/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [3/10] (duration: 0:00:00.002859200)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=4/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [4/10] (duration: 0:00:00.002367584)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=5/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [5/10] (duration: 0:00:00.002356959)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=6/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [6/10] (duration: 0:00:00.002005590)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=7/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [7/10] (duration: 0:00:00.001805386)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=8/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [8/10] (duration: 0:00:00.001839926)
Executing `crank-clock` at change_rate_reverse_playback.validatetest:48 [repeat=9/10] ( )
? Action `crank-clock` at change_rate_reverse_playback.validatetest:48 done 'OK' [9/10] (duration: 0:00:00.001235687)
<position: 0:00:00.000000000 duration: 99:99:99.999999999 speed: -1.000000 />
<position: 0:00:00.000000000 duration: 99:99:99.999999999 speed: -1.000000 />
Executing `stop` at change_rate_reverse_playback.validatetest:50 (
- on-message=eos
)
? Action `stop` at change_rate_reverse_playback.validatetest:50 done 'OK' (duration: 0:00:00.000257954)
change_rate_reverse_playback.validatetest --> State change request NULL, quitting mainloop
validateflowoverride0 --> Checking that flow /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-sink-expected matches expected flow /home/buildroot/gstreamer/build/subprojects/gst-plugins-base/tests/validate/validate.videorate.change_rate_reverse_playback/change_rate_reverse_playback/log-videorate-sink-actual
validateflowoverride0 --> OK
validateflowoverride1 --> Checking that flow /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback/flow-expectations/log-videorate-src-expected matches expected flow /home/buildroot/gstreamer/build/subprojects/gst-plugins-base/tests/validate/validate.videorate.change_rate_reverse_playback/change_rate_reverse_playback/log-videorate-src-actual
validateflowoverride1 --> OK
warning : a serialized event received should be pushed in the same 'time' as it was received
Detected on <videorate:src>
Description : serialized events should be pushed in the same order they are received and serialized with buffers. If an event is received after a buffer with timestamp end 'X', it should be pushed right after buffers with timestamp end 'X'
critical : We got a g_log critical issue
Detected on <pipeline0>
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
Details : gst_event_new_qos: assertion 'diff >= 0 || -diff <= timestamp' failed
Details : gst_pad_push_event: assertion 'GST_IS_EVENT (event)' failed
dotfile : no dotfile produced as GST_DEBUG_DUMP_DOT_DIR is not set.
backtrace :
gst_debug_get_stack_trace (gstinfo.c:3234)
gst_validate_report_new (gst-validate-report.c:921)
gst_validate_report_valist (gst-validate-reporter.c:189)
gst_validate_report (gst-validate-reporter.c:323)
g_logv (/usr/lib/libglib-2.0.so.0.7200.2:0xffff5027b16c)
g_log (/usr/lib/libglib-2.0.so.0.7200.2:0xffff5027b414)
gst_event_new_qos (gstevent.c:1219)
gst_video_rate_src_event (gstvideorate.c:1025)
gst_validate_pad_monitor_src_event_func (gst-validate-pad-monitor.c:2192)
gst_pad_send_event_unchecked (gstpad.c:5897)
gst_pad_push_event_unchecked (gstpad.c:5541)
gst_pad_push_event (gstpad.c:5678)
gst_base_sink_chain_unlocked.constprop.0 (gstbasesink.c:2927)
gst_base_sink_chain_main (gstbasesink.c:4078)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_video_rate_transform_ip (gstvideorate.c:1718)
default_generate_output (gstbasetransform.c:2187)
gst_base_transform_chain (gstbasetransform.c:2345)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_base_transform_chain (gstbasetransform.c:2381)
gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2348)
gst_pad_chain_data_unchecked (gstpad.c:4444)
gst_pad_push_data (gstpad.c:4708)
gst_pad_push (gstpad.c:4827)
gst_base_src_loop (gstbasesrc.c:3030)
gst_task_func (gsttask.c:384)
?? (/usr/lib/libglib-2.0.so.0.7200.2:0xffff502a4650)
?? (/usr/lib/libglib-2.0.so.0.7200.2:0xffff502a37a8)
?? (/usr/lib/libc.so.6:0xffff4fdf0ae8)
?? (/usr/lib/libc.so.6:0xffff4fe5a5d8)
Issues found: 37
Returning 18 as errors were found
=======> Test FAILED (Return value: 18)
not ok 1 /home/buildroot/gstreamer/subprojects/gst-plugins-base/tests/validate/videorate/change_rate_reverse_playback.validatetest Got a critical report
```
[change_rate_reverse_playback-stderr.log](/uploads/9411b8c63cb5c72e2a3d3735eb3bb551/change_rate_reverse_playback-stderr.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/970Uridecodebin does not work with certain RTSP video streams2023-07-27T10:15:33ZMatteo FoglioUridecodebin does not work with certain RTSP video streamsHello, I am dealing with two RTSP video streams that cannot be decoded using `uridecodebin`.
**Disclaimer**:I am working with Nvidia Deepstream which is based on Gstreamer. However the issue seems to be related to `uridecodebin`.
The ...Hello, I am dealing with two RTSP video streams that cannot be decoded using `uridecodebin`.
**Disclaimer**:I am working with Nvidia Deepstream which is based on Gstreamer. However the issue seems to be related to `uridecodebin`.
The following pipelines kinda work on only one of the streams (it saved a video that cannot be played... while the `fakesink` pipeline does not seem to print anything):
```
gst-launch-1.0 uridecodebin uri=$RTSP_STREAM ! filesink location='test.mp4'
gst-launch-1.0 uridecodebin uri=$RTSP_STREAM ! nvvideoconvert ! fakesink
```
The RTSP video streams can be played correctly using VLC and ffplay.
One of the two streams (not both) can be decoded using the following pipeline, which uses Nvidia hardware acceleration to decode the video:
```
gst-launch-1.0 --gst-debug=v4l2videodec:5 rtspsrc location=$RTSP_STREAM protocols=tcp latency=1000 drop-on-latency=1 timeout=5000000 ! rtph264depay ! h264parse ! nvv4l2decoder cudadec-memtype=2 num-extra-surfaces=1 ! queue leaky=2 max-size-buffers=1 ! nvvideoconvert nvbuf-memory-type=3 output-buffers=1 ! capsfilter caps=video/x-raw,format=RGBA ! fakesink
```
Both the video can be decoded with the same pipeline using the software decoder (however I need to use the hardware decoder)
```
gst-launch-1.0 --gst-debug=v4l2videodec:5 rtspsrc location=$RTSP_STREAM protocols=tcp latency=1000 drop-on-latency=1 timeout=5000000 ! rtph264depay ! h264parse ! avdec_h264 ! queue leaky=2 max-size-buffers=1 ! nvvideoconvert nvbuf-memory-type=3 output-buffers=1 ! capsfilter caps=video/x-raw,format=RGBA ! filesink location='test-nvv4l2decoder.mp4'
```
The RTSP video streams are private but I am happy to privately share them with anyone who can help me debug the issue.
I am also trying to get more help from Nvidia on their forum, but the issue seems to be caused by Gstreamer components.
More here: https://forums.developer.nvidia.com/t/uridecodebin-cannot-decode-an-rtsp-video-stream/217422
Thank you!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1285iOS: Cannot retrieve width & height via "check_media_size" method2022-06-15T16:35:04ZSiegbaertiOS: Cannot retrieve width & height via "check_media_size" methodHello GStreamer community,
I am developing a native iOS application, which should be capable of displaying a live videostream.
My code is based on the official [GStreamer iOS tutorials](https://gstreamer.freedesktop.org/documentation/tu...Hello GStreamer community,
I am developing a native iOS application, which should be capable of displaying a live videostream.
My code is based on the official [GStreamer iOS tutorials](https://gstreamer.freedesktop.org/documentation/tutorials/ios/index.html?gi-language=c).
The stream itself works. It is displayed and I am quite satisfied with resolution, FPS and latency of the stream.
But I am not able to get the following method - which was taken from the [tutorials](https://gstreamer.freedesktop.org/documentation/tutorials/ios/a-basic-media-player.html?gi-language=c) - to return the expected result:
```objc
static void check_media_size (GStreamerBackend *self) {
GstElement *video_sink;
GstPad *video_sink_pad;
GstCaps *caps;
GstVideoInfo info;
/* Retrieve the Caps at the entrance of the video sink */
g_object_get (self->pipeline, "video-sink", &video_sink, NULL);
video_sink_pad = gst_element_get_static_pad (video_sink, "sink");
caps = gst_pad_get_current_caps (video_sink_pad);
if (gst_video_info_from_caps (&info, caps)) {
NSLog(@"check_media_size - Media size is %dx%d, notifying application", info.width, info.height);
info.width = info.width * info.par_n / info.par_d;
GST_DEBUG ("Media size is %dx%d, notifying application", info.width, info.height);
if (self->ui_delegate && [self->ui_delegate respondsToSelector:@selector(mediaSizeChanged:height:)])
{
[self->ui_delegate mediaSizeChanged:info.width height:info.height];
}
}
gst_caps_unref(caps);
gst_object_unref (video_sink_pad);
gst_object_unref(video_sink);
}
```
The function call:
`g_object_get (self->pipeline, "video-sink", &video_sink, NULL);`
triggers the following warning:
> (:22803): GLib-GObject-�[1;33mWARNING�[0m **: �[34m08:43:06.226�[0m: g_object_get_is_valid_property: object class 'GstPipeline' has no property named 'video-sink'
As a result, the next 2 lines of code also fail:
```
video_sink_pad = gst_element_get_static_pad (video_sink, "sink");
caps = gst_pad_get_current_caps (video_sink_pad);
```
> (:22803): GStreamer-�[1;35mCRITICAL�[0m **: �[34m08:43:06.226�[0m: gst_element_get_static_pad: assertion 'GST_IS_ELEMENT (element)' failed.
> (:22803): GStreamer-�[1;35mCRITICAL�[0m **: �[34m08:43:06.226�[0m: gst_pad_get_current_caps: assertion 'GST_IS_PAD (pad)' failed
and finally, the instruction in the if(...) block always returns false
`if (gst_video_info_from_caps (&info, caps))`
therefore, the code inside the if-block is never executed and there's no way to receive the media info (e.g. width & height) of the video being played.
I do not understand why the pipeline does not seem to have a "video-sink" property, but the stream itself works and is displayed.
Any help/hint would be appreciated.
----
### Additional information
**GStreamer version:** I tested the behaviour with GStreamer 1.19.3 as well as 1.20.2.
On the server side (MacOs), I am running the following pipeline:
`gst-launch-1.0 -v autovideosrc ! "video/x-raw,framerate=30/1" ! queue ! jpegenc ! queue ! rtpjpegpay ! udpsink host=<IP_ADDRESS> port=8003`
On client side (iOS), this is the pipeline used to display the stream:
`udpsrc port=8003 ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, a-framerate=(string)30.000000, payload=(int)26, ssrc=(uint)2661516146, timestamp-offset=(uint)3924289949, seqnum-offset=(uint)1975 ! rtpbin ! rtpjpegdepay ! queue ! jpegdec ! queue ! videoconvert ! autovideosink sync=false`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1284Gstreamer Android does not compile with Gradle plugin 7.22024-02-28T07:35:56ZMiguel SesmaGstreamer Android does not compile with Gradle plugin 7.2### Describe your issue
Starting with Android Gradle plugin 7.2.0, GStreamer does not compile and fails with an error:
[CXX1415] .../video/build/.cxx/Debug/1s5v2mh6/arm64-v8a/android_gradle_build.json debug|arm64-v8a : gstreamer_android...### Describe your issue
Starting with Android Gradle plugin 7.2.0, GStreamer does not compile and fails with an error:
[CXX1415] .../video/build/.cxx/Debug/1s5v2mh6/arm64-v8a/android_gradle_build.json debug|arm64-v8a : gstreamer_android-debug-gst-build-arm64-v8a.abi 'gst-build-arm64-v8a' is invalid. Valid values are 'armeabi-v7a, arm64-v8a, x86, x86_64'
#### Expected Behavior
Normal compilation as it happened until AGP 7.1.2
#### Observed Behavior
The compiled folder names under AGP 7.0 don't accept the prefix "gst-build-"
#### Setup
- MacOS
- Macbook M1
- Tested with 1.18.4 and 1.20.2
- ./gradlew assembleDebug
### Solutions you have tried
There is a easy workaround that is editing Gstreamer files "gstreamer-1.0.mk" (Under for example arm64/share/gst-android/ndk-build) and edit line
`GSTREAMER_BUILD_DIR := gst-build-$(TARGET_ARCH_ABI)` removing the prefix so it looks like
`GSTREAMER_BUILD_DIR := $(TARGET_ARCH_ABI)`
And of course do this for each architecture supported.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/97iOS: Cannot retrieve width & height via "check_media_size" method2022-06-15T16:32:06ZSiegbaertiOS: Cannot retrieve width & height via "check_media_size" methodHello GStreamer community,
I am developing a native iOS application, which should be capable of displaying a live videostream.
My code is based on the official [GStreamer iOS tutorials](https://gstreamer.freedesktop.org/documentation/tu...Hello GStreamer community,
I am developing a native iOS application, which should be capable of displaying a live videostream.
My code is based on the official [GStreamer iOS tutorials](https://gstreamer.freedesktop.org/documentation/tutorials/ios/index.html?gi-language=c).
The stream itself works. It is displayed and I am quite satisfied with resolution, FPS and latency of the stream.
But I am not able to get the following method - which was taken from the [tutorials](https://gstreamer.freedesktop.org/documentation/tutorials/ios/a-basic-media-player.html?gi-language=c) - to return the expected result:
```objc
static void check_media_size (GStreamerBackend *self) {
GstElement *video_sink;
GstPad *video_sink_pad;
GstCaps *caps;
GstVideoInfo info;
/* Retrieve the Caps at the entrance of the video sink */
g_object_get (self->pipeline, "video-sink", &video_sink, NULL);
video_sink_pad = gst_element_get_static_pad (video_sink, "sink");
caps = gst_pad_get_current_caps (video_sink_pad);
if (gst_video_info_from_caps (&info, caps)) {
NSLog(@"check_media_size - Media size is %dx%d, notifying application", info.width, info.height);
info.width = info.width * info.par_n / info.par_d;
GST_DEBUG ("Media size is %dx%d, notifying application", info.width, info.height);
if (self->ui_delegate && [self->ui_delegate respondsToSelector:@selector(mediaSizeChanged:height:)])
{
[self->ui_delegate mediaSizeChanged:info.width height:info.height];
}
}
gst_caps_unref(caps);
gst_object_unref (video_sink_pad);
gst_object_unref(video_sink);
}
```
The function call:
`g_object_get (self->pipeline, "video-sink", &video_sink, NULL);`
triggers the following warning:
> (:22803): GLib-GObject-�[1;33mWARNING�[0m **: �[34m08:43:06.226�[0m: g_object_get_is_valid_property: object class 'GstPipeline' has no property named 'video-sink'
As a result, the next 2 lines of code also fail:
```
video_sink_pad = gst_element_get_static_pad (video_sink, "sink");
caps = gst_pad_get_current_caps (video_sink_pad);
```
> (:22803): GStreamer-�[1;35mCRITICAL�[0m **: �[34m08:43:06.226�[0m: gst_element_get_static_pad: assertion 'GST_IS_ELEMENT (element)' failed.
> (:22803): GStreamer-�[1;35mCRITICAL�[0m **: �[34m08:43:06.226�[0m: gst_pad_get_current_caps: assertion 'GST_IS_PAD (pad)' failed
and finally, the instruction in the if(...) block always returns false
`if (gst_video_info_from_caps (&info, caps))`
therefore, the code inside the if-block is never executed and there's no way to receive the media info (e.g. width & height) of the video being played.
I do not understand why the pipeline does not seem to have a "video-sink" property, but the stream itself works and is displayed.
Any help/hint would be appreciated.
----
### Additional information
**GStreamer version:** I tested the behaviour with GStreamer 1.19.3 as well as 1.20.2.
On the server side (MacOs), I am running the following pipeline:
`gst-launch-1.0 -v autovideosrc ! "video/x-raw,framerate=30/1" ! queue ! jpegenc ! queue ! rtpjpegpay ! udpsink host=<IP_ADDRESS> port=8003`
On client side (iOS), this is the pipeline used to display the stream:
`udpsrc port=8003 ! application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, a-framerate=(string)30.000000, payload=(int)26, ssrc=(uint)2661516146, timestamp-offset=(uint)3924289949, seqnum-offset=(uint)1975 ! rtpbin ! rtpjpegdepay ! queue ! jpegdec ! queue ! videoconvert ! autovideosink sync=false`