gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2024-03-28T09:21:55Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1042qml6glsink: impossible to render in parallel into 2 (or more) qml6glsinks2024-03-28T09:21:55ZRobert Guziolowskiqml6glsink: impossible to render in parallel into 2 (or more) qml6glsinksCreate a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the ...Create a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the .qml file (in the test application the _snow_ pattern.
**Expected behavior**
Two streams shown independently (_snow_ and _smpte_ patterns).
**Suggested correction**
I found the correction (in my case) for this problem changing the code of the destructor of GstQSGTexture (gstqsg6material.cc file) from
`delete m_texture;`
to
`m_texture->deleteLater();`
Edit: [merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6467) ready.
~~I'll create a merge request soon.~~
[CMakeLists.txt](/uploads/205dbecbffd2f9bf6eaa2d27e699ed7b/CMakeLists.txt)
[main.cpp](/uploads/a8bc6bb2b07640b8c87e1d178e3436a2/main.cpp)
[Main.qml](/uploads/e6e90727abf79eaaae869be14d5435fb/Main.qml)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/992rollback seek RTSP2022-08-25T14:44:21ZSwingrollback seek RTSPHey,
I'm having a mysterious problem when I'm seeking.
So I'm using gstreamer 1.20.3 on Android.
I also had this problem with all other version.
Here is my custom Pipeline: "`rtspsrc name=src protocols=4 buffer-mode=1 is-live=false ...Hey,
I'm having a mysterious problem when I'm seeking.
So I'm using gstreamer 1.20.3 on Android.
I also had this problem with all other version.
Here is my custom Pipeline: "`rtspsrc name=src protocols=4 buffer-mode=1 is-live=false latency=2000 src. ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! capsfilter name=filter ! autovideosink sync=true src. ! queue ! rtpmp4gdepay ! aacparse ! avdec_aac ! audioconvert ! audioresample ! volume name=vol volume=0.00000001 ! autoaudiosink sync=false`"
To seek I use "` gst_element_seek (data->pipeline, 1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, desired_position, GST_SEEK_TYPE_SET, GST_CLOCK_TIME_NONE);`"
I have no errors from Gstreamer in the log.
I got different type of "bug"
- if my first seek in the video is to 2:01 i will go back to 0:00 and then i seek again to 3:41 i will go to 2:01 etc i will always have one seek latethe thing is that the video I received is good but only the seekbar and the timer are wrong.
- sometimes it works perfectly
- My first seek work and then we go back to the first problem
I've tried a lot of different things but I can't figure out why sometimes it works and sometimes it doesn't.
When I look with wireshark on my network, I take a look at the packet. The packet I send is good (PLAY with range) and the packet I receive is (200 OK with a good range).So it can't come from a mistake in a packet.
I put a lot of debug inside my code to see if something wasn't good, but everything was fine.
I have no more ideas.When I'm using my url on VLC it works perfectly.
Disclaimer: Yes I know that rtsp isn't made for this. But I have no other choice.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/975qtmoovrecover: wrong recover for mov with fixed audio sample rate2022-05-16T14:05:37ZVincenzo Martenaqtmoovrecover: wrong recover for mov with fixed audio sample ratethe qtmoovrecover plugin fails to correctly recover mov files with fixed audio sample rate.
attached you can find a patch containing a fix for this problem.
[0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch](/uploads/067...the qtmoovrecover plugin fails to correctly recover mov files with fixed audio sample rate.
attached you can find a patch containing a fix for this problem.
[0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch](/uploads/067717e09e05c316e6887463fcb0a251/0002-qtmoovrecover-fix-for-recoverying-mov-with-fixed-aud.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/974qtmoovrecover: vlc does not play the recovered mp42022-05-16T14:05:47ZVincenzo Martenaqtmoovrecover: vlc does not play the recovered mp4if vlc founds the sample_description_index set to 0 in the stsc atom
it refuses to play the video while other players don't.
attached you can find a patch containing a workaround for this problem.
[0001-qtmoovrecover-workaround-to-make...if vlc founds the sample_description_index set to 0 in the stsc atom
it refuses to play the video while other players don't.
attached you can find a patch containing a workaround for this problem.
[0001-qtmoovrecover-workaround-to-make-the-recovered-file-.patch](/uploads/55b93775a0cff482e10fe9041b5043fe/0001-qtmoovrecover-workaround-to-make-the-recovered-file-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/959Memory OOM when using v4l2h264enc2022-03-11T14:20:14ZBenjaminMemory OOM when using v4l2h264encI'm using the v4l2h264enc element to encode the video stream from a ADV7282-M CSI2 Video Decoder, which I'm passing via an appsrc element. In certain scenarios (e.g. disconnecting the Video Source to the Video Decoder) I encounter the is...I'm using the v4l2h264enc element to encode the video stream from a ADV7282-M CSI2 Video Decoder, which I'm passing via an appsrc element. In certain scenarios (e.g. disconnecting the Video Source to the Video Decoder) I encounter the issue that my Application runs OOM.
This starts with the encoder not outputting any data anymore and the Application taking more and more Memory. Like if a Worker Thread stops working, and it queues the Input Data till OOM.
I was able to reproduce this issue with feeding in random Data from `/dev/urandom` via an appsrc. I guess something similar happens when disconnecting the Video Source to the Video Decoder as it tries to lock to the Video Signal and outputs whatever it receives At this moment.
An example Application to reproduce this is attached to this issue.
I was able to reproduce this issue on:
- Raspberry Pi CM4 - Debian 11 - GStreamer 1.18.4 - Linux 5.15.24
- Raspberry Pi 3 - ArchLinux ARM - GStreamer 1.20.0 - Linux 5.15.27-1-rpi-ARCH
- i.MX8MM - Debian 11 - GStreamer 1.16.2 - Linux 5.17.0-rc1
Code:
```
#include <stdio.h>
#include <stdbool.h>
#include <unistd.h>
#include <gst/gst.h>
#include <gst/app/gstappsrc.h>
#include <gst/app/gstappsink.h>
#include <gst/gstbuffer.h>
#include <gst/gstmemory.h>
#ifdef __arm__
#define IMAGE_WIDTH 720
#define IMAGE_HEIGHT 576
#endif
#define VIDEO_GST_DEBUG "*:3"
GstElement *pPipeline = NULL;
GstElement *pAppSrc = NULL;
void init_pipeline()
{
if (pPipeline != NULL)
return;
unsigned int major, minor, micro, nano;
/* initialize gstreamer */
setenv("GST_DEBUG", VIDEO_GST_DEBUG, 5);
gst_init(NULL, NULL);
gst_version(&major, &minor, µ, &nano);
gst_update_registry();
printf("Gstreamer initialized. \n");
printf("Gstreamer version: %u %u %u %u \n", major, minor, micro, nano);
#ifdef __arm__
char *pipelineStr = "appsrc name=appsrc ! video/x-raw, interlace-mode=interleaved, framerate=25/1, format=UYVY, width=720, height=576 ! "
"deinterlace method=linear ! videocrop top=16 left=16 right=16 bottom=16 ! videorate ! videoscale ! "
"video/x-raw, framerate=25/1, width=640, height=480 ! videoconvert ! "
"queue ! v4l2h264enc output-io-mode=2 extra-controls=\"controls,h264_profile=0,video_bitrate=1000000,h264_i_frame_period=10,repeat_sequence_header=1;\" ! "
"video/x-h264, level=(string)3, profile=baseline, stream-format=byte-stream ! filesink location=out.h264";
pPipeline = gst_parse_launch(pipelineStr, NULL);
printf("Pipeline: %s \n", pipelineStr);
#endif
pAppSrc = gst_bin_get_by_name(GST_BIN(pPipeline), "appsrc");
// ASSERT(pAppSrc != NULL);
g_object_set(pAppSrc, "format", GST_FORMAT_TIME, NULL);
if (pPipeline == NULL)
{
printf("Failed to init pipeline \n");
exit(-1);
}
/* Start playing */
gst_element_set_state(pPipeline, GST_STATE_PLAYING);
}
FILE *myfile = NULL;
void write_gst_data(char *buffer, size_t length)
{
GstBuffer *gstbuffer;
GstFlowReturn ret;
GstMapInfo map;
/* copy frame to gst buffer */
gstbuffer = gst_buffer_new_and_alloc(length);
gst_buffer_map(gstbuffer, &map, GST_MAP_WRITE);
memcpy(map.data, buffer, length);
gst_buffer_unmap(gstbuffer, &map);
/* push data to appsrc */
ret = gst_app_src_push_buffer(GST_APP_SRC(pAppSrc), gstbuffer);
if (ret != GST_FLOW_OK)
{
printf("-EINVAL GST_FLOW! \n");
}
}
int main(int argc, char *argv[])
{
init_pipeline();
while (true)
{
char *uyvybuffer = (char *)malloc(IMAGE_WIDTH * IMAGE_HEIGHT * 2);
FILE *fp;
fp = fopen("/dev/urandom", "r");
fread(uyvybuffer, 1, IMAGE_WIDTH * IMAGE_HEIGHT * 2, fp);
fclose(fp);
write_gst_data(uyvybuffer, IMAGE_WIDTH * IMAGE_HEIGHT * 2);
free(uyvybuffer);
// 25FPS -> 40ms
usleep(40 * 1000);
}
}
```
Build:
```
gcc -g main.c -I. -o decoder `pkg-config --cflags --libs gstreamer-1.0` `pkg-config --cflags --libs gstreamer-app-1.0`
```
For reference:
https://github.com/raspberrypi/linux/issues/4906
https://forums.raspberrypi.com/viewtopic.php?p=1977561#p1977561https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/957rtpsession: receiving own RTCP packet triggers SSRC reset (multicast)2023-01-02T16:08:01ZMarc Leemanrtpsession: receiving own RTCP packet triggers SSRC reset (multicast)When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the paylo...When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the payloader.
This was detected with rtpsink, but I remember fixing this issue some time ago with using rtpsrc too.
```
0:00:34.327905772 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:3035:rtp_session_process_rtcp: received RTCP packet
0:00:34.327952247 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:2424:rtp_session_process_sr: got SR packet: SSRC 5b942eaf, time 117:48:14.735605623
0:00:34.327975166 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:1703:check_collision: Collision for SSRC 5b942eaf from new incoming packet, change our sender ssrc
0:00:34.327997084 3455462 0x7f5c6c06b520 DEBUG rtpsource rtpsource.c:1300:rtp_source_mark_bye: marking SSRC 5b942eaf as BYE, reason: SSRC Collision
0:00:34.328074452 3455462 0x7f5c6c06b520 DEBUG GST_EVENT gstevent.c:310:gst_event_new_custom: creating new event 0x7f5c600054b0 custom-upstream 69121
```
Seems to be related to this issue:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/568https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/943splitmuxsrc: pattern-matching syntax inconsistent with other "multifile" elem...2021-12-13T22:34:31ZAbleBaconsplitmuxsrc: pattern-matching syntax inconsistent with other "multifile" elementsThe `splitmuxsrc` element uses glob-style pattern matching, so like:
- `myfiles*.mp4`
Whereas other `mutlifile` elements (like `multifilesrc`) use a `printf`-style of pattern-matching:
- `myfiles%04d.mp4`
The `splitmuxsrc` element also...The `splitmuxsrc` element uses glob-style pattern matching, so like:
- `myfiles*.mp4`
Whereas other `mutlifile` elements (like `multifilesrc`) use a `printf`-style of pattern-matching:
- `myfiles%04d.mp4`
The `splitmuxsrc` element also lacks the ability of `multifilesrc` to specify start and stop indices.
Is there a reason for this inconsistency? It would be nice if `splitmuxsrc` had the same syntax and capabilities as `multifilesrc`.
And how come these elements don't allow filenames to be specified via regex via GLib's `GRegex` utilities?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/931rtspsrc: pipeline struck after few minutes of streaming when `select-stream` ...2021-10-01T17:23:30ZDeep Patelrtspsrc: pipeline struck after few minutes of streaming when `select-stream` callback is enabledversion: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-...version: 1.18.5
My callback function is as below:
```py
def select_stream_callback(self, rtspsrc, num, caps, udata):
media = caps.get_structure(0).get_value('media')
encoding = caps.get_structure(0).get_value('encoding-name')
# skip stream other than video
if media != 'video':
return False
return True
```
It is to be noted that the stream works fine if this signal is not enabled
Here is the debug logs
```log
0:04:26.241871000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241877000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241891000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241901000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241907000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241921000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.241962000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.241988000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.241997000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242012000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242035000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242046000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242248000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242286000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242298000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242385000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242398000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242414000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242440000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242488000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242497000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242512000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242535000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242545000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242560000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242583000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242592000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242607000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242639000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242654000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242728000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242740000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242756000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242780000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242789000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242805000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242828000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242837000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242853000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242876000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242886000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242900000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.242922000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.242931000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.242946000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.243039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.243052000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.243066000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
2021-10-01 17:18:14 INFO 1633108694.376356
0:04:26.533112000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533151000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533314000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533391000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533429000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533465000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533511000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533529000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533558000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533567000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533585000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533615000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533630000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533650000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533689000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533703000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533714000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 950 on channel 0
0:04:26.533745000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533760000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533773000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 1400 on channel 0
0:04:26.533799000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.533811000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.533823000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 777 on channel 0
0:04:26.673265000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:26.673296000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:26.673312000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:26.673430000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:28.069402000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:28.069475000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:30.960379000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:30.960410000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:30.960439000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:30.960504000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:32.167497000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:32.167569000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:35.578354000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:35.578386000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:35.578402000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 76 on channel 1
0:04:35.578450000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:35.716265000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 84 bytes RTCP
0:04:35.716330000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:39.466840000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:39.466873000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:39.466903000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:39.466959000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:40.946154000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:40.946293000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:44.898856000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:44.898895000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:44.898917000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:44.898968000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:45.429008000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:45.429091000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.466056000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:49.466136000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:49.743003000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:49.743039000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:49.743061000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:49.743113000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:53.399676000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:53.399758000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:04:55.208214000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:04:55.208252000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:04:55.208275000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:04:55.208325000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:04:57.821064000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:04:57.821148000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:00.858707000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:00.858746000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:00.858769000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
0:05:00.858923000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:3615:on_ssrc_active:<source> source in session 0 is active
0:05:03.120458000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3244:gst_rtspsrc_sink_chain:<source> sending 60 bytes RTCP
0:05:03.120543000 30139 0x7f8538007240 DEBUG rtspsrc gstrtspsrc.c:3247:gst_rtspsrc_sink_chain:<source> sent RTCP, 0
0:05:06.542809000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5611:gst_rtspsrc_loop_interleaved:<source> we received a server message
0:05:06.542842000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5644:gst_rtspsrc_loop_interleaved:<source> got data message
0:05:06.542866000 30139 0x7f853c005700 DEBUG rtspsrc gstrtspsrc.c:5414:gst_rtspsrc_handle_data:<source> pushing data of size 56 on channel 1
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/928souphttpsrc: session sharing2021-09-24T13:34:42ZBetacentaurisouphttpsrc: session sharingIt's regarding this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/ext/soup/gstsouphttpsrc.c#L924
Why can a session not be shared if a proxy or a custom timeout or ssl-strict is set?
Background: I try to o...It's regarding this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/ext/soup/gstsouphttpsrc.c#L924
Why can a session not be shared if a proxy or a custom timeout or ssl-strict is set?
Background: I try to open a hls stream. The http request to the master manifest returns Set-Cookie http headers. These cookies need to be added to subsequent http calls to the segment manifests.
When I set a custom timeout or a proxy or ssl-strict = false, the http session is not shared and so cookies are not used in subsequent http calls which results in a connection failure. It only works with default values for timeout, proxy and ssl-strict.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/904Demote dvdemux to marginal2021-09-24T13:34:37ZEdward HerveyDemote dvdemux to marginal`dvdemux` (and `dvdec`) both rely on libdv which hasn't been maintained in ages.
* Means it doesn't properly recognize any non-SD formats (i.e. all the DVCPro variants)
* The fact that it's not maintained means that we can't really fix/...`dvdemux` (and `dvdec`) both rely on libdv which hasn't been maintained in ages.
* Means it doesn't properly recognize any non-SD formats (i.e. all the DVCPro variants)
* The fact that it's not maintained means that we can't really fix/improve it. If ever there are any security issues that's also worrying
I propose we do like for `dvdec` and we demote the rank of `dvdemux` to marginal, and enable the gst-libav DV demuxer with a rank of SECONDARY. I've tested a few files with that demuxer and it works fine.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/895equalizer plugin doesn't seem to be controllable2021-09-24T13:34:31ZMWWorksequalizer plugin doesn't seem to be controllableTrying to attach a control source to the equalizer plugin - the source code suggests the bands values are GST_PARAM_CONTROLLABLE. I'm using python, which hopefully isn't the issue! My code works with the volume plugin:
```
gst_adjust = ...Trying to attach a control source to the equalizer plugin - the source code suggests the bands values are GST_PARAM_CONTROLLABLE. I'm using python, which hopefully isn't the issue! My code works with the volume plugin:
```
gst_adjust = Gst.ElementFactory.make("volume", "adjust")
gst_pipeline.add(gst_adjust)
gst_cs0 = GstController.InterpolationControlSource()
gst_cs0.set_property('mode', GstController.InterpolationMode.LINEAR)
gst_adjust.add_control_binding(GstController.DirectControlBinding.new(gst_adjust,"volume",gst_cs0))
print(gst_cs0.set(0.1*Gst.SECOND,0.2))
```
But not when adjusted to the 3 or 10 band equalizer (I also get a True output, but no audible effect):
```
gst_adjust = Gst.ElementFactory.make("equalizer-3bands", "adjust")
gst_pipeline.add(gst_adjust)
gst_cs0 = GstController.InterpolationControlSource()
gst_cs0.set_property('mode', GstController.InterpolationMode.LINEAR)
gst_adjust.add_control_binding(GstController.DirectControlBinding.new(gst_adjust, "band0", gst_cs0))
print(gst_cs0.set(0.1*Gst.SECOND,0.99))
```
Presetting the property prior to running the pipline works as expected, but obviously not dynamic:
`print(gst_cs0.set(0.1*Gst.SECOND,12))`
I'm not an expert so could be missing something - but it seems that the equalizer should respond to controller changes?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/894matroskademux: Attachments undetected when their size exceeds 15MB2021-10-20T08:16:35ZRafał Dzięgielmatroskademux: Attachments undetected when their size exceeds 15MB`matroskademux` element has a defined [`MAX_BLOCK_SIZE` of 15MB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/matroska/matroska-demux.c#L5311). Due to how it is handled, it...`matroskademux` element has a defined [`MAX_BLOCK_SIZE` of 15MB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/matroska/matroska-demux.c#L5311). Due to how it is handled, it unfortunately breaks attachments detection if their combined size in video exceeds that limit.
Tested on both 1.18 and 1.19 git.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/893rtph264pay: aggregate-mode=zerolatency does not work with Chrome (2021-09-24T13:34:30ZSebastian Drögertph264pay: aggregate-mode=zerolatency does not work with Chrome (When enabling logs, Chrome prints the following over and over again and nothing else.
```
[406344:15:0604/080643.626376:WARNING:video_rtp_depacketizer_h264.cc(226)] Received packet containing more than 10 NAL units. Will not keep track ...When enabling logs, Chrome prints the following over and over again and nothing else.
```
[406344:15:0604/080643.626376:WARNING:video_rtp_depacketizer_h264.cc(226)] Received packet containing more than 10 NAL units. Will not keep track sps and pps ids for all of them.
[406344:15:0604/080643.950581:WARNING:video_receive_stream2.cc(788)] No decodable frame in 200 ms, requesting keyframe.
```
Sometimes it's displaying a few frames, most of the time it just hangs. `chrome://webrtc-internals` shows that it receives packets, can't decode them and sends PLIs all the time.
This can be reproduced with the webrtc-unidirectional-h264 example with some minor changes to get a very low complexity stream. Using a plain black videotestsrc makes it even worse. Note that you might have to right-click in Chrome, enable controls and then click on the "play" button due to restrictive autoplay rules.
```diff
diff --git a/webrtc/sendonly/webrtc-unidirectional-h264.c b/webrtc/sendonly/webrtc-unidirectional-h264.c
index 593d861..07abceb 100644
--- a/webrtc/sendonly/webrtc-unidirectional-h264.c
+++ b/webrtc/sendonly/webrtc-unidirectional-h264.c
@@ -22,7 +22,7 @@
#ifdef G_OS_WIN32
#define VIDEO_SRC "mfvideosrc"
#else
-#define VIDEO_SRC "v4l2src"
+#define VIDEO_SRC "videotestsrc pattern=ball"
#endif
gchar *video_priority = NULL;
```
Streams with more complexity don't show this problem so much.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/885rtspsrc: set-parameter / get-parameter action signals assume parameter values...2021-09-24T13:34:28ZNirbheek Chauhannirbheek.chauhan@gmail.comrtspsrc: set-parameter / get-parameter action signals assume parameter values are text"set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action com..."set-parameter" takes four params:
`const char *name` (the name of the param)
`const char *value` (the value of the param)
`const char *content_type` (text/parameters, etc)
`GstPromise * promise` (to get notified when the action completes)
And then it just does:
> `g_string_append_printf (req->body, "%s: %s\r\n", name, value);`
This means you can't send arbitrary data (via media type negotiation); all you can send is content-type "text/<something>". This does not match all the possibilities listed in the spec: https://datatracker.ietf.org/doc/html/rfc7826#section-13.9
Interestingly, the "handle-request" signal is correctly implemented, and you can receive arbitrary data in "SET_PARAMETER".
The same problem also exists for "get-parameter". We should probably rework these and add new signals that allow sending / receiving GBytes.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/884v4l2convert: race condition of group_released_handler2021-09-24T13:34:27ZKevin Songv4l2convert: race condition of group_released_handlerWe found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,f...We found below WARNING when run v4l2convert. How can we ensure group_released_handler don't disconnect in gst_v4l2_buffer_pool_stop when gst_v4l2_buffer_pool_resurrect_buffer()?
gst-launch-1.0 videotestsrc num-buffers=50 ! video/x-raw,format=BGRx,width=640,height=480 ! v4l2convert ! video/x-raw,format=RGB16 ! waylandsink sync=false
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.807843250
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
(gst-launch-1.0:5105): GLib-GObject-WARNING **: 20:17:06.169: ../glib-2.60.7/gobject/gsignal.c:2641: instance '0xffff94011200' has no handler with id '16'
Setting pipeline to NULL ...
Total showed frames (51), playing for (0:00:00.808691125), fps (63.065).
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/882Cannot capture window image with ximagesrc and xid : X reports invalid parame...2021-09-24T13:34:27ZYann SalmonCannot capture window image with ximagesrc and xid : X reports invalid parameter attributesI am trying to pinpoint why I sometimes (and unpredictably !) get a black video instead of the image of the selected window in Kazam screencast. It uses GStreamer for capturing so I tried to run a capture using the command line example i...I am trying to pinpoint why I sometimes (and unpredictably !) get a black video instead of the image of the selected window in Kazam screencast. It uses GStreamer for capturing so I tried to run a capture using the command line example in the GStreamer documentation.
I can (seemingly always) capture the whole desktop with
``gst-launch-1.0 ximagesrc ! video/x-raw,framerate=5/1 ! videoconvert ! theoraenc ! oggmux ! filesink location=/tmp/desktop.ogg``
However, specifying an xid gives various results. Sometimes it just works. Sometimes it fails with
```
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 4 (X_ShmGetImage)
Serial number of failed request: 42
Current serial number in output stream: 42
```
Sometimes it seems to start recording normally but on Ctrl-C'ing it, it says
```
^Chandling interrupt.
Interruption : arrêt du pipeline…
Execution ended after 0:00:04.728716374
Définition du pipeline à PAUSED...
Définition du pipeline à READY (prêt)…
```
then seems to stall for several minutes before concluding
```
Définition du pipeline à NULL…
Libération du pipeline…
```
and the resulting video is a corrupted file.
This is with
GStreamer 1.16.2
X.Org X Server 1.20.9
kernel 5.8.0-50-lowlatency
KUbuntu 20.04
KDE Framework 5.68.0
nvidia driver, 460.73.01
Capturing the same window with OBS works without a problem on the same system.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/881GstRpiCamSrc error for bitrate greater than 200000002021-09-24T13:34:26ZPanderGstRpiCamSrc error for bitrate greater than 20000000GstRpiCamSrc documentation says maximum bitrate is 24000000 (24E6) but gives an error for bitrates greater than 20000000 (20E6) for camera version 2 (perhaps not for version 1).
Can somebody reproduce this for version 1 camera and/or ve...GstRpiCamSrc documentation says maximum bitrate is 24000000 (24E6) but gives an error for bitrates greater than 20000000 (20E6) for camera version 2 (perhaps not for version 1).
Can somebody reproduce this for version 1 camera and/or version 2 camera? Perhaps there is only for version 2 another maximum that applies.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/880Improvements camera modes documentation GstRpiCamSrc2021-09-24T13:34:26ZPanderImprovements camera modes documentation GstRpiCamSrcHere are some improvements I would like to suggest for the documentation of GstRpiCamSrc. The source for these changes is https://picamera.readthedocs.io/en/release-1.12/fov.html#camera-modes
1. For https://gitlab.freedesktop.org/gstrea...Here are some improvements I would like to suggest for the documentation of GstRpiCamSrc. The source for these changes is https://picamera.readthedocs.io/en/release-1.12/fov.html#camera-modes
1. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L277 change first string into `"1920x1080 16:9 1-30fps / 1920x1080 0.1-30fps w/ v.2 board"`
2. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L280 change first string into `2592x1944 4:3 1-15fps / 3240x2464 0.1-15fps w/ v.2 board`
3. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L283 change first string into `"2592x1944 4:3 0.1666-1fps / 3240x2464 0.1-15fps w/ v.2 board"`
4. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L285 change first string into `"1296x972 4:3 1-42fps / 1640x1232 4:3 0.1-40fps w/ v.2 board"`
5. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L287 change first string into `"1296x730 16:9 1-49fps / 1640x922 16:9 0.1-40fps w/ v.2 board"`
6. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L290 change first string into `"640x480 4:3 42.1-60fps / 1280x720 16:9 40-90fps w/ v.2 board"`
7. For https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/sys/rpicamsrc/gstrpicamsrc.c#L292 change first string into `"640x480 4:3 60.1-90fps / 640x480 4:3 40-90fps w/ v.2 board"`
Please, double check that these proposed strings are correct. I have also the following questions:
- A. What should happen to the second string on the lines listed above with respect to the v.2 board? (What does `-slow` and `-fast` represent exactly? Are there conflicts with v.1 definitions for v.2?)
- B. Should the Partial Fov or Full FoV from readthedocs URL be added somehwere?
- C. Should the Video and Image support from readthedocs URL be added somewhere?
See also https://gstreamer.freedesktop.org/documentation/rpicamsrc/index.html?gi-language=c#GstRpiCamSrcSensorModehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/877lamemp3enc: incorrect duration / bitrate for vbr encoded tracks2021-09-24T13:34:26Zcrvilamemp3enc: incorrect duration / bitrate for vbr encoded tracksHere, we enncode Track_1.wav to vbr mp3.
`$ gst-launch-1.0 -v filesrc location="Track_1.wav" ! decodebin ! audioconvert ! audioresample ! lamemp3enc target=quality quality="0.0" ! filesink location="Track_1_lamemp3enc_vbr_q_0.000.mp3"`
...Here, we enncode Track_1.wav to vbr mp3.
`$ gst-launch-1.0 -v filesrc location="Track_1.wav" ! decodebin ! audioconvert ! audioresample ! lamemp3enc target=quality quality="0.0" ! filesink location="Track_1_lamemp3enc_vbr_q_0.000.mp3"`
```sh
$ file Track_1_lamemp3enc_vbr_q_0.000.mp3
Track_1_lamemp3enc_vbr_q_0.000.mp3: MPEG ADTS, layer III, v1, 32 kbps, 44.1 kHz, JntStereo
```
```sh
$ mplayer Track_1_lamemp3enc_vbr_q_0.000.mp3
MPlayer 1.4 (Debian), built with gcc-10 (C) 2000-2019 MPlayer Team
Playing Track_1_lamemp3enc_vbr_q_0.000.mp3.
libavformat version 58.45.100 (external)
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 44100 Hz, 2 ch, s16le, 32.0 kbit/2.27% (ratio: 4000->176400)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 1.8 (01.8) of 1590.0 (26:30.0) 0.6%
```
**Results:**
--------------
Incorrect duration : `1590 secs`<br>
Expected duration : `198` seconds
Incorrect bitrate : `32 kbps`<br>
Expected bitrate : `> 200 kbps`, since vbr encoding quality is best ( `0.0` ) )https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/874twcc: enabling it increases packet loss2021-09-24T13:34:25ZTtwcc: enabling it increases packet lossWhen I enable twcc via capsfilter I start to get a lot of packet loss (according to twcc) and the video becomes unwatchable.
I experimented with different encoders and payloaders but the results are similar.
I use webrtcbin to stream vi...When I enable twcc via capsfilter I start to get a lot of packet loss (according to twcc) and the video becomes unwatchable.
I experimented with different encoders and payloaders but the results are similar.
I use webrtcbin to stream video from GStreamer to GStreamer, ie. 1-way.
Running on MacOS Big Sur, building from master with Cerbero.
As discussed with @hgr on MR !927, this is not fixed by !927 and gstreamer!384.
I'm probably doing something wrong so any pointers will be much appreciated.
---
**VP8**
Source:
`videotestsrc ! video/x-raw,framerate=5/1 ! videoconvert ! vp8enc deadline=1 target-bitrate=5000 ! queue ! rtpvp8pay !
capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=VP8,extmap-3=http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01`.
Receiving end (I set the same capsfilter on a recvonly webrtctransceiver):
`rtpvp8depay ! vp8dec ! videoconvert ! queue ! glimagesink`
Rtpsession is giving this every few seconds:
`rtpsession rtpsession.c:2228:process_twcc_packet: [00m Could not schedule TWCC straight away`
---
**H264**
Source:
`videotestsrc ! video/x-raw,framerate=5/1 ! x264enc ! queue ! rtph264pay !
capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264,extmap-3=http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01`
Receiving end (I set the same capsfilter on a recvonly webrtctransceiver):
`rtph264depay request-keyframe=true ! queue ! h264parse config-interval=-1 !
avdec_h264 qos=true ! videoconvert ! glimagesink`
The h264 depayloader is giving warnings when twcc is enabled:
`gstrtph264depay.c:1365:gst_rtp_h264_depay_process:<rtph264depay0> [00m missing FU start bit on an earlier packet. Dropping.`
---
**Output**.
This is a sample log output with a very large negative avg-delta-of-delta, which seems curious to me. But that's is perhaps due to the large packet loss:
`rtpsession rtpsession.c:2890:rtp_session_process_twcc:<RTPSession@0x7ff26612c010> [00m Current TWCC stats RTPTWCCStats, bitrate-sent=(uint)38220, bitrate-recv=(uint)50289, packets-sent=(uint)13, packets-recv=(uint)1, packet-loss-pct=(double)86.343612670898438, avg-delta-of-delta=(gint64)-97416666;`
---
**Misc**.
I experimented with the following, but it did't seem to change anything:
- webrtc bundle policy vs none.
- 1-way vs 2-way video.
- Relay server vs. p2p.
- Wifi vs cellular network. (Haven't tried cable but just enabling twcc makes everything worse, so this doesn't seem to be the reason).