GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-09-26T15:36:30Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1735Pulsesink clock doesn't advance initially2023-09-26T15:36:30ZEdward HerveyPulsesink clock doesn't advance initially* version : 1.22/1.20
Example pipeline : `gst-play-1.0 --use-playbin3 https://d1wal6k3d7ssin.cloudfront.net/out/v1/ea91db0906c847a4931b46a9ec36e77b/index.m3u8`
* Works: `--audiosink=alsasink`
* Works: `--audiosink=jackaudiosink` (via p...* version : 1.22/1.20
Example pipeline : `gst-play-1.0 --use-playbin3 https://d1wal6k3d7ssin.cloudfront.net/out/v1/ea91db0906c847a4931b46a9ec36e77b/index.m3u8`
* Works: `--audiosink=alsasink`
* Works: `--audiosink=jackaudiosink` (via pipewire)
* Fails: `--audiosink=pulsesink` (via pipewire)
The issue is that once the pipeline has fully buffered (100% buffering) it will not start playback straightaway, there's a noticeable gap.
The underlying problem seems to be that the selected clock (from pulsesink) ... doesn't advance for quite some time.
The longer the initial buffering takes, the longer it will hang for once prerolled.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1733rtph265depay: Does not always forward all `GstReferenceTimestampMeta`s2023-08-11T09:33:13ZMike Seddonrtph265depay: Does not always forward all `GstReferenceTimestampMeta`sFrom reading @slomo's excellent blog post here (https://coaxion.net/blog/2022/05/instantaneous-rtp-synchronization-retrieval-of-absolute-sender-clock-times-with-gstreamer/) I had expected that gstreamer 1.21.90 (aka 1.22.0 RC1) added som...From reading @slomo's excellent blog post here (https://coaxion.net/blog/2022/05/instantaneous-rtp-synchronization-retrieval-of-absolute-sender-clock-times-with-gstreamer/) I had expected that gstreamer 1.21.90 (aka 1.22.0 RC1) added some additional RFC6051 support - namely the ability to output `GstReferenceTimestampMetaAPI` objects from a `playbin` by setting the `add-reference-timestamp-meta` property to `true`. The expected result is that all buffers output from `playbin` (or equivalent) have a `GstReferenceTimestampMetaAPI` attached right from the first produced buffer.
Quote:
```
On the receiver-side no changes would actually be necessary. The use of the header extension is signaled via the SDP (see RFC 5285) and it will be automatically made use of inside rtpbin as another source of NTP / RTP timestamp mappings in addition to the RTCP Sender Reports.
```
After testing the `recv` side of @slomo's code from https://gitlab.freedesktop.org/slomo/rtp-rapid-sync-example/-/tree/rapid-synchronization I am seeing strange behaviour (removed some of the log). This is connected to an iPro (formerly Panasonic) camera with up-to-date (Dec 2022) firmware.
1. It is taking until buffer at 2.33s before the first `GstReferenceTimestampMetaAPI` is produced.
2. There appear to be multiple `GstReferenceTimestampMetaAPI` metas attached to each buffer.
3. At 2.56s the `GstReferenceTimestampMetaAPI` is not produced for a single buffer.
4. On different startups the `GstReferenceTimestampMetaAPI` never seems to be produced
There is a big chance that I have done something incorrectly but is this the expected behavior?
```
Buffer { ptr: 0x7f0c90057000, pts: 0:00:00.129052812, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: DISCONT | MARKER | HEADER, metas: [GstVideoMetaAPI] }
Have no sender clock time
Buffer { ptr: 0x7f0c9004fa20, pts: 0:00:00.195698104, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI] }
...
Have no sender clock time
Buffer { ptr: 0x7f0c90057000, pts: 0:00:02.269231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI] }
Have no sender clock time
Buffer { ptr: 0x7f0c9004fa20, pts: 0:00:02.335897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.012666645
Buffer { ptr: 0x7f0c802cf120, pts: 0:00:02.369231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.045999979
Buffer { ptr: 0x7f0c802c9360, pts: 0:00:02.435897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.112666645
Buffer { ptr: 0x7f0c90057000, pts: 0:00:02.469231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.145999979
Buffer { ptr: 0x7f0c9004fa20, pts: 0:00:02.535897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.212666645
Buffer { ptr: 0x7f0c802cf120, pts: 0:00:02.569231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI] }
Have no sender clock time
Buffer { ptr: 0x7f0c802c9360, pts: 0:00:02.635897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.312666645
Buffer { ptr: 0x7f0c90057000, pts: 0:00:02.669231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.345999979
Buffer { ptr: 0x7f0c9004fa20, pts: 0:00:02.735897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.412666645
Buffer { ptr: 0x7f0c802cf120, pts: 0:00:02.769231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.445999979
Buffer { ptr: 0x7f0c802c9360, pts: 0:00:02.835897999, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.512666645
Buffer { ptr: 0x7f0c90057000, pts: 0:00:02.869231333, dts: --:--:--.---------, duration: 0:00:00.050000000, size: 64, offset: 18446744073709551615, offset_end: 18446744073709551615, flags: MARKER, metas: [GstVideoMetaAPI, GstReferenceTimestampMetaAPI, GstReferenceTimestampMetaAPI] }
Have sender clock time 990987:26:32.545999979
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1727rtspsrc not working when using protocols=tcp2023-01-22T10:49:11ZMostafa Alizadehrtspsrc not working when using protocols=tcpI'm trying to use my cell phone as an RTSP server and my PC as the client. So for the cell phone, I'm using the RTSP Camera Server android app and on the PC I tried this command:
`gst-launch-1.0.exe rtspsrc protocols=tcp location=rtsp://...I'm trying to use my cell phone as an RTSP server and my PC as the client. So for the cell phone, I'm using the RTSP Camera Server android app and on the PC I tried this command:
`gst-launch-1.0.exe rtspsrc protocols=tcp location=rtsp://IP:Port/camera latency=100 ! queue ! decodebin ! autovideosink`
After running this command the output is stuck in "Progress: (request) Sent PLAY request" state without showing any frames:
![Screenshot_2023-01-22_071100](/uploads/251be76c322e65dcf987e420fdc15aca/Screenshot_2023-01-22_071100.png)
If I change the protocols to UDP or delete that argument, then it works:
`gst-launch-1.0.exe rtspsrc protocols=udp location=rtsp://IP:Port/camera latency=100 ! queue ! decodebin ! autovideosink`
However, I need it to be TCP since I'm going to use the pipeline inside a docker.
Any idea about this problem?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1726v1.21.90 fails to build: gst-plugins-bad/ext/gs: undefined reference to `goog...2023-01-21T22:12:12ZJohn Laurence Poolev1.21.90 fails to build: gst-plugins-bad/ext/gs: undefined reference to `google::cloud::storage::v1_36_0...### Describe your issue
<!-- a clear and concise summary of the bug. -->
build of v1.21.90 fails with subprojects/gst-plugins-bad/ext/gs/libgstgs.so
#### Expected Behavior
successful compile
#### Observed Behavior
Failed during linkage...### Describe your issue
<!-- a clear and concise summary of the bug. -->
build of v1.21.90 fails with subprojects/gst-plugins-bad/ext/gs/libgstgs.so
#### Expected Behavior
successful compile
#### Observed Behavior
Failed during linkage for gst-plugins-bad/ext/gs/libgstgs
```
[3574/4598] Linking target subprojects/gst-plugins-bad/ext/gs/libgstgs.so
FAILED: subprojects/gst-plugins-bad/ext/gs/libgstgs.so
c++ -o subprojects/gst-plugins-bad/ext/gs/libgstgs.so subprojects/gst-plugins-bad/ext/gs/libgstgs.so.p/gstgscommon.cpp.o subprojects/gst-plugins-bad/ext/gs/libgstgs.so.p/gstgssink.cpp.o subprojects/gst-plugins-bad/ext/gs/libgstgs.so.p/gstgssrc.cpp.o subprojects/gst-plugins-bad/ext/gs/libgstgs.so.p/gstgs.cpp.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgstgs.so -Wl,-z,nodelete '-Wl,-rpath,$ORIGIN/../../../gstreamer/libs/gst/base:$ORIGIN/../../../gstreamer/gst' -Wl,-rpath-link,/home/jlpoole/gstreamer/build/subprojects/gstreamer/libs/gst/base -Wl,-rpath-link,/home/jlpoole/gstreamer/build/subprojects/gstreamer/gst subprojects/gstreamer/libs/gst/base/libgstbase-1.0.so.0.2190.0 subprojects/gstreamer/gst/libgstreamer-1.0.so.0.2190.0 /usr/lib64/libglib-2.0.so /usr/lib64/libgobject-2.0.so /usr/lib64/libgmodule-2.0.so -pthread /usr/lib64/pkgconfig/../../lib64/libgoogle_cloud_cpp_storage.so /usr/lib64/pkgconfig/../../lib64/libcrc32c.so /usr/lib64/pkgconfig/../../lib64/libgoogle_cloud_cpp_common.so /usr/lib64/pkgconfig/../../lib64/libabsl_bad_optional_access.so /usr/lib64/pkgconfig/../../lib64/libcurl.so /usr/lib64/pkgconfig/../../lib64/libssl.so /usr/lib64/pkgconfig/../../lib64/libcrypto.so /usr/lib64/pkgconfig/../../lib64/libabsl_str_format_internal.so /usr/lib64/pkgconfig/../../lib64/libabsl_time.so /usr/lib64/pkgconfig/../../lib64/libabsl_civil_time.so /usr/lib64/pkgconfig/../../lib64/libabsl_strings.so /usr/lib64/pkgconfig/../../lib64/libabsl_strings_internal.so -lrt /usr/lib64/pkgconfig/../../lib64/libabsl_base.so /usr/lib64/pkgconfig/../../lib64/libabsl_spinlock_wait.so /usr/lib64/pkgconfig/../../lib64/libabsl_int128.so /usr/lib64/pkgconfig/../../lib64/libabsl_throw_delegate.so /usr/lib64/pkgconfig/../../lib64/libabsl_time_zone.so /usr/lib64/pkgconfig/../../lib64/libabsl_bad_variant_access.so /usr/lib64/pkgconfig/../../lib64/libabsl_raw_logging_internal.so /usr/lib64/pkgconfig/../../lib64/libabsl_log_severity.so -Wl,--end-group
/usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: subprojects/gst-plugins-bad/ext/gs/libgstgs.so.p/gstgscommon.cpp.o: in function `gst_gs_create_client(char const*, char const*, _GError**)':
/home/jlpoole/gstreamer/build/../subprojects/gst-plugins-bad/ext/gs/gstgscommon.cpp:35: undefined reference to `google::cloud::storage::v1_36_0::oauth2::CreateServiceAccountCredentialsFromJsonContents(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, absl::lts_20211102::optional<std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, absl::lts_20211102::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, google::cloud::storage::v1_36_0::ChannelOptions const&)'
collect2: error: ld returned 1 exit status
[3591/4598] Compiling C++ object subprojects/openh264-2.3.1/test/api/test_api.p/encode_options_test.cpp.o
ninja: build stopped: subcommand failed.
jlpoole@eos ~/gstreamer $
```
#### Setup
- **Operating System:** Linux eos 5.15.85-gentoo-dist #1 SMP Mon Jan 9 20:25:49 PST 2023 x86_64 AMD Ryzen 7 5700U with Radeon Graphics AuthenticAMD GNU/Linux
- **Device:** Computer laptop
- **GStreamer Version:**
```
jlpoole@eos ~/gstreamer $ git status
HEAD detached at 1.21.90
nothing to commit, working tree clean
jlpoole@eos ~/gstreamer $
```
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type:
```
git checkout tags/1.21.90
meson setup build
ninja -C build
```
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### Screenshots if relevant
NA
### Solutions you have tried
nothing
### Related non-duplicate issues
not found
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
I'll provide links to complete logs in the next 20 minutes after I create this Issue.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1723VP9 video wrong colours when converted to RGB2023-06-25T09:36:46ZBastien NoceraVP9 video wrong colours when converted to RGBFrom https://gitlab.gnome.org/GNOME/totem/-/issues/571
Thumbnailing [this video](/uploads/a4af7c5dbf8c952d41acc119bca0753f/2023-01-16-14-50-48-densita_corrente.mkv) generates a preview in the wrong colours as per the screenshot:
![imag...From https://gitlab.gnome.org/GNOME/totem/-/issues/571
Thumbnailing [this video](/uploads/a4af7c5dbf8c952d41acc119bca0753f/2023-01-16-14-50-48-densita_corrente.mkv) generates a preview in the wrong colours as per the screenshot:
![image](/uploads/0d206632bbd3b427bd06ddebebab0395/image.png)
Tested with GStreamer 1.21.90 using totem's development Flatpak.
The code to do the colour conversion is at:
https://gitlab.gnome.org/GNOME/totem/-/blob/master/src/gst/totem-gst-pixbuf-helpers.chttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1721[C#] Possible Memory Leak2023-09-29T09:57:24ZJan Lukas Gernert[C#] Possible Memory Leak### Describe your issue
I'm using the [`gstreamer-netcore`](https://github.com/vladkol/gstreamer-netcore) bindings, which seem to be a very thin layer around `gstreamer-sharp` to load the native libraries, to build a `net6.0` app. The ap...### Describe your issue
I'm using the [`gstreamer-netcore`](https://github.com/vladkol/gstreamer-netcore) bindings, which seem to be a very thin layer around `gstreamer-sharp` to load the native libraries, to build a `net6.0` app. The application streams h264 video via rtsp from a network camera. Running the application is fine: a steady up and down of memory usage, as I would expect. If for some reason there is problem with the connection to the hardware the application tries to disconnect and reconnect to the camera every 30 seconds. Internally I destroy the current pipeline and create a new one. I noticed that every time that happens a considerable amount of memory is allocated and never freed again.
I wrote a minimal sample to create -> start -> get a frame -> destroy the pipeline in a small loop. The memory usage keeps on growing really fast with the high-res images of the camera until ~16 GB which is the amount of ram in my system. I also tested this with a lower res stream of "Big Buck Bunny" streamed via VLC. And the memory usage grows at a slower pace.
I'm not sure if I'm missing something here and need to fix my C# code. I'm aware of [this post](https://gitlab.gnome.org/GNOME/glib/-/issues/1079#note_1627608), even though I don't understand it completely. There the memory usage doesn't grow after some time. That's not the behavior I see in my case.
#### Expected Behavior
I would expect the memory usage after destroying the pipeline to return to the value of before starting the pipeline. Or at least to stabilize after some time.
#### Observed Behavior
Memory usage grows without limit given enough time (at least in the bounds of my system memory).
the minimal sample running with Big Buck Bunny
![Screenshot_from_2023-01-19_16-23-59](/uploads/a2e69056a38677ffd0203bccf01fca29/Screenshot_from_2023-01-19_16-23-59.png)
And again the minimal sample with the high resolution network camera
![Screenshot_from_2023-01-19_16-28-58](/uploads/fa64414ca09c6206ccb765f4b1016732/Screenshot_from_2023-01-19_16-28-58.png)
I also noticed that the element names in the state change messages keep counting up. From
```
[StateChange] videoconvert0 From Null to Ready pending at VoidPending
[StateChange] avdec_h264-0 From Null to Ready pending at VoidPending
[StateChange] h264parse0 From Null to Ready pending at VoidPending
[StateChange] rtph264depay0 From Null to Ready pending at VoidPending
```
to
```
[StateChange] videoconvert60 From Paused to Playing pending at VoidPending
[StateChange] avdec_h264-60 From Paused to Playing pending at VoidPending
[StateChange] h264parse60 From Paused to Playing pending at VoidPending
[StateChange] rtph264depay60 From Paused to Playing pending at VoidPending
```
and so on. Is this expected or are these elements not freed after destroying the pipeline?
#### Setup
- **Operating System:** Fedora 37 / Windows 10
- **Device:** Computer
- **GStreamer Version:** 1.20.5
- **Command line:**
### Steps to reproduce the bug
Run the minimal sample with `dotnet run`.
```
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<RootNamespace>gstreamer_leak_test</RootNamespace>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="gstreamer-sharp-netcore" Version="0.0.8" />
<PackageReference Include="SkiaSharp" Version="2.88.3" />
<PackageReference Include="SkiaSharp.NativeAssets.Linux" Version="2.88.3" />
</ItemGroup>
</Project>
```
```
using Gst;
using Gst.App;
using SkiaSharp;
Console.WriteLine("Starting Test");
Test.Run();
public class Test
{
private const ulong MAX_PULL_SAMPLE_TIMEOUT_NS = 5000000000;
private const long MAX_SINK_BUFFER_LATENESS = 100000000;
private const string PipelineDescription = "rtspsrc name=src latency=0 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! appsink name=sink";
private const string StreamUri = "rtsp://localhost:8554/vlc-test-stream";
private Pipeline? _pipeline;
private Element? _source;
private AppSink? _appSink;
static Test()
{
Application.Init();
GtkSharp.GstreamerSharp.ObjectManager.Initialize();
}
private Test() {}
public static void Run()
{
var test = new Test();
while(true)
{
test.CreatePipeline();
test.StartPipeline();
test.GetFrame();
test.DestroyPipeline();
}
}
private void CreatePipeline()
{
_pipeline = (Pipeline)Parse.Launch(PipelineDescription);
_source = (Element)_pipeline.GetChildByName("src");
_source["location"] = StreamUri;
_appSink = (AppSink)_pipeline.GetChildByName("sink");
_appSink["caps"] = Caps.FromString("video/x-raw,format=BGRA");
_appSink.Drop = true;
_appSink.Sync = true;
_appSink.Qos = true;
_appSink.MaxLateness = MAX_SINK_BUFFER_LATENESS;
_appSink.MaxBuffers = 1;
_appSink.EnableLastSample = false;
StateChangeReturn ret = _pipeline.SetState(State.Ready);
if (ret != StateChangeReturn.Success)
throw new Exception("Pipeline not ready");
CheckMessages();
}
private void StartPipeline()
{
_pipeline?.SendEvent(Event.NewFlushStart());
_pipeline?.SendEvent(Event.NewFlushStop(reset_time: true));
var ret = _pipeline?.SetState(State.Playing);
if (ret == StateChangeReturn.Failure)
throw new Exception("failed to start pipeline");
CheckMessages();
}
private void DestroyPipeline()
{
_pipeline?.SetState(State.Null);
CheckMessages();
_source?.Dispose();
_appSink?.Dispose();
_pipeline?.Dispose();
_source = null;
_appSink = null;
_pipeline = null;
}
private void GetFrame()
{
using (Sample? sample = _appSink?.TryPullSample(MAX_PULL_SAMPLE_TIMEOUT_NS))
{
if (sample == null) throw new Exception("No sample received after 5 seconds");
CheckMessages();
Caps caps = sample.Caps;
Structure cap = caps[0];
string format = cap.GetString("format");
cap.GetInt("width", out int width);
cap.GetInt("height", out int height);
using (var buffer = sample.Buffer)
{
MapInfo map;
if (format == "BGRA" && buffer.Map(out map, MapFlags.Read))
{
SKBitmap bmp = new SKBitmap(width, height, SKColorType.Bgra8888, SKAlphaType.Opaque);
map.CopyTo(bmp.GetPixels(), bmp.RowBytes * bmp.Height);
// do something with the bitmap
buffer.Unmap(map);
}
}
}
}
private void CheckMessages()
{
Message? message = null;
do
{
message = _pipeline?.Bus?.Pop();
PrintMessage(message);
}
while(message != null);
}
private void PrintMessage(Message? message)
{
if (message == null)
return;
switch (message.Type)
{
case MessageType.ResetTime:
Console.WriteLine($"[ResetTime]");
break;
case MessageType.StateChanged:
message.ParseStateChanged(out State oldstate, out State newstate, out State pendingstate);
Console.WriteLine($"[StateChange] {message.Src.Name} From {oldstate} to {newstate} pending at {pendingstate}");
break;
case MessageType.Error:
message.ParseError(out GLib.GException error, out string debug);
Console.WriteLine($"[Error] {error.Message}, element {message.Src}, debug {debug}");
break;
case MessageType.StreamStatus:
message.ParseStreamStatus(out StreamStatusType type, out Element owner);
Console.WriteLine($"[StreamStatus] Type {type} from {owner.Name}");
break;
}
}
}
```
### How reproducible is the bug?
Alwayshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1719audiorate: does not handle pad offset2023-01-17T10:07:15ZGuillaume Desmottesaudiorate: does not handle pad offsetUpstream of my `audiorate` element is producing buffers with a pad offset (`gst_pad_set_offset()`).
But this offset is ignored by `audiorate` leading in huge difference between the expected ts and so all buffers being dropped.
`gstaudio...Upstream of my `audiorate` element is producing buffers with a pad offset (`gst_pad_set_offset()`).
But this offset is ignored by `audiorate` leading in huge difference between the expected ts and so all buffers being dropped.
`gstaudiorate.c:520:gst_audio_rate_chain:<composition-stream-producers-audiorate-6166f5b8-fe13-41dc-9116-65f00453e801> in_time:0:00:00.128000000, in_duration:0:00:00.021333333, in_size:4096, in_offset:6144, in_offset_end:7168, ->next_offset:222346942030, ->next_ts:1286:43:47.958958333`https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/405Add qrencode recipe for qroverlay plugin2023-01-18T06:37:09ZErik MoqvistAdd qrencode recipe for qroverlay pluginHello!
I installed https://gstreamer.freedesktop.org/data/pkg/windows/1.20.5/msvc/gstreamer-1.0-msvc-x86_64-1.20.5.msi and noticed that the qroverlay plugin is not installed. Any chance it can be added in a future release? Looks like th...Hello!
I installed https://gstreamer.freedesktop.org/data/pkg/windows/1.20.5/msvc/gstreamer-1.0-msvc-x86_64-1.20.5.msi and noticed that the qroverlay plugin is not installed. Any chance it can be added in a future release? Looks like the libqrencode dependency is missing, so the plugin is not built.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1713rtph264pay: silently errors out in certain pipelines2023-01-14T01:16:18ZMathieu Duponchellertph264pay: silently errors out in certain pipelinesI haven't investigated in detail, but I would expect this pipeline to either error out or result in caps and buffers pushed to fakesink:
```
gst-launch-1.0 -v videotestsrc num-buffers=1 ! videoconvert ! videoscale ! videorate skip-to-fi...I haven't investigated in detail, but I would expect this pipeline to either error out or result in caps and buffers pushed to fakesink:
```
gst-launch-1.0 -v videotestsrc num-buffers=1 ! videoconvert ! videoscale ! videorate skip-to-first=true drop-only=true ! video/x-raw, format=ABGR64_LE, width=1280, height=720, framerate=30/1, multiview-mode=mono, pixel-aspect-ratio=1/1, interlace-mode=progressive ! videoconvert ! videoscale ! videorate skip-to-first=true drop-only=true ! video/x-raw, pixel-aspect-ratio=1/1, format=\(string\){NV12, YV12, I420} ! nvh264enc ! h264parse ! video/x-h264, stream-format=avc ! rtph264pay ! application/x-rtp, media=video, payload=102, encoding-name=H264, profile=baseline ! fakesink silent=false
```
Instead, what I observe is that no caps or buffers make it to the sink, but it still ends up posting EOS.
Errors are logged however:
```
0:00:00.308779758 169194 0x2613180 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.308817883 169194 0x2613180 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.308838748 169194 0x2613180 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.308899661 169194 0x2612f60 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.308950836 169194 0x2612f60 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.308996557 169194 0x2612f60 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
0:00:00.309040224 169194 0x2612f60 ERROR rtph264pay gstrtph264pay.c:706:gst_rtp_h264_pay_setcaps:<rtph264pay0> failed to set sps/pps
```
This is annoying because it means we need to special case this in `webrtcsink`, which uses such pipelines to discover caps, and currently expects that fakesink has received caps when the pipeline posts EOS and no errors.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1712vaapih264dec: Produces `views=(int)2, ... multiview-mode=(string)mono` for si...2023-01-15T15:54:52ZTorsten Schulzvaapih264dec: Produces `views=(int)2, ... multiview-mode=(string)mono` for single view (mono) media### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
#### Expected Behavior
vaapih264dec should produce `views=(int)1` for mono media
#### Observed Behavior
vaapih264dec produces `views=(int)2` for mono media, which some sinks are silently ignoring, others reject (like nnstrwamer tensor_converter)
#### Setup
- **Operating System: Ubuntu 22.04**
- **Device:** Computer -->
- **GStreamer Version: 1.20.1 **
### Steps to reproduce the bug
1. open terminal
2. THIS WORKS - type `GST_DEBUG=2 gst-launch-1.0 souphttpsrc location="https://storage.googleapis.com/ts-video-test/test1_vlog.mp4" ! qtdemux ! h264parse ! vaapih264dec ! vaapipostproc ! "video/x-raw,views=(int)2" ! videoconvert ! autovideosink`
3. THIS FAILS - type `GST_DEBUG=2 gst-launch-1.0 souphttpsrc location="https://storage.googleapis.com/ts-video-test/test1_vlog.mp4" ! qtdemux ! h264parse ! vaapih264dec ! vaapipostproc ! "video/x-raw,views=(int)1" ! videoconvert ! autovideosink`
### How reproducible is the bug?
Consistently
### Screenshots if relevant
n/a
### Solutions you have tried
I can provide a proposed patch to gstvaapidecoder_h264.c
### Related non-duplicate issues
na
### Additional Information
nahttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/404uwp: fix up GLib port after upgrade to 2.742023-04-11T07:57:41ZTim-Philipp Müllertim@centricular.comuwp: fix up GLib port after upgrade to 2.74UWP build is currently non-functional, needs some work on the GLib port to stub out certain functions.
Unclear if anyone's using this build actually, so if you are please let us know.UWP build is currently non-functional, needs some work on the GLib port to stub out certain functions.
Unclear if anyone's using this build actually, so if you are please let us know.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1710`ximagesrc` does not draw mouse cursor when window, catched with xname, is mo...2023-01-13T11:13:22ZJulien FR`ximagesrc` does not draw mouse cursor when window, catched with xname, is moved.### Describe your issue
I am using `ximagesrc` to stream specific window using xname property, but I have some trouble with mouse cursor when windows initial position changes.
#### Expected Behavior
<!-- What did you expect to happen --...### Describe your issue
I am using `ximagesrc` to stream specific window using xname property, but I have some trouble with mouse cursor when windows initial position changes.
#### Expected Behavior
<!-- What did you expect to happen -->
#### Observed Behavior
<!-- What actually happened -->
#### Setup
* Debian 9/11
* Gstreamer 1.16/1.20
* XFCE
* Dual-screen
### Steps to reproduce the bug
1. open terminal
2. run `xclock`
3. run `gst-launch ximagesrc xname="xclock" ! ximagesink``
### How reproducible is the bug?
When xclock windows is moved then the mouse pointer is not well drawn in video, the offset corresponds to the movement of the window. If the xclock window is too far from its starting position, the cursor is no longer drawn.
### Screenshots if relevant
```
Screen 1 Screen 2
+---------------------------------+---------------------------------+
| +---------+ | |
| | | | gst-launch |
| | | | +---------+ |
| | | | | | |
| | +---------+ | | | |
| | | | | | | | |
| +----|----+ | | | | |
| | X | | | X | |
| | | | +---------+ |
| | | | |
| +---------+ | |
+---------------------------------+---------------------------------+
```
The X represent the mouse pointer: it is drawn with an offset.
### Additional Information
Question asked on gstreamer-devel: https://lists.freedesktop.org/archives/gstreamer-devel/2022-December/080713.htmlhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/402android: Not possible anymore to not link to gio / disable CA certificates2023-01-12T19:22:13ZSebastian Drögeandroid: Not possible anymore to not link to gio / disable CA certificatesThis was broken in https://gitlab.freedesktop.org/gstreamer/cerbero/-/commit/a368b18a70c5be2c6ae0c00a9d7e7492e091764b .
It now unconditionally uses gio API even if `GSTREAMER_INCLUDE_CA_CERTIFICATES` is disabled. In that case it will fa...This was broken in https://gitlab.freedesktop.org/gstreamer/cerbero/-/commit/a368b18a70c5be2c6ae0c00a9d7e7492e091764b .
It now unconditionally uses gio API even if `GSTREAMER_INCLUDE_CA_CERTIFICATES` is disabled. In that case it will fail linking because of unresolved symbols to the gtls API.
CC @ystreethttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1707Ubuntu static linking fails /usr/bin/ld: cannot find file2023-01-11T12:10:45ZhibrandonevansUbuntu static linking fails /usr/bin/ld: cannot find fileHi, I'm using `gstreamer-rs` to build a statically linked APP. The first thing I did was to download the `gstreamer` source code and execute `meson --default-library=static -Dgst-full-libraries=app,audio,video,pbutils -Dges=enabled -Dtoo...Hi, I'm using `gstreamer-rs` to build a statically linked APP. The first thing I did was to download the `gstreamer` source code and execute `meson --default-library=static -Dgst-full-libraries=app,audio,video,pbutils -Dges=enabled -Dtools=enabled -Dbad=enabled builddir `, it builds successfully.
Then I run a simple example in `gstreamer-rs`, before I configure two environment variables, namely `export PKG_CONFIG_PATH="~/Desktop/Favorites/gstreamer/builddir/meson-private"`, and `export SYSTEM_DEPS_LINK=static`.
In the end I got the error:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "/tmp/rustcde7dOT/symbols.o".......
= note: /usr/bin/ld: cannot find -lges-1.0
/usr/bin/ld: cannot find -lxml2
/usr/bin/ld: cannot find -lgstvalidate-1.0
/usr/bin/ld: cannot find -lgstcontroller-1.0
/usr/bin/ld: cannot find -lgstpbutils-1.0
/usr/bin/ld: cannot find -lgstvideo-1.0
/usr/bin/ld: cannot find -lgstaudio-1.0
/usr/bin/ld: cannot find -lgsttag-1.0
/usr/bin/ld: cannot find -lgstbase-1.0
/usr/bin/ld: cannot find -lgstcheck-1.0
/usr/bin/ld: cannot find -lgstreamer-1.0
collect2: error: ld returned 1 exit status
```
Am I missing something?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1705Using GStreamer as sub project to another project - gst-env.py2023-01-10T15:03:23ZLenin TorresUsing GStreamer as sub project to another project - gst-env.py### Describe your issue
When using GStreamer mono repo as a subproject of another project using meson, it is not possible to use the `gst-env.py` script to create the environment with the correct PATHs.
Using `--builddir` pointing to th...### Describe your issue
When using GStreamer mono repo as a subproject of another project using meson, it is not possible to use the `gst-env.py` script to create the environment with the correct PATHs.
Using `--builddir` pointing to the build directory of the project it find some GStreamer files but not all the necessary, no plugins for example.
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
#### Expected Behavior
I expect that when I run `python3 gst-env.py --builddir ./build/` it looks for the GStreamer directory in `./build/subprojects/gstreamer` but it looks for `./build/gstreamer`
<!-- What did you expect to happen -->
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** Linux
- **Device:** Jetson - Xavier
- **GStreamer Version:** 1.20
- **Command line:** `python3 subprojects/gstreamer/gst-env.py --builddir ./build/`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. include GStreamer subproject to meson.build
2. configure and build with ninja
3. Create the environment with gst-env.py
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/290fmp4mux: add support for MISB KLV metadata2023-01-19T11:56:01ZLucas Johnsonfmp4mux: add support for MISB KLV metadataMISB ST1910 specifies how to package metadata into an Event Message (emsg) Box of the CMAF. meta/x-klv could be added as a type accepted on the sink pad.MISB ST1910 specifies how to package metadata into an Event Message (emsg) Box of the CMAF. meta/x-klv could be added as a type accepted on the sink pad.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1699Improve documentation for replicating CI's environment localy2023-06-12T14:27:50ZJordan PetridіsImprove documentation for replicating CI's environment localyThe following discussion from !3681 should be addressed:
- [ ] @alatiera started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3681#note_1710124): (+2 comments)
> we can add a volume mount so w...The following discussion from !3681 should be addressed:
- [ ] @alatiera started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3681#note_1710124): (+2 comments)
> we can add a volume mount so we don't have to checkout the repo, however since the container runs as a different uid and currently even as root, this will mess the file permissions
>
> `docker run -it -v $(pwd):/local-checkout fedora:2022-12-10.0-main`Jordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1694va: vapostproc does not implement caps negotiation correctly2023-01-09T11:08:20ZSebastian Drögeva: vapostproc does not implement caps negotiation correctly```console
# works
$ gst-launch-1.0 gltestsrc ! glcolorconvert ! gldownload ! video/x-raw,format=NV12 ! vapostproc ! vah264enc ! fakesink
# doesn't work because vapostproc can't convert RGBA->NV12 it seems
$ gst-launch-1.0 gltestsrc ! gl...```console
# works
$ gst-launch-1.0 gltestsrc ! glcolorconvert ! gldownload ! video/x-raw,format=NV12 ! vapostproc ! vah264enc ! fakesink
# doesn't work because vapostproc can't convert RGBA->NV12 it seems
$ gst-launch-1.0 gltestsrc ! glcolorconvert ! gldownload ! vapostproc ! vah264enc ! fakesink
```https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/113The code snippets in Basic Tutorial indicate wrong line of code2023-07-12T12:57:40ZStevenThe code snippets in Basic Tutorial indicate wrong line of codeThe code snippets in Basic Tutorial indicate wrong line of code. [For example],(https://gstreamer.freedesktop.org/documentation/tutorials/basic/concepts.html#properties)
the illustration of the property should use the following code.
```...The code snippets in Basic Tutorial indicate wrong line of code. [For example],(https://gstreamer.freedesktop.org/documentation/tutorials/basic/concepts.html#properties)
the illustration of the property should use the following code.
```
/* Modify the source's properties */
g_object_set (source, "pattern", 0, NULL);
```
I think the whole Basic Tutorial have the same issue, might be dut to example sorce code have be modified.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/112Replace GTK3 tutorials/examples with GTK42023-01-06T08:13:41ZSebastian DrögeReplace GTK3 tutorials/examples with GTK4