GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:33:30Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/276dashdemux: index information returned by gst_mpd_client_get_next_fragment is ...2021-09-24T14:33:30ZBugzilla Migration Userdashdemux: index information returned by gst_mpd_client_get_next_fragment is not used## Submitted by Florin Apostol
**[Link to original bug (#752714)](https://bugzilla.gnome.org/show_bug.cgi?id=752714)**
## Description
The gst_mpd_client_get_next_fragment function will set the index information for each media segmen...## Submitted by Florin Apostol
**[Link to original bug (#752714)](https://bugzilla.gnome.org/show_bug.cgi?id=752714)**
## Description
The gst_mpd_client_get_next_fragment function will set the index information for each media segment. But this information is never used by the caller function gst_dash_demux_stream_update_fragment_info. The stream->fragment data is set with all other information except the index related ones.
But even if the gst_dash_demux_stream_update_fragment_info function will properly update the index information on stream->fragment, the gstadaptivedemux is written such that the index is downloaded only when the header is retrieved (in the gst_adaptive_demux_stream_download_header_fragment function).
I believe the index downloading code should be moved from gst_adaptive_demux_stream_download_header_fragment to gst_adaptive_demux_stream_download_fragment so that it is attempted for each media fragment. According to the standard, each media segment can have its own segment index, so gstadaptivedemux should try to get all of them, not just the first one.
I don't have any real life examples that use segment index. If some could be provided, I could test this and provide a patch.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/275h263parse: update proper PAR calculations2021-09-24T14:33:30ZBugzilla Migration Userh263parse: update proper PAR calculations## Submitted by Vineeth
**[Link to original bug (#752690)](https://bugzilla.gnome.org/show_bug.cgi?id=752690)**
## Description
In case of h263 video format, libav is calculating the PAR as 12/11
but qtdemux is overwriting it to 1/...## Submitted by Vineeth
**[Link to original bug (#752690)](https://bugzilla.gnome.org/show_bug.cgi?id=752690)**
## Description
In case of h263 video format, libav is calculating the PAR as 12/11
but qtdemux is overwriting it to 1/1, resulting in wrong PAR being passed on.
So instead of just using the PAR from demuxer, check the PAR value in parser,
and compare the demuxer and parser PAR to determine the actual PAR.
This will align the PAR calculation to how it is done in libav, gstavviddec.chttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/271tests: remove usage of g_assert()2021-09-24T14:33:28ZBugzilla Migration Usertests: remove usage of g_assert()## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#752175)](https://bugzilla.gnome.org/show_bug.cgi?id=752175)**
## Description
Created attachment 307147
proposed patch for gst-plugins-bad
In relation to ...## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#752175)](https://bugzilla.gnome.org/show_bug.cgi?id=752175)**
## Description
Created attachment 307147
proposed patch for gst-plugins-bad
In relation to the discussion in https://bugzilla.gnome.org/show_bug.cgi?id=752123
Avoid usage of g_assert() in unit tests and use fail_unless() instead.
Would it be a good idea to create a new fail_if_reached() to replace the uses of g_assert_not_reached() in unit tests?
**Patch 307147**, "proposed patch for gst-plugins-bad":
[0001-tests-remove-usage-of-g_assert.patch](/uploads/b1cb8ff5fb579a6ebb5736f5329cad3f/0001-tests-remove-usage-of-g_assert.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/270dashdemux: Rename functions that talk about the current segment to say so ins...2021-09-24T14:33:27ZBugzilla Migration Userdashdemux: Rename functions that talk about the current segment to say so instead of "next"## Submitted by Florin Apostol
**[Link to original bug (#752085)](https://bugzilla.gnome.org/show_bug.cgi?id=752085)**
## Description
The changes introduced by https://bugzilla.gnome.org/show_bug.cgi?id=751850 are wrong. The segment...## Submitted by Florin Apostol
**[Link to original bug (#752085)](https://bugzilla.gnome.org/show_bug.cgi?id=752085)**
## Description
The changes introduced by https://bugzilla.gnome.org/show_bug.cgi?id=751850 are wrong. The segment_index indicates the next segment to be fetched while the gst_mpd_client_advance_segment will return GST_FLOW_OK if the current segment is still valid, so it is OK to advance the segment_index to segments_count (not a valid index in the segment array) and return GST_FLOW_OK.
Please reverse the changes introduced in https://bugzilla.gnome.org/show_bug.cgi?id=751850https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/269decklink: Black screen when grabbing 1080p30 from decklink intensity pro 4K2021-09-24T14:33:27ZBugzilla Migration Userdecklink: Black screen when grabbing 1080p30 from decklink intensity pro 4K## Submitted by sylvain cormier
**[Link to original bug (#752028)](https://bugzilla.gnome.org/show_bug.cgi?id=752028)**
## Description
Created attachment 306940
GST_DEBUG=*:6
gst-launch-1.0 decklinkvideosrc mode = 10 connecti...## Submitted by sylvain cormier
**[Link to original bug (#752028)](https://bugzilla.gnome.org/show_bug.cgi?id=752028)**
## Description
Created attachment 306940
GST_DEBUG=*:6
gst-launch-1.0 decklinkvideosrc mode = 10 connection= 2 ! xvimagesink
gives black screen.
**Attachment 306940**, "GST_DEBUG=*:6":
[GstreamerLog.txt.tar.gz](/uploads/1190bae71a6d93d718504fe2d1259b77/GstreamerLog.txt.tar.gz)
Version: 1.5.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/268bayer2rgb: odd width causes segmentation fault2021-09-24T14:33:27ZBugzilla Migration Userbayer2rgb: odd width causes segmentation fault## Submitted by Dimitrios Katsaros
**[Link to original bug (#752014)](https://bugzilla.gnome.org/show_bug.cgi?id=752014)**
## Description
I am trying to develop a component that uses the x-bayer format. After trying to debug a segme...## Submitted by Dimitrios Katsaros
**[Link to original bug (#752014)](https://bugzilla.gnome.org/show_bug.cgi?id=752014)**
## Description
I am trying to develop a component that uses the x-bayer format. After trying to debug a segmentation fault I reached this pipeline:
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-bayer ! bayer2rgb ! ximagesink
The pipeline Starts normally, then the ximagesink causes a renegotiation to happen to maximize the framesize. That causes a segmentation fault. I cannot determine if the problem is the bayer2rgb component or the v4l2src.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/267uvch264mjpgdemux: Output h.264 stream doesn't have pts information (GST_CLOCK...2021-09-24T14:33:26ZBugzilla Migration Useruvch264mjpgdemux: Output h.264 stream doesn't have pts information (GST_CLOCK_TIME_NONE)## Submitted by Kumar Vishal
**[Link to original bug (#751874)](https://bugzilla.gnome.org/show_bug.cgi?id=751874)**
## Description
I am using uvch264src plugin for obtaining Preview (jpeg@360p) and main stream (h.264@1080p) at 15 f...## Submitted by Kumar Vishal
**[Link to original bug (#751874)](https://bugzilla.gnome.org/show_bug.cgi?id=751874)**
## Description
I am using uvch264src plugin for obtaining Preview (jpeg@360p) and main stream (h.264@1080p) at 15 fps.
Camera: Logitech c920.
Internally uvch264src uses uvch264mjpgdemux for doing the demux operation.
After demuxing step, the pts of the h.264 stream is set to GST_CLOCK_TIME_NONE (99:99:99.999999999). Even if I pass this through h264parse, the pts of the stream is not fixed. As a result, when I dump this video muxed with audio onto file system (.mp4), the video frame is frozen, while the audio playbacks normally (using VLC player). Playback doesn't work at all using gst-play-1.0
Version: 1.5.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/266avfvideosrc: use AVCaptureSession beginConfiguration/commitConfiguration2021-09-24T14:33:26ZBugzilla Migration Useravfvideosrc: use AVCaptureSession beginConfiguration/commitConfiguration## Submitted by Ilya Konstantinov
**[Link to original bug (#751552)](https://bugzilla.gnome.org/show_bug.cgi?id=751552)**
## Description
AVCaptureSession's beginConfiguration and commitConfiguration should be used to make initializa...## Submitted by Ilya Konstantinov
**[Link to original bug (#751552)](https://bugzilla.gnome.org/show_bug.cgi?id=751552)**
## Description
AVCaptureSession's beginConfiguration and commitConfiguration should be used to make initialization as efficient as possible.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/265ITU-R BS.1770 / EBU R128 element2023-01-03T19:53:55ZBugzilla Migration UserITU-R BS.1770 / EBU R128 element## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#751534)](https://bugzilla.gnome.org/show_bug.cgi?id=751534)**
## Description
It would be nice to have a ebu r128 element in gstreamer. This is just a feature request...## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#751534)](https://bugzilla.gnome.org/show_bug.cgi?id=751534)**
## Description
It would be nice to have a ebu r128 element in gstreamer. This is just a feature request to start a discussion in case anyone else is interested in this.
There are two use cases which should be covered by this element:
* Allow to implement the replaygain 2 spec [0]. This includes all the things currently handled by the replaygain element, like passing in multiple streams and computing a global and per stream gain adjustment/peak.
* Allow to implement a compliant ebu r128 meter as specified in EBU TECH 3341 [1].
So this would be similar to a combination of the current replaygain element and the level element.
For the actual implementation the libebur128 [2] library seems like a good candidate as it's available in distros already. bs1770gain seems more feature rich, but only provides a CLI tool and no shared library.
[0] http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification
[1] https://tech.ebu.ch/docs/tech/tech3341.pdf
[2] https://github.com/jiixyj/libebur128
[3] http://bs1770gain.sourceforge.net/https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/264compositor: refactor in order to have alpha sources blended over non alpha ones2021-09-24T14:33:25ZBugzilla Migration Usercompositor: refactor in order to have alpha sources blended over non alpha ones## Submitted by Jean-Michel Hautbois (jmleo)
**[Link to original bug (#751484)](https://bugzilla.gnome.org/show_bug.cgi?id=751484)**
## Description
The idea is to be able to compose a YUV with a AYUV into a YUV without having to con...## Submitted by Jean-Michel Hautbois (jmleo)
**[Link to original bug (#751484)](https://bugzilla.gnome.org/show_bug.cgi?id=751484)**
## Description
The idea is to be able to compose a YUV with a AYUV into a YUV without having to convert twice.
It could be useful to use porter/duff operations for this.
Needs some refactoring in compositor, in order to select the proper blend function based on sources opacities.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/263bpmdetect: it's just crazy2021-09-24T14:33:24ZBugzilla Migration Userbpmdetect: it's just crazy## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#751457)](https://bugzilla.gnome.org/show_bug.cgi?id=751457)**
## Description
It's provides BPM few times per second, very different.
Here what I have for Iron Maide...## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#751457)](https://bugzilla.gnome.org/show_bug.cgi?id=751457)**
## Description
It's provides BPM few times per second, very different.
Here what I have for Iron Maiden's song named Night Wing, which is kinda slow and relaxing.
0:01:44.153469388: bpm-change
bpm: 87.161568
0:01:44.231836735: bpm-change
bpm: 102.273079
0:01:44.310204082: bpm-change
bpm: 87.605453
0:01:44.336326531: bpm-change
bpm: 102.275314
0:01:44.362448980: bpm-change
bpm: 119.003883
0:01:44.388571429: bpm-change
bpm: 93.015221
0:01:44.414693878: bpm-change
bpm: 106.442261
0:01:44.545306122: bpm-change
bpm: 134.060410
0:01:44.571428571: bpm-change
bpm: 135.934280
0:01:44.597551020: bpm-change
bpm: 106.241516
0:01:44.675918367: bpm-change
bpm: 130.866714
0:01:45.381224490: bpm-change
bpm: 109.939919
0:01:45.407346939: bpm-change
bpm: 107.384407
0:01:45.433469388: bpm-change
bpm: 92.727814
0:01:45.459591837: bpm-change
bpm: 136.055618
0:01:45.485714286: bpm-change
bpm: 106.717567
0:01:45.537959184: bpm-change
bpm: 136.059326
0:01:45.564081633: bpm-change
bpm: 106.626236
0:01:45.590204082: bpm-change
bpm: 135.762405
0:01:45.616326531: bpm-change
bpm: 106.626465
0:01:45.720816327: bpm-change
bpm: 136.527771
0:01:45.929795918: bpm-change
bpm: 106.718384
0:01:45.955918367: bpm-change
bpm: 136.221283
0:01:46.086530612: bpm-change
bpm: 148.490067
0:01:46.112653061: bpm-change
bpm: 136.525070
0:01:46.295510204: bpm-change
bpm: 31.038805
0:01:46.373877551: bpm-change
bpm: 62.254467
0:01:46.400000000: bpm-change
bpm: 131.138596
0:01:46.530612245: bpm-change
bpm: 33.087658
0:01:46.556734694: bpm-change
bpm: 98.822479
0:01:46.687346939: bpm-change
bpm: 33.087734
0:01:46.844081633: bpm-change
bpm: 99.065544
0:01:46.896326531: bpm-change
bpm: 49.928188
0:01:46.974693878: bpm-change
bpm: 99.073532
0:01:47.209795918: bpm-change
bpm: 114.543060
0:01:47.314285714: bpm-change
bpm: 120.766243
0:01:47.497142857: bpm-change
bpm: 159.715683
0:01:47.601632653: bpm-change
bpm: 169.155441
0:01:47.706122449: bpm-change
bpm: 130.444199
0:01:47.732244898: bpm-change
bpm: 147.756073
0:01:47.758367347: bpm-change
bpm: 135.897797
0:01:47.784489796: bpm-change
bpm: 159.716187
0:01:47.810612245: bpm-change
bpm: 135.908035
0:01:47.862857143: bpm-change
bpm: 106.815742
0:01:48.124081633: bpm-change
bpm: 135.895920
0:01:48.150204082: bpm-change
bpm: 106.814934
0:01:48.254693878: bpm-change
bpm: 120.892731
0:01:48.280816327: bpm-change
bpm: 106.909233
0:01:48.359183673: bpm-change
bpm: 135.605347
0:01:48.385306122: bpm-change
bpm: 120.882492
0:01:48.411428571: bpm-change
bpm: 181.669678
0:01:48.489795918: bpm-change
bpm: 120.764008
0:01:48.568163265: bpm-change
bpm: 180.309387
0:01:48.672653061: bpm-change
bpm: 120.759743
0:01:48.698775510: bpm-change
bpm: 180.854233
0:01:48.777142857: bpm-change
bpm: 120.761261
0:01:48.803265306: bpm-change
bpm: 180.571365
0:01:49.221224490: bpm-change
bpm: 181.954803
0:01:49.299591837: bpm-change
bpm: 120.757683
0:01:49.351836735: bpm-change
bpm: 181.138626
0:01:49.926530612: bpm-change
bpm: 182.238922
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/262dvbbasebin: optional support of target device in uri2021-09-24T14:33:23ZBugzilla Migration Userdvbbasebin: optional support of target device in uri## Submitted by Hugues Fruchet
**[Link to original bug (#751367)](https://bugzilla.gnome.org/show_bug.cgi?id=751367)**
## Description
Created attachment 305901
dvbbasebin: optional support of target device in uri
The attached...## Submitted by Hugues Fruchet
**[Link to original bug (#751367)](https://bugzilla.gnome.org/show_bug.cgi?id=751367)**
## Description
Created attachment 305901
dvbbasebin: optional support of target device in uri
The attached patch improves dvb uri handler to let user set the target DVB device. This is usefull when several DVB frontend cards are connected on the same device.
Target device is given in uri using syntax "dvb://`<device>`/`<channel name>`":
gst-launch-1.0 playbin uri="dvb:///dev/dvb/adapter0/frontend1/France 2"
This was tested on B2120 ST reference board running STiH412 'Monaco' chipset with 2x DVB-T frontend card connected.
Tested on GStreamer-1.4.5, but patch attached is rebased on master branch.
**Patch 305901**, "dvbbasebin: optional support of target device in uri":
[0001-dvbbasebin-optional-support-of-target-device-in-uri.patch](/uploads/afd8609be19ef912400edcb01ee58c5e/0001-dvbbasebin-optional-support-of-target-device-in-uri.patch)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/261bpmdetect: Provide timestamps together with BPM information2021-09-24T14:33:23ZBugzilla Migration Userbpmdetect: Provide timestamps together with BPM information## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#751292)](https://bugzilla.gnome.org/show_bug.cgi?id=751292)**
## Description
It's always equal to 18446744073709551615 when I try to fetch tags like that (sorry for C++1...## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#751292)](https://bugzilla.gnome.org/show_bug.cgi?id=751292)**
## Description
It's always equal to 18446744073709551615 when I try to fetch tags like that (sorry for C++11):
gst_pad_set_event_function_full(pad, [](GstPad *pad, GstObject *parent, GstEvent *event) -> gboolean
{
switch (GST_EVENT_TYPE(event))
{
case GST_EVENT_TAG:
{
gdouble bpm = 0;
GstTagList *tag_list = nullptr;
gst_event_parse_tag(event, &tag_list);
gst_tag_list_get_double(tag_list, GST_TAG_BEATS_PER_MINUTE, &bpm);
g_print("BPM change detected: %lf BPM\n", bpm);
/// What GST_EVENT_TIMESTAMP(event) should show here?
}
break;
default:
break;
}
return true;
}, nullptr, nullptr);
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/260videostitching: Open CV video stitching plugin based on GstVideoAggregator2021-09-24T14:33:22ZBugzilla Migration Uservideostitching: Open CV video stitching plugin based on GstVideoAggregator## Submitted by kevin
**[Link to original bug (#751203)](https://bugzilla.gnome.org/show_bug.cgi?id=751203)**
## Description
I developed one Open CV video stitching plugin based on GstVideoAggregator.
Test command:
gst-lau...## Submitted by kevin
**[Link to original bug (#751203)](https://bugzilla.gnome.org/show_bug.cgi?id=751203)**
## Description
I developed one Open CV video stitching plugin based on GstVideoAggregator.
Test command:
gst-launch-1.0 filesrc location=IMG_20150529_152901.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152907.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. videostitching name=stitcher stitcher.src ! videoconvert ! ximagesink sync=false
gst-launch-1.0 filesrc location=IMG_20150529_152901.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152907.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. videostitching feturetypes=0 warptypes=2 seamfindtypes=3 bacostfuncs=1 name=stitcher stitcher.src ! videoconvert ! ximagesink sync=false
gst-launch-1.0 filesrc location=IMG_20150529_152901.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152907.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152913.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152918.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152924.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152929.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152933.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152938.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152942.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152947.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. filesrc location=IMG_20150529_152951.jpg ! jpegdec ! videoconvert ! imagefreeze ! stitcher. videostitching feturetypes=0 warptypes=2 seamfindtypes=3 bacostfuncs=1 name=stitcher stitcher.src ! videoconvert ! ximagesink sync=false
### Depends on
* [Bug 746529](https://bugzilla.gnome.org/show_bug.cgi?id=746529)
* [Bug 748377](https://bugzilla.gnome.org/show_bug.cgi?id=748377)
* [Bug 753687](https://bugzilla.gnome.org/show_bug.cgi?id=753687)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/259tsdemux and push-mode not calculating2021-09-24T14:33:22ZBugzilla Migration Usertsdemux and push-mode not calculating## Submitted by iot..@..ud.com
**[Link to original bug (#750660)](https://bugzilla.gnome.org/show_bug.cgi?id=750660)**
## Description
Created attachment 304888
Does not work example log
I’m having a problem with the mpegtspac...## Submitted by iot..@..ud.com
**[Link to original bug (#750660)](https://bugzilla.gnome.org/show_bug.cgi?id=750660)**
## Description
Created attachment 304888
Does not work example log
I’m having a problem with the mpegtspacketizer.c implementation of mpegts_packetizer_pts_to_ts
I have a HLS demuxer ( not the open source version that is available, but a home grown one that I am working on open sourcing) that pushes TS files into the pipeline. On actual Set top box hardware this implementation autoplugs and works fine. The problem comes when I try to run it on a PC with the tsdemux in gst-plugins-bad.
When I send the TS stream to the tsdemux, the tsdemux does actually parse and find the correct PTS and DTS however since I don’t have calculate_skew nor calculate_offset set to TRUE the code flow in mpegts_packetizer_pts_to_ts always reports back that Not enough information to calculate proper timestamp.
Now with the exact same stream I do a filesrc autoplugged pipeline and load the first transport stream segment into playbin and because this is a pull src the pipeline and the tsdemux can correctly parse and set the timestamps PTS/ DTS and play the stream.
I’m stuck with how to actually fix this function. I have attached two logs, one working ( the pull source I noted from above) and the HLS demux that is a push source that doesn’t work.
I have referenced [bug 687178](https://bugzilla.gnome.org/show_bug.cgi?id=687178)
https://bugzilla.gnome.org/review?bug=687178&attachment=228530
However I have the same issue with the 1.4.4 release. Even though my demux element sends a segment event (which should theoretically turn on calculate_skew) it seems the tsdemux is throwing this segment information away and calculate_skew never gets turned on.
0:00:00.185801239 20235 0x1552ca0 DEBUG tsdemux gbuild/src/gst-plugins-bad-1.4.4/gst/mpegtsdemux/tsdemux.c:890:push_event:`<tsdemux0>` Ignoring segment event (recreated later)
I've tried commenting out the above with no change in behavior.
Any suggestions on how to proceed would be greatly appreciated. I’m also happy to provide any code or libraries.
Thanks,
Matt
**Attachment 304888**, "Does not work example log":
[does_not_work](/uploads/a1a3d41ee6c20fd74d9b342c6bff9632/does_not_work)
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/258videofilters: add support for convolution based gaussian filter2021-09-24T14:33:21ZBugzilla Migration Uservideofilters: add support for convolution based gaussian filter## Submitted by Sanjay NM
**[Link to original bug (#750433)](https://bugzilla.gnome.org/show_bug.cgi?id=750433)**
## Description
There is no support for convolution based gaussian filter## Submitted by Sanjay NM
**[Link to original bug (#750433)](https://bugzilla.gnome.org/show_bug.cgi?id=750433)**
## Description
There is no support for convolution based gaussian filterhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/256Decklink: Frame Stepping Event does not work.2021-09-24T14:33:20ZBugzilla Migration UserDecklink: Frame Stepping Event does not work.## Submitted by FredT
**[Link to original bug (#750125)](https://bugzilla.gnome.org/show_bug.cgi?id=750125)**
## Description
Pipeline is:
filesink->queue-> videoparse -> queue-> videoconvert -> queue-> decklinkvideosink
...## Submitted by FredT
**[Link to original bug (#750125)](https://bugzilla.gnome.org/show_bug.cgi?id=750125)**
## Description
Pipeline is:
filesink->queue-> videoparse -> queue-> videoconvert -> queue-> decklinkvideosink
When issuing the following command in python
sink.send_event(Gst.Event.new_step(Gst.Format.BUFFERS, 1, 1, True, False))
I can see that the position of the timeline is moving forward for each step but I don't see the video moving forward.
When stepping multiple time the pipeline crash after maybe 10-15 times then I the following error:
0:00:37.042014985 26959 0x2b2bed0 WARN decklinkvideosink gstdecklinkvideosink.cpp:472:gst_decklink_video_sink_prepare:`<decklinkvideosink0>` error: Failed to create video frame: 0x80000008
0:00:37.042057226 26959 0x2b2bed0 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<decklinkvideosink0>` posting message: GStreamer encountered a general stream error.
0:00:37.042081956 26959 0x2b2bed0 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<decklinkvideosink0>` posted error message: GStreamer encountered a general stream error.
0:00:37.042124896 26959 0x2b2bf70 INFO task gsttask.c:315:gst_task_func:<qA:src> Task going to paused
0:00:37.042131845 26959 0x2b2c0a0 INFO basesrc gstbasesrc.c:2851:gst_base_src_loop:`<testSource>` pausing after gst_pad_push() = error
I tested the pipeline with frame stepping autovideosink and it was stepping correctly.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/254bayer2rgb: add support for 24-bit RGB/BGR output2021-09-24T14:33:20ZBugzilla Migration Userbayer2rgb: add support for 24-bit RGB/BGR output## Submitted by Hamdi Rakkez
**[Link to original bug (#749439)](https://bugzilla.gnome.org/show_bug.cgi?id=749439)**
## Description
Why, unlike Gstreamer-0.10, Gstreamer-1.0 does not deliver a RGB image format ?## Submitted by Hamdi Rakkez
**[Link to original bug (#749439)](https://bugzilla.gnome.org/show_bug.cgi?id=749439)**
## Description
Why, unlike Gstreamer-0.10, Gstreamer-1.0 does not deliver a RGB image format ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/253disparity: Add a "max-disparity" property2021-09-24T14:33:19ZBugzilla Migration Userdisparity: Add a "max-disparity" property## Submitted by ji0..@..ng.com
**[Link to original bug (#749260)](https://bugzilla.gnome.org/show_bug.cgi?id=749260)**
## Description
Created attachment 303253
add a "max-disparity" property
The disparity element based on Ope...## Submitted by ji0..@..ng.com
**[Link to original bug (#749260)](https://bugzilla.gnome.org/show_bug.cgi?id=749260)**
## Description
Created attachment 303253
add a "max-disparity" property
The disparity element based on OpenCV is used for calculating disparities between two input images, but the current element only supports inputs whose maximum disparity is smaller than 16/32/64. (This fixed value depends on the algorithm type)
For supporting high-resolution images with larger disparity, I added a new property, "max-disparity". It can control a disparity size the element handles.
You can check it using the following command.
gst-launch-1.0 multifilesrc location=../L0000000000.png ! pngdec ! videoconvert ! video/x-raw,colorimetry="1:1:0:0" ! disp0.sink_right multifilesrc location=../R0000000000.png ! pngdec ! videoconvert ! video/x-raw,colorimetry="1:1:0:0" ! disp0.sink_left disparity max-disparity=64 name=disp0 method=sbm disp0.src ! videoconvert ! xvimagesink sync=false
2d1ac47a57d7e72c125975353c9e9dac691f50b6
~~**Patch 303253**~~, "add a "max-disparity" property":
[add_max_disparity.diff](/uploads/15f56ef30a147de4785a6cb3e4f3bb1d/add_max_disparity.diff)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/252rsndvdsrc: please tell me if my drive's region code is not yet set2021-09-24T14:33:19ZBugzilla Migration Userrsndvdsrc: please tell me if my drive's region code is not yet set## Submitted by Fabian Greffrath
**[Link to original bug (#749229)](https://bugzilla.gnome.org/show_bug.cgi?id=749229)**
## Description
Hi there,
I have been camping with my kids over the easter holidays. One day, it was rainin...## Submitted by Fabian Greffrath
**[Link to original bug (#749229)](https://bugzilla.gnome.org/show_bug.cgi?id=749229)**
## Description
Hi there,
I have been camping with my kids over the easter holidays. One day, it was raining outside and the kids were bored. I wanted to do them a favor and unpacked my Thinkpad to play a DVD for them. I inserted the DVD into the drive, started Totem and... nothing. "Ah, crap" I thought, "I need libdvdcss, this is a commercial DVD by one of the big studios". So, I pulled out my smartphone, enabled tethering for the laptop, grabbed the sources, compiled and installed the library. Phew. Tried again and... still nothing. Now, the kids were bored and disappointed. :/
Now, a few weeks later, I found out that the region code for my DVD drive was still unset and that this is a common issue when trying to decrypt DVD content. However, I was a bit disenchanted by the fact that attempting to play a DVD on Linux was still such an unsatisfying experience.
What I'd like to see improved:
1) Is there a way to detect that libdvdcss2 is not installed but will be needed for the current DVD to play? Please tell me.
2) Is there a way to detect that the region code for my drive is currently unset but needs to be set for the current DVD to play? Please tell me.
2a) Bonus points for offering me a way to set the DVD region code from within Totem.
3) Still need to verify, but I believe the DVD in question was additionally "protected" by ARccOS. I don't know if it will work now that I have libdvdcss2 installed and my region code set. But, if it is possible to detect that the "copy protection" mechanism of the disc is responsible for it not playing, please tell me. The current error message is a bit vague and could mean anything.
Thank you very much!
- Fabian