GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-03-07T00:33:01Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2336mfh264enc: element fails when transitioning to PLAYING if the hardware encode...2023-03-07T00:33:01ZVishesh Bhartiyamfh264enc: element fails when transitioning to PLAYING if the hardware encoder limit has been exceeded### Describe your issue
NVidia GeForce graphics cards have a simultaneous hardware encoding limit of 3. When trying to more than 3 streams using the mfh264enc element, the element fails, as expected. However, this failure happens in the ...### Describe your issue
NVidia GeForce graphics cards have a simultaneous hardware encoding limit of 3. When trying to more than 3 streams using the mfh264enc element, the element fails, as expected. However, this failure happens in the transition from the PAUSED to PLAYING states, which is unexpected since other hardware encoding elements like the nvh264enc fail in the transition from NULL to READY.
#### Expected Behavior
mfh264enc fails when going from NULL to READY.
#### Observed Behavior
mfh264enc fails when going from PAUSED to PLAYING.
#### Setup
- Operating System: Windows
- Device: Computer with an Nvidia GeForce graphics card
- GStreamer Version: 1.20.3
### Steps to reproduce the bug
1. Run 3 pipelines that use the mfh264enc. Everything would work as normal
2. Run a fourth pipeline that uses the mfh264enc. This pipeline should fail when attempting to transition from PAUSED to PLAYING.
### How reproducible is the bug?
Alwayshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2335gst_play_get_video_snapshot() does not work, always returns NULL2023-03-07T08:19:13Znullptrgst_play_get_video_snapshot() does not work, always returns NULL### 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/ -->
Using gst_play_get_video_snapshot() on a paused video in WebM or H256 video always returns NULL instead of a sample corresponding to the snapshot.
#### Expected Behavior
Non-NULL return when used on a video that has been loaded and paused.
#### Observed Behavior
Always NULL return
#### Setup
- **Operating System:** Fedora 36
- **Device:** Computer
- **GStreamer Version:** 1.2
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. apply diff to the gst-examples/playback/player/gtk/gtk-play.c example
2. build the example
3. run, pick a video when prompted, and click the pause button (which triggers the snapshot taking and NULL check)
4. program should abort due to a failed assert (asserted non-NULL return from gst_play_get_video_snapshot())
### How reproducible is the bug?
I've only tried it with H.265 and webm video
### Screenshots if relevant
### Solutions you have tried
Calling gst_play_get_video_snapshot() with different formats (JPEG, PNG), different configuration structures with different widths/heights, and NULL configuration structures.
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->[gtk-play.c.diff](/uploads/9c3823f4993ec13815863271af0ff887/gtk-play.c.diff)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2328v4l2: unknown control 'bypass_mode'2023-03-06T09:10:21ZTuğba Karav4l2: unknown control 'bypass_mode'Hi, I have an 4K USB cam from ELP, I tried to run this command ` v4l2-ctl -d /dev/video0 --set-fmt-video=width=2592,height=1944,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100`
in terminal of amd64 (my PC) and...Hi, I have an 4K USB cam from ELP, I tried to run this command ` v4l2-ctl -d /dev/video0 --set-fmt-video=width=2592,height=1944,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100`
in terminal of amd64 (my PC) and arm64(Nvidia Jetson Nano) but I got `unknown control 'bypass_mode'` , when I search it in nvidia devlepers forum someone faced it before in the [link](https://forums.developer.nvidia.com/t/inogeni-4k-usb3-0-and-gstreamer-problem/57673/9?u=tugbakara) and it was kernel bug but link is broken and I am searching another solution different than kernel patch. Also, in the issues there is not any smilar issue there.
Is there anyone faced issue before? How to solve it?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2105Move away from accessing `GObject::ref_count`2023-03-02T19:16:45ZSebastian DrögeMove away from accessing `GObject::ref_count`As discussed with @ebassi earlier, there are plans to implemented biased refcounting in GObject. This would make access to the `ref_count` field useless and would break the refcount debugging and refcount testing we have, and also make t...As discussed with @ebassi earlier, there are plans to implemented biased refcounting in GObject. This would make access to the `ref_count` field useless and would break the refcount debugging and refcount testing we have, and also make the refcount tracer useless.
The `ref_count` field is clearly marked as private and that it shouldn't be accessed from the outside. We're doing that since basically forever nonetheless, but it's not guaranteed to continue working.
In the short term we should probably get rid of the tests and refcount debugging (and maybe deprecate `gst_object_ref()` / `gst_object_unref()`), and deprecate the refcount tracing API so that at least no new users of it appear. In parallel users of the refcount tracer should probably start looking at an alternative approach.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2104pad-added does not get fired for decodebin2023-03-02T19:13:14ZCraig Carnellpad-added does not get fired for decodebin### Describe your issue
I am using gstreamer to decode a packet at a time using appsrc, decodebin, videoconvert and appsink to pull out the decoded frames which will be rendered later in the application.
I have created caps from the sou...### Describe your issue
I am using gstreamer to decode a packet at a time using appsrc, decodebin, videoconvert and appsink to pull out the decoded frames which will be rendered later in the application.
I have created caps from the source file, however pad-added signal of decodebin is never fired, so decodebin is never linked to videoconvert.
I have noticed that my callback function is called when video is set to video/x-raw, which is obviously the wrong caps for the file below. I am using decodebin as the code needs to work on different formats.
I can see in the log that h264parse, vaapidecodebin are created. However since decodebin never gets linked due to pad-added not firing, my data has no where to go!
#### Expected Behavior
Testfile: jellyfish-3-mbps-hd-h264.mkv
Caps used:
```
video/x-h264, level=(string)4, profile=(string)high,
codec_data=(buffer)01640028ffe1002e67640028ac2ca401e0089f97ff0001000152020202800001f48000753070100016e36000089545f8c7076858b44801000568eb735250,
stream-format=(string)avc, alignment=(string)au, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1,
framerate=(fraction)30000/1001, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8,
colorimetry=(string)bt709, parsed=(boolean)true
```
GStreamer should fire my call back function once decodebin has source pad.
Code Source
```
data.pipeline = gst_pipeline_new("pipeline");
data.app_source = gst_element_factory_make("appsrc", "video_source");
m_bus = gst_pipeline_get_bus(GST_PIPELINE (data.pipeline));
gst_bus_add_watch(m_bus, (GstBusFunc)CBBusMessage, this);
// fake test caps (real from the file)
GstCaps *test = gst_caps_from_string("video/x-h264, level=(string)4, profile=(string)high, codec_data=(buffer)01640028ffe1002e67640028ac2ca401e0089f97ff0001000152020202800001f48000753070100016e36000089545f8c7076858b44801000568eb735250, stream-format=(string)avc, alignment=(string)au, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30000/1001, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, colorimetry=(string)bt709, parsed=(boolean)true");
g_object_set(G_OBJECT(data.app_source),
"caps", test,
"stream-type", 0, // stream-type is stream or seekable for push mode
"format", GST_FORMAT_TIME, // GST_FORMAT_TIME for timestamped buffers
"is-live", true,
nullptr);
data.decoder = gst_element_factory_make("decodebin", "mydecoder");
g_signal_connect (data.decoder, "pad-added", G_CALLBACK (CBNewPadAdded), this);
data.queue = gst_element_factory_make("queue", "queue");
data.video_convert = gst_element_factory_make("videoconvert", "video_convert");
data.app_sink = gst_element_factory_make ("appsink", "app_sink");
g_object_set(data.app_sink, "emit-signals", true, nullptr);
g_signal_connect (data.app_sink, "new-sample", G_CALLBACK (CBNewSample), this);
gst_bin_add_many (GST_BIN (data.pipeline), data.app_source, data.decoder, data.queue,
data.video_convert, data.app_sink, nullptr);
if(!gst_element_link_many (data.app_source, data.decoder, nullptr)) {
return false;
}
if(!gst_element_link_many (data.video_convert, data.app_sink, nullptr)) {
return false;
}
ret = gst_element_set_state(data.pipeline, GST_STATE_PLAYING);
main_loop = g_main_loop_new(nullptr, false);
Snip: my call back function:
GstFlowReturn CDVDVideoCodecGStreamerWrapper::CBNewPadAdded(GstElement *object, GstPad *pad, gpointer user_data) {
// link pads
}
```
I tried launching it using gst_parse_launch:
```
pipeline appsrc name=video_src ! video/x-h264, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, alignment=(string)au, stream-format=(string)avc, codec_data=(buffer)01640028ffe1002e67640028ac2ca401e0089f97ff0001000152020202800001f48000753070100016e36000089545f8c7076858b44801000568eb735250fdf8f800 ! decodebin name=decoder ! videoconvert name=video_convert ! appsink name=app_sink
```
Same issue, decodebin has no peers.
#### Observed Behavior
CBNewPadAdded call back function is never called.
decodebin has no peer messages in terminal output.
See: https://pastebin.com/U4THdqbj
I have noticed that CBNewPadAdded is fired when I use wrong caps like video/x-raw. I have tried other solutions like using filtercap bin, I have also tried setting g_object_set(data.decoder, "sink-caps", data.input_caps, nullptr); instead of caps on the appsrc.
#### Setup
- Ubuntu 22.10 x86/64 Linux
- Laptop
- GStreamer 1.20.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2092AV1 mpeg-ts muxing & demuxing2023-03-02T14:48:15ZOlivier Crêteolivier.crete@ocrete.caAV1 mpeg-ts muxing & demuxingWe should try to implement the AV1 in MPEG-TS spec in GStreamer:
https://code.videolan.org/videolan/av1-mapping-specs/blob/master/ts-carriage.mdWe should try to implement the AV1 in MPEG-TS spec in GStreamer:
https://code.videolan.org/videolan/av1-mapping-specs/blob/master/ts-carriage.mdEdward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2067gstreamer-full: Generate .pc files that link against gstreamer-full for all g...2023-06-17T22:48:31ZThibault Sauniertsaunier@igalia.comgstreamer-full: Generate .pc files that link against gstreamer-full for all gst librariesRight now to consume a gstreamer-full build, the user has to explicitly link against it and thus make change to the application, instead we should have `.pc` files for `gstreamer-1.0` and all GStreamer lib pointing to it directly so it c...Right now to consume a gstreamer-full build, the user has to explicitly link against it and thus make change to the application, instead we should have `.pc` files for `gstreamer-1.0` and all GStreamer lib pointing to it directly so it can be consumed without any change in the applications. To build `gstreamer-rs` and application using it that feature is basically necessary.
I have started a branch with investigation work but at this point there is a cycling dependency when trying to statically link GStreamer libraries leading to `pkg-config` getting into an infinite loop.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2066playbin: buggy seek to beginning after end of audio playback2023-03-02T10:26:49ZMatthieu Imbertplaybin: buggy seek to beginning after end of audio playbackTested with gstreamer 1.22.
Play a sound with playbin.
When the sound has finished playing, perform a flushing seek to the beginning of the buffer.
Replay the sound.
Then the following happens:
- If the sound is long enough (longer ...Tested with gstreamer 1.22.
Play a sound with playbin.
When the sound has finished playing, perform a flushing seek to the beginning of the buffer.
Replay the sound.
Then the following happens:
- If the sound is long enough (longer than 2 seconds for example), it replays correctly, but a part at the beginning of the sound is missing in an audible manner (i estimate a few milliseconds, it can be eard with sounds with a fast attack). If replaying continuously, the length of the missing segment at the beginning can vary slightly in an audible manner
- If the sound is short enough (tested with a sound of 0.1s), after two or three replays, playbin is then unable to replay the sound
I have put code and sound samples to reproduce this bug here: https://github.com/mimbert/gst-playbin-seek-test
There is a short bass drum sound of 0.1s to show the second behaviour, and the same sample longer, with reverberation added, to show the first behaviour.
There is a vagrant file to check the bug in different environments. The bug occurs on debian testing with pipewire acting as the pulseaudio server, gstreamer 1.22 (vagrant box name `debtesting`), and it does not occur on debian stable with regular pulseaudio, with gstreamer 1.18 (vagrant box name `debtstable`). Interrestingly, it does not occur on debian stable with regular pulseaudio, with only gstreamer 1.22 taken from debian testing (vagrant box name `debstable2`), so i don't know if the bug is actually in gstreamer or caused by the specific interaction between gstreamer and pipewire.
I also made some tests by using explicit audio sinks instead of the default automatic audio sink and got these results on my development laptop on debian testing, gstreamer 1.22, pipewire (pipewire being the pulseaudio server and the jack server):
- pulsesink (pipewire): the bug occurs
- jackaudiosink: the bug occurs, but less. I can hear that still there is a small part of the sound (smaller than pulsink) missing at beginning after the first play/seek to beginning.
- openalsink: works perfectly, no bug (in this situation, openal is a client of the pulseaudio (pipewire) server).
The code that allows selecting the sink is in the `misc-tests` branch of https://github.com/mimbert/gst-playbin-seek-test
For example i have run it like that:
`$ ./gst-playbin-seek-test.py --sink=pulsesink bass_drum_reverb.wav`
`$ ./gst-playbin-seek-test.py "--sink=jackaudiosink/connect=explicit/port-names=USB Audio #1:playback_FL,USB Audio #1:playback_FR" bass_drum_reverb.wav`
`$ ./gst-playbin-seek-test.py --sink=openalsink bass_drum_reverb.wav`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2065Playsink: Failed to initialize colorbalance shader2023-03-02T10:14:16ZZaidan AlaouiPlaysink: Failed to initialize colorbalance shaderWe are getting the following failure when trying to create a pipeline under Android as follows:
filesrc -> decodebin -> playsink
```
The following log are returned:
../gst-libs/gst/gl/gstglslstage.c:519:_compile_shader:<glslstage1> frag...We are getting the following failure when trying to create a pipeline under Android as follows:
filesrc -> decodebin -> playsink
```
The following log are returned:
../gst-libs/gst/gl/gstglslstage.c:519:_compile_shader:<glslstage1> fragment shader compilation failed:1:1: L0001: Typename expected, found 'samplerExternalOES'
../gst-libs/gst/gl/gstgldebug.c:307:_gst_gl_debug_callback:<glcontextegl2> high: GL error from API id:38, Error:glDeleteShader::<shader> is not a value generated by OpenGL
../ext/gl/gstglcolorbalance.c:265:_create_shader:<glcolorbalance0> error: Failed to initialize colorbalance shader
../ext/gl/gstglcolorbalance.c:265:_create_shader:<glcolorbalance0> error: fragment shader compilation failed:1:1: L0001: Typename expected, found 'samplerExternalOES'
```
A native window is created and is passed to Playsink using:
gst_video_overlay_expose (GST_VIDEO_OVERLAY (data->playsink));
Is this a known issue ? Any suggestions ?
Thankshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2058rtp: Header extension for csrc-audio-level2023-03-06T16:19:44ZPhilippe Normandrtp: Header extension for csrc-audio-levelWe have an extension covering RFC 6464, `urn:ietf:params:rtp-hdrext:ssrc-audio-level` but for RFC 6465 (`urn:ietf:params:rtp-hdrext:csrc-audio-level`) nothing yet. Is that something rtpfunnel could handle?We have an extension covering RFC 6464, `urn:ietf:params:rtp-hdrext:ssrc-audio-level` but for RFC 6465 (`urn:ietf:params:rtp-hdrext:csrc-audio-level`) nothing yet. Is that something rtpfunnel could handle?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2040hlsdemux2: Send the PDT tag again after a seek2023-03-01T10:40:00ZEdward Herveyhlsdemux2: Send the PDT tag again after a seekRight now we never re-send it after a seek (or live re-sync), whereas we should since the PDT<=>running-time changedRight now we never re-send it after a seek (or live re-sync), whereas we should since the PDT<=>running-time changedhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2038audiobasesink: discontinuity detect will result in drop audio frames2023-09-11T10:53:51Zshengqi2022audiobasesink: discontinuity detect will result in drop audio frameswhen playing some audio, audiobasesink will try to align the sample and wait discontinuity expired in gst_audio_base_sink_get_alignment. This result in some frames dropped between last buffer and current buffer.
the test pipeline is "fi...when playing some audio, audiobasesink will try to align the sample and wait discontinuity expired in gst_audio_base_sink_get_alignment. This result in some frames dropped between last buffer and current buffer.
the test pipeline is "filesrc location=/data/xxx.wma ! asfdemux ! avdec_wmapro ! audioconvert ! alsasink"
Here's a log snippet showing this happening (For a clearer analysis, I added some log, see at [ysq]). This log snippet print the first three buffers when frame drop occurs.
**the first buffer render ok, render from 49151 to 51199**
```
0:00:01.366447385 804 0x2cf010 DEBUG GST_SCHEDULING gstpad.c:4443:gst_pad_chain_data_unchecked:<alsasink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0xb3e03690, pts 0:00:01.186879819, dts 99:99:99.999999999, dur 0:00:00.046439909, size 16384, offset none, offset_end none, flags 0x0
0:00:01.366477616 804 0x2cf010 DEBUG basesink gstbasesink.c:3826:gst_base_sink_chain_unlocked:<alsasink0> got times start: 0:00:01.186879819, end: 0:00:01.233319728
0:00:01.366506924 804 0x2cf010 DEBUG basesink gstbasesink.c:2166:gst_base_sink_get_sync_times:<alsasink0> got times start: 0:00:01.186879819, stop: 0:00:01.233319728, do_sync 0
0:00:01.366529539 804 0x2cf010 LOG basesink gstbasesink.c:2725:gst_base_sink_do_sync:<alsasink0> avg frame diff 0:00:00.046887371
0:00:01.366545385 804 0x2cf010 DEBUG basesink gstbasesink.c:3944:gst_base_sink_chain_unlocked:<alsasink0> rendering object 0xb3e03690
0:00:01.366573847 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1905:gst_audio_base_sink_render:<alsasink0> time 0:00:01.186879819, start 0:00:00.000000000, samples 2048
0:00:01.366615539 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1942:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:01.366641077 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2008:gst_audio_base_sink_render:<alsasink0> running: start 0:00:01.186879819 - stop 0:00:01.233319728
0:00:01.366667385 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2050:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:01.186879819 - stop 0:00:01.233319728
0:00:01.366703770 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2081:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 52341, render_stop 54389 //caculate timestamp in samples, 52341-50293=2048 frames
0:00:01.366720154 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1745:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] sink->next_sample 49151, sample_offset 52341, sample_diff 3190 //sink->next_sample is last render ended position
0:00:01.366733770 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1752:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] max_sample_diff 1764
0:00:01.275152846 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1765:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] time(caculate sample_offset in timestamp)0:00:01.186870748,priv->discont_time 0:00:00.277981859,priv->discont_wait 0:00:01.000000000
0:00:01.275173231 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1793:gst_audio_base_sink_get_alignment:<alsasink0> [ysq]diff(caculate sample_diff in timestamp) +0:00:00.072335600
0:00:01.366765462 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1786:gst_audio_base_sink_get_alignment:<alsasink0> align with prev sample, ABS (-3190) < 1764
0:00:01.366781001 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2142:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 49151, render_stop 51199, align -3190
0:00:01.366796462 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2154:gst_audio_base_sink_render:<alsasink0> [ysq]rendering at 49151 2048/2048
```
**this second buffer render ok, render from 51199 to 53247**
```
0:00:01.416471770 804 0x2cf010 DEBUG GST_SCHEDULING gstpad.c:4443:gst_pad_chain_data_unchecked:<alsasink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x2cef38, pts 0:00:01.233319728, dts 99:99:99.999999999, dur 0:00:00.046439909, size 16384, offset none, offset_end none, flags 0x0
0:00:01.416500693 804 0x2cf010 DEBUG basesink gstbasesink.c:3826:gst_base_sink_chain_unlocked:<alsasink0> got times start: 0:00:01.233319728, end: 0:00:01.279759637
0:00:01.416528847 804 0x2cf010 DEBUG basesink gstbasesink.c:2166:gst_base_sink_get_sync_times:<alsasink0> got times start: 0:00:01.233319728, stop: 0:00:01.279759637, do_sync 0
0:00:01.416551693 804 0x2cf010 LOG basesink gstbasesink.c:2725:gst_base_sink_do_sync:<alsasink0> avg frame diff 0:00:00.046831438
0:00:01.416567616 804 0x2cf010 DEBUG basesink gstbasesink.c:3944:gst_base_sink_chain_unlocked:<alsasink0> rendering object 0x2cef38
0:00:01.416595616 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1905:gst_audio_base_sink_render:<alsasink0> time 0:00:01.233319728, start 0:00:00.000000000, samples 2048
0:00:01.416627616 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1942:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:01.416651847 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2008:gst_audio_base_sink_render:<alsasink0> running: start 0:00:01.233319728 - stop 0:00:01.279759637
0:00:01.416677693 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2050:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:01.233319728 - stop 0:00:01.279759637
0:00:01.416727924 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2081:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 54389, render_stop 56437
0:00:01.416745001 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1745:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] sink->next_sample 51199, sample_offset 54389, sample_diff 3190
0:00:01.416758462 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1752:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] max_sample_diff 1764
0:00:01.325247308 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1765:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] time(caculate sample_offset in timestamp)0:00:01.233310657,priv->discont_time 0:00:00.277981859,priv->discont_wait 0:00:01.000000000
0:00:01.325268616 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1793:gst_audio_base_sink_get_alignment:<alsasink0> [ysq]diff(caculate sample_diff in timestamp) +0:00:00.072335600
0:00:01.416789847 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1786:gst_audio_base_sink_get_alignment:<alsasink0> align with prev sample, ABS (-3190) < 1764
0:00:01.416805385 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2142:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 51199, render_stop 53247, align -3190
0:00:01.416821539 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2154:gst_audio_base_sink_render:<alsasink0> [ysq]rendering at 51199 2048/2048
```
**the third buffer render NG, frame dropped between 53247 and 56437, droped 56437-53247=3190 frames, we can hear carton**
```
0:00:01.457781308 804 0x2cf010 DEBUG GST_SCHEDULING gstpad.c:4443:gst_pad_chain_data_unchecked:<alsasink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0xb3e6e800, pts 0:00:01.279759637, dts 99:99:99.999999999, dur 0:00:00.046439909, size 16384, offset none, offset_end none, flags 0x0
0:00:01.457861847 804 0x2cf010 DEBUG basesink gstbasesink.c:3826:gst_base_sink_chain_unlocked:<alsasink0> got times start: 0:00:01.279759637, end: 0:00:01.326199546
0:00:01.457939077 804 0x2cf010 DEBUG basesink gstbasesink.c:2166:gst_base_sink_get_sync_times:<alsasink0> got times start: 0:00:01.279759637, stop: 0:00:01.326199546, do_sync 0
0:00:01.457998847 804 0x2cf010 LOG basesink gstbasesink.c:2725:gst_base_sink_do_sync:<alsasink0> avg frame diff 0:00:00.046782496
0:00:01.458042539 804 0x2cf010 DEBUG basesink gstbasesink.c:3944:gst_base_sink_chain_unlocked:<alsasink0> rendering object 0xb3e6e800
0:00:01.458118539 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1905:gst_audio_base_sink_render:<alsasink0> time 0:00:01.279759637, start 0:00:00.000000000, samples 2048
0:00:01.458205616 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1942:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:01.458274924 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2008:gst_audio_base_sink_render:<alsasink0> running: start 0:00:01.279759637 - stop 0:00:01.326199546
0:00:01.458345308 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2050:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:01.279759637 - stop 0:00:01.326199546
0:00:01.458476385 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2081:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 56437, render_stop 58485, rate 4607182418800017408
0:00:01.458525924 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1745:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] sink->next_sample 53247, sample_offset 56437, sample_diff 3190
0:00:01.458565616 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1752:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] max_sample_diff 1764
0:00:01.366432539 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1765:gst_audio_base_sink_get_alignment:<alsasink0> [ysq] time(caculate sample_offset in timestamp)0:00:01.279750566,priv->discont_time 0:00:00.277981859,priv->discont_wait 0:00:01.000000000
0:00:01.458646001 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1772:gst_audio_base_sink_get_alignment: [ysq] set discont flag is TRUE
0:00:01.366463154 1033 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:1793:gst_audio_base_sink_get_alignment:<alsasink0> [ysq]diff(caculate sample_diff in timestamp) +0:00:00.072335600
0:00:01.458703001 804 0x2cf010 WARN audiobasesink gstaudiobasesink.c:1797:gst_audio_base_sink_get_alignment:<alsasink0> Unexpected discontinuity in audio timestamps of +0:00:00.072335600, resyncing
0:00:01.458750924 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2142:gst_audio_base_sink_render:<alsasink0> [ysq] render_start 56437, render_stop 58485, align 0 //here, it is should rendered at 53247, but render at 56437
0:00:01.458797231 804 0x2cf010 DEBUG audiobasesink gstaudiobasesink.c:2154:gst_audio_base_sink_render:<alsasink0> [ysq]rendering at 56437 2048/2048
```
the third buffer's pts,sample_diff,and render position are all normal, I am a bit confused why the discont flag should be set true here?
if do like this, there may be a cartoon when playing many audio files. Internally, our solution is not set discont flag to avoid drop frames.
Any thoughts about this audio frame drop?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2033Program stalls when reading the file truncatedMJ2000.mj22023-02-28T19:10:50ZUpanita GoswamiProgram stalls when reading the file truncatedMJ2000.mj2### 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
<!-- What did you expect to happen -->
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:**
- SMP Debian 5.15.5-2~bpo11+1 (2022-01-02)
- **Device:** Computer / Tablet / Mobile / Virtual Machine <!-- Delete as appropriate !-->
- Desktop
-
- **GStreamer Version:**
- $ gst-launch-1.0 --version
gst-launch-1.0 version 1.18.4
GStreamer 1.18.4
http://packages.qa.debian.org/gstreamer1.0
-
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. See attached code repro.cpp and file truncatedMJ2000.mj2
2. Compile code
`**g++ repro.cpp -o repro -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/user/include/gcc_headers -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0 -lgstbase-1.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lgstapp-1.0
**`
3. ./repro
4. The stall is reproducible sporadically. I am looping over the code for 1000 iterations and can see the stall at random iterations.
For example, in the following instance, the program stalled at iteration 737 (bolded).
`
(repro:58908): GStreamer-CRITICAL **: 12:03:17.930: gst_mini_object_unref: assertion 'mini_object != NULL' failed
iteration::735
Playbin initializated successfully
Appsink has been created
State change failedCould not create videoCapsObtain the videoCaps from the appsink
State change to PLAYING failedState change failedplaybin successfully changed to playing
(repro:58908): GStreamer-CRITICAL **: 12:03:17.947: gst_mini_object_unref: assertion 'mini_object != NULL' failed
iteration::736
Playbin initializated successfully
Appsink has been created
State change failedCould not create videoCapsObtain the videoCaps from the appsink
State change to PLAYING failedState change failedplaybin successfully changed to playing
(repro:58908): GStreamer-CRITICAL **: 12:03:17.963: gst_mini_object_unref: assertion 'mini_object != NULL' failed
**iteration::737**
Playbin initializated successfully
Appsink has been created
Could not create videoCapsObtain the videoCaps from the appsink
playbin successfully changed to playing
`
You can run the program multiple times to see the stall. Sometimes it may go through fine upto iteration 1000.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Intermittent[truncatedMJ2000.mj2](/uploads/530c193cd77bbb8bd2869678a14fd03c/truncatedMJ2000.mj2)[repro.cpp](/uploads/2912c4e0cba948a0e43bcb8fb38d89b3/repro.cpp)
### 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/gstreamer/-/issues/2026curl plugin does not follow redirects: Internal data flow error2023-07-17T11:52:45ZGleb Popovcurl plugin does not follow redirects: Internal data flow error### Describe your issue
`gst-play-1.0 https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv` doesn't work.
#### Expected Behavior
The video file plays correctly.
#### Observed Behavior
```
Now playing https://files.kde.org/pla...### Describe your issue
`gst-play-1.0 https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv` doesn't work.
#### Expected Behavior
The video file plays correctly.
#### Observed Behavior
```
Now playing https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv
Prerolling...
ERROR Internal data flow error. for https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv
ERROR debug information: ../libs/gst/base/gstbasesrc.c(2770): gst_base_src_get_range (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstCurlHttpSrc:source:
Subclass GstCurlHttpSrc neither returned a buffer nor submitted a buffer list from its create function
Reached end of play list.
```
#### Setup
- **GStreamer Version: 1.22**
### How reproducible is the bug?
The reproducibility of the bug is Always
### Solutions you have tried
`curl https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv` also doesn't output anything. To make it work I have to pass `--location` flag.
### Related non-duplicate issues
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1120
### Additional Information
The plugin already has a property controlling usage of `--location` flag: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/88a8d9e8cd9c1ac69520fa27f732857bc2ebb52a/subprojects/gst-plugins-bad/ext/curl/gstcurlhttpsrc.c#L384
It probably should be just enabled by default.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2025warning(f'DEPRECATED use of the `plugins` variable in @project_name@.')2023-03-01T07:51:46Ztab magicwarning(f'DEPRECATED use of the `plugins` variable in @project_name@.')hi gstreamer team
after "meson setup builddir", i got the output like this, i have no idea about it, could you kindly help?
The Meson build system
Version: 0.53.2
Source dir: /home/magic/work/opensource/AVB_TSN/gstreamer/gstreamer
Build ...hi gstreamer team
after "meson setup builddir", i got the output like this, i have no idea about it, could you kindly help?
The Meson build system
Version: 0.53.2
Source dir: /home/magic/work/opensource/AVB_TSN/gstreamer/gstreamer
Build dir: /home/magic/work/opensource/AVB_TSN/gstreamer/gstreamer/builddir
Build type: native build
meson.build:172:15: ERROR: Expecting rparen got string.
warning(f'DEPRECATED use of the `plugins` variable in @project_name@.')
^_^https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2024v4l2dec sink caps negotiation failed when driver exports h265 level2023-02-28T03:26:52ZRandy Liv4l2dec sink caps negotiation failed when driver exports h265 level### Describe your issue
All the current v4l2 video stateful decoder drivers don't export codec level.
You could see only stateful encoder use `V4L2_CID_MPEG_VIDEO_H264_LEVEL` and `V4L2_CID_MPEG_VIDEO_HEVC_LEVEL` in the upstream kernel dr...### Describe your issue
All the current v4l2 video stateful decoder drivers don't export codec level.
You could see only stateful encoder use `V4L2_CID_MPEG_VIDEO_H264_LEVEL` and `V4L2_CID_MPEG_VIDEO_HEVC_LEVEL` in the upstream kernel driver.
If a decoder driver supports `V4L2_CID_MPEG_VIDEO_HEVC_LEVEL` query, it would failed the negotiation with `h265parse`, as the we won't export the h265 tier.
#### Expected Behavior
pad negotiation success
#### Observed Behavior
pad negotiation failed
#### Setup
- **Operating System: Linux
- **Device: Computer, embedded platform
- **GStreamer Version: 464c51a78aee860aceb2319be27006c43f8f331a
- **Command line: `gst-launch-1.0 filesrc location=hevc.mp4 ! qtdemux ! h265parse ! v4l2h265dec ! fakesink`
### Steps to reproduce the bug
### How reproducible is the bug?
### Screenshots if relevant
```
/GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:sink: caps = video/x-h265, stream-format=(string)hvc1, alignment=(string)au, tier=(string
)main, profile=(string)main, codec_data=(buffer)01016000000000000000000000f000fcfdf8f800000f03a00001001940010c01ffff016000000300000300000300000
30000949024a10001003242010101600000030000030000030000030000a001e020021c7f96526491b61a588aa93130cbecfaf37e59f5e1446272ed90a2000100074401c1a57c08
90, width=(int)3840, height=(int)2160, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1
Redistribute latency...
0:00:00.044095320 498 0x55a2472400 DEBUG v4l2videodec gstv4l2videodec.c:1193:gst_v4l2_video_dec_sink_getcaps:<v4l2h265dec0> Retur
ning sink caps video/x-h265, width=(int)[ 64, 4096 ], height=(int)[ 64, 2176, 2 ], framerate=(fraction){ 0/1, [ 1/1, 200/1 ] }, stream-format=(
string)byte-stream, alignment=(string)au, level=(string){ 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6 }, profile=(string){ main, main-still-pictu
re, main-10 }, colorimetry=(string){ bt709, bt601, smpte240m, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=
(boolean)true
/GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:src: caps = video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, tier=(
string)main, profile=(string)main, width=(int)3840, height=(int)2160, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, chroma-format
=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true
```
### Solutions you have tried
If I let the driver do not support level query, the v4l2h265dec would copy the level and tier info from the upstream pad.
```
0:01:23.735590560 526 0x555568b800 DEBUG v4l2videodec gstv4l2videodec.c:1193:gst_v4l2_video_dec_sink_getcaps:<v4l2h265dec0> Returning sink caps video/x-h265, width=(int)[ 64, 4096 ], height=(int)[ 64, 2176, 2 ], framerate=(fraction){ 0/1, [ 1/1, 200/1 ] }, stream-format=(string)byte-stream, alignment=(string)au, colorimetry=(string){ bt709, bt601, smpte240m, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true
/GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:src: caps = video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, tier=(string)main, profile=(string)main, width=(int)3840, height=(int)2160, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true
0:01:25.536659400 526 0x555568b800 DEBUG v4l2videodec gstv4l2videodec.c:1193:gst_v4l2_video_dec_sink_getcaps:<v4l2h265dec0> Returning sink caps video/x-h265, width=(int)3840, height=(int)2160, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, stream-format=(string)byte-stream, alignment=(string)au, colorimetry=(string){ bt709, bt601, smpte240m, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true, tier=(string)main, profile=(string)main, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8
```
### Related non-duplicate issues
### Additional Information
Should I let the v4l2oject query the h265 tier or just remove the tier from the src negotiation caps?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2023v4l2 can't neotigate with HDR colorimetry2023-02-28T03:15:02ZRandy Liv4l2 can't neotigate with HDR colorimetry### Describe your issue
The colorimetry in v4l2 videodec sink caps doesn't contain HDR one.
#### Expected Behavior
v4l2object should try to enumerate such colorimetry.
#### Observed Behavior
colorimetry=(string){ bt709, bt601, smpte240...### Describe your issue
The colorimetry in v4l2 videodec sink caps doesn't contain HDR one.
#### Expected Behavior
v4l2object should try to enumerate such colorimetry.
#### Observed Behavior
colorimetry=(string){ bt709, bt601, smpte240m, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }
#### Setup
- **Operating System: Linux
- **Device: Computer, embedded platform
- **GStreamer Version: 464c51a78aee860aceb2319be27006c43f8f331a
- **Command line: `gst-launch-1.0 filesrc location=hevc_bt2100_pq.mp4 ! qtdemux ! h265parse ! v4l2h265dec ! fakesink`
### Steps to reproduce the bug
Just run that command above
### How reproducible is the bug?
Just run that command above
### Screenshots if relevant
```
/GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:sink: caps = video/x-h265, stream-format=(string)hvc1, alignment=(string)au, level=(strin
g)5, tier=(string)main, profile=(string)main-10, codec_data=(buffer)01022000000090000000000096f000fffdfafa00000f03a00001001940010c01ffff022000000300900000030000030096998a0240a10001003b420101022000000300900000030000030096a001e020021c4d96662a49126bc05a848804db0800001f400002ed430166937000
07270e0001312d90a2000100074401c172f66240, width=(int)3840, height=(int)2160, framerate=(fraction)24000/1001, pixel-aspect-ratio=(fraction)1/1 Redistribute latency...
0:00:00.040327920 530 0x5583dfa400 DEBUG v4l2videodec gstv4l2videodec.c:1193:gst_v4l2_video_dec_sink_getcaps:<v4l2h265dec0> Retur
ning sink caps video/x-h265, width=(int)[ 64, 4096 ], height=(int)[ 64, 2176, 2 ], framerate=(fraction){ 0/1, [ 1/1, 200/1 ] }, stream-format=(
string)byte-stream, alignment=(string)au, profile=(string){ main, main-still-picture, main-10 }, colorimetry=(string){ bt709, bt601, smpte240m,
1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true
/GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:src: caps = video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, level=(string)5, tier=(string)main, profile=(string)main-10, width=(int)3840, height=(int)2160, framerate=(fraction)24000/1001, pixel-aspect-ratio=(f
raction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)10, bit-depth-chroma=(uint)10, colorimetry=(string)bt2100-pq, parsed=(boolean)true, mastering-display-info=(string)34000:16000:13250:34500:7500:3000:15365:16450:10000000:0, content-light-level=(string)1000:100
### Solutions you have tried
```
### Related non-duplicate issues
### Additional Information
Was considered fixed in https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/commit/b87db31fbe070cd75166472f5f1dc489bb2e83a0#note_1794688https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2022v4l2: Should be using some ioctl() wrapper to handle EINTR / EAGAIN2023-02-27T20:31:58ZNicolas Dufresnev4l2: Should be using some ioctl() wrapper to handle EINTR / EAGAINSomething I've been kind of aware forever, and surprising no one has complained, is that our ioctl() calls do not handling EINT/EGAIN errors. This is often fixed with small wrappers like xiotcl. Here's the libdrm implementation as an exa...Something I've been kind of aware forever, and surprising no one has complained, is that our ioctl() calls do not handling EINT/EGAIN errors. This is often fixed with small wrappers like xiotcl. Here's the libdrm implementation as an example:
```
/**
* Call ioctl, restarting if it is interrupted
*/
drm_public int
drmIoctl(int fd, unsigned long request, void *arg)
{
int ret;
do {
ret = ioctl(fd, request, arg);
} while (ret == -1 && (errno == EINTR || errno == EAGAIN));
return ret;
}
```
I suspect one way to trigger this is to play with the signal driven leak tracer features, but to be honest, there must be very little signal driven workflow these days that aren't about terminating the process since no one have complained for over a decade.Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/64Gstreamer on .NET 7 and Xamarin.Android2023-02-27T11:44:40ZszekelymatyasGstreamer on .NET 7 and Xamarin.AndroidI'm a newbie and I'm interested in using Gstreamer Sharp on a Xamarin Android project. Do you have any idea where to start? I have already run sample codes on Windows with .NET 7. I also created an app with .NET 7 and Xamarin, and copied...I'm a newbie and I'm interested in using Gstreamer Sharp on a Xamarin Android project. Do you have any idea where to start? I have already run sample codes on Windows with .NET 7. I also created an app with .NET 7 and Xamarin, and copied the same code (no UI yet). Obviously, it threw an exception on Gst.Application.Init(): System.DllNotFoundException: 'gstreamer-1.0-0.dll'.
I know that Gstreamer can run on Android. Here are my questions:
1. Is it a viable solution?
2. If yes, how do I install it or wire it up?
3. Is there any difference between running it on an emulator and a real device?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/452Add a means to log and create an ErrorMessage at once2023-02-27T11:41:52ZFrançois LaignelAdd a means to log and create an ErrorMessage at onceWhen creating an `ErrorMessage`, it is common to also log it, which either means duplicating the message or using something like:
```rust
const ERR: &str = "loop terminated unexpectedly";
gst::error!(CAT, imp: self, "{ERR}");
...When creating an `ErrorMessage`, it is common to also log it, which either means duplicating the message or using something like:
```rust
const ERR: &str = "loop terminated unexpectedly";
gst::error!(CAT, imp: self, "{ERR}");
return Err(gst::error_msg!(gst::LibraryError::Failed, ["{ERR}"]));
```
It would be convenient to use a single macro to perform both operation at once.