gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:38:37Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1370add GstDRMFormat struct API2021-09-24T14:38:37ZVíctor Manuel Jáquez Lealadd GstDRMFormat struct APIThe following discussion from gstreamer-vaapi!346 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346#note_578782): (+2 comments)
> I've had a ...The following discussion from gstreamer-vaapi!346 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346#note_578782): (+2 comments)
> I've had a bit of a later complaint for using the dual array in waylandsink, so perhaps we could make an effort and create `struct GstDRMFormat { format, mod }` ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1369mpegts: PTS calculated from bitrate is wrong2021-09-24T14:38:37ZYury Shatzmpegts: PTS calculated from bitrate is wrongWhen mpegtsmux has **bitrate** attribute set, it tries to write at exactly this bitrate, and sets PTS for outgoing buffers according to bytes written since beginning of stream - see gst/tsmux/tsmux.c
```
if (mux->bitrate)
GST_BUFFER_P...When mpegtsmux has **bitrate** attribute set, it tries to write at exactly this bitrate, and sets PTS for outgoing buffers according to bytes written since beginning of stream - see gst/tsmux/tsmux.c
```
if (mux->bitrate)
GST_BUFFER_PTS (buf) =
gst_util_uint64_scale (mux->n_bytes * 8, GST_SECOND, mux->bitrate);
```
If (total bitrate of incoming streams) <= bitrate that's ok.
However, if user miscalculates and sets muxer bitrate to a value that is too low, muxer PTS counter starts to run ahead of the incoming streams. For instance, buffers might enter muxer with PTS=100,000,000,000 and exit with PTS=101,000,000,000. This leads to synchronized sink elements (udpsink for instance) delaying these buffers, so in effect we are losing some frames and output gets really jerky.
Please note that it is very easy for a user to miscalculate, since it is hard to estimate bitrate of subtitles, and muxer never complains if the actual bitrate exceeds nominal.
I am not sure what would be the right solution and if this code is really needed. What's the point really? Muxer always selects the "best" buffer among sinks - this is the one with the lowest PTS. So, PTS is monotonous. Why should it throw away this perfectly good PTS and replace it with some calculated value?
gstbasetxmux.c contains code for preserving incoming PTS, but it gets called AFTER the code above and has no effect.
```
if (!GST_CLOCK_TIME_IS_VALID (GST_BUFFER_PTS (buf)))
{
GST_BUFFER_PTS (buf) = mux->last_ts;
}
```
For my build I simply disabled this if statement so that incoming PTS (stored in last_ts) has priority. But I have no idea in what scenarios PTS calculation from bitrate is useful, so I can't make an MR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1365proxysrc: Add property to configure internal queue size?2021-09-24T14:38:37ZPhilippe Normandproxysrc: Add property to configure internal queue size?The element can queue up to 200 buffers currently, which might introduce some delay between the producer and the consumer. Would it be acceptable to allow apps to configure the queue `max-size-buffers` property of the internal queue?
Cu...The element can queue up to 200 buffers currently, which might introduce some delay between the producer and the consumer. Would it be acceptable to allow apps to configure the queue `max-size-buffers` property of the internal queue?
Currently I do this manually, looking up the queue by iterating elements of the proxysrc (bin).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1364Simulcast support for webrtcbin2022-09-13T07:47:51ZValeriy PiddubchakSimulcast support for webrtcbinAs I can see from source code of webrtcbin, it does not support simulcast. Is it possible to add? If yes, can somebody give me roadmap ?
For now I plan to do the following:
- Build pipeline where webrtcbin will have 2 sink pads to han...As I can see from source code of webrtcbin, it does not support simulcast. Is it possible to add? If yes, can somebody give me roadmap ?
For now I plan to do the following:
- Build pipeline where webrtcbin will have 2 sink pads to handle streams with different bitrate and size:
```
source0 --> tee --> encoder0 --> webrtcbin0
\-> encoder1 --> webrtcbin0
```
- Inside webrtcbin add funnel element which will "mux" packets from sink pads into one stream
- Modify Offer to add information about simulcasthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1363Support for MPEG2-TS over AVTP (via IEC 61883-4)2021-09-24T14:38:36ZJens RossbachSupport for MPEG2-TS over AVTP (via IEC 61883-4)Please add support for streaming MPEG2-TS over AVTP, i.e. an AVTP plugin supporting IEC 61883-4 format.Please add support for streaming MPEG2-TS over AVTP, i.e. an AVTP plugin supporting IEC 61883-4 format.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1359mediafoundation: Implement generic URI source2021-09-24T14:38:35ZSeungha Yangseungha@centricular.commediafoundation: Implement generic URI source`GstMFSourceReader` was introduced for an internal of `mfvideosrc` element to to read data from video capture device.
We can extend the usage of `GstMFSourceReader` to read data from any URI (http, file or so) if it's supported by Media...`GstMFSourceReader` was introduced for an internal of `mfvideosrc` element to to read data from video capture device.
We can extend the usage of `GstMFSourceReader` to read data from any URI (http, file or so) if it's supported by MediaFoundation.
Moreover, `GstMFSourceReader` can be enhanced to be able to read data from UWP file object which would be a more generic
approach than https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1001
See also https://docs.microsoft.com/en-us/windows/win32/api/mfreadwrite/nn-mfreadwrite-imfsourcereaderhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1348webrtcbin: unit tests occasionally segfault/crash on CI2023-05-19T20:27:06ZTim-Philipp Müllertim@centricular.comwebrtcbin: unit tests occasionally segfault/crash on CIRecently we've been seeing segfaults of various webrtc unit tests on the CI, but we don't seem to get stack traces from validate.
(I'm sure there was an issue for it already, but I just can't seem to find it. I'm sure I even labelled it...Recently we've been seeing segfaults of various webrtc unit tests on the CI, but we don't seem to get stack traces from validate.
(I'm sure there was an issue for it already, but I just can't seem to find it. I'm sure I even labelled it.)
I just caught one likely crash in [a valgrind job](https://gitlab.freedesktop.org/tpm/gstreamer/-/jobs/3441365), so posting details here:
```
## test_media_setup.valgrind:
Thread 12:
Invalid read of size 4
at 0x868FD91: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x868F0E4: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x504BC4A: socket_source_dispatch (gsocket.c:3854)
by 0x4A56ECC: g_main_dispatch (gmain.c:3189)
by 0x4A56ECC: g_main_context_dispatch (gmain.c:3854)
by 0x4A5725F: g_main_context_iterate.isra.0 (gmain.c:3927)
by 0x4A57592: g_main_loop_run (gmain.c:4123)
by 0x6248192: ??? (in /usr/lib64/libgupnp-igd-1.0.so.4.2.0)
by 0x4A804C1: g_thread_proxy (gthread.c:805)
by 0x4F624BF: start_thread (pthread_create.c:479)
by 0x4C83132: clone (clone.S:95)
Address 0x78e44a8 is 56 bytes inside a block of size 8,352 free'd
at 0x483DA0C: free (vg_replace_malloc.c:540)
by 0x4A5CD7C: g_free (gmem.c:192)
by 0x4A756A3: g_slice_free1 (gslice.c:1135)
by 0x4B62345: g_type_free_instance (gtype.c:1936)
by 0x4B66343: g_value_unset (gvalue.c:275)
by 0x4B5AB3C: g_signal_emit_valist (gsignal.c:3421)
by 0x4B5BF68: g_signal_emit_by_name (gsignal.c:3487)
by 0x868EE5E: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x868F437: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x868FC03: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x868F0E4: ??? (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x504BC4A: socket_source_dispatch (gsocket.c:3854)
by 0x4A56ECC: g_main_dispatch (gmain.c:3189)
by 0x4A56ECC: g_main_context_dispatch (gmain.c:3854)
by 0x4A5725F: g_main_context_iterate.isra.0 (gmain.c:3927)
by 0x4A57592: g_main_loop_run (gmain.c:4123)
by 0x6248192: ??? (in /usr/lib64/libgupnp-igd-1.0.so.4.2.0)
by 0x4A804C1: g_thread_proxy (gthread.c:805)
by 0x4F624BF: start_thread (pthread_create.c:479)
by 0x4C83132: clone (clone.S:95)
Block was alloc'd at
at 0x483C80B: malloc (vg_replace_malloc.c:309)
by 0x4A5CC88: g_malloc (gmem.c:99)
by 0x4A74F95: g_slice_alloc (gslice.c:1024)
by 0x4A755BD: g_slice_alloc0 (gslice.c:1050)
by 0x4B61F79: g_type_create_instance (gtype.c:1836)
by 0x4B4442C: g_object_new_internal (gobject.c:1805)
by 0x4B46347: g_object_new_valist (gobject.c:2128)
by 0x4B4669C: g_object_new (gobject.c:1648)
by 0x8674EAD: gupnp_context_manager_create (in /usr/lib64/libgupnp-1.0.so.4.0.1)
by 0x6246564: ??? (in /usr/lib64/libgupnp-igd-1.0.so.4.2.0)
by 0x6248023: ??? (in /usr/lib64/libgupnp-igd-1.0.so.4.2.0)
by 0x4B44A7D: g_object_new_with_custom_constructor (gobject.c:1777)
by 0x4B44A7D: g_object_new_internal (gobject.c:1803)
by 0x4B45B14: g_object_new_with_properties (gobject.c:1973)
by 0x4B466C0: g_object_new (gobject.c:1645)
by 0x61E293A: nice_agent_gather_candidates (agent.c:3086)
by 0x61A3443: gst_webrtc_ice_stream_gather_candidates (icestream.c:190)
by 0x61B02F8: _set_description_task (gstwebrtcbin.c:4600)
by 0x61A5FA7: _execute_op (gstwebrtcbin.c:765)
by 0x4A537CA: g_idle_dispatch (gmain.c:5627)
by 0x4A56ECC: g_main_dispatch (gmain.c:3189)
by 0x4A56ECC: g_main_context_dispatch (gmain.c:3854)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1346tests: intermittent line21 test failure2021-09-24T14:38:33ZU. Artie Eofftests: intermittent line21 test failure```meson test --no-rebuild -v```
Observed that the line21 check test fails intermittently with the following error when running in a ubuntu:bionic Docker container:
```
../tests/check/elements/line21.c:80:F:general:basic:0: Assertion '...```meson test --no-rebuild -v```
Observed that the line21 check test fails intermittently with the following error when running in a ubuntu:bionic Docker container:
```
../tests/check/elements/line21.c:80:F:general:basic:0: Assertion 'in_cc_meta != out_cc_meta' failed
```
FWIW, the container is started with `--privileged` option.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1343mpegtsmux shouldn't write HDMV registration information2021-10-08T09:39:26ZVivia Nikolaidoumpegtsmux shouldn't write HDMV registration informationFile `gst/mpegtsmux/tsmux/tsmuxstream.c` line 791:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsmux/tsmux/tsmuxstream.c#L791
```
/* FIXME : Not sure about this additional_identification_info */
...File `gst/mpegtsmux/tsmux/tsmuxstream.c` line 791:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsmux/tsmux/tsmuxstream.c#L791
```
/* FIXME : Not sure about this additional_identification_info */
guint8 add_info[] = { 0xFF, 0x1B, 0x44, 0x3F };
descriptor = gst_mpegts_descriptor_from_registration ("HDMV",
add_info, 4);
g_ptr_array_add (pmt_stream->descriptors, descriptor);
```
Quoting my colleague Devin Heitmueller:
> HDMV is specifically the registration descriptor used for Blu-Ray read-only media.
>
> Registration descriptors are intended to inform the downstream decoder that a stream conforms to some specification. Standards bodies such as DVB, ATSC, SCTE, or the Blu-Ray Disc Association may require either the transport stream or specific elementary streams be marked to indicate conformance to their standards, as the standards body may require a more strict interpretation of the original H.264 or ISO 13818 specification.
>
> Determining the specifics of what the Blu-Ray Disc Association requires in order to have a conformant stream would require access to their non-public specifications. As neither ATSC nor DVB require a registration descriptor on their video elementary streams, and we intend to make no claim to conform to the Blu-Ray standard, the descriptor should be removed from transport streams we create.
>
> According to the SMPTE registration authority (https://smpte-ra.org/registered-mpeg-ts-ids), the HDMV registration descriptor:
>
> This RID is used for identification of the stream which conforms to the specification of "System Description Blu-ray Disc Read-Only Format part 3 Audio Visual Basic Specifications"
>
> There are other cases where we will need to insert registration descriptors, such as streams which conform to the SCTE-35 or SMPTE 2038 standards. However neither of those have the registration descriptor specified for the video
I looked into fixing it and thought about maybe enabling it only for m2ts mode. So basically the `GstMpegTsMux` class is the one that knows whether we have `m2ts-mode` enabled. Then it creates `BaseTsMux`, which then creates `TsMux`, which then creates a `TsMuxStream`, and that's where I need to know that mode. I then looked even further in the code and noticed the ATSC version, which is creating a subclass, overriding `create_ts_mux`, which overrides `create_new_stream`, which overrides `gst_atsc_mux_stream_get_es_descrs` and that's how it works there. So I don't see any other way around this other than creating a whole new subclass to deprecate `m2ts-mode` and breaking API.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1337d3d11desktopdupsrc: Expose dirty-rect area via ROI video meta2021-09-24T14:38:32ZSeungha Yangseungha@centricular.comd3d11desktopdupsrc: Expose dirty-rect area via ROI video metaThe dirty-rect concept in dxgiscreencapsrc (Desktop Duplication API) can be shared with d3d11videosink (both are based on DXGI!!). Note that d3d11videosink is utilizing the direty-rect concept in a very limited way while swapchaining. Bu...The dirty-rect concept in dxgiscreencapsrc (Desktop Duplication API) can be shared with d3d11videosink (both are based on DXGI!!). Note that d3d11videosink is utilizing the direty-rect concept in a very limited way while swapchaining. But if the capture side dirty-rect information can be forwarded to d3d11videosink, we might be able to save more GPU resource while swapchaining.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1336mfvideoenc: Add support for ROI videometa2021-09-24T14:38:31ZSeungha Yangseungha@centricular.commfvideoenc: Add support for ROI videometaSimilar to ROI + delta-qp implementation in msdk and vaapi, `mediafoundation` video encoder can support delta-qp for ROI.
See https://docs.microsoft.com/en-us/windows/win32/medfound/codecapi-avencvideoroienabled and https://docs.microso...Similar to ROI + delta-qp implementation in msdk and vaapi, `mediafoundation` video encoder can support delta-qp for ROI.
See https://docs.microsoft.com/en-us/windows/win32/medfound/codecapi-avencvideoroienabled and https://docs.microsoft.com/en-us/windows/win32/medfound/mfsampleextension-roirectanglehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1335inter: decouple pipelines and send encoded data (or any)2022-05-01T19:57:11ZDaniel Gomezinter: decouple pipelines and send encoded data (or any)Hi!
## Concept
I would like to decouple pipelines in the way that they are independent from each other so, I can change the state of any of them or seek... without pushing events/queries/status into the other. But I would like to use i...Hi!
## Concept
I would like to decouple pipelines in the way that they are independent from each other so, I can change the state of any of them or seek... without pushing events/queries/status into the other. But I would like to use it with encoded data.
A simple scenario where I think this can be useful would be something like this:
![decouple-pipelines-concept](/uploads/8faa72b99662b8232ae257e6288835a4/decouple-pipelines-concept.png)
> Note: I took the boxes 'design' from here. Hope it's fine :) https://gstreamer.freedesktop.org/documentation/application-development/basics/elements.html?gi-language=c
In the above diagram, buffers should be pushed from `intersink` element to the `intersrc` element and then, depending on the input-selector, only one of them is decoded and finally presented on the display.
## New GStreamer element
I've been checking all the available components to achieve the above scenario and it looks like it's either 'weird' this above scenario or just nobody tried to do it before. But, 5 years ago some [patches](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/204) were sent to actually accomplish this but they never got merged so, I took the patch series and rename the files as it was asked. [Here the code.](https://gitlab.freedesktop.org/daniel.qtec/gst-plugins-bad/-/tree/inter-plugin).
I know, for this purpose, buffers [cannot be dropped](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1317#note_531666). At least until you get a new key-frame which can be detected with [`GST_BUFFER_FLAG_DELTA_UNIT`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/master/gst/gstbuffer.h#L233). And pipelines need to be synced. So, that's what I would like to achieve.
## First try
```
GST_DEBUG="inter*:9" \
gst-launch-1.0 videotestsrc ! \
video/x-raw,width=320,height=240,format=NV12 ! \
queue ! \
x264enc key-int-max=10 ! \
h264parse ! \
"video/x-h264,stream-format=avc,alignment=au,level=(string)2,profile=(string)high,width=320,height=240,pixel-aspect-ratio=1/1,framerate=30/1" ! \
intersink channel=ch0 \
\
intersrc channel=ch0 ! \
fakesink
```
> Note: I've configured the encoder to send a key frame every 10 frames with `key-int-max=10` so, any client can be connected at any time and start decoding frames.
Above pipeline works fine and I can see how buffers are pushed from the 'source' pipeline to the 'sink' one. The problem comes whenever I add the decoder into the sink pipeline.
```
\
intersrc channel=ch0 ! \
avdec_h264 ! \
fakesink
```
In this case, the `intersink` pushes the first buffer and `intersrc` gets it to push it into the decoupled pipeline. Then, `intersrc` waits for the next buffer and here a second buffer comes in and comes out. Finally, `intersrc` waits again for until the next buffer comes but it never comes and I don't know the reason.
I've added a condition to wait until certain amount of time and then restart the sequence but a new buffer never comes in. In the WIP branch the code will timeout and send a NULL buffer so, it will crash.
Any idea what could be happening?
Is it just wrong or not a good idea the approach?
Should I use 'streams' instead of just buffers to feed the decoder?
Thanks in advance!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1333mpegts: gst_mpegts_descriptor_parse_dvb_short_event may be failing to correc...2021-09-24T14:38:30ZRussel Windermpegts: gst_mpegts_descriptor_parse_dvb_short_event may be failing to correctly parse real short event descriptors from FreeviewI am working in Rust so there is gst_mpegts_sys and gst_mpegts libraries involved. However, I think this problem may be an mpegts library problem.
I regularly get short event descriptors on Freeview from Crystal Palace, UK that cause th...I am working in Rust so there is gst_mpegts_sys and gst_mpegts libraries involved. However, I think this problem may be an mpegts library problem.
I regularly get short event descriptors on Freeview from Crystal Palace, UK that cause the Rust code to panic. I also get ones that work fine.
At the Rust level the backtrace is:
```
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1069
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1504
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:511
11: std::panicking::begin_panic
at /home/users/russel/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:438
12: glib::gstring::GString::new
at /home/users/russel/.cargo/git/checkouts/glib-928cf7b282977403/3a64675/src/gstring.rs:51
13: <glib::gstring::GString as glib::translate::FromGlibPtrFull<*mut i8>>::from_glib_full
at /home/users/russel/.cargo/git/checkouts/glib-928cf7b282977403/3a64675/src/gstring.rs:311
14: glib::translate::from_glib_full
at /home/users/russel/.cargo/git/checkouts/glib-928cf7b282977403/3a64675/src/translate.rs:1312
15: gstreamer_mpegts::auto::descriptor::Descriptor::parse_dvb_short_event
at /home/users/russel/Repositories/Git/Masters/Public/GStreamer_MPEGTS/src/auto/descriptor.rs:231
16: me_tv::epg_manager::build_eit
at src/epg_manager.rs:80
17: me_tv::epg_manager::run
at src/epg_manager.rs:217
18: me_tv::main::{{closure}}::{{closure}}
at src/main.rs:102
```
an instance of a descriptor that causes this problem is:
```
[77, 97, 101, 110, 103, 9, 31, 1, 111, 189, 248, 87, 165, 203, 32, 83, 31, 2, 166, 209, 154, 243, 159, 218, 96, 0, 99, 26, 118, 71, 154, 115, 23, 1, 191, 124, 109, 167, 88, 173, 90, 23, 35, 204, 248, 169, 27, 229, 59, 86, 83, 30, 226, 221, 124, 171, 35, 104, 7, 250, 191, 218, 172, 143, 112, 245, 87, 171, 187, 58, 169, 169, 139, 213, 248, 171, 221, 57, 138, 224, 146, 129, 141, 19, 45, 241, 233, 47, 185, 111, 142, 203, 182, 210, 120, 186, 189, 151, 32]
```
an instance of a descriptor that works fine is:
```
[77, 188, 101, 110, 103, 16, 73, 84, 86, 32, 69, 118, 101, 110, 105, 110, 103, 32, 78, 101, 119, 115, 167, 78, 97, 116, 105, 111, 110, 97, 108, 32, 97, 110, 100, 32, 105, 110, 116, 101, 114, 110, 97, 116, 105, 111, 110, 97, 108, 32, 110, 101, 119, 115, 32, 119, 105, 116, 104, 32, 114, 101, 112, 111, 114, 116, 115, 32, 97, 110, 100, 32, 97, 110, 97, 108, 121, 115, 105, 115, 32, 102, 114, 111, 109, 32, 73, 84, 86, 39, 115, 32, 67, 111, 114, 114, 101, 115, 112, 111, 110, 100, 101, 110, 116, 115, 32, 105, 110, 32, 116, 104, 101, 32, 85, 75, 32, 97, 110, 100, 32, 97, 114, 111, 117, 110, 100, 32, 116, 104, 101, 32, 119, 111, 114, 108, 100, 44, 32, 112, 108, 117, 115, 32, 97, 32, 102, 111, 99, 117, 115, 32, 111, 110, 32, 116, 104, 101, 32, 115, 116, 111, 114, 105, 101, 115, 32, 116, 104, 97, 116, 32, 109, 97, 116, 116, 101, 114, 32, 116, 111, 32, 121, 111, 117, 46, 32, 91, 83, 93]
```
which delivers the three results:
```
eng
ITV Evening News
National and international news with reports and analysis from ITV's Correspondents in the UK and around the world, plus a focus on the stories that matter to you. [S]
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1328Follow-up from "fdkaacenc: Add missing SURROUND mappings"2021-09-24T14:38:30ZVivia NikolaidouFollow-up from "fdkaacenc: Add missing SURROUND mappings"The following discussion from !1352 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1352#note_541889):
> ```
> Also add SIDE for 5 and 5.1 beca...The following discussion from !1352 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1352#note_541889):
> ```
> Also add SIDE for 5 and 5.1 because of ffmpeg compatibility, because the
> following pipeline downmixes to mono otherwise:
>
> gst-launch-1.0 audiotestsrc num-buffers=1 ! audio/x-raw, channels=6 !
> avenc_ac3 ! avdec_ac3 ! audioconvert ! fdkaacenc ! fakesink -v
> ```
>
> It seems like a bug that this would downmix to mono. Certainly stereo would be a better choice already, so it seems like there's also something to look at here. Maybe a bug in the audioconvert negotiation code, not sure.
>
> Should at least open an issue about that, maybe with a testcase that still works after this MR was merged.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1325interlace does possibly-wrong passthrough when field-order is missing from up...2021-09-24T14:38:26ZVivia Nikolaidouinterlace does possibly-wrong passthrough when field-order is missing from upstream capsThe following discussion from !1349 should be addressed:
field-order is optional in the caps. This means that, if we're in a non-telecine mode and we have TFF upstream and top-field-first=FALSE in interlace (or the other way around), AN...The following discussion from !1349 should be addressed:
field-order is optional in the caps. This means that, if we're in a non-telecine mode and we have TFF upstream and top-field-first=FALSE in interlace (or the other way around), AND field-order isn't mentioned in the caps, we will do passthrough here and end up outptuting wrong data. Must detect missing field-order info and not do passthrough in that case, but instead check the GstVideoBufferFlags.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1324Port gst-project-maker to python2021-09-24T14:38:26ZNicolas DufresnePort gst-project-maker to pythonCreated as a follow up, there was some interest in moving away from bash and using python instead. This was split from the original issue which was focused on moving from autotools to meson.
The following discussion from !184 should be ...Created as a follow up, there was some interest in moving away from bash and using python instead. This was split from the original issue which was focused on moving from autotools to meson.
The following discussion from !184 should be addressed:
- [ ] @seungha.yang started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/184#note_380856): (+1 comment)
> bash script is not Windows compatible. I think moving everything to python is the most reasonable way.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1323proxy: pipeline states problem2021-09-24T14:38:26ZDaniel Gomezproxy: pipeline states problemHi,
I'm playing with the `proxy` plugin and looks like the decoupled and the 'source' pipelines are sharing the pipeline state in a weird way. Basically the pipeline state travels upstream which conflicts with [this statement](https://g...Hi,
I'm playing with the `proxy` plugin and looks like the decoupled and the 'source' pipelines are sharing the pipeline state in a weird way. Basically the pipeline state travels upstream which conflicts with [this statement](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/commit/3f7e29d5b32f20dff75a58186533e40bb0ed4081) commit message:
> All queries, events, buffers, and buffer lists are proxied. State
> changes, clocks, and base times for the two pipelines are independent
> since the upstream and downstreams continue to be different pipelines.
I've taken an example and modify it a bit to reproduce the problem:
Here the repo:
https://github.com/dagmcr/gstreamer-cheat-sheet
Here the how to run it:
```
./gstreamer-cheat-sheet/python_examples/gstproxy_02_playbin.py <video-file>
```
The code will create 3 pipelines. Here the example with an mp4 file:
* playbin pipeline: `playbin0`
This is the 'source' pipeline which uses the `playbin` element to take a video, decode and play it. It also takes the `proxysink` element to use it as audio and video sink for the `playbin` element.
![playbin0](/uploads/6ef64577b9e08d2e81460a24ecbc1a14/playbin0.png)
* video sink pipeline: `pipeline0`
This is the 'sink' and decoupled video pipeline which links with the above `proxysink` video.
![pipeline0](/uploads/6c28942c0a7de94d02a14de3301b9832/pipeline0.png)
* audio sink pipeline: `pipeline1`
This is the 'sink' and decoupled audio pipeline which links with the above `proxysink` audio.
![pipeline1](/uploads/ebdca696f4af3286dcc9ec66acccfd24/pipeline1.png)
When the application starts, it also initializes a simple interface to control the pipelines:
![simple-interface](/uploads/86866666220b2888378349d41bc39270/simple-interface.png)
I would expect if you want to control the video/audio pipeline you would do it through `playbin0` to start/pause the video and audio. But when you pause `playbin0`, video and audio continues flowing to the sink pipelines (`pipepline0` and `pipeline1`). So, to actually stop the video you do it through the `pipeline0` and if you want to stop the audio you do it through `pipeline1`.
**Expected behaviour**
If you pause `playbin0` you pause audio and video pipeline. Therefore, buffer data is not pushed from `proxysink` to `proxysrc`. Then, `pipeline0` and `pipeline1` would receive the latest buffer or an empty one but still will continue in playing state.
If you pause either `pipeline0` or `pipeline1` you don't pause the video and the audio on the `playbin0`. So, if you just pause the `pipeline0` (video sink), you will continue listening the audio and when you start playing again `pipeline0`, video will not continue from the moment you stop but will continue exactly at the moment the audio is playing.
**proxy plugin code**
The `proxysrc` element handles the internal src pad by enabling disabling it depending on the pipe state:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/proxy/gstproxysrc.c#L256 but I don't see where in the code the pipeline state 'travels' from one the `proxysink` to the `proxysrc`. Is it because of they share a [common parent](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/proxy/gstproxysrc.c#L225)?
Any help?
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1320wasapisrc: fails to negotiate stream when applying a mix matrix2021-09-24T14:38:26ZJeff Sipkowasapisrc: fails to negotiate stream when applying a mix matrix**Summary:** When using the wasapisrc plugin, I am able to successfully set up a pipeline as follows:
`wasapisrc ! queue ! audioconvert ! audioresample ! opusenc ! fakesink`
However, when adding the mix-matrix parameter to audioconve...**Summary:** When using the wasapisrc plugin, I am able to successfully set up a pipeline as follows:
`wasapisrc ! queue ! audioconvert ! audioresample ! opusenc ! fakesink`
However, when adding the mix-matrix parameter to audioconvert, as in
`wasapisrc ! queue ! audioconvert mix-matrix="<<(float)1, (float)0>, <(float)0, (float)1>>" ! audioresample ! opusenc ! fakesink`
The pipeline fails with the output
```
ERROR: from element /GstPipeline:pipeline0/GstWasapiSrc:wasapisrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstWasapiSrc:wasapisrc0:
streaming stopped, reason not-negotiated (-4)
```
Full log attached
[mix_matrix.log](/uploads/ea00140487b1af5919fb8806ff5f8bac/mix_matrix.log)
**Environment:** Windows 10https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1315Follow-up from "WIP:winscreencap: Add screen capture element using Desktop Du...2021-09-24T14:38:25ZSeungha Yangseungha@centricular.comFollow-up from "WIP:winscreencap: Add screen capture element using Desktop Duplication API."The following discussion from !863 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/863#note_528486): (+5 comments)
> This of course means that once...The following discussion from !863 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/863#note_528486): (+5 comments)
> This of course means that once the frame is captured the timestamp is in the past already. As no latency is reported here this will cause all frames to be too late.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1314proxy: gst-stream-error-quark: Internal data stream error2021-09-24T14:38:25ZDaniel Gomezproxy: gst-stream-error-quark: Internal data stream errorHi guys,
I'm using proxy plugin to decouple pipelines but I have an issue when I try to decouple two pipelines and use h264 data in between. Just mention that the problem does not exist if:
1. proxysink/proxysrc are part of the same pip...Hi guys,
I'm using proxy plugin to decouple pipelines but I have an issue when I try to decouple two pipelines and use h264 data in between. Just mention that the problem does not exist if:
1. proxysink/proxysrc are part of the same pipeline.
2. I use RAW data instead.
3. h264 data is inside a container like 'mpegts'.
## example 1
This is 1 pipeline executing 2 'sub' pipelines which are communicated through `proxysink`/`proxysrc`. Here, h264 data flows properly from one sub-pipeline to the other.
Here how the components are linked inside the same pipeline:
```
sub-pipeline1:
filesrc ! qtdemux ! multiqueue ! \
h264parse ! video/x-h264,stream-format=byte-stream,aligment=au ! queue ! proxysink \
\
sub-pipeline2:
proxysrc ! avdec_h264 ! video/x-raw ! queue ! autovideosink
```
Here the graph:
![example0-proxy-r0](/uploads/b0fbf4139c2319309893e0cf6b0b7040/example0-proxy-r0.png)
## example 2
This is when I try the above but sub-pipelines are executed in different pipelines. So, something like:
Pipeline 1:
```
sub-pipeline1:
filesrc ! qtdemux ! multiqueue ! \
h264parse ! video/x-h264,stream-format=byte-stream,aligment=au ! queue ! proxysink
```
Pipeline 2:
```
sub-pipeline1:
proxysrc ! avdec_h264 ! video/x-raw ! queue ! autovideosink
```
In this case, I get the next error:
```
0:00:00.090315812 48480 0x246ab60 WARN qtdemux qtdemux.c:6605:gst_qtdemux_loop:<qtdemux0> error: Internal data stream error.
0:00:00.090391172 48480 0x246ab60 WARN qtdemux qtdemux.c:6605:gst_qtdemux_loop:<qtdemux0> error: streaming stopped, reason error (-5)
Error: gst-stream-error-quark: Internal data stream error. (1): qtdemux.c(6605): gst_qtdemux_loop (): /GstPipeline:b_pipedoc_src/GstQTDemux:qtdemux0:
streaming stopped, reason error (-5)
```
Here the graph for the 1st pipeline:
![example0-proxy-r1-p1](/uploads/47c34e06babb7dce1c7d8fedc88d3cb4/example0-proxy-r1-p1.png)
Here the graph for the 2st pipeline:
![example0-proxy-r1-p2](/uploads/1bed5300b7cc1c5442b094107d38dd5f/example0-proxy-r1-p2.png)
## Questions
Any idea why this is happening?
What is funny is that if you enable debug level 7 then, the 2nd example works fine.
Here the log file with level 5 in case it can help:
[ex0-proxy-r1.log](/uploads/698280df274ddd0c9aa978052c9c61c1/ex0-proxy-r1.log)
Thanks!