GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-12-20T00:51:19Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1592Onvif-backchannel with autoaudiosrc2022-12-20T00:51:19ZShigeharu KamiyaOnvif-backchannel with autoaudiosrcHi
I run the following Onvif backchannel example and was successful.
https://github.com/GStreamer/gst-plugins-good/blob/master/tests/examples/rtsp/test-onvif.c
However, regarding the pipeline "audiotestsrc is-live=true wave=red-noise !...Hi
I run the following Onvif backchannel example and was successful.
https://github.com/GStreamer/gst-plugins-good/blob/master/tests/examples/rtsp/test-onvif.c
However, regarding the pipeline "audiotestsrc is-live=true wave=red-noise ! mulawenc ! rtppcmupay ! appsink name=out",
If I change audiotestsrc to autoaudiosrc, the sound becomes choppy and choppy.
Could you let me know if there is any additional processing required?
I also tried the audiorate element. The crackling disappeared, but the sound stopped after a few seconds.
I think the caps will be unique by going through the mulawenc element.
Could you give me some advice?
Best regards,https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1591mpegaudioparse seek / forwarding stream2022-11-20T19:51:48ZTomaž Smodišmpegaudioparse seek / forwarding streamHi
I have pipeline in constructor for MP3 playback. The forwarding with query/seek does not work. My pipeline is
```
pipelinePlay = gst_pipeline_new ("pipeline");
source = gst_element_factory_make ("filesrc", "source");
...Hi
I have pipeline in constructor for MP3 playback. The forwarding with query/seek does not work. My pipeline is
```
pipelinePlay = gst_pipeline_new ("pipeline");
source = gst_element_factory_make ("filesrc", "source");
parse = gst_element_factory_make("mpegaudioparse","parser");
decode = gst_element_factory_make("mpg123audiodec","audiomp3decoder");
convert = gst_element_factory_make("audioconvert","converter");
resample = gst_element_factory_make("audioresample","resampler");
volume = gst_element_factory_make("volume",NULL);
equalizer = gst_element_factory_make("equalizer-3bands", "equalizer");
sink = gst_element_factory_make("alsasink", "sink");
if (!pipelinePlay || !source || !parse || !decode || !volume || !equalizer || !sink)
{
g_printerr ("Failed to create audio send elements");
}
g_object_set(volume,"volume",0.0, NULL); //nastavimo začetno glasnost
gst_bin_add_many(GST_BIN(pipelinePlay),source,parse,decode,volume,equalizer,sink, NULL);
if(!(gst_element_link_many(source,parse,decode,volume,equalizer,sink, NULL)))
{
g_printerr ("Audio send elements could not be linked.\n");
gst_object_unref (pipelinePlay);
}
busPipelinePlay = gst_pipeline_get_bus(GST_PIPELINE(pipelinePlay));
gst_bus_add_signal_watch (busPipelinePlay);
g_signal_connect (busPipelinePlay, "message::eos", G_CALLBACK (&playerForm::message_eos), NULL);
```
Then I call method:
````
void playerForm::on_forwardButton_clicked()
{
query=gst_query_new_segment (GST_FORMAT_DEFAULT);
if (gst_element_query (pipelinePlay, query))
{
gst_query_parse_segment(query,¤tRate,NULL,NULL,NULL);
}
GstState cur_state;
gst_element_get_state(sink,&cur_state,NULL,0);
if(cur_state == GST_STATE_PLAYING)
{
if(currentRate==1.0)
{
speed=2.0;
ui->labelPicForSpeed->setStyleSheet("QLabel:enabled {background-image: url(../MP3player/pics/forward2x.png); background-repeat: no-repeat;}");
}
else if (currentRate==2.0)
{
speed=4.0;
ui->labelPicForSpeed->setStyleSheet("QLabel:enabled {background-image: url(../MP3player/pics/forward4x.png); background-repeat: no-repeat;}");
}
else if (currentRate==4.0)
{
speed=8.0;
ui->labelPicForSpeed->setStyleSheet("QLabel:enabled {background-image: url(../MP3player/pics/forward8x.png); background-repeat: no-repeat;}");
}
else if (currentRate==8.0)
{
speed=16.0;
ui->labelPicForSpeed->setStyleSheet("QLabel:enabled {background-image: url(../MP3player/pics/forward16x.png); background-repeat: no-repeat;}");
}
else if(currentRate==16.0)
{
speed=1.0;
ui->labelPicForSpeed->setStyleSheet("QLabel:enabled {background-image: url(../MP3player/pics/play.png); background-repeat: no-repeat;}");
}
}
if(currentRate>0) //če smo v rewind načinu so vrednosti speed vmanjši od 1 (torej vrtimo nazaj) in če kliknemo forward so parametri vrstice seek_event drugačni kot enake vrstice v rewind načinu! Zato najprej preverimo, če res vrtimo res naprej!
{
gst_element_query_position(pipelinePlay, GST_FORMAT_TIME, &position);
seek_event=gst_event_new_seek (speed, GST_FORMAT_TIME, (GstSeekFlags) (GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE), GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_END, 0);
gst_element_send_event (sink, seek_event);
}
}
````
Now, the same code is working for forwardnig mp4 video stream!
What am I missing?
kind regards Thomashttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1590CI: update macos runners (macos 13, xcode 14.1, gitlab-runner 15.5.1)2022-11-22T02:22:23ZMatthew Watersmatthew@centricular.comCI: update macos runners (macos 13, xcode 14.1, gitlab-runner 15.5.1)##### Why?
- `~8` months since previous update
- cerbero cache update
##### Depends:
- None at this time
##### Checklist:
- [x] Provision new intel macos runner gst-mac-ci3
- [x] install gitlab-runner 15.5.1
- [x] re-disable ssl_h...##### Why?
- `~8` months since previous update
- cerbero cache update
##### Depends:
- None at this time
##### Checklist:
- [x] Provision new intel macos runner gst-mac-ci3
- [x] install gitlab-runner 15.5.1
- [x] re-disable ssl_host_strict check: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29084
- [x] install parallels 18.1.0
- [x] VM copy macOS-Monterey from gst-mac-ci1 or gst-mac-ci2
- [x] Run to install updated parallels tools
- [x] `gitlab-runner start`
- [x] smoke test with a CI run: https://gitlab.freedesktop.org/ystreet/cerbero/-/jobs/32039999 https://gitlab.freedesktop.org/ystreet/cerbero/-/jobs/32039996
- [x] Generate new VM for macOS 13/XCode 14.1 on gst-mac-ci3
- [x] take snapshot
- [x] macOS 13
- [x] Xcode 14.1
- [x] first run completed
- [x] update gitlab-runner 15.5.1
- [x] update cerbero source cache
- [x] ~~remove old sources~~
- [x] register new vm with tags: `gst-ios-16`, `gst-mac-13`
- [x] Update CI tags used by cerbero: https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/1025
- [x] smoke test with a CI run: https://gitlab.freedesktop.org/ystreet/cerbero/-/pipelines/742598
- [ ] Update gst-mac-ci1:
- [x] ~~gitlab-runner stop~~
- [x] ~~remove macOS-Catalina VM and runner entry~~
- [ ] ~~update host to macOS 10.14.6~~
- [ ] ~~install parallels 18.1.0~~
- [ ] ~~install gitlab-runner 15.5.1~~
- [ ] ~~Run macOS-BigSur VM for parallels tools update~~
- [ ] ~~Run macOS-Monterey VM for parallels tools update~~
- [x] ~~Copy macOS-Ventura VM from gst-mac-ci3~~
- [ ] ~~Register macOS-Ventura runner with tags `gst-mac-13`, `gst-ios-16`~~
- [ ] ~~re-disable ssl_host_strict check: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29084~~
- [ ] ~~gitlab-runner start~~
- [ ] ~~smoke test with a CI run:~~
- gst-mac-ci1 considered dead, will be replaced
- [x] Update gst-mac-ci2:
- [x] gitlab-runner stop
- [x] remove macOS-Catalina VM and runner entry
- [x] update host to macOS 13.0.1
- [x] install parallels 18.1.0
- [x] install gitlab-runner 15.5.1
- [x] ~~Run macOS-BigSur VM for parallels tools update~~ crashes VM, disabled automatic parallels tools update
- [x] ~~Run macOS-Monterey VM for parallels tools update~~ crashes VM, disabled automatic parallels tools update
- [x] Copy macOS-Ventura VM from gst-mac-ci3
- [x] Register macOS-Ventura runner with tags `gst-mac-13`, `gst-ios-16`
- [x] re-disable ssl_host_strict check: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29084
- [x] gitlab-runner start
- [x] smoke test with a CI run: https://gitlab.freedesktop.org/ystreet/cerbero/-/pipelines/742968
- [x] Provision replacement intel macos runner gst-mac-ci1:
- [x] install gitlab-runner 15.5.1
- [x] re-disable ssl_host_strict check: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29084
- [x] ensure `$PATH` workaround is in place
- [x] install parallels 18.1.0
- [x] VM copy macOS-Monterey from gst-mac-ci2 or gst-mac-ci3
- [x] Run to install updated parallels tools, crashes VM, disabled automatic parallels tools update
- [x] VM copy macOS-Ventura from gst-mac-ci2 or gst-mac-ci3
- [x] Run to install updated parallels tools
- [x] VM copy macOS-BigSur from gst-mac-ci2
- [x] Run to install updated parallels tools, crashes VM, disabled automatic parallels tools update
- [x] copy CI ssh key
- [x] `gitlab-runner start`
- [x] smoke test with a CI runMatthew Watersmatthew@centricular.comMatthew Watersmatthew@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/270Critical error on fmp4 dashmp4mux element2022-11-27T18:55:05ZBedilbek KhamidovCritical error on fmp4 dashmp4mux elementGStreamer version: 1.20.3
fmp4 Version: 0.9.1-274e57a5
Rust version: rustc 1.65.0 (897e37553 2022-11-02)
OS: Ubuntu 22.04
Linux kernel version: 5.15.0-52-generic
Hi. I am building a pipeline to split a video into fragmented mp...GStreamer version: 1.20.3
fmp4 Version: 0.9.1-274e57a5
Rust version: rustc 1.65.0 (897e37553 2022-11-02)
OS: Ubuntu 22.04
Linux kernel version: 5.15.0-52-generic
Hi. I am building a pipeline to split a video into fragmented mp4 1s chunks with gstreamer. The below command is causing an error output:
```bash
gst-launch-1.0 filesrc location="sample_1080p_h265.mp4" ! qtdemux name=demux demux.video_0 ! libde265dec ! x265enc key-int-max=30 ! h265parse ! video/x-h265,stream-format=hvc1,alignment=au ! .video splitmuxsink location="fragments-dash/%02d.mp4" max-size-time=1000000000 muxer=dashmp4mux
```
However same command with default `mp4mux` muxer is working fine.
Here is log output of the command:
```bash
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPipeline:pipeline0/GstLibde265Dec:libde265dec0: Unsupported extra data version 1, decoding may fail
Additional debug info:
../ext/libde265/libde265-dec.c(583): gst_libde265_dec_set_format (): /GstPipeline:pipeline0/GstLibde265Dec:libde265dec0
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', mux/fmp4/src/fmp4mux/imp.rs:650:34
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0: GStreamer encountered a general supporting library error.
Additional debug info:
/home/bedilbek/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/5dd56d8/gstreamer-base/src/subclass/aggregator.rs(876): gstreamer_base::subclass::aggregator (): /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0:
Panicked: called `Option::unwrap()` on a `None` value
Execution ended after 0:00:34.788963538
Setting pipeline to NULL ...
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0: GStreamer encountered a general supporting library error.
Additional debug info:
/home/bedilbek/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/5dd56d8/gstreamer/src/subclass/element.rs(443): gstreamer::subclass::element (): /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0:
Panicked
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0: GStreamer encountered a general supporting library error.
Additional debug info:
/home/bedilbek/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/5dd56d8/gstreamer/src/subclass/element.rs(443): gstreamer::subclass::element (): /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0:
Panicked
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0: GStreamer encountered a general supporting library error.
Additional debug info:
/home/bedilbek/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/5dd56d8/gstreamer/src/subclass/element.rs(443): gstreamer::subclass::element (): /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink0/GstDASHMP4Mux:dashmp4mux0:
Panicked
Freeing pipeline ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1588playbin3: about-to-finish signal missing after short network streams2022-11-23T13:05:33ZRobert Tiemannplaybin3: about-to-finish signal missing after short network streams
The issue can be reproduced with `gst-play-1.0`, playing some short files from a DLNA server:
`gst-play-1.0 --use-playbin3 --gapless http://my.dlna.server/20_seconds.flac http://my.dlna.server/5_seconds.flac http://my.dlna.server/20_se...
The issue can be reproduced with `gst-play-1.0`, playing some short files from a DLNA server:
`gst-play-1.0 --use-playbin3 --gapless http://my.dlna.server/20_seconds.flac http://my.dlna.server/5_seconds.flac http://my.dlna.server/20_seconds.flac`.
The files [20_seconds.flac](/uploads/dd5ef5606642dd95573e4c1391e182ee/20_seconds.flac) and [5_seconds.flac](/uploads/a914eb7004879151cee85138046da414/5_seconds.flac) are 20 and 5 seconds long, respectively.
- Playing the files directly with `gst-play-1.0` in the order suggested above prints `About to finish, preparing next title` twice as expected.
- Playing the files from a DLNA server, however, prints `About to finish, preparing next title` only once near the end of the first stream. The expected message near the end of the second stream is missing.
- The short stream must be preceeded by a long stream to trigger the bug. When starting playback with the short stream, the `about-to-finish` signal is sent, but immediately at the beginning instead of near the end of the short stream.
Tested with version b2bfb066ec4409d1112af000e82a8510a0d1eca4 on main branch, 100% reproducible.Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/426gtksink Example compile error sink.property2022-11-21T09:42:19Zevandromelosgtksink Example compile error sink.propertyI'm trying to use gtk and gstreamer and I'm follwing the gtksin example: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/main/examples/src/bin/gtksink.rs
But unfortunately when I try to run I've got this error, also I've tr...I'm trying to use gtk and gstreamer and I'm follwing the gtksin example: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/main/examples/src/bin/gtksink.rs
But unfortunately when I try to run I've got this error, also I've tried different this but I was not able to fix.
Could someone help me?
Thanks in advance.
version 0.19.2
Windows 10
Gstreamer MSVC binaries 1.20.4
```
error[E0277]: the trait bound `for<'b> gtk::Widget: gstreamer::glib::value::FromValue<'b>` is not satisfied
--> src\main.rs:35:34
|
35 | let widget = sink.property::<gtk::Widget>("widget");
| ^^^^^^^^^^^ the trait `for<'b> gstreamer::glib::value::FromValue<'b>` is not implemented for `gtk::Widget`
|
= help: the following other types implement trait `gstreamer::glib::value::FromValue<'a>`:
<&'a BufferListRef as gstreamer::glib::value::FromValue<'a>>
<&'a BufferPool as gstreamer::glib::value::FromValue<'a>>
<&'a BufferRef as gstreamer::glib::value::FromValue<'a>>
<&'a Bus as gstreamer::glib::value::FromValue<'a>>
<&'a CapsFeaturesRef as gstreamer::glib::value::FromValue<'a>>
<&'a CapsRef as gstreamer::glib::value::FromValue<'a>>
<&'a ChildProxy as gstreamer::glib::value::FromValue<'a>>
<&'a ContextRef as gstreamer::glib::value::FromValue<'a>>
and 314 others
note: required by a bound in `gstreamer::prelude::ObjectExt::property`
--> C:\Users\xavero\.cargo\registry\src\github.com-1ecc6299db9ec823\glib-0.16.2\src\object.rs:1726:20
|
1726 | fn property<V: for<'b> FromValue<'b> + 'static>(&self, property_name: &str) -> V;
| ^^^^^^^^^^^^^^^^^^^^^ required by this bound in `gstreamer::prelude::ObjectExt::property`
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1586playbin3: No gapless playback after seek operation2022-12-02T10:03:53ZRobert Tiemannplaybin3: No gapless playback after seek operationThe issue can be reproduced with `gst-play-1.0`, playing some files from a DLNA server:
`gst-play-1.0 --use-playbin3 --gapless http://my.dlna.server/1.flac http://my.dlna.server/2.flac`
How to reproduce:
1. Run `gst-play-1.0` with at l...The issue can be reproduced with `gst-play-1.0`, playing some files from a DLNA server:
`gst-play-1.0 --use-playbin3 --gapless http://my.dlna.server/1.flac http://my.dlna.server/2.flac`
How to reproduce:
1. Run `gst-play-1.0` with at least two network streams which are meant to be played gapless. (The issue does not occur when playing from files.)
2. Seek forward as far as you like, but stop when `About to finish, preparing next title` is printed. Seeking one step forward is enough to trigger the issue.
3. Let the first stream play and listen to the transition to the next stream.
4. There will be a short, audible gap.
There is no gap (I think) when seeking further forward after `About to finish, preparing next title` has been printed.
Tested with version b2bfb066ec4409d1112af000e82a8510a0d1eca4 on main branch, 100% reproducible.Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/999jpegdec: YUV->RGB conversion breaks decoding on some files2022-11-20T14:21:34ZIvan Molodetskikhjpegdec: YUV->RGB conversion breaks decoding on some filesThe file: [Test](/uploads/b61929cefdc82b8b47450758c03764c9/Test.jpg)
The app: [Identity](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity), uses `playbin3` with `gtk4paintablesink` (tested with all latest crates.io vers...The file: [Test](/uploads/b61929cefdc82b8b47450758c03764c9/Test.jpg)
The app: [Identity](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity), uses `playbin3` with `gtk4paintablesink` (tested with all latest crates.io versions).
This is what happens:
```
0:00:00.168425527 51816 0x7f6ec40fdea0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.168856034 51816 0x7f6ec40fdea0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.180820209 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:2817:gst_video_decoder_chain:<jpegdec0> Received buffer without a new-segment. Assuming timestamps start from 0.
0:00:00.181474351 51816 0x7f6ec4108d20 WARN video-info video-info.c:760:gst_video_info_to_caps: invalid matrix 0 for RGB format, using RGB
0:00:00.185750787 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:4799:_gst_video_decoder_error:<jpegdec0> error: Failed to decode JPEG image
0:00:00.185775092 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:4801:_gst_video_decoder_error:<jpegdec0> error: Decode error #20: Improper call to JPEG library in state 205
0:00:00.185876224 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: No valid frames decoded before end of stream
0:00:00.185893056 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: no valid frames found
```
If I remove `gtk4paintablesink` and let `playbin3` create its own window, then there's no error.
`GST_DEBUG=5` logs:
* [works-without-gtk4paintablesink.log](/uploads/337938ec9652027c537ae79c5a87af16/works-without-gtk4paintablesink.log)
* [broken-with-gtk4paintablesink.log](/uploads/215dd8831153919ff962de5371a29dae/broken-with-gtk4paintablesink.log)
Original Identity issue: https://gitlab.gnome.org/YaLTeR/identity/-/issues/30https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1585av1decoder: No longer decode av1-1-b8-22-svc-L1T22022-11-19T12:49:12ZNicolas Dufresneav1decoder: No longer decode av1-1-b8-22-svc-L1T2While testing current branch on MTK8195 V4L2 driver, I notice that we had a regression on av1-1-b8-22-svc-L1T2 fluster test. I haven't had time to fully investigate yet, but commenting out that following check fixes the issue:
```diff
+...While testing current branch on MTK8195 V4L2 driver, I notice that we had a regression on av1-1-b8-22-svc-L1T2 fluster test. I haven't had time to fully investigate yet, but commenting out that following check fixes the issue:
```diff
+#if 0
if (priv->current_picture->temporal_id > self->highest_spatial_layer) {
ret = GST_FLOW_ERROR;
GST_VIDEO_DECODER_ERROR (self, 1, STREAM, DECODE,
@@ -720,6 +721,7 @@ gst_av1_decoder_handle_frame (GstVideoDecoder * decoder,
self->highest_spatial_layer), (NULL), ret);
goto out;
}
+#endif
```
In practice, it fails on the very first decode, which leave me wonder if we didn't screw up the initialization of `self->highest_spatial_layer` or if we didn't mean to check `>=`.
cc @He_Junyan @seungha.yangNicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/425gst_net: impl From<gstreamer::ClockTime> for gstreamer_net::gstreamer::ClockTime2022-11-17T08:10:06ZCorey Cgst_net: impl From<gstreamer::ClockTime> for gstreamer_net::gstreamer::ClockTimeI spent a lot of time on a weird error message today:
```
24 | net_clock: gst_net::NetClientClock::new(
| ---------------------------- required by a bound introduced by this call
...
28 | ...I spent a lot of time on a weird error message today:
```
24 | net_clock: gst_net::NetClientClock::new(
| ---------------------------- required by a bound introduced by this call
...
28 | gst::ClockTime::ZERO,
| ^^^^^^^^^^^^^^^^^^^^ the trait `From<gstreamer::ClockTime>` is not implemented for `std::option::Option<gstreamer_net::gstreamer::ClockTime>`
```
To my surprise, the fix was that I needed to pass `gst_net::gst::ClockTime::ZERO` not `gst::ClockTime::ZERO`.
The `gst_net::gst` is just the `gstreamer` crate re-exported, right? This seems like an easy patch I'd love to help with if it is fixable. I am fairly new to rust and the gst code outside of C, but I'm guessing we should be able to impl the `From<gstreamer::ClockTime>` for the re-exported `gst_net::gst::ClockTime` in the `gst_net` module?
If not, at the very least I could add a doc comment with an example to `gst_net::NetClientClock::new` where I got tripped up.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1581playbin3: it can't play some files if one track of the files can't be decoded...2023-01-20T09:31:41Zelliot chenplaybin3: it can't play some files if one track of the files can't be decoded, no matter it's audio track or video track. While playbin2 can.1. For some files which include audio and video track, maybe one track can't work in some cases.
2. playbin3 fail to play those files, while playbin2 can do it.
3. For example, audio track of one file can't work when set format fail in ...1. For some files which include audio and video track, maybe one track can't work in some cases.
2. playbin3 fail to play those files, while playbin2 can do it.
3. For example, audio track of one file can't work when set format fail in gst_ffmpegauddec_set_format function by libav, and playbin3 will return directly. While playbin2 can still play the video track no matter the audio track can't work.
4. Is this as expected for playbin3?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/269jpegdec: YUV->RGB conversion breaks decoding on some files2022-11-18T08:46:23ZIvan Molodetskikhjpegdec: YUV->RGB conversion breaks decoding on some filesThe file: [Test.jpg](/uploads/1b96cf73325bebdd42cba20f2151d7ba/Test.jpg)
The app: [Identity](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity), uses `playbin3` with `gtk4paintablesink` (tested with all latest crates.io ...The file: [Test.jpg](/uploads/1b96cf73325bebdd42cba20f2151d7ba/Test.jpg)
The app: [Identity](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity), uses `playbin3` with `gtk4paintablesink` (tested with all latest crates.io versions).
This is what happens:
```
0:00:00.168425527 51816 0x7f6ec40fdea0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.168856034 51816 0x7f6ec40fdea0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.180820209 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:2817:gst_video_decoder_chain:<jpegdec0> Received buffer without a new-segment. Assuming timestamps start from 0.
0:00:00.181474351 51816 0x7f6ec4108d20 WARN video-info video-info.c:760:gst_video_info_to_caps: invalid matrix 0 for RGB format, using RGB
0:00:00.185750787 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:4799:_gst_video_decoder_error:<jpegdec0> error: Failed to decode JPEG image
0:00:00.185775092 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:4801:_gst_video_decoder_error:<jpegdec0> error: Decode error #20: Improper call to JPEG library in state 205
0:00:00.185876224 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: No valid frames decoded before end of stream
0:00:00.185893056 51816 0x7f6ec4108d20 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: no valid frames found
```
If I remove `gtk4paintablesink` and let `playbin3` create its own window, then there's no error.
`GST_DEBUG=5` logs:
* [works-without-gtk4paintablesink.log](/uploads/7c04df0a975ca7e7bba797eba254802e/works-without-gtk4paintablesink.log)
* [broken-with-gtk4paintablesink.log](/uploads/a881dcc061454b11fd3c3da354883788/broken-with-gtk4paintablesink.log)
Original Identity issue: https://gitlab.gnome.org/YaLTeR/identity/-/issues/30https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1579vah264enc: Should not post ERROR message on flushing2022-11-17T06:15:45ZSeungha Yangseungha@centricular.comvah264enc: Should not post ERROR message on flushingthis element is printing error level debug log and posting error message to bus even if flow-return from pad-push is flushing. That's noisy and I don't think that's expected behavior
@vjaquez @He_Junyanthis element is printing error level debug log and posting error message to bus even if flow-return from pad-push is flushing. That's noisy and I don't think that's expected behavior
@vjaquez @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1578rtpdepay: Depay elements attach multiple copies of GstReferenceTimestampMeta ...2022-11-19T08:44:22Zmattc1170rtpdepay: Depay elements attach multiple copies of GstReferenceTimestampMeta to media buffers### Describe your issue
When rtspsrc property add-reference-timestamp-metadata=true, a downstream rtph264depay element will attach multiple copies of the same GstReferenceTimestampMeta to the depayloaded media buffers. This can have sign...### Describe your issue
When rtspsrc property add-reference-timestamp-metadata=true, a downstream rtph264depay element will attach multiple copies of the same GstReferenceTimestampMeta to the depayloaded media buffers. This can have signficant performance impacts further downstream in a pipeline like the following one we have in our RTSP proxy server:
rtspsrc add-reference-timestamp-metadata=true ! rtph264depay ! h264parse ! ... ! rtph264pay ! ...
For example, if there are 10 packet buffers for a frame of RTP H.264 video, each of those packet buffers will contain the same reference timestamp meta. The rtph264depay element will then attach all 10 metadata to the depayloaded frame. And then later when we payload the frame buffer again for proxying, we now have 10 more buffers each with 10 instance of the same metadata. Allocating/deallocating 100+ instances of metadata @ 30fps for multiple cameras has a pretty large performance impact on our GStreamer RTSP proxy server.
#### Expected Behavior
There should be only one instance of NTP GstReferenceTimestampMeta in depayloaded buffers.
#### Observed Behavior
There are multiple copies of the same NTP GstReferenceTimestampMeta in depayloaded buffers -- one for each packet of a video frame.
#### Setup
- **Operating System: Linux**
- **Device:** Computer / Virtual Machine
- **GStreamer Version: 1.21.2**
- **Command line:** gst-launch-1.0 rtspsrc add-reference-timestamp-metadata=true location=<IP camera> ! rtph264depay ! h264parse ! rtph264pay ! fakesink
### Steps to reproduce the bug
1. Open terminal
2. type `GST_DEBUG=GST_BUFFER:5 gst-launch-1.0 rtspsrc add-reference-timestamp-metadata=true location=<IP address of h.264 camera> ! rtph264depay ! h264parse ! rtph264pay ! fakesink`
3. Observe the many, many instances of GstReferenceTimestampMeta being attached to buffers.
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Have coded up a possible fix in rtpbasedepayload.c that I will post.
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/396nasm 2.10.07 bootstrap fails to detect version, crashes bootstrap2022-12-05T09:46:25ZNathan Widmyernasm 2.10.07 bootstrap fails to detect version, crashes bootstrapI'm on an M1 MBP trying to build a Dockerfile w/ `FROM --platform=x86_64 centos:7`
bootstrap installs dependencies, then tries to grab nasm version, but fails:
```
Install prefix will be /usr/src/cerbero/build/dist/linux_x86_64
Install ...I'm on an M1 MBP trying to build a Dockerfile w/ `FROM --platform=x86_64 centos:7`
bootstrap installs dependencies, then tries to grab nasm version, but fails:
```
Install prefix will be /usr/src/cerbero/build/dist/linux_x86_64
Install prefix will be /usr/src/cerbero/build/build-tools
Running command 'yum -y install gcc gcc-c++ automake autoconf libtool gettext-devel make cmake bison flex nasm pkgconfig curl intltool rpm-build redhat-rpm-config python3-devel libXrender
-devel pulseaudio-libs-devel libXv-devel mesa-libGL-devel libXcomposite-devel perl-ExtUtils-MakeMaker libXi-devel perl-XML-Simple gperf wget libXrandr-devel libXtst-devel git xorg-x11-uti
l-macros mesa-libEGL-devel ccache openssl-devel alsa-lib-devel'
...
Dependencies Resolved
================================================================================
Package Arch Version Repository
Size
================================================================================
Installing:
...
nasm x86_64 2.10.07-7.el7 base 402 k
...
Complete!
Building the following recipes: m4 autoconf gettext-m4 automake libtool pkg-config ninja meson orc-tool intltool-m4 cmake nasm
Building using 5 job(s) with the following job subdivisions: compile: 2, and 3 general job(s)
nasm: error: unrecognised option `--version'
nasm: error: no input file specified
type `nasm -h' for help
Traceback (most recent call last):
File "<string>", line 20, in <module>
File "/usr/src/cerbero/cerbero/main.py", line 183, in main
Main(sys.argv[1:])
File "/usr/src/cerbero/cerbero/main.py", line 53, in __init__
self.run_command()
File "/usr/src/cerbero/cerbero/main.py", line 152, in run_command
res = commands.run(command, self.config, self.args)
File "/usr/src/cerbero/cerbero/commands/__init__.py", line 78, in run
return _commands[command].run(config, args)
File "/usr/src/cerbero/cerbero/commands/bootstrap.py", line 60, in run
bootstrapper.start(jobs=args.jobs)
File "/usr/src/cerbero/cerbero/bootstrap/build_tools.py", line 150, in start
oven.start_cooking()
File "/usr/src/cerbero/cerbero/build/oven.py", line 131, in start_cooking
run_until_complete(self._cook_recipes(ordered_recipes))
File "/usr/src/cerbero/cerbero/utils/__init__.py", line 627, in run_until_complete
result = loop.run_until_complete(tasks)
File "/usr/lib64/python3.6/asyncio/base_events.py", line 484, in run_until_complete
return future.result()
File "/usr/src/cerbero/cerbero/build/oven.py", line 403, in _cook_recipes
default_queue.put_nowait(RecipeStepPriority(recipe, 0, "init"))
File "/usr/lib64/python3.6/asyncio/queues.py", line 148, in put_nowait
if self.full():
File "/usr/lib64/python3.6/asyncio/queues.py", line 115, in full
if self._maxsize <= 0:
TypeError: '<=' not supported between instances of 'str' and 'int'
Task was destroyed but it is pending!
task: <Task pending coro=<Oven._cook_recipes.<locals>.cook_recipe_worker() running at /usr/src/cerbero/cerbero/build/oven.py:263> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x401092ea68>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<Oven._cook_recipes.<locals>.cook_recipe_worker() running at /usr/src/cerbero/cerbero/build/oven.py:263> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x401092ea08>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<Oven._cook_recipes.<locals>.cook_recipe_worker() running at /usr/src/cerbero/cerbero/build/oven.py:263> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x401092e9a8>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<Oven._cook_recipes.<locals>.cook_recipe_worker() running at /usr/src/cerbero/cerbero/build/oven.py:263> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x401092e948>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<Oven._cook_recipes.<locals>.cook_recipe_worker() running at /usr/src/cerbero/cerbero/build/oven.py:263> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x401092e8e8>()]>>
```
nasm 2.10.07 is found via `-v`:
```
[root@90354ef8d58a /]# which nasm
/usr/bin/nasm
[root@90354ef8d58a /]# nasm --version
nasm: error: unrecognised option `--version'
nasm: error: no input file specified
type `nasm -h' for help
[root@90354ef8d58a /]# nasm -v
NASM version 2.10.07 compiled on Jun 9 2014
```
They added `--v` in ~2.12 and then changed it to `--version` later. I didn't do an exhaustive search.
Probably best to execute w/ `-v` since that seems like it's always available.
This may be low priority because nasm 2.10 is over 8 years old, and better to use a much newer version anyway.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/268uriplaylistbin: look at decodebin32024-03-04T13:18:27ZGuillaume Desmottesuriplaylistbin: look at decodebin3`decodebin3` [received a bunch of gapless related improvements](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784) in 1.22.
It would be interesting to look if some of those could be used to simplify `uriplaylistbin`.`decodebin3` [received a bunch of gapless related improvements](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784) in 1.22.
It would be interesting to look if some of those could be used to simplify `uriplaylistbin`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/266aws: awss3hlssink links a video stream to 'audio' pad by default2022-11-16T08:37:20ZAndreas Frischaws: awss3hlssink links a video stream to 'audio' pad by defaultwith this pipeline
`GST_DEBUG=*:5 gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 ! x264enc threads=4 ! awss3hlssink endpoint-uri="..." bucket=gstreamersink key-prefix=hlsvideotest name=hlssink audiotestsrc ! faac ! a...with this pipeline
`GST_DEBUG=*:5 gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 ! x264enc threads=4 ! awss3hlssink endpoint-uri="..." bucket=gstreamersink key-prefix=hlsvideotest name=hlssink audiotestsrc ! faac ! aacparse ! hlssink.audio -e
`
I noticed the following minor issue:
```
0:00:00.299898878 161659 0x55d354e5ac00 INFO GST_ELEMENT_PADS gstutils.c:1816:gst_element_link_pads_full: trying to link element aacparse0:(any) to element hlssink:audio
0:00:00.299901958 161659 0x55d354e5ac00 INFO GST_ELEMENT_PADS gstelement.c:1014:gst_element_get_static_pad: found pad hlssink:audio
0:00:00.299905442 161659 0x55d354e5ac00 DEBUG GST_ELEMENT_PADS gstutils.c:1884:gst_element_link_pads_full: pad hlssink:audio is already linked to x264enc0:src
0:00:00.299908643 161659 0x55d354e5ac00 INFO default gstutils.c:2206:gst_element_link_pads_filtered: Could not link pads: aacparse0:(null) - hlssink:audio
0:00:00.299912308 161659 0x55d354e5ac00 ERROR GST_PIPELINE subprojects/gstreamer/gst/parse/grammar.y:1086:gst_parse_perform_link: could not link aacparse0 to hlssink
```
it should automatically use the correct 'video' pad and not the 'audio' pad in order to link the video encoder to the hlssink.
the pipeline works when explicitely linking the video encoder to hlssink.video.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/424awss3hlssink links a video stream to 'audio' pad by default2022-11-15T16:42:57ZAndreas Frischawss3hlssink links a video stream to 'audio' pad by defaultwith this pipeline
`GST_DEBUG=*:5 gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 ! x264enc threads=4 ! awss3hlssink endpoint-uri="..." bucket=gstreamersink key-prefix=hlsvideotest name=hlssink audiotestsrc ! faac ! a...with this pipeline
`GST_DEBUG=*:5 gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 ! x264enc threads=4 ! awss3hlssink endpoint-uri="..." bucket=gstreamersink key-prefix=hlsvideotest name=hlssink audiotestsrc ! faac ! aacparse ! hlssink.audio -e
`
I noticed the following minor issue:
```
0:00:00.299898878 161659 0x55d354e5ac00 INFO GST_ELEMENT_PADS gstutils.c:1816:gst_element_link_pads_full: trying to link element aacparse0:(any) to element hlssink:audio
0:00:00.299901958 161659 0x55d354e5ac00 INFO GST_ELEMENT_PADS gstelement.c:1014:gst_element_get_static_pad: found pad hlssink:audio
0:00:00.299905442 161659 0x55d354e5ac00 DEBUG GST_ELEMENT_PADS gstutils.c:1884:gst_element_link_pads_full: pad hlssink:audio is already linked to x264enc0:src
0:00:00.299908643 161659 0x55d354e5ac00 INFO default gstutils.c:2206:gst_element_link_pads_filtered: Could not link pads: aacparse0:(null) - hlssink:audio
0:00:00.299912308 161659 0x55d354e5ac00 ERROR GST_PIPELINE subprojects/gstreamer/gst/parse/grammar.y:1086:gst_parse_perform_link: could not link aacparse0 to hlssink
```
it should automatically use the correct 'video' pad and not the 'audio' pad in order to link the video encoder to the hlssink.
the pipeline works when explicitely linking the video encoder to hlssink.video.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/105Gstreamer with multiple stream rendering in Windows OS2022-11-15T17:18:49ZFirdose K AGstreamer with multiple stream rendering in Windows OSHello Team,
I am able to render multiple RTSP streams which are transmitting from different IP cameras using GStreamer and Janus in Linux environment. But, now, I want to render multiple RTSP streams in Windows operating system. But, he...Hello Team,
I am able to render multiple RTSP streams which are transmitting from different IP cameras using GStreamer and Janus in Linux environment. But, now, I want to render multiple RTSP streams in Windows operating system. But, here, GStreamer supports Windows OS and at the same time, Janus doesn’t have support for Windows OS. Hence, request you to suggest suitable to media framework to deploy in Windows OS along with GStreamer to render the multiple RTSP streams.
Any help would be appreciated. Thank you.
Best Regards,
Firdose.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1570rtpjitterbuffer: Waiting on timers during EOS handling can deadlock2023-10-10T05:57:31ZSebastian Drögertpjitterbuffer: Waiting on timers during EOS handling can deadlockThis is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
G...This is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
GST_EVENT_TYPE (outevent) == GST_EVENT_EOS) {
g_assert (priv->eos);
while (rtp_timer_queue_length (priv->timers) > 0) {
/* Stopping timers */
unschedule_current_timer (jitterbuffer);
JBUF_WAIT_TIMER (priv);
}
}
```
* `gst_rtp_jitter_buffer_flush_start()` does **not** cause any flushing or anything of the timers. Doing `JBUF_SIGNAL_TIMER` would not be sufficient (would still be racy) because nothing is making sure that the timers are actually flushed away. Maybe code similar to the `GST_STATE_CHANGE_PAUSED_TO_READY` handling would be needed, together with actually starting the timers again later.
This then causes the streaming thread to wait there, the timer thread to wait on the same condition variable in `wait_next_timeout`, and the flushing thread to wait forever for the streaming thread to shut down.
----
The timer condition variable handling (and also others) seems also rather fragile. Especially for the timer we have two threads waiting for the same condition variable and there is only ever a `g_cond_signal()`.
For this and the other condition variables it seems like they're sometimes missing a loop to protect against spurious wakeups and also are sometimes missing an actual condition they check before/after being woken up.