GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:35:00Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/501[h264parse] [codecparsers] warning observed when parsing some H.264 SEI NALs ...2021-09-24T14:35:00ZBugzilla Migration User[h264parse] [codecparsers] warning observed when parsing some H.264 SEI NALs when payload contains emulation_prevention_three_byte## Submitted by Ursula Maplehurst
**[Link to original bug (#776551)](https://bugzilla.gnome.org/show_bug.cgi?id=776551)**
## Description
Created attachment 342549
Patch
I had been seeing the following warning from h264parse w...## Submitted by Ursula Maplehurst
**[Link to original bug (#776551)](https://bugzilla.gnome.org/show_bug.cgi?id=776551)**
## Description
Created attachment 342549
Patch
I had been seeing the following warning from h264parse when parsing an H.264 stream with some application-specific SEI NALs:
W GStreamer+codecparsers_h264: 17:21:32.788894716 0xb9567db0 gsth264parser.c:1212:gst_h264_parser_parse_sei_message error parsing "Sei message"
W GStreamer+h264parse: 17:21:32.788945174 0xb9567db0 gsth264parse.c:524:gst_h264_parse_process_sei:`<h264parse0>` failed to parse one or more SEI message
Upon further investigation, it looks like certain SEI NALs were causing nal_reader_read to eat up some 0x03 bytes which are not actually emulation prevention bytes. Patch for the issue attached.
Cheers,
Ursula
**Patch 342549**, "Patch":
[codecparsers-nalutils.patch](/uploads/488be2b98b5db22b69702cf751a7d4b1/codecparsers-nalutils.patch)
Version: 1.10.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/500rawvideoparse internal data stream error with bt2020 colorimetry if resolutio...2021-09-24T14:35:00ZBugzilla Migration Userrawvideoparse internal data stream error with bt2020 colorimetry if resolution is not 4k## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#776446)](https://bugzilla.gnome.org/show_bug.cgi?id=776446)**
## Description
gst-launch-1.0 filesrc location=/dev/zero blocksize=3110400 num-buffers=1000 ! r...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#776446)](https://bugzilla.gnome.org/show_bug.cgi?id=776446)**
## Description
gst-launch-1.0 filesrc location=/dev/zero blocksize=3110400 num-buffers=1000 ! rawvideoparse width=1920 height=1080 framerate=30 format=nv12 ! "video/x-raw, format=(string)NV12, colorimetry=(string)bt2020" ! fakesink -v
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error.
The following works okay:
gst-launch-1.0 filesrc location=/dev/zero blocksize=12441600 num-buffers=1000 ! rawvideoparse width=3840 height=2160 framerate=30 format=nv12 ! "video/x-raw, format=(string)NV12, colorimetry=(string)bt2020" ! fakesink -vhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/499Memory leak fixed in usage of gst_element_get_request_pad() API2021-09-24T14:34:59ZBugzilla Migration UserMemory leak fixed in usage of gst_element_get_request_pad() API## Submitted by Garima
**[Link to original bug (#776334)](https://bugzilla.gnome.org/show_bug.cgi?id=776334)**
## Description
Created attachment 342296
Memory leak fixed in usage of gst_element_get_request() API
Memory leak f...## Submitted by Garima
**[Link to original bug (#776334)](https://bugzilla.gnome.org/show_bug.cgi?id=776334)**
## Description
Created attachment 342296
Memory leak fixed in usage of gst_element_get_request() API
Memory leak fixed in usage of gst_element_get_request() API.
gst_element_get_request() returns requested GstPad which need to be released after its usage.
Changes done in following file:
ext/resindvd/resindvdbin.c
gst/sdp/gstsdpdemux.c
sys/dvb/dvbbasebin.c
Added gst_object_unref() to release the memory.
Find the attached patch.
~~**Patch 342296**~~, "Memory leak fixed in usage of gst_element_get_request() API":
[0001-Fix-memory-leaks-in-usage-of-gst_element_get_request.patch](/uploads/b8247b7be9de5f0549b5082828dd63ab/0001-Fix-memory-leaks-in-usage-of-gst_element_get_request.patch)
Version: 1.9.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/498dvbsuboverlay: don't composite if cannot map frame2021-09-24T14:34:59ZBugzilla Migration Userdvbsuboverlay: don't composite if cannot map frame## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#776238)](https://bugzilla.gnome.org/show_bug.cgi?id=776238)**
## Description
If the frame to composite cannot be mapped, the frame is passed as
is, wih...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#776238)](https://bugzilla.gnome.org/show_bug.cgi?id=776238)**
## Description
If the frame to composite cannot be mapped, the frame is passed as
is, wihtout blending the image, logging an info message.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/497FDK-AAC plugin does not expose LATM/LOAS transmux support2021-09-24T14:34:59ZBugzilla Migration UserFDK-AAC plugin does not expose LATM/LOAS transmux support## Submitted by Rafael Diniz
**[Link to original bug (#776236)](https://bugzilla.gnome.org/show_bug.cgi?id=776236)**
## Description
FDK-AAC does support LATM/LOAS muxing, but gstreamer plugin does not. LATM/LOAS mux is widelly used ...## Submitted by Rafael Diniz
**[Link to original bug (#776236)](https://bugzilla.gnome.org/show_bug.cgi?id=776236)**
## Description
FDK-AAC does support LATM/LOAS muxing, but gstreamer plugin does not. LATM/LOAS mux is widelly used worldwide in ISDB-T DTV.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/496omx - in error state at end of video (before EOS)2021-09-24T14:34:58ZBugzilla Migration Useromx - in error state at end of video (before EOS)## Submitted by Stuart Axon
**[Link to original bug (#776091)](https://bugzilla.gnome.org/show_bug.cgi?id=776091)**
## Description
Created attachment 341953
Deallocate texture in FLUSH_START
I've been playing a video, just be...## Submitted by Stuart Axon
**[Link to original bug (#776091)](https://bugzilla.gnome.org/show_bug.cgi?id=776091)**
## Description
Created attachment 341953
Deallocate texture in FLUSH_START
I've been playing a video, just before it gets to the end it freezes and I get the output below.
For now I haven't managed to make some minimal code to reproduce it yet, so just wondering it is known - similar to the OMX bug mentioned earier ?
https://lists.freedesktop.org/archives/gstreamer-devel/2016-December/061931.html
0:01:32.395974718 7472 0x2364200 ERROR omx gstomx.c:1955:gst_omx_port_wait_buffers_released_unlocked:`<omxh264dec-omxh264dec0>` Timeout waiting for egl_render port 221 to release all buffers
0:01:32.396736066 7472 0x2364200 WARN omxvideodec gstomxvideodec.c:1620:gst_omx_video_dec_loop:`<omxh264dec-omxh264dec0>` error: Unable to reconfigure output port
0:01:32.398866620 7472 0x224f480 ERROR omx gstomx.c:836:gst_omx_component_set_state:`<omxh264dec-omxh264dec0>` Last operation returned an error. Setting last_error manually.
0:01:32.398946516 7472 0x224f480 ERROR omx gstomx.c:845:gst_omx_component_set_state:`<omxh264dec-omxh264dec0>` Error setting egl_render state from 4 to 3: Insufficient resources (0x80001000)
0:01:32.399041984 7472 0x224f480 ERROR omx gstomx.c:872:gst_omx_component_get_state:`<omxh264dec-omxh264dec0>` Component egl_render in error state: Insufficient resources (0x80001000)
0:01:32.399663280 7472 0x224f480 ERROR omx gstomx.c:1467:gst_omx_port_set_flushing:`<omxh264dec-omxh264dec0>` Component egl_render is in error state: Insufficient resources (0x80001000)
0:01:32.400010725 7472 0x224f480 ERROR omx gstomx.c:1467:gst_omx_port_set_flushing:`<omxh264dec-omxh264dec0>` Component egl_render is in error state: Insufficient resources (0x80001000)
0:01:32.400604053 7472 0x224f480 WARN omxvideodec gstomxvideodec.c:2146:gst_omx_video_dec_flush:`<omxh264dec-omxh264dec0>` Failed to populate output port: Incorrect state operation (0x80001018)
0:01:32.402515808 7472 0x2364200 ERROR omx gstomx.c:1257:gst_omx_port_acquire_buffer:`<omxh264dec-omxh264dec0>` Component egl_render is in error state: Insufficient resources
0:01:32.403512778 7472 0x2364200 WARN omxvideodec gstomxvideodec.c:1527:gst_omx_video_dec_loop:`<omxh264dec-omxh264dec0>` error: OpenMAX component in error state None (0x00000000)
El viernes, 9 de diciembre de 2016 13:41:18 (CET) Stuart Axon escribió:
> I'm pretty sure I'm using the one from gst-plugins-bad (I'm using gstreamer
> master, last built about 3 days ago). But not 100% sure, is there a way to
> tell ?
If you're using master, then you're using gst-plugins-bad almost for sure.
Anyway, it doesn't really mind, as none of the two versions seem to listen to
the FLUSH_START event.
> So maybe I could mitigate this by manually calling drain() if in the error
> state or hook into the FLUSH_START?
My suggestion would be to focus on FLUSH_START instead of reacting in the
error state. In my experience, when "Insufficient resources" happens, it's too
late to revert to a working state again.
So, what I would do would be to touch gst_glimage_sink_event()[1], adding a
case for FLUSH_START. There you could do the same as the DRAIN query does[2]
(copy-paste or refactor into a common function called from both places). Make
sure that you don't return inside the case, so the code flow continues and
ends up calling to the ancestor class method to process the event[3]. That
last part is important for the right operation of the element.
> I haven't seen the error in dispmanx-gst-play, however, my player is a bit
> more complex - I update the play state (seek, or try and change file) in
> gobject timer, from data I get on the network. S++
I haven't looked in deep how dispmanx-gst-play works, so I can't give an
opinion about why things work there. Maybe a different sink is used (one which
doesn't hold EGL buffers for itself on flush), I don't know.
Another think I forgot: check that your Raspberry has enough graphics memory
configured. Assuming you're using raspbian: sudo raspi-config, advanced
options, memory split. Use some higher value such as 128.
In any case, I hope the suggestions help you to fix the issue. :-)
Cheers.
[1] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
gstglimagesink.c?id=1.10.2#n1023
[2] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
gstglimagesink.c?id=1.10.2#n1118
[3] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
gstglimagesink.c?id=1.10.2#n1069
--
Enrique Ocaña González
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Disable Popup Ads | Edit this page
~~**Patch 341953**~~, "Deallocate texture in FLUSH_START":
[dealloc_texture.patch](/uploads/81205c5adedb96dac9bac999b3af0b57/dealloc_texture.patch)
### Blocking
* [Bug 776167](https://bugzilla.gnome.org/show_bug.cgi?id=776167)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/495New library for synchronised playback2021-09-24T14:34:58ZBugzilla Migration UserNew library for synchronised playback## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#776089)](https://bugzilla.gnome.org/show_bug.cgi?id=776089)**
## Description
I've been working on gst-sync-server, which I wrote about at:
https://arunraghavan.n...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#776089)](https://bugzilla.gnome.org/show_bug.cgi?id=776089)**
## Description
I've been working on gst-sync-server, which I wrote about at:
https://arunraghavan.net/2016/11/gstreamer-and-synchronisation-made-easy/
The summary of this is that the library provides a server and client object such that a server can publish one or more URIs for clients to receive and synchronise to. Mechanisms exist to control client playback (pause/stop for now).
The network transport for control is abstracted into an interface for users of the API to be able to use their own transport, and a default TCP-based implementation is included.
I'd like to propose this for inclusion in gst-plugins-bad, so we have a single, standardised way to provide synchronised playback. There are features that I will be working on (included in a TODO list). This includes support for configuring per-client transformations (for video wall mode), as well as more mundane features such as seeking.
Examples of the API use are at:
https://github.com/ford-prefect/gst-sync-server/tree/master/examples
GTK-Doc documentation is at:
https://arunraghavan.net/temp/gst-sync-server/
The code itself is at:
https://github.com/ford-prefect/gst-sync-server/https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/491mpdparser: Parse MPD Anchor "t" and "period" parameters2021-09-24T14:34:56ZBugzilla Migration Usermpdparser: Parse MPD Anchor "t" and "period" parameters## Submitted by Seungha Yang
**[Link to original bug (#775757)](https://bugzilla.gnome.org/show_bug.cgi?id=775757)**
## Description
ISO/IEC 23009-1:2014 Annex C.4 defines MPD Anchor which is to indicate
start time offset, period, ...## Submitted by Seungha Yang
**[Link to original bug (#775757)](https://bugzilla.gnome.org/show_bug.cgi?id=775757)**
## Description
ISO/IEC 23009-1:2014 Annex C.4 defines MPD Anchor which is to indicate
start time offset, period, and etc.
Basically, the syntax of MPD Anchor follows Media Fragments URI 1.0
from key-value pair parsing point of view.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/489Improve opencv motion detection element2021-09-24T14:34:55ZBugzilla Migration UserImprove opencv motion detection element## Submitted by Will Newton
**[Link to original bug (#775701)](https://bugzilla.gnome.org/show_bug.cgi?id=775701)**
## Description
This series of patches attempts to improve the performance of the plugin and also a few more cosmetic...## Submitted by Will Newton
**[Link to original bug (#775701)](https://bugzilla.gnome.org/show_bug.cgi?id=775701)**
## Description
This series of patches attempts to improve the performance of the plugin and also a few more cosmetic improvements along the way. There are still opportunities for improving the plugin further but hopefully this is a step in the right direction.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/487Add HEVC encoder element based on Turing2021-09-24T14:34:54ZBugzilla Migration UserAdd HEVC encoder element based on Turing## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775354)](https://bugzilla.gnome.org/show_bug.cgi?id=775354)**
## Description
http://turingcodec.org/## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775354)](https://bugzilla.gnome.org/show_bug.cgi?id=775354)**
## Description
http://turingcodec.org/https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/486dash: validate: Error message on the bus stating that file is invalidate when...2021-09-24T14:34:54ZBugzilla Migration Userdash: validate: Error message on the bus stating that file is invalidate when seeking (with stop value)## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775266)](https://bugzilla.gnome.org/show_bug.cgi?id=775266)**
## Description
Created attachment 340932
GST_DEBUG=5 logs
Validate test: validate.dash.pla...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775266)](https://bugzilla.gnome.org/show_bug.cgi?id=775266)**
## Description
Created attachment 340932
GST_DEBUG=5 logs
Validate test: validate.dash.playback.seek_with_stop.dash_exMPD_BIP_TC1
Failure example: https://ci.gstreamer.net/job/GStreamer-master-validate/4074/testReport/junit/validate.dash.playback/seek_with_stop/dash_exMPD_BIP_TC1/
Critical issues:
Got error: This file is invalid and cannot be played. -- Debug message: qtdemux.c(6598): gst_qtdemux_process_adapter (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: sample data crosses atom boundary
Wrong combined flow return error(-5). Expected: eos(-3)
It is quite racy but not to hard to reproduce with:
gst-validate-launcher -t validate.dash.playback.seek_with_stop.dash_exMPD_BIP_TC1 --forever
It only happen with the seek_with_stop scenario in the last 200 runs, never on other seeking scenarios.
**Attachment 340932**, "GST_DEBUG=5 logs":
[dash_exMPD_BIP_TC1.gstdebug.tar.gz](/uploads/1f075897bc7eef502bdc0ef8940a2ac7/dash_exMPD_BIP_TC1.gstdebug.tar.gz)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/485Delay on start from windows source2021-09-24T14:34:53ZBugzilla Migration UserDelay on start from windows source## Submitted by Alberto Fanjul
**[Link to original bug (#775236)](https://bugzilla.gnome.org/show_bug.cgi?id=775236)**
## Description
Trying to stream a screen mirroring from windows I get an undefined initial lag https://github.com...## Submitted by Alberto Fanjul
**[Link to original bug (#775236)](https://bugzilla.gnome.org/show_bug.cgi?id=775236)**
## Description
Trying to stream a screen mirroring from windows I get an undefined initial lag https://github.com/albfan/miraclecast/issues/103#issuecomment-263050110
I can provide dumps, logs or do any check you need.
Maybe related with
https://bugzilla.gnome.org/show_bug.cgi?id=769536
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/484directsoundsrc: Fixating to mono if 1-8 channels are possible2021-09-24T14:34:53ZBugzilla Migration Userdirectsoundsrc: Fixating to mono if 1-8 channels are possible## Submitted by Bob Squirrell
**[Link to original bug (#775176)](https://bugzilla.gnome.org/show_bug.cgi?id=775176)**
## Description
Left and right channels are combined to form two mono channels. If source has left channel or righ...## Submitted by Bob Squirrell
**[Link to original bug (#775176)](https://bugzilla.gnome.org/show_bug.cgi?id=775176)**
## Description
Left and right channels are combined to form two mono channels. If source has left channel or right channel only, then the output is on both channels with no panning.
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/482hls:validate: Setting state intensively on HLS stream can lead to several dif...2021-09-24T14:34:52ZBugzilla Migration Userhls:validate: Setting state intensively on HLS stream can lead to several different ERROR on the bus## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775118)](https://bugzilla.gnome.org/show_bug.cgi?id=775118)**
## Description
Validate tests: validate.hls.playback.change_state_intensive.hls_bibbop
Failu...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775118)](https://bugzilla.gnome.org/show_bug.cgi?id=775118)**
## Description
Validate tests: validate.hls.playback.change_state_intensive.hls_bibbop
Failure examples:
* https://ci.gstreamer.net/job/GStreamer-master-validate/4052/testReport/junit/validate.hls.playback/change_state_intensive/hls_bibbop/
Error: Internal data stream error. -- Debug message: gstadaptivedemux.c(3363): gst_adaptive_demux_stream_download_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin40/GstDecodeBin:decodebin40/GstHLSDemux:hlsdemux40:
streaming stopped, reason not-linked (-1)
* https://ci.gstreamer.net/job/GStreamer-master-validate/4090/testReport/junit/validate.hls.playback/change_state_intensive/hls_bibbop/
Error: Internal data stream error. -- Debug message: gstadaptivedemux.c(2247): _src_chain (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin27/GstDecodeBin:decodebin27/GstHLSDemux:hlsdemux27: streaming stopped, reason error (-5)
I have not investigated yet.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/480RFC: entatransform plugin2021-09-24T14:34:52ZBugzilla Migration UserRFC: entatransform plugin## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#774991)](https://bugzilla.gnome.org/show_bug.cgi?id=774991)**
## Description
Vivante 2D GPUs feature a video rasterizer that is able to scale frames or to transf...## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#774991)](https://bugzilla.gnome.org/show_bug.cgi?id=774991)**
## Description
Vivante 2D GPUs feature a video rasterizer that is able to scale frames or to transform frames between certain pixel formats using a filter kernel.
The created the etnatransform plugin, which allows to use the video rasterizer via the etnaviv driver in Gstreamer pipelines.
The current plugin basically consists of code that was copied together from the xf86-video-armada driver (filter kernel) and the etnaviv tests in libdrm and repackaged to be usable as a Gstreamer plugin. It is not really well tested, would benefit a lot from some refactoring and modularization, and contains some crude workarounds.
It is not ready for inclusion in Gstreamer, but maybe someone finds use for it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/479iqa makes it difficult to support multiple metrics2021-09-24T14:34:52ZBugzilla Migration Useriqa makes it difficult to support multiple metrics## Submitted by LRN
**[Link to original bug (#774944)](https://bugzilla.gnome.org/show_bug.cgi?id=774944)**
## Description
This was discussed on the IRC, the gist is that iqa hardcodes all input to be converted to RGB for dssim, and...## Submitted by LRN
**[Link to original bug (#774944)](https://bugzilla.gnome.org/show_bug.cgi?id=774944)**
## Description
This was discussed on the IRC, the gist is that iqa hardcodes all input to be converted to RGB for dssim, and not all metrics can be computed on RGB.
One possible fix is to make existing Iqa class a dssim-only class (renaming it to IqaDssim), and implement other metrics as separate IqaSomething classes. Not a lot of code duplication, since GstVideoAggregator does most of the plumbing anyway.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/478mpegts: buffer offset set to GST_BUFFER_OFFSET_NONE2021-09-24T14:34:51ZBugzilla Migration Usermpegts: buffer offset set to GST_BUFFER_OFFSET_NONE## Submitted by Milos Seleceni
**[Link to original bug (#774837)](https://bugzilla.gnome.org/show_bug.cgi?id=774837)**
## Description
Hi, in mpegtsmux.c in function mpegtsmux_collected_buffer the input buffer has offset set to GST_B...## Submitted by Milos Seleceni
**[Link to original bug (#774837)](https://bugzilla.gnome.org/show_bug.cgi?id=774837)**
## Description
Hi, in mpegtsmux.c in function mpegtsmux_collected_buffer the input buffer has offset set to GST_BUFFER_OFFSET_NONE which is valid if we do not know it. In case of video stream this buffer offset should be the frame number stored in this buffer. I need that frame number to write it into the timecode property of Jpeg2000 ELSM header. I'm not able to track it back where the buffers are created and how to set right offset value.
Is it bug or we do not know the offset at this time ?
Can you help me to understand where the buffers are created and how can I add the correct offset? I guess that frame number should be already known when the mpegtsmux receive the buffer.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/477Update smoke codec2021-09-24T14:34:51ZBugzilla Migration UserUpdate smoke codec## Submitted by Andrew Esh
**[Link to original bug (#774801)](https://bugzilla.gnome.org/show_bug.cgi?id=774801)**
## Description
We ported a modified smoke codec from gstreamer 0.10 to 1.0. It builds, and has been tested within our...## Submitted by Andrew Esh
**[Link to original bug (#774801)](https://bugzilla.gnome.org/show_bug.cgi?id=774801)**
## Description
We ported a modified smoke codec from gstreamer 0.10 to 1.0. It builds, and has been tested within our system. We tried to use the existing smoke codec, but it seemed to be unmaintained. This patch should be used with caution.
Version: 1.9.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/476iqa does not take buffer formats into account2021-09-24T14:34:50ZBugzilla Migration Useriqa does not take buffer formats into account## Submitted by LRN
**[Link to original bug (#774781)](https://bugzilla.gnome.org/show_bug.cgi?id=774781)**
## Description
How to reproduce:
* Take two video streams, put them through iqa.
* Observe the result.
* Put videoconv...## Submitted by LRN
**[Link to original bug (#774781)](https://bugzilla.gnome.org/show_bug.cgi?id=774781)**
## Description
How to reproduce:
* Take two video streams, put them through iqa.
* Observe the result.
* Put videoconvert elements and capsfilters before iqa sinkpads and convert one stream into I420, the other to, say, BGRA.
* Observe that the result is different now.
Expected result:
iqa refuses to compare streams with different formats
OR
iqa internally (by itself or inside dssim library) converts streams into the same format as needed
Actual result:
iqa passes buffers from both streams to dssim, claiming that the streams have RGBA format, regardless of the actual stream formathttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/475Move GstPhotography interface to -base2021-09-24T14:34:50ZBugzilla Migration UserMove GstPhotography interface to -base## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774779)](https://bugzilla.gnome.org/show_bug.cgi?id=774779)**
## Description
We should move this. It is a prerequisite to moving camerabin.
Some comments/questions aft...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774779)](https://bugzilla.gnome.org/show_bug.cgi?id=774779)**
## Description
We should move this. It is a prerequisite to moving camerabin.
Some comments/questions after reviewing:
- GST_PHOTOGRAPHY_AUTOFOCUS_DONE: Name of custom GstMessage that will be
posted to #GstBus when autofocusing is complete. Shouldn't we have a
gst_photography_is_autofocus_done_message() for this, just like we have
gst_is_video_overlay_prepare_window_handle_message() and
gst_is_missing_plugin_message(), plus _parse_autofocus_done_message()?
- GST_PHOTOGRAPHY_SHAKE_RISK: same as for AUTOFOCUS done
- GST_PHOTOGRAPHY_PROP_*(): do we really want to require interface implementors
to implement all of these properties? And then again implement setters as
vfuncs? Seems a bit tedious, and also makes it more difficult for implementors
to only support some of the functionality, doesn't it? (properties are good
for things like automatic UI dialogs of course)
- struct GstPhotographySettings: used to set/get all options in one go. Assumes
implementor supports all options; duplicates other mechanisms of getting and
setting options (wrapper API for interface vfuncs and properties) with a third
option, and the wrapper func doesn't even have fallback code for when the
interface doesn't implement ::set_config or ::get_config.
- struct GstPhotographySettings: if we keep it it needs padding
- prepare_for_capture: why is the callback not done via a signal instead?
(also, no destroy_notify for user_data, but callback can do that I suppose)
How is failure communicated? Should we differentiate between still image and
video capture?
- typedef void (*GstPhotographyCapturePrepared) (gpointer data, const GstCaps *configured_caps);
why not GstPhotography-implementing object as first argument?
- set_autofocus: no gboolean return like all the others?
### Depends on
* [Bug 757352](https://bugzilla.gnome.org/show_bug.cgi?id=757352)
### Blocking
* [Bug 789741](https://bugzilla.gnome.org/show_bug.cgi?id=789741)