gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2023-07-27T10:10:43Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/1000shmsink/shmsrc crashes if data is pushed too quickly2023-07-27T10:10:43ZKyle J. Vernyishmsink/shmsrc crashes if data is pushed too quicklyHello. I have noticed that pushing data "too quickly" to an AppSrc can cause it to crash. I am streaming extremely high bitrate 4K video which can range from 12Mbps to 120Mbps depending on my test. I feed an AppSrc with H264 RTP packets ...Hello. I have noticed that pushing data "too quickly" to an AppSrc can cause it to crash. I am streaming extremely high bitrate 4K video which can range from 12Mbps to 120Mbps depending on my test. I feed an AppSrc with H264 RTP packets that I have received in my own application. The pipeline is as follows:
appsrc ! queue2 ! shmsink
I have my application coded in C/C++. I am using a queue2 for the supposed advantage in network streams. Here are the important bits:
**Creating elements**
```
m_appsrc = gst_element_factory_make("appsrc", NULL);
m_shmQueue = gst_element_factory_make("queue2", NULL);
m_shmsink = gst_element_factory_make("shmsink", NULL);
```
**Configuring elements**
```
g_object_set(G_OBJECT(m_shmQueue), "max-size-buffers", 10000, "max-size-bytes", 0, "max-size-time", 0, "use-buffering", true, NULL );
g_object_set(G_OBJECT(m_shmsink), "socket-path", m_shmSocketPath.c_str(), "wait-for-connection", false, "sync", false, "async", false, NULL);
GstCaps * caps = gst_caps_from_string("application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96");
g_object_set(G_OBJECT(m_appsrc), "min-latency", 20000000, "is-live", true, "do-timestamp", true, "max-bytes", 20000000, "caps", caps, "format", GST_FORMAT_TIME, "block", true, NULL);
g_signal_connect (m_appsrc, "need-data", G_CALLBACK (StartFeed), &g_sourceid);
g_signal_connect (m_appsrc, "enough-data", G_CALLBACK (StopFeed), &g_sourceid);
```
**Building Pipeline**
```
gst_bin_add_many(GST_BIN(m_pipeline), m_appsrc, m_shmQueue, m_shmsink, NULL);
if (gst_element_link_many(m_appsrc, m_shmQueue, m_shmsink, NULL) != true) {
LOG_ERROR(subprocess) << "Elements could not be linked";
return -1;
}
gst_element_set_state (m_pipeline, GST_STATE_PLAYING);
```
I spawn a thread which pulls RTP packets from my application's `boost::circular_buffer<std::vector<uint8_t>>`. Each buffer in the circular buffer is a single RTP packet. I am 100% confident these packets are well formatted (in fact, they are generated by GStreamer). Here is the `PushData` thread.
```
PushData()
{
GstBuffer *buffer;
GstFlowReturn ret;
GstMapInfo map;
static const boost::posix_time::time_duration timeout(boost::posix_time::milliseconds(250));
static GstClockTime duration = 33333333; //.0333 seconds
while (m_running)
{
bool notInWaitForNewBundlesState = TryWaitForIncomingDataAvailable(timeout);
if (notInWaitForNewBundlesState) {
m_incomingQueueMutex.lock();
padded_vector_uint8_t incomingRtpFrame(std::move(m_incomingRtpPacketQueue.front()));
m_incomingRtpPacketQueue.pop_front();
m_incomingQueueMutex.unlock();
/* Create a new empty buffer */
buffer = gst_buffer_new_and_alloc(incomingRtpFrame.size());
// copy in from our local queue
gst_buffer_map(buffer, &map, GST_MAP_WRITE);
memcpy(map.data, incomingRtpFrame.data(), incomingRtpFrame.size());
/* Set its timestamp and duration */
GST_BUFFER_PTS(buffer) = gst_util_uint64_scale(m_numSamples, GST_SECOND, SAMPLE_RATE);
GST_BUFFER_DURATION(buffer) = duration;
/* Push the buffer into the appsrc */
gst_buffer_unmap(buffer, &map);
// code crashes if we get to push_buffer too quickly (too often?). Need to find a better solution. Crashes reguardless of the method used to push_buffer
boost::this_thread::sleep_for(boost::chrono::microseconds(30));
ret = gst_app_src_push_buffer((GstAppSrc *) GetAppSrc(), buffer); // takes ownership of buffer we DO NOT deref
// g_signal_emit_by_name((GstAppSrc *) GetAppSrc(), "push-buffer", buffer, &ret); // does not take ownership of buffer you must deref
// gst_buffer_unref(buffer);
if (ret != GST_FLOW_OK) {
/* We got some error */
std::cout << "WARNING: could not push data into app src. Err code: " << ret << std::endl;
continue;
}
m_numSamples += 1;
}
}
return; // get here only when shutting down
}
```
Note:
Some notes:
- The appsrc crashes regardless of the method used to push buffers (signal vs push_buffer). If the sleep command in the PushData is removed, about 1 second of video is passed to the shared memory sink before the data flow stops. With the sleep command, the code never crashes.
- I can tell the appsrc crashes because about 10 seconds after the crash my queue2 fills up and blocks as intended
- I can tell the appsrc crashes because my pipeline that picks up from the shmsink stops seeing new data
I am having a great deal of trouble debugging this issue. If I enable deep debugging (GST_DEBUG=5+) then GStreamer slows itself down such that it has the same effect as putting the sleep in the code! So I can either run the code with no debugging tools and sleep (it runs and I get no info). Or I can run the code with debugging tools and no sleep but it runs very slowly and the queue2 eventually fills up and I don't achieve my failure mode.
Some final notes
- TryWaitGetDataAvailable basically checks if my circular buffer is empty and if the enough-data signal was emitted
- The other end of the shmsink runs in a bash script and is something like
```
gst-launch-1.0 shmsrc socket-path=$shm_socket_path is-live=true do-timestamp=true ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! queue ! rtph264depay ! h264parse ! mp4mux ! filesink location=$file/$filename.mp4 -e &
```
With the sleep, the file is successfully reconstructed at the filesink. Without the sleep, the appsrc crashes and only the first second of the file is reconstructed at the filesink.
I am happy to investigate this issue more.
Thank you.
Kylehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/988Playsink: Failed to initialize colorbalance shader2023-03-02T10:14:00ZZaidan 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/gst-plugins-base/-/issues/980DeviceMonitor no longer provides device.bus_path, device.profile.name2023-07-18T10:46:22Z3snowp7imDeviceMonitor no longer provides device.bus_path, device.profile.nameI revisited an old project and found that building a `device` property value for a `pulsesrc` element no longer worked because device monitor is no longer providing the `device.bus_path` or `device.profile.name` properties on the devices...I revisited an old project and found that building a `device` property value for a `pulsesrc` element no longer worked because device monitor is no longer providing the `device.bus_path` or `device.profile.name` properties on the devices returned from `get_devices`. Is it possible to get these properties through some new method, or, are there other means of getting the same information?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/972Support DSD native2023-07-27T12:22:14Zantonio manciniSupport DSD nativeHi,
there is no work on native DSD support?
It seems that someone did, successfully...
`[root@homepc tmp]# gst-typefind-1.0 /tmp/2L-45_stereo_01_DSF_2822k_1b.dsf
/tmp/2L-45_stereo_01_DSF_2822k_1b.dsf - audio/x-dsf`
```
[root@homepc...Hi,
there is no work on native DSD support?
It seems that someone did, successfully...
`[root@homepc tmp]# gst-typefind-1.0 /tmp/2L-45_stereo_01_DSF_2822k_1b.dsf
/tmp/2L-45_stereo_01_DSF_2822k_1b.dsf - audio/x-dsf`
```
[root@homepc tmp]# gst-inspect-1.0 | grep dsd
pcm2dsd128: pcm2dsd128: PCM to DSD Converter
pcm2dsd: pcm2dsd: PCM to DSD Converter
audiopcm2dsdbin: audiopcm2dsdbin: AudioPCM2DSDBin
pcm2dsd64: pcm2dsd64: PCM to DSD Converter
pcm2dsd256: pcm2dsd256: PCM to DSD Converter
audiopcm2dsd: audiopcm2dsd: AudioPCM2DSD
libav: avdec_dsd_msbf_planar: libav DSD (Direct Stream Digital), most significant bit first, planar decoder
libav: avdec_dsd_lsbf_planar: libav DSD (Direct Stream Digital), least significant bit first, planar decoder
libav: avdec_dsd_msbf: libav DSD (Direct Stream Digital), most significant bit first decoder
libav: avdec_dsd_lsbf: libav DSD (Direct Stream Digital), least significant bit first decoder
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/944"tee" causes green bar at bottom of video (Y out of sync with UV)2021-10-12T18:02:06Zlegerde2"tee" causes green bar at bottom of video (Y out of sync with UV)I want to send video to a display port and an H.265 encoder. Everything works with the exception of a green bar. The green bar is showing that the Y and UV channels are out of sync. I have circled the easy places to spot with red cir...I want to send video to a display port and an H.265 encoder. Everything works with the exception of a green bar. The green bar is showing that the Y and UV channels are out of sync. I have circled the easy places to spot with red circles.
![green_bar](/uploads/3e570c47ff279cb0acd307841a380888/green_bar.png)
My pipline is as follows.
![pipeline](/uploads/88d5b3d522ed3ce48b92f1a3eccabfed/pipeline.png)
My gstreamer command that causes the **green bar** is as follows:
`gst-launch-1.0 v4l2src io-mode=4 \`
` ! video/x-raw,format=NV16_10LE32,width=1920,height=1080,framerate=60/1 \`
` ! tee name=t \`
` t. ! queue \`
` ! kmssink bus-id="fd4a0000.zynqmp-display" plane-id=39 sync=false fullscreen-overlay=true driver-name=xlnx \`
` t. ! queue \`
` ! omxh265enc num-slices=8 control-rate=variable target-bitrate=2000 max-bitrate=3000 \`
` ! video/x-h265, alignment=nal \`
` ! h265parse \`
` ! perf \`
` ! rtph265pay config-interval=1 pt=96 \`
` ! udpsink host=192.168.168.100 port=5000`
The following gstreamer command **without a "tee" works** and does not have a green bar:
`gst-launch-1.0 v4l2src io-mode=4 \`
` ! video/x-raw,format=NV16_10LE32,width=1920,height=1080,framerate=60/1 \`
` ! omxh265enc num-slices=8 control-rate=variable target-bitrate=2000 max-bitrate=3000 \`
` ! video/x-h265 \`
` ! perf \`
` ! h265parse \`
` ! rtph265pay config-interval=1 pt=96 \`
` ! udpsink host=192.168.168.100 port=5000`
I believe the following warning is relevant:
**WARN** omxvideoenc gstomxvideoenc.c:2874:gst_omx_video_enc_configure_input_buffer:<omxh265enc-omxh265enc0> input buffer doesn't provide video meta, can't adjust stride and slice height
How can I fix the unaligned Y / UV?
I appreciate any ideas or help in resolving this. (I tried hard to format this for clarity. :) )https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/917parsebin: use chain after free2023-06-09T14:59:55ZSirius Wuparsebin: use chain after freeA use-after-free bug of parsebin occurs if playbin3 is set to NONE a few seconds after it is set to PLAYING. I'm using 1.16 on Android to play an mp4 video.
The following log shows that `connect_pad` executed by thread 0x7f5a5430 (tid ...A use-after-free bug of parsebin occurs if playbin3 is set to NONE a few seconds after it is set to PLAYING. I'm using 1.16 on Android to play an mp4 video.
The following log shows that `connect_pad` executed by thread 0x7f5a5430 (tid 3036) try to lock the chain 0x808fed90 after the chain 0x808fed90 was freed by thread 0x81a24520 (tid 2245).
```
06-28 04:54:37.004 2075 3036 D GStreamer+parsebin: 0:05:46.479062582 0x7f5a5430 ../gst/playback/gstparsebin.c:2855:gst_parse_chain_new:<parsebin40> Creating new chain 0x808fed90 with parent group 0x8ff272b0
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.484662874 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.484768749 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locked chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.010 2075 2245 D GStreamer+parsebin: 0:05:46.484866457 0x81a24520 ../gst/playback/gstparsebin.c:2681:gst_parse_chain_free_internal:<parsebin40> Hiding chain 0x808fed90
06-28 04:54:37.010 2075 2245 D GStreamer+parsebin: 0:05:46.484979624 0x81a24520 ../gst/playback/gstparsebin.c:2811:gst_parse_chain_free_internal:<parsebin40> Hidden chain 0x808fed90
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.485093957 0x81a24520 ../gst/playback/gstparsebin.c:2812:gst_parse_chain_free_internal:<parsebin40> unlocking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.018 2075 3036 D GStreamer+parsebin: 0:05:46.492812332 0x7f5a5430 ../gst/playback/gstparsebin.c:1751:connect_pad:<parsebin40> pad qtdemux37:video_0 , chain:0x808fed90, 2 factories, caps video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3, profile=(string)high, codec_data=(buffer)0164001effe1001c6764001eacd940b43dbff0020001b100000303e90000ea600f162d9601000668ebe3cb22c0, width=(int)720, height=(int)480, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)32/27
06-28 04:54:37.019 2075 2245 V GStreamer+parsebin: 0:05:46.494063874 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.019 2075 2245 V GStreamer+parsebin: 0:05:46.494214082 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locked chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.020 2075 2245 D GStreamer+parsebin: 0:05:46.494361957 0x81a24520 ../gst/playback/gstparsebin.c:2681:gst_parse_chain_free_internal:<parsebin40> Freeing chain 0x808fed90
06-28 04:54:37.020 2075 2245 D GStreamer+parsebin: 0:05:46.494531416 0x81a24520 ../gst/playback/gstparsebin.c:2811:gst_parse_chain_free_internal:<parsebin40> Freed chain 0x808fed90
06-28 04:54:37.020 2075 2245 V GStreamer+parsebin: 0:05:46.494663249 0x81a24520 ../gst/playback/gstparsebin.c:2812:gst_parse_chain_free_internal:<parsebin40> unlocking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.023 2075 3036 V GStreamer+parsebin: 0:05:46.498147791 0x7f5a5430 ../gst/playback/gstparsebin.c:1839:connect_pad locking chain 0x808fed90 from thread 0x7f5a5430
```
The following are the backtraces of thread 0x7f5a5430 (tid 3036) and thread 0x81a24520 (tid 2245). Where should I put `CHAIN_MUTEX_LOCK(chain)` to fix this issue? Attached file is a more complete log after function `pad_added_cb` was called, which results in the `connect_pad` call.[use-after-free.log](/uploads/3dc99fa785a2823a36fb32638b52a9b5/use-after-free.log)
```
Thread 0x7f5a5430
Thread 106 (Thread 2075.3036):
#0 0xb18173f4 in syscall () from target:/system/lib/libc.so
#1 0xb1847560 in __pthread_mutex_lock_with_timeout(pthread_mutex_internal_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0x837fb26a in g_mutex_lock (mutex=0x808fed98) at ../glib/gthread-posix.c:214
#3 0x835231ba in connect_pad (parsebin=<optimized out>, src=<optimized out>, parsepad=<optimized out>, pad=<optimized out>, caps=<optimized out>, factories=<optimized out>, chain=<optimized out>, deadend_details=<optimized out>) at ../gst/playback/gstparsebin.c:1839
#4 analyze_new_pad (parsebin=<optimized out>, src=<optimized out>, pad=0x80868e40, caps=0x80830918, chain=<optimized out>) at ../gst/playback/gstparsebin.c:1498
#5 0x8352586e in pad_added_cb (element=0x8e2c5ad0, pad=<optimized out>, chain=<optimized out>) at ../gst/playback/gstparsebin.c:2459
#6 0x837b0acc in ffi_call_SYSV () from target:/data/app/com.karaokeui-2/lib/arm/libgstreamer_android.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
```
Thread 96 (Thread 2075.2245):
#0 0xb18173f4 in syscall () from target:/system/lib/libc.so
#1 0xb1847560 in __pthread_mutex_lock_with_timeout(pthread_mutex_internal_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0x83742ae8 in gst_pad_stop_task (pad=0x80026ea8) at ../gst/gstpad.c:6306
#3 0x8373970a in activate_mode_internal (pad=0x80026ea8, parent=0x8e2c5ad0, mode=<optimized out>, active=<optimized out>) at ../gst/gstpad.c:1217
#4 0x83739250 in gst_pad_set_active (pad=0x80026ea8, active=0) at ../gst/gstpad.c:1115
#5 0x83727854 in activate_pads (vpad=<optimized out>, ret=0x8d80a148, active=0x8d80a198) at ../gst/gstelement.c:3062
#6 0x837324da in gst_iterator_fold (it=0x8b4e74a8, func=0x8372783d <activate_pads>, ret=0x8d80a148, user_data=0x8d80a198) at ../gst/gstiterator.c:617
#7 0x8372780a in iterator_activate_fold_with_resync (iter=0x8b4e74a8, func=<optimized out>, user_data=0x8d80a198) at ../gst/gstelement.c:3086
#8 0x83727652 in gst_element_pads_activate (element=0x8e2c5ad0, active=<optimized out>) at ../gst/gstelement.c:3131
#9 0x837261d2 in gst_element_change_state_func (element=0x8e2c5ad0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3196
#10 0x8347057c in gst_qtdemux_change_state (element=0x8e2c5ad0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/isomp4/qtdemux.c:2761
#11 0x83724d12 in gst_element_change_state (element=0x8e2c5ad0, transition=<optimized out>) at ../gst/gstelement.c:2974
#12 0x837265d4 in gst_element_set_state_func (element=0x8e2c5ad0, state=GST_STATE_NULL) at ../gst/gstelement.c:2928
#13 0x835277ac in gst_parse_chain_free_internal (chain=0x8b4e76d8, hide=<optimized out>) at ../gst/playback/gstparsebin.c:2817
#14 0x8352915c in gst_parse_chain_free (chain=0x8b4e76d8) at ../gst/playback/gstparsebin.c:2838
#15 gst_parse_bin_change_state (element=0x7fa75e10, transition=<optimized out>) at ../gst/playback/gstparsebin.c:4342
#16 0x83724d12 in gst_element_change_state (element=0x7fa75e10, transition=<optimized out>) at ../gst/gstelement.c:2974
#17 0x837265d4 in gst_element_set_state_func (element=0x7fa75e10, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#18 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#19 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#20 0x8350fa2a in gst_decodebin3_change_state (element=0x8e53f338, transition=<optimized out>) at ../gst/playback/gstdecodebin3.c:2876
#21 0x83724d12 in gst_element_change_state (element=0x8e53f338, transition=<optimized out>) at ../gst/gstelement.c:2974
#22 0x837265d4 in gst_element_set_state_func (element=0x8e53f338, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#23 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#24 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#25 0x8351beb6 in gst_uri_decode_bin3_change_state (element=0x8e53f1a0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gsturidecodebin3.c:1054
#26 0x83724d12 in gst_element_change_state (element=0x8e53f1a0, transition=<optimized out>) at ../gst/gstelement.c:2974
#27 0x837265d4 in gst_element_set_state_func (element=0x8e53f1a0, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#28 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#29 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#30 0x834e9740 in gst_play_bin3_change_state (element=0x8b4e2040, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gstplaybin3.c:4944
#31 0x83724d12 in gst_element_change_state (element=0x8b4e2040, transition=<optimized out>) at ../gst/gstelement.c:2974
#32 0x837265d4 in gst_element_set_state_func (element=0x8b4e2040, state=GST_STATE_NULL) at ../gst/gstelement.c:2928
#33 0x88125e30 in set_uri (player=0x81a0c800, uri=0x7cbca960 "file:///data/user/0/com.karaokeui/files/broadcast/20201030_3.mp4") at jni/inul.c:780
#34 0x8812a550 in dispatch (action=0x7cb83380, player=0x81a0c800) at jni/actions.c:11
#35 0x837e51a8 in g_thread_pool_thread_proxy (data=0x82461a68) at ../glib/gthreadpool.c:307
#36 0x837e4600 in g_thread_proxy (data=0x81a24520) at ../glib/gthread.c:784
#37 0xb1846d34 in __pthread_start(void*) () from target:/system/lib/libc.so
#38 0xb1819aae in __start_thread () from target:/system/lib/libc.so
#39 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/875HDR10 CLL metadata is allowed to change2022-06-20T13:13:59ZValZapodHDR10 CLL metadata is allowed to changeContrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to cha...Contrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to change in mp4. As ffmpeg mail says (right now [last HDR metadata patches](https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3373) are being accepted):
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg108319.html
> in that some formats allow use to set it on frame,
> some on the stream, some on the container
> I notice that color data can be set per frame and per stream already
> and I don’t fully understand how these interact if converting between data in
> frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
> HEVC SEI in hvc1 format).
And this is correct. Free CTA-861-G (and now -H) standard mandate that and I quote:
> If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it
> determines that the Sink is capable of receiving that information, the Source shall send the Dynamic
> Range and Mastering InfoFrame **once per Video Field**
What that means is that it is allowed to change and display should be fast enough to change it on the fly.
In fact there is a sample from "In the Heart of the Sea" movie https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4 that utilizes that.
It can cause all kind of issues for you. mpv does support it and so does MadVR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/859glfilterapp recordgraphic example doesn't work2021-01-22T08:19:25ZAndrey Burmaginglfilterapp recordgraphic example doesn't workHello everyone.
I'm trying to use `glfilterapp` gl-plugin to draw on the videostream.
For this I try to run this example:
`https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/recordgraphic/main.cpp`
Bu...Hello everyone.
I'm trying to use `glfilterapp` gl-plugin to draw on the videostream.
For this I try to run this example:
`https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/recordgraphic/main.cpp`
But here I get a link error.
Anyway, if I get rid of the caps filtering and put only `glimagesink` after `glfilterapp` and `gltestsrc` before it, I run into black screen.
Also if I don't pass a draw-callback into `glfilterapp`, videostream flows just fine.
I can't use `glimagesink` for drawing, like here:
https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/cube/main.cpp
Because I just need to draw on the video without displaying it immediately.
So, could you please explain me how to change this example in order to draw something using `glfilterapp`?
My GStreamer version is 1.16.2.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/762gtkglsink: resize video widget causes SIGSEGV on Xwayland2020-05-31T09:29:06ZRussel Windergtkglsink: resize video widget causes SIGSEGV on XwaylandThe evidence comes from using Me TV (a DVB desktop application, https://github.com/Me-TV/Me-TV) on a fully up-to-date Debian Sid laptop. When running on Xorg there appears to be no problem. However when running on Xwayland using OpenGL a...The evidence comes from using Me TV (a DVB desktop application, https://github.com/Me-TV/Me-TV) on a fully up-to-date Debian Sid laptop. When running on Xorg there appears to be no problem. However when running on Xwayland using OpenGL any attempt to resize the video display window causes a SIGSEGV – this happens on every attempt at resize so is reproducible and consistent. There is no problem not using OpenGL.
Running Me TV from CLion, the stack trace (for thread 17 of 36) reports the SIGSEGV to have happened three anonymous function calls from a call to gst_gl_memory_copy_teximage.
* xwayland: 2:1.20.8-2
* libgl1-mesa-dri: 20.0.7
* libglx-mesa0: 20.0.7
The device driver appears to be i915 from the libgl1-mesa-dri package.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/755Issue Raspberry 4-64 + Mesa VC4 driver + Gstreamer = red Label on video2020-05-21T13:14:27ZehyoussefIssue Raspberry 4-64 + Mesa VC4 driver + Gstreamer = red Label on videoI Build an image with Mesa VC4 driver, weston and Webkit (wpebackend-fdo) on Wayland for Raspberry pi 4-64 i have an issue with playing video i have a red layer on video with Gstreamer.
when i play the video with Gstreamer the red label...I Build an image with Mesa VC4 driver, weston and Webkit (wpebackend-fdo) on Wayland for Raspberry pi 4-64 i have an issue with playing video i have a red layer on video with Gstreamer.
when i play the video with Gstreamer the red label on video exist
==>exp : gst-play-1.0 --videosink glimagesink simpson.mp4
![imFalse](/uploads/e6ffee07fd1952b93cdb3093e861b0e2/imFalse.jpg).
But when i play the video with Gstreamer and change "glimagesink" with "waylandsink" it work perfectly.
==>exp :gst-play-1.0 --videosink waylandsink simpson.mp4
![imTrue](/uploads/4c8f60ffedbd526193ae1e477623aa5c/imTrue.jpg)
#gst-inspect-1.0 --version :
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origin
#Weston Version 8.0.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/727HDR: MDCV and CLL should not be exposed as a caps2022-06-20T13:21:47ZStéphane Cerveauscerveau@igalia.comHDR: MDCV and CLL should not be exposed as a capsIn the case of HDR10+ dynamic meta (see #700), the GOPs or scene can change MDCV and CLL values during the stream playback.
A GstVideoMeta approach should be considered instead of caps.
Only the type of HDR (HDR10, HDR10+, DolbyVision...In the case of HDR10+ dynamic meta (see #700), the GOPs or scene can change MDCV and CLL values during the stream playback.
A GstVideoMeta approach should be considered instead of caps.
Only the type of HDR (HDR10, HDR10+, DolbyVision) should be exposed by caps allowing downstream element to adapt and optimize data retrieval.Stéphane Cerveauscerveau@igalia.comStéphane Cerveauscerveau@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/699pbutils: Basic-tutorial-7 crashes2019-12-05T03:44:56ZSirius Wupbutils: Basic-tutorial-7 crashesI'm using Ubuntu 18.04. The following command crash.
```
cargo run --bin basic-tutorial-7
```
It crashed:
```
Obtained request pad src_0 for audio branch
Obtained request pad src_1 for video branch
Segmentation fault (core dumped)
```...I'm using Ubuntu 18.04. The following command crash.
```
cargo run --bin basic-tutorial-7
```
It crashed:
```
Obtained request pad src_0 for audio branch
Obtained request pad src_1 for video branch
Segmentation fault (core dumped)
```
I examine the binary with core dump:
```
gdb target/debug/basic-tutorial-7 ./tutorials/core
```
Although I got some backtrace, but I do not know how to continue from here, any suggestion?
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memset_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:188
188 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory.
[Current thread is 1 (Thread 0x7f3d26b1e700 (LWP 32416))]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /media/ccwu/e7458cf5-858e-4184-afc4-73301087e303/home/alvin/mapacode/git/gstreamer-rs/target/debug/basic-tutorial-7.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) l
183 in ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S
(gdb) backtrace
#0 0x00007f3d4cc7c930 in __memset_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:188
#1 0x00007f3d4a53fd27 in () at /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0
#2 0x00007f3d4ddd688b in () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#3 0x00007f3d4dddebb3 in gst_pad_push () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#4 0x00007f3d4b1acba9 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#5 0x00007f3d4de0b269 in () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#6 0x00007f3d4d869b60 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f3d4d869195 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007f3d4d1d16db in start_thread (arg=0x7f3d26b1e700) at pthread_create.c:463
#9 0x00007f3d4cce288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/670UriDecodeBin fails to use giosrc for dav URIs2022-05-04T05:29:40ZIñigo IllanUriDecodeBin fails to use giosrc for dav URIsI have been trying to reproduce videos from a dav server but uridecodebin doesn't seem to know how to handle dav resources.
More specifically, if I try running:
`gst-launch-1.0 -v playbin3 uri="dav://....mp4"`
I get the following erro...I have been trying to reproduce videos from a dav server but uridecodebin doesn't seem to know how to handle dav resources.
More specifically, if I try running:
`gst-launch-1.0 -v playbin3 uri="dav://....mp4"`
I get the following error:
```
Missing element: DAV protocol source
ERROR: from element /GstURISourceBin:urisourcebin0: No URI handler implemented for "dav".
Additional debug info:
gsturisourcebin.c(1521): gen_source_element (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0
```
I have giosrc installed and I can run `gst-launch-1.0 -v giosrc location="dav://....mp4" ! fakesink` perfectly fine
- Operating System: Ubuntu 19.10 (Beta)
- Gstreamer version: 1.16.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/668Ethernet camera performance significantly degraded in version 1.142019-09-19T08:53:17ZGrant BurkhartEthernet camera performance significantly degraded in version 1.14I have a simple pipeline to display an ethernet camera using the NXP IMX6d chip. In Gstreamer version 1.8.3, the video is nice and smooth. But in version 1.14, the video becomes very jerky.
Of course the pipeline is in code but in a gst...I have a simple pipeline to display an ethernet camera using the NXP IMX6d chip. In Gstreamer version 1.8.3, the video is nice and smooth. But in version 1.14, the video becomes very jerky.
Of course the pipeline is in code but in a gst-launch command line, it would be `udpsrc port=<port_num> ! application/x-rtp media=video,clock-rate=90000,encoding-name=H264,payload=96 ! rtph264depay ! h264parse ! imxvpudec ! imxipuvideosink framebuffer=<device_name>`.
To isolate the problem I inserted a bufferprobe on each source pad and found that on the src pad of the decoder I was getting the correct 30 frames/second in 1.8.3, but in 1.14 I am only getting around 9 frames per second.
After a bunch of tests, I was able to isolate the change that caused the difference in behavior: https://gitlab.freedesktop.org/bilboed/gst-plugins-base/commit/8bee96c4a2a377e325fb59c6535fee3767096307.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/644Having Compilation error on video-format.c for video_orc_unpack_VUYA and vide...2019-10-17T01:13:40ZLim Siew HoonHaving Compilation error on video-format.c for video_orc_unpack_VUYA and video_orc_pack_VYUYI'm having a compilation error in master branch:
Build command: `./autogen.sh --prefix=/usr --libdir=/usr/lib --disable-gtk-doc`
Here is the output error message:
```
gcc -DNDEBUG -g -O3 -Wall -g -O2 -fPIC -I/home/root/Gst_framework/gs...I'm having a compilation error in master branch:
Build command: `./autogen.sh --prefix=/usr --libdir=/usr/lib --disable-gtk-doc`
Here is the output error message:
```
gcc -DNDEBUG -g -O3 -Wall -g -O2 -fPIC -I/home/root/Gst_framework/gst-plugins-base/gst-libs -I/home/root/Gst_framework/gst-plugins-base/gst-libs -I/usr/include/gstreamer-1.0 -I/usr/lib/libffi-3.2.1/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -I/usr/include/gstreamer-1.0 -I/usr/lib/libffi-3.2.1/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c /home/root/Gst_framework/gst-plugins-base/gst-libs/gst/app/tmp-introspectw0c3nmvw/GstApp-1.0.c -o /home/root/Gst_framework/gst-plugins-base/gst-libs/gst/app/tmp-introspectw0c3nmvw/GstApp-1.0.o -Wno-deprecated-declarations -pthread
CC libgstfft_1.0_la-kiss_fftr_s16.lo
video-format.c: In function 'unpack_VUYA':
video-format.c:5266:3: error: implicit declaration of function 'video_orc_unpack_VUYA'; did you mean 'video_orc_unpack_VYUY'? [-Werror=implicit-function-declaration]
video_orc_unpack_VUYA (d, s, width);
^~~~~~~~~~~~~~~~~~~~~
video_orc_unpack_VYUY
video-format.c:5266:3: error: nested extern declaration of 'video_orc_unpack_VUYA' [-Werror=nested-externs]
video-format.c: In function 'pack_VUYA':
video-format.c:5278:3: error: implicit declaration of function 'video_orc_pack_VUYA'; did you mean 'video_orc_pack_VYUY'? [-Werror=implicit-function-declaration]
video_orc_pack_VUYA (d, s, width);
^~~~~~~~~~~~~~~~~~~
video_orc_pack_VYUY
video-format.c:5278:3: error: nested extern declaration of 'video_orc_pack_VUYA' [-Werror=nested-externs]
CC libgstfft_1.0_la-kiss_fftr_s32.lo
g-ir-scanner: link: /bin/sh ../../../libtool --mode=link --tag=CC gcc -o /home/root/Gst_framework/gst-plugins-base/gst-libs/gst/app/tmp-introspectw0c3nmvw/GstApp-1.0
```
After I added #include "video-orc-dist.h" in video-format.c file, I managed to compile successful.
It is missing header file that define for video_orc_pack_VUYA and video_orc_unpack_VUYA function.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/596glbasefilter: gst_gl_base_filter_gl_start() tries to use a NULL context2020-11-03T05:37:00ZGuillaume Desmottesglbasefilter: gst_gl_base_filter_gl_start() tries to use a NULL contextMy app is quickly creating and destroying `playbin` pipelines which are using `gtkglsink` and `glsinkbin` as video sink. This is a bug on my side but by doing so I raised a crash in `glbasefilter`.
```
#0 0x00007f6dab4678bb in gst_gl_i...My app is quickly creating and destroying `playbin` pipelines which are using `gtkglsink` and `glsinkbin` as video sink. This is a bug on my side but by doing so I raised a crash in `glbasefilter`.
```
#0 0x00007f6dab4678bb in gst_gl_insert_debug_marker (context=0x0, format=format@entry=0x7f6dab492e52 "starting element %s") at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstgldebug.c:387
#1 0x00007f6dab45c3d6 in gst_gl_base_filter_gl_start (context=<optimized out>, data=<optimized out>) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglbasefilter.c:283
#2 0x00007f6dab4839f3 in _run_message_sync (message=0x7f6d92172470) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:573
#3 0x00007f6dab483992 in _run_message_async (message=0x564e9b769060) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:640
#4 0x00007f6dc14e197b in () at /lib64/libglib-2.0.so.0
#5 0x00007f6dc14e506d in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#6 0x00007f6dc14e5438 in () at /lib64/libglib-2.0.so.0
#7 0x00007f6dc14e5762 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#8 0x00007f6dab483a75 in gst_gl_window_default_run (window=0x564e9b917d80) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglwindow.c:499
#9 0x00007f6dab466d10 in gst_gl_context_create_thread (context=0x7f6dac007af0) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglcontext.c:1305
#10 0x00007f6dc150e2aa in () at /lib64/libglib-2.0.so.0
#11 0x00007f6dc121458e in start_thread () at /lib64/libpthread.so.0
#12 0x00007f6dc1128683 in clone () at /lib64/libc.so.6
```
As you can see when `gst_gl_base_filter_gl_start` is called as a callback `filter->context` is `NULL`.
I checked and `gst_gl_base_filter_reset` is called between the `gst_gl_context_thread_add` and the callback.
The obvious fix would to early return in `context` is `NULL` but I'm not familiar enough with gl threading system so I'm not sure if that's the proper way to fix this.
I suspect `gst_gl_base_filter_gl_stop` may suffer the same bug. Especially as `context` is set to `NULL` right after invoking it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/571Rendering Support for CEA 608 Closed Captions2020-06-09T12:41:27ZAaron BoxerRendering Support for CEA 608 Closed CaptionsUse https://github.com/szatmary/libcaption (MIT License) to extract 608 text and control commands.
Test file and pipeline can be found in #553Use https://github.com/szatmary/libcaption (MIT License) to extract 608 text and control commands.
Test file and pipeline can be found in #553https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/543GL hangs after acc098a736949d465d7f77e5de94a75627209147 on newer amd GCN cards2019-06-13T14:01:52ZJordan PetridіsGL hangs after acc098a736949d465d7f77e5de94a75627209147 on newer amd GCN cardsAfter acc098a736949d465d7f77e5de94a75627209147 when I run the `check-gst-pugins-base.pipeleines_gl*` tests it hangs the machine. ssh and Pulseaudio are still responsive and it looks like its the graphics driver that has hang up.
Revert...After acc098a736949d465d7f77e5de94a75627209147 when I run the `check-gst-pugins-base.pipeleines_gl*` tests it hangs the machine. ssh and Pulseaudio are still responsive and it looks like its the graphics driver that has hang up.
Reverting the commit makes the hangs go away. This specific machine is a raven ridge apu with the amdgpu driver so it possible that its just a dirver bug since the hw and driver are quite new. The configuration tested is Fedora 29 with kenrel 4.19.14 and mesa 18.2.8.
```
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c3) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 3801
Flags: bus master, fast devsel, latency 0, IRQ 71
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at d0000000 (64-bit, prefetchable) [size=2M]
I/O ports at 1000 [size=256]
Memory at d0600000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
Kernel driver in use: amdgpu
Kernel modules: amdgpu
```
I asked @slomo to try and reproduce the hang, but was not able to do so with an igpu with the `i965` driver. I will try to troubleshoot further in the coming days.
To reproduce:
```sh
# clone gst-build or from an existing checkout
meson build && ninja -C build
./gst-uninstalled.py gst-validate-launcher check.gst-plugins-base.pipelines_gl* -fs --mute --dump-on-failure --no-display --meson-no-rebuild
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/537There is a problem with the `gstreamer-pbutils-1.0.pc` file2019-05-01T17:33:10ZDavid IngThere is a problem with the `gstreamer-pbutils-1.0.pc` fileWhat it has:
```text
Requires: gstreamer-1.0
```
What it **should** have:
```text
Requires: gstreamer-1.0 gstreamer-audio-1.0 gstreamer-tag-1.0
```
I am building `1.14.4` in a properly isolated environment which has no pr...What it has:
```text
Requires: gstreamer-1.0
```
What it **should** have:
```text
Requires: gstreamer-1.0 gstreamer-audio-1.0 gstreamer-tag-1.0
```
I am building `1.14.4` in a properly isolated environment which has no prior gstreamer packages installed whatsoever (I used an `ubuntu:18.04` docker container). The change to the pkg-config file (described above) was necessary to get rid of an error (shown below) during the build of `gst-editing-services`:
```text
FAILED: tools/ges-launch-1.0
cc -o tools/ges-launch-1.0 'tools/f9d35d4@@ges-launch-1.0@exe/ges-validate.c.o' 'tools/f9d35d4@@ges-launch-1.0@exe/ges-launch.c.o' 'tools/f9d35d4@@ges-launch-1.0@exe/ges-launcher.c.o' 'tools/f9d35d4@@ges-launch-1.0@exe/utils.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group ges/libges-1.0.so.0.1404.0 /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstreamer-1.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstbase-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstvideo-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstcontroller-1.0.so /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libxml2.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../ges' -Wl,-rpath-link,/home/default_user/.conan/data/gst-editing-services/1.14.4/my_conan_user/my_conan_channel/build/366aad263bfda46cc558dc04848127644df385d3/build/ges
/usr/bin/ld: warning: libgstaudio-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgsttag-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_channel_get_fallback_mask'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_init'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_from_string'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_from_caps'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_get_info'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_tag_list_to_vorbiscomment_buffer'
collect2: error: ld returned 1 exit status
[94/192] Linking target tests/check/ges_backgroundsource.
FAILED: tests/check/ges_backgroundsource
cc -o tests/check/ges_backgroundsource 'tests/check/7d01337@@ges_backgroundsource@exe/ges_backgroundsource.c.o' 'tests/check/7d01337@@ges_backgroundsource@exe/ges_test-utils.c.o' 'tests/check/7d01337@@ges_backgroundsource@exe/nle_common.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group ges/libges-1.0.so.0.1404.0 /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstreamer-1.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstbase-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstvideo-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstcontroller-1.0.so /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libxml2.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstcheck-1.0.so -lm -Wl,--end-group '-Wl,-rpath,$ORIGIN/../../ges' -Wl,-rpath-link,/home/default_user/.conan/data/gst-editing-services/1.14.4/my_conan_user/my_conan_channel/build/366aad263bfda46cc558dc04848127644df385d3/build/ges
/usr/bin/ld: warning: libgstaudio-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgsttag-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_channel_get_fallback_mask'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_init'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_from_string'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_from_caps'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_get_info'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_tag_list_to_vorbiscomment_buffer'
collect2: error: ld returned 1 exit status
[95/192] Linking target tests/check/ges_asset.
FAILED: tests/check/ges_asset
cc -o tests/check/ges_asset 'tests/check/7d01337@@ges_asset@exe/ges_asset.c.o' 'tests/check/7d01337@@ges_asset@exe/ges_test-utils.c.o' 'tests/check/7d01337@@ges_asset@exe/nle_common.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group ges/libges-1.0.so.0.1404.0 /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstreamer-1.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstbase-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstvideo-1.0.so /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstcontroller-1.0.so /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libxml2.so /home/default_user/.conan/data/gstreamer/1.14.4/my_conan_user/my_conan_channel/package/4e54a2085b064ce4acf33d77f8e46b7ddb19327e/lib/libgstcheck-1.0.so -lm -Wl,--end-group '-Wl,-rpath,$ORIGIN/../../ges' -Wl,-rpath-link,/home/default_user/.conan/data/gst-editing-services/1.14.4/my_conan_user/my_conan_channel/build/366aad263bfda46cc558dc04848127644df385d3/build/ges
/usr/bin/ld: warning: libgstaudio-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgsttag-1.0.so.0, needed by /home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so, not found (try using -rpath or -rpath-link)
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_channel_get_fallback_mask'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_init'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_from_string'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_info_from_caps'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_audio_format_get_info'
/home/default_user/.conan/data/gst-plugins-base/1.14.4/my_conan_user/my_conan_channel/package/dfae0ad53239c3635b1bcbc0d33fb8115366adef/lib/libgstpbutils-1.0.so: undefined reference to `gst_tag_list_to_vorbiscomment_buffer'
collect2: error: ld returned 1 exit status
[97/192] Compiling C object 'tests/check/7d01337@@ges_layer@exe/ges_layer.c.o'.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/523videoconvert: Add fastpath for RGB -> I4202018-12-20T15:42:45ZBenjamin Bergvideoconvert: Add fastpath for RGB -> I420The openh264enc only takes I420 as input format. Unfortunately, the conversion of RGB to I420 seemingly causes a higher CPU load than the openh264enc encoder does. That seems out of proportion.
Maybe it is possible to improve this a lot...The openh264enc only takes I420 as input format. Unfortunately, the conversion of RGB to I420 seemingly causes a higher CPU load than the openh264enc encoder does. That seems out of proportion.
Maybe it is possible to improve this a lot even with an intermediate conversion.