GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-10-05T12:03:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/762Dashsink mpd for dvbsrc is invalid as per https://conformance.dashif.org/2021-10-05T12:03:46ZvandanaDashsink mpd for dvbsrc is invalid as per https://conformance.dashif.org/The generated mpd file is not valid as per
https://conformance.dashif.org/
@dabrain34 Pls see
gstreamer pipeline:
`gst-launch-1.0 -v --gst-debug-no-color=1 dashsink name=dashsink mpd-baseurl=http://localhost/media/kls2iesj/ mpd-root-pat...The generated mpd file is not valid as per
https://conformance.dashif.org/
@dabrain34 Pls see
gstreamer pipeline:
`gst-launch-1.0 -v --gst-debug-no-color=1 dashsink name=dashsink mpd-baseurl=http://localhost/media/kls2iesj/ mpd-root-path=/var/www/localhost/media/kls2iesj mpd-filename=live.mpd target-duration=10 min-buffer-time=2 minimum-update-period=5 dynamic=true muxer=ts dvbsrc modulation=5 adapter=0 frequency=147000000 delsys=dvb-c-b ! queue ! tsdemux ! mpegvideoparse ! decodebin ! x264enc bitrate=1200 key-int-max=60 ! video/x-h264,stream-format=byte-stream,profile=main ! dashsink.video_0`
Generated mpd file is attached[live_fixed_high.mpd](/uploads/cb0d3a3a9ca126bb15e7bd938d4fde21/live_fixed_high.mpd)
Validated it here with dvb option checked
https://conformance.dashif.org/
The error logs is as follows:
```
Legend: Errors, Warnings, Information ***
Log No MPD Validation Report
1 0XLink resolving successful
2 MPD validation successful - DASH is valid!
3 Schematron validation successful - DASH is valid!
4 Warning for HbbTV-DVB DASH Validation Requirements check for DVB: Section 'MPD' - 'MPD@minimumUpdatePeriod has a lower value than 1 second.
5 ###'DVB check violated: Section E.2.1- The MPD SHALL indicate either or both of the following profiles: "urn:dvb:dash:profile:dvb-dash:2014" and "urn:hbbtv:dash:profile:isoff-live:2012"', specified profile could not be found.
6 Warning for DVB check: Section 11.1- 'All Representations that are intended to be decoded and presented by a DVB conformant Player SHOULD be such that they will be inferred to have an @profiles attribute that includes the profile name defined in clause 4.1 as well as either the one defined in 4.2.5 or the one defined in 4.2.8', found profiles: urn:mpeg:dash:profile:isoff-main:2011.
7 Warning for DVB check: Section 4.7.2- 'If the MPD is dynamic or if the MPD@availabilityStartTime is present then the MPD SHOULD countain at least one UTCTiming element with the @schemeIdUri attribute set to one of the following: urn:mpeg:dash:utc:ntp:2014, urn:mpeg:dash:utc:http-head:2014, urn:mpeg:dash:utc:http-xsdate:2014, urn:mpeg:dash:utc:http-iso:2014, urn:mpeg:dash:utc:http-ntp:2014 ', UTCTiming element could not be found in the provided MPD.
8 ###'DVB check violated: Section 4.4- For any Representation within an Adaptation Set with @contentType="video" @frameRate attribute SHALL be present if not in the AdaptationSet element', could not be found in neither Period 1 Adaptation Set 1 nor Period 1 Adaptation Set 1 Representation 1.
9 Warning for DVB check: Section 4.4- 'For any Representation within an Adaptation Set with @contentType="video" @sar attribute SHOULD be present or inherited from the Adaptation Set', could not be found in neither Period 1 Adaptation Set 1 nor Period 1 Adaptation Set 1 Representation 1.
10 ###'DVB check violated: Section 5.1.3- If (AVC video codec is) present the value of @codecs attribute SHALL be set in accordance with RFC 6381, clause 3.3', not found or not complete within Period 1 Adaptation Set 1.
11 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxWidth attribute (or @width if all Representations have the same width) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
12 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxHeight attribute (or @height if all Representations have the same height) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
13 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @maxFrameRate attribute (or @frameRate if all Representations have the same frameRate) SHOULD be present', could not be found in Period 1 Adaptation Set 1.
14 Warning for DVB check: Section 4.4- 'For any Adaptation Sets with @contentType="video" @par attribute SHOULD be present', could not be found in Period 1 Adaptation Set 1.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/761uridecodebin3, dashdemux: Video is not playing when dashdemux switch to next ...2022-04-30T22:34:21ZShlomi Amituridecodebin3, dashdemux: Video is not playing when dashdemux switch to next period in mpdHi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=...Hi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006 decodebin.audio_0 ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=host.docker.internal port=55008`
Both audio and video are playing fine, but after ~4m when dashdemux advance to the next period, I see the following:
new audio_01 src pad is created
new video_01 src pad is created
decodebin3 automatically selects properly audio_01, but it doesn't seem to receive any collection event for video_01 stream, and it ends up with video_00 and audio_01 streams being selected, where nothing is being pushed to video_00 since it was used for the first period.
As a result, the pipeline keeps playing only audio from the new period, and no video is being played at all.
Note that if I change the pipeline to play only video, the next period is played just fine: (So the issue isn't suspected to be with the video stream itself)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006`
Logs attached with GST_DEBUG level is set to 3,*dash*:5,*soup*:4,gstadaptivedemux:4,*decodebin*:5,*parsebin*:5
[gst-main-debug.log](/uploads/4a73452a8f72ad57072db52076c5e1ee/gst-main-debug.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1672[uridecodebin3][dashdemux] Video is not playing when dashdemux switch to next...2021-10-05T10:34:13ZShlomi Amit[uridecodebin3][dashdemux] Video is not playing when dashdemux switch to next period in mpdHi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=...Hi.
I'm using the following pipeline to play a dash where the mpd is having 2 periods. (gstreamer v1.18.4)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006 decodebin.audio_0 ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=host.docker.internal port=55008`
Both audio and video are playing fine, but after ~4m when dashdemux advance to the next period, I see the following:
new audio_01 src pad is created
new video_01 src pad is created
decodebin3 automatically selects properly audio_01, but it doesn't seem to receive any collection event for video_01 stream, and it ends up with video_00 and audio_01 streams being selected, where nothing is being pushed to video_00 since it was used for the first period.
As a result, the pipeline keeps playing only audio from the new period, and no video is being played at all.
Note that if I change the pipeline to play only video, the next period is played just fine: (So the issue isn't suspected to be with the video stream itself)
`gst-launch-1.0 -v uridecodebin3 uri=https://dash.akamaized.net/dash264/TestCases/5a/nomor/4.mpd name=decodebin connection-speed=250 caps="video/x-h264;audio/x-raw" decodebin.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream ! rtph264pay ! udpsink host=host.docker.internal port=55006`
Logs attached with GST_DEBUG level is set to 3,*dash*:5,*soup*:4,gstadaptivedemux:4,*decodebin*:5,*parsebin*:5
[gst-main-debug.log](/uploads/13ee8fb0d5d46b26417f023511494337/gst-main-debug.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1671h264parse: Fragmented mp4 causes Nal units to be wrongly parsed as Nal type ...2021-10-04T14:52:27Zpointcontrolsh264parse: Fragmented mp4 causes Nal units to be wrongly parsed as Nal type 0, ref_idc 0![movie_data_new_cat](/uploads/a302a629e5d6ef47094ae0bb5055582b/movie_data_new_cat.mp4)
Version: 1.18.5
`gst-launch-1.0 playbin uri=file://attached_file.mp4` causes
> Setting pipeline to PAUSED ...
>Pipeline is PREROLLING ...
>Got co...![movie_data_new_cat](/uploads/a302a629e5d6ef47094ae0bb5055582b/movie_data_new_cat.mp4)
Version: 1.18.5
`gst-launch-1.0 playbin uri=file://attached_file.mp4` causes
> Setting pipeline to PAUSED ...
>Pipeline is PREROLLING ...
>Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
>ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode
vaapidecode0: No valid frames decoded before end of stream
>Additional debug info:
>gstvideodecoder.c(1161): gst_video_decoder_sink_event_default ():/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:>vaapidecode0:
>no valid frames found
>ERROR: pipeline doesn't want to preroll.
>Setting pipeline to NULL ...
>Freeing pipeline ...
After enabling logs, it can be seen:
`h264parse gsth264parse.c:2653:gst_h264_parse_set_caps:<h264parse0> profile 4d0001
0:00:00.373674118 28356 0x7f5c541c6230 DEBUG h264parse gsth264parse.c:2661:gst_h264_parse_set_caps:<h264parse0> nal length size 4
0:00:00.373678870 28356 0x7f5c541c6230 DEBUG codecparsers_h264 gsth264parser.c:242:gst_h264_parse_nalu_header: Nal type 0, ref_idc 0
0:00:00.373683925 28356 0x7f5c541c6230 DEBUG h264parse gsth264parse.c:722:gst_h264_parse_process_nal:<h264parse0> processing nal of type 0 Unknown, size 22
0:00:00.373688216 28356 0x7f5c541c6230 DEBUG codecparsers_h264 gsth264parser.c:242:gst_h264_parse_nalu_header: Nal type 0, ref_idc 0
`
This file is played normally with ffplay, vlc, chrome, firefox. FFMPEG gives no warnings about incorrect mp4, and every Nal unit has the correct type when dumpedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/933v4l2src output truncated after changing capture size2021-10-07T09:47:33ZDamian Hobson-Garciadamian@hobsong.comv4l2src output truncated after changing capture sizeWhen doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exist...When doing some testing with the vivid driver I noticed that if the v4l2src capture size is reduced
from the default, it can never be properly restored to its original size. This behaviour carries
across processes, so this problem exists even when running `gst-launch` multiple times.
This only happens for devices that support the crop / compose API.
To reproduce:
```bash
$ sudo modprobe vivid n_devs=1 input_types=0x3
```
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=640, width=480 ! ximagesink
```
Output scaled down to 640x480 as expected
```
$ gst-launch-1.0 v4l2src ! ximagesink
```
Window size is 1280x720, but the image data is still 640x480 (right and bottom of image is black)
```
$ gst-launch-1.0 v4l2src ! video/x-raw, width=1280, width=720 ! ximagesink
```
Even explicitly setting the output size makes no difference. Image is still 640x480.
It seems like the problem is that the composition selection rectangle is reduced to 640x480 by the vivid driver, but is not
increased again when a larger capture buffer size is requested. This looks like valid driver behaviour according
to the spec, which doesn't require that the compose rectangle is reset on S_FMT.
I think that v4l2src would need to reset the compose rectangle to the default value when it does the format setting to avoid this
problem.
Does this sound correct?https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/346MSVC x86 build is shipping x86_64 pkg-config.exe binary2022-09-21T08:09:55ZSeungha Yangseungha@centricular.comMSVC x86 build is shipping x86_64 pkg-config.exe binaryso installed `pkg-config` binary is unusable for x86 packageso installed `pkg-config` binary is unusable for x86 packagehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/760sysprof dependency (via libsoup) does not build on Meson 0.59.22021-12-19T19:46:34ZMichael Farrellsysprof dependency (via libsoup) does not build on Meson 0.59.2I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Me...I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Meson macro, `meson.build_root`](https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b).
This was fixed in sysprof a year ago: https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b
And then this commit was included when libsoup updated: https://gitlab.gnome.org/GNOME/libsoup/-/commit/7a98acbda55edd69762bf1c4e18dc66a968e9969
However, gstreamer points at https://gitlab.gnome.org/GNOME/libsoup/-/commit/e190e70298be1186ad1a8a5dd0ac430463f76fee, [which references an old commit of sysprof](https://gitlab.gnome.org/GNOME/libsoup/-/blob/e190e70298be1186ad1a8a5dd0ac430463f76fee/subprojects/sysprof.wrap) that lacks the fix: https://gitlab.gnome.org/GNOME/sysprof/-/commit/1bb0eb7798f6a88667681229dde415ed663b1053
Please update to a current version of `libsoup`, or use a cherry-pick branch that includes this patch:
```
~/gstreamer/subprojects/sysprof$ git diff
diff --git a/meson.build b/meson.build
index 26f289f..98ea5a2 100644
--- a/meson.build
+++ b/meson.build
@@ -84,7 +84,7 @@ has_clockid = cc.has_member('struct perf_event_attr', 'clockid', prefix: '#inclu
config_h.set('HAVE_PERF_CLOCKID', has_use_clockid and has_clockid)
add_project_arguments([
- '-I' + meson.build_root(), # config.h
+ '-I' + meson.current_build_dir(), # config.h
], language: 'c')
global_c_args = [
```
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/93Failing to build Tutorial on iOS2021-10-06T09:17:38ZLoris PlassonFailing to build Tutorial on iOSHello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library...Hello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library not found for -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)`
I'm running Xcode 13.0, any idea?
Thanks a lot!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/758appsink: caps event error, caps still have parent2021-10-03T21:10:43ZMauriceappsink: caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstsample.c#L352)). Afterwards, `priv->last_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/943[AppSink] caps event error, caps still have parent2021-10-03T19:16:26ZMaurice[AppSink] caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.18/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/1.18.4/gst/gstsample.c#L352)). Afterwards, `priv->las_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/932gstreamer1.0-qt5 package not available on Raspberry2021-10-06T07:05:26ZStefano Cottafavigstreamer1.0-qt5 package not available on RaspberryHi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for i...Hi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for installation on my Pi.
I'm using gstreamer1.0 (1.14.4) from Debian Buster apt.
Not sure if this is a bug or is expected?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-bad/-/issues/1670teletext stream using application/x-teletext with mpegtsmux ? Showing wrong ...2023-07-11T10:52:18ZRobert Henselteletext stream using application/x-teletext with mpegtsmux ? Showing wrong type in DVBInspector and VLC Platback.Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine...Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine tune a little more then adapt the pipeline into a python app on linux for my DATV DVB-S transmitter project.
Issue I have is I'm sucking out the Teletext data from a TS file Program 4 on PID 1978 using the tsdemux plugin.
I'm pulling out the teletext data by selecting the correct pid attaching to pad private_0_07b ( 0=teletext PID =0x07b = Decimal 1978) from the **TSdemux**. These are so many Gstreamer pages on the web with conflicting information on correctly setting the stream and PID and the demux. Anyway, PES data flows through to be remuxed into **mpegtsmux** on the application/x-teletext pad PID of 1980.
Is seems to work however, I'd unable to show the correct teletext type=6?? Somehow it showing to be DVB subtitling in DVBInspector which isn't correct.
I'm using Gstreamer's recent windows build where all elements and plugins are version 1.19.1
I know there has been ongoing work in making **mpegtsmux** DVB and ATSC compliant which is a move forward and appreciative for all the work which goes into Gstreamer framework. I've tried **ffmpeg** however, I not sure how to go about muxing teletext data with ffmpeg as there naff all information I could find. Plenty on subtitling and actual plugin for such. sparse with actual teletext? I know there is the teletexdec plugin
Only 'if' there was a plugin for encoding teletextenc ??
Back on my issue:-
Is there a issue with mpegtsmux? or is it something I've done in my pipeline OR, plainly what I'm doing is not how you do it?
Attached is my Pipeline which encodes BigBuckBunny as RAW Video and audio to TS stream with Teletext encoding. I'd be working with live AV using fiffo's into gestreamer pipeline on the project. Teletext I hope to work on injecting these using **appsrc** however, more investigation and reseach on how to do buffer and PCR time stamping.. Has anyone out there has successfully done what I'm trying to do?
Pictures below show PID 1980 showing DVBSubtitling service (WRONG) in addition, VLC confirms such by advertising Subtitles however not the display Teletext.
gst-launch-1.0
mpegtsmux name=mux prog-map=program_map,sink_1000=10,sink_1001=10,sink_1980=10
! filesink location=C:/temp/meta1.ts ^
filesrc location=C:/Temp/big_buck_bunny_720p24.y4m
! decodebin name=vdec
! video/x-raw,format=I420,width=1280,height=720
! x264enc tune=zerolatency bitrate=5000 byte-stream=true threads=2 key-int-max=15 intra-refresh=true
! video/x-h264, profile=main
! queue
! mux.sink_1000
filesrc location=C:/Temp/BigBuckBunny-stereo.flac
! decodebin name=adec
! audioconvert
! voaacenc bitrate=128000
! aacparse
! queue
! mux.sink_1001
filesrc location=C:/temp/OC3.demo.ts
! tsdemux name=demux program-number=4 parse-private-sections=false
demux.private_0_07ba
! queue
! application/x-teletext
! mux.sink_1980
VLC codec information
![image](/uploads/5dfb335d4f4930fc9a5a6e30ec27857f/image.png)
DVB Inspector tables
![image](/uploads/3f7d6bfc487d279d2f97592f5fa04f6f/image.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/757rtsp-server: corrupt memory due to raciness in the session timeout handling2021-10-31T12:25:49ZOgnyan Tonchevrtsp-server: corrupt memory due to raciness in the session timeout handlingI have been noticing quite strange crashes in an application using gst-rtsp-server, mostly in glibc's malloc()/ the Glib slice allocator(when g_slice=always-malloc is not set) and other parts of the code which at a first glance seemed qu...I have been noticing quite strange crashes in an application using gst-rtsp-server, mostly in glibc's malloc()/ the Glib slice allocator(when g_slice=always-malloc is not set) and other parts of the code which at a first glance seemed quite unrelated to get-rtsp-server. But eventually managed to narrow the problem down to a corrupt memory caused by the session timeout mechanism.
Problem 1)
What happens is that under some circumstances clients will trigger session timeout and send RTSP TEARDOWN at the same time. Then gst_rtsp_session_filter() which is called by the session timeout mechanism will drop the reference owned by 'priv->medias' to the GstRTSPSessionMedia. handle_teardown() will try to do the very same thing. This would have not caused any issue if gst_rtsp_session_filter() was not temporarily releasing the lock while calling GstRTSPSessionFilterFunc.
This is the problematic piece of code:
```
gst_rtsp_session_filter():
g_mutex_unlock (&priv->lock);
res = func (sess, media, user_data);
g_mutex_lock (&priv->lock);
```
when this happens handle_teardown() will take the lock and drop the reference hold from the private structure, gst_rtsp_session_filter() will then try to do the same after that. The ref count here will still be greater than zero since the intern hash table, visited, also holds a ref, but when the hash table gets freed at the end of the function the unref will be on an already freed object.
Problem 2)
handle_* () functions in the client can be called while the session is being finalized due to session timeout. They do call:
`sessmedia = gst_rtsp_session_get_media (session, path, &matched);`
which is a transfer-none call, in the meantime sessmedia may be freed by gst_rtsp_session_filter (). One solution could possibly be to implement a version which does transfer-full?
Do you have any suggestion how to solve that correctly?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/756dvdread: Add device probe support2021-09-30T16:28:05ZBugzilla Migration Userdvdread: Add device probe support## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodeb...## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodebin for instance it is a pain to get dvdread to use the right device node. Once Oliviers GstDevice stuff is implemented the dvdread element should be made to use it.
### Depends on
* [Bug 678402](https://bugzilla.gnome.org/show_bug.cgi?id=678402)
### Blocking
* [Bug 687617](https://bugzilla.gnome.org/show_bug.cgi?id=687617)https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/56To generate the answer in webrtc in python2021-09-30T11:55:14ZAadeITTo generate the answer in webrtc in pythonHi , everyone
using python to generate the answer ,but get answer
`v=0
s=-
t=0 0`
and this error
`ERROR:gstwebrtcbin.c:1150:_check_if_negotiation_is_needed: assertion failed: (trans->mline < gst_sdp_message_medias_len (webrtc->...Hi , everyone
using python to generate the answer ,but get answer
`v=0
s=-
t=0 0`
and this error
`ERROR:gstwebrtcbin.c:1150:_check_if_negotiation_is_needed: assertion failed: (trans->mline < gst_sdp_message_medias_len (webrtc->current_local_description->sdp))
Abandoned (core dumped)
`
Thanks
This is my code , to generate the answer only , please replace a RTSP_URL in 19 line in this python code
[nn_webrtc.py](/uploads/7eadd24ba04179c479e3ce9c9510e018/nn_webrtc.py)https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/61RFC: Ship GLib bindings as part of GStreamer inside GStreamer's namespace2021-10-04T01:25:26ZAndoni Morales AlastrueyRFC: Ship GLib bindings as part of GStreamer inside GStreamer's namespaceI would love to see in the nearest future GStreamer providing NuGet packages ready-to-use as part of the official release process.
For that to happen, several things need to be improved on the way:
1. Make GstSharp bindings work with o...I would love to see in the nearest future GStreamer providing NuGet packages ready-to-use as part of the official release process.
For that to happen, several things need to be improved on the way:
1. Make GstSharp bindings work with other nugets proving depeding or providing GLib bindings
2. Provide NuGet binary packages:
* GstSharp.win32_x86_64
* GstSharp.osx_x86_64
* GstSharp.linux_arm
* etc ...
3. Automate NuGet packages with cerbero
The first stone in the road is the GLib's bindings situation:
* There are several forks of Glib's bindings
* Forks are not compatible between them
* Within the same Fork, versions are not backwards compatible
* GstSharp needs a very specific version of glib-sharp
* GstSharp NuGet packages its own version of glib-sharp
The biggest issue here is that releases of glib-sharp are not backwards compatible, which means that 2 projects depending on glib-sharp can't work together, since only one version of the glib-sharp will be loaded.
This an example where things can go wrong:
* I create a new MyGtkPlayer project
* I add as dependencies GstSharp and GtkSharp
* GtkSharp depends on GlibSharp providing a version of glib-sharp
* GstSharp provides its own version of glib-sharp
* The application will load one of the 2 assemblies
* BOOM!
Renaming the assembly glib-sharp.dll to gstreamer-glib-sharp.dll will not work either, since it will provide the same GLib clases in the same GLib namespace.
For all these reasons GstSharp needs to ship its own version of GLib and it has to be done with a namespace different than `GLib`
Possible solutions:
* Use [ILMerge](https://github.com/tom-englert/ILMerge.Fody#namespaceprefix) with a namespace prefix. This will weave the generated gstreamer-sharp.dll and merge glib-sharp and gio-sharp into the final assembly, creating an internal copy of GLib that is not exposed.
* Import [GtkSharp](https://github.com/GLibSharp/GtkSharp) sources in gstreamer-sharp, rename the namespace to GStreamer.GLib. This will ease maintenace a lot, since fixes in GtkSharp are directly done in gstreamer-sharp's repohttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/755playbin3: tracer leaks2022-11-10T09:21:07ZGuillaume Desmottesplaybin3: tracer leaksThe leaks tracer is detecting a bunch of leaks when running `gst-play-1.0` on a video file with `--use-playbin3`.
```
$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 tests/medias/video-2s.mkv
(...)
0...The leaks tracer is detecting a bunch of leaks when running `gst-play-1.0` on a video file with `--use-playbin3`.
```
$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 tests/medias/video-2s.mkv
(...)
0:00:02.180382846 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstTagList, address=(gpointer)0x7f6e74140630, description=(string)taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;, ref-count=(uint)1, trace=(string);
0:00:02.180399648 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstStreamCollection, address=(gpointer)0x7f6e7800c660, description=(string)collection 0x7f6e7800c660 (1 streams) < stream video 0x7f6e7800c030, ID f2d60c1e06ba3aa6cf5f38c574482211fbe2efc8a2a5ddaa0dc9ead670e23370/001:3992135233783999116, flags 0x2, caps [video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true], tags [taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;], >, ref-count=(uint)1, trace=(string);
0:00:02.180409558 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstStream, address=(gpointer)0x7f6e7800c030, description=(string)stream video 0x7f6e7800c030, ID f2d60c1e06ba3aa6cf5f38c574482211fbe2efc8a2a5ddaa0dc9ead670e23370/001:3992135233783999116, flags 0x2, caps [video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true], tags [taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;], ref-count=(uint)1, trace=(string);
0:00:02.180422602 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstMemory, address=(gpointer)0x83c600, description=(string)0x83c600, ref-count=(uint)1, trace=(string);
0:00:02.180428627 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7f6e7410a040, description=(string)<'':sink_0>, ref-count=(uint)55, trace=(string);
0:00:02.180434930 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f6e70014c50, description=(string)video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, ref-count=(uint)1, trace=(string);
0:00:02.180441880 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstBuffer, address=(gpointer)0x7f6e78007a20, description=(string)buffer: 0x7f6e78007a20, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 45, offset none, offset_end none, flags 0x0, ref-count=(uint)1, trace=(string);
** (gst-play-1.0:654132): WARNING **: 16:19:13.367: Leaks detected and logged under GST_DEBUG=GST_TRACER:7
```
We do not have those when running without `--use-playbin3`.
Most of those are fixed with gst-plugins-base!1174 except this one for which I did not find any obvious culprit.
```
0:00:02.256666402 654310 0x18b0090 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7f1bdc0fc080, description=(string)<'':sink_0>, ref-count=(uint)55, trace=(string);
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/754vaapi: Deadlock playing UHD video content2021-09-29T10:12:17ZStéphane Cerveauscerveau@igalia.comvaapi: Deadlock playing UHD video contentthis [UHD content](https://4kmedia.org/lg-oled-art-uhd-4k-demo/) fails to play with this given pipeline:
```
GST_DEBUG=vaapi*:5 gst-launch-1.0 -v playbin3 uri=file:///opt/NFS/Medias/Videos/HDR/LG\ OLED\ Art\ HDR\ UHD\ 4K\ Demo.ts
```
...this [UHD content](https://4kmedia.org/lg-oled-art-uhd-4k-demo/) fails to play with this given pipeline:
```
GST_DEBUG=vaapi*:5 gst-launch-1.0 -v playbin3 uri=file:///opt/NFS/Medias/Videos/HDR/LG\ OLED\ Art\ HDR\ UHD\ 4K\ Demo.ts
```
Working with
`gst-launch-1.0 -v filesrc location= /opt/NFS/Medias/Videos/HDR/LG\ OLED\ Art\ HDR\ UHD\ 4K\ Demo.ts ! tsdemux ! queue ! h265parse ! vaapih265dec ! vaapipostproc hdr-tone-map=auto ! "video/x-raw(memory:VASurface),format=P010_10LE,colorimetry=bt2020-10" ! vaapisink fullscreen=1`
Here is my vainfo
```
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.1.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointEncSlice
VAProfileVP9Profile2 : VAEntrypointVLD
```
VLC is able to play this media smoothly
[00007fb530c057f0] avcodec decoder: Using Intel i965 driver for Intel(R) Kaby Lake - 2.1.0 for hardware decoding
Further comment can be found after https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/270#note_531375https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/753HDR: support dynamic metadata2023-02-01T21:24:02ZStéphane Cerveauscerveau@igalia.comHDR: support dynamic metadataFollowing the work performed in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/400, the next step would be to be able to support dynamic metadata.
This implementation should provide a mechanism to update each element wi...Following the work performed in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/400, the next step would be to be able to support dynamic metadata.
This implementation should provide a mechanism to update each element with newer values instead of using GstCaps.
API change:
- Provide a new GStVideo meta with HDR dynamic meta information
Links:
[ATSC Specification for HDR10+](https://www.atsc.org/wp-content/uploads/2018/02/S34-301r2-A341-Amendment-2094-40.pdf)