GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:36:32Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/746vc1parse: error when seeking2021-09-24T14:36:32ZBugzilla Migration Uservc1parse: error when seeking## Submitted by Ung, Teng En
**[Link to original bug (#796767)](https://bugzilla.gnome.org/show_bug.cgi?id=796767)**
## Description
Created attachment 372974
AVI vc1 video stream
When using this pipeline :-
"filesrc locatio...## Submitted by Ung, Teng En
**[Link to original bug (#796767)](https://bugzilla.gnome.org/show_bug.cgi?id=796767)**
## Description
Created attachment 372974
AVI vc1 video stream
When using this pipeline :-
"filesrc location=./ogg_vc1_2ch_44100hz_1920x_1080y_no_audio.avi ! avidemux ! queue ! avdec_vc1 ! xvimagesink"
There is no error.
But when adding vc1parse into the pipeline, the seek just return error.
"filesrc location=./ogg_vc1_2ch_44100hz_1920x_1080y_no_audio.avi ! avidemux ! queue ! vc1parse ! avdec_vc1 ! xvimagesink"
**Attachment 372974**, "AVI vc1 video stream":
[ogg_vc1_2ch_44100hz_1920x_1080y_no_audio.avi.xz](/uploads/41a0db6c416d69bb5b3a8717e5c30079/ogg_vc1_2ch_44100hz_1920x_1080y_no_audio.avi.xz)
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/748jitterbuffer: Flushing and timer thread2021-09-24T13:33:55ZEdward Herveyjitterbuffer: Flushing and timer threadAlmost all rtsp *seeking* validate tests are failing right now, one part of it is related to how jitterbuffer handles flushing.
The timer thread is:
* Started in READY=>PAUSED (but actually blocked until PAUSED=>PLAYING)
* Stopped in PA...Almost all rtsp *seeking* validate tests are failing right now, one part of it is related to how jitterbuffer handles flushing.
The timer thread is:
* Started in READY=>PAUSED (but actually blocked until PAUSED=>PLAYING)
* Stopped in PAUSED=>READY (but the blocked variable is set in PLAYING=>PAUSED)
The problem is that this assumes that the jitterbuffer:
* Will only ever go to PLAYING once
* Will never ever get any FLUSH events (resetting the contents)
* By extension will never see more than one EOS
If the jitterbuffer receives a flush start/stop events:
* It won't reset all the timers (especially the EOS one)
* It won't stop waiting and put itself in a "before anything arrived" state
When the pads are deactivated (PAUSED=>READY) that thread won't put itself in a "Ready to be stoped" state either which can cause various deadlockshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/747ksvideosrc: fails to initialize Datapath VisionRGB-E2S2021-09-24T14:36:32ZBugzilla Migration Userksvideosrc: fails to initialize Datapath VisionRGB-E2S## Submitted by bou..@..il.com
**[Link to original bug (#796769)](https://bugzilla.gnome.org/show_bug.cgi?id=796769)**
## Description
Created attachment 372982
debugLevel6
I have a Datapath VisionRGB-E2S capture device.
It ...## Submitted by bou..@..il.com
**[Link to original bug (#796769)](https://bugzilla.gnome.org/show_bug.cgi?id=796769)**
## Description
Created attachment 372982
debugLevel6
I have a Datapath VisionRGB-E2S capture device.
It is installed on windows and works fine using directshow.
I am trying to open its stream through GStreamer, and the provided command by gst-device-monitor-1.0.exe fails with "reason-not-negotiated `<-4>`".
I've added the gst-device-monitor output, and a level 6 debug output.
**Attachment 372982**, "debugLevel6":
[DebugInfo.tar.gz](/uploads/56f0a8ad0c0420d4a0ad21f39c47dd9e/DebugInfo.tar.gz)
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/752Chained compositors causes racy not-negotiated error2021-09-24T13:25:50ZJan SchmidtChained compositors causes racy not-negotiated errorThis pipeline fails with a not-negotiated error about 75% of the time, but succeeds randomly:
`gst-launch-1.0 videotestsrc ! compositor ! video/x-raw,width=1920,height=1080 ! timeoverlay ! compositor name=overlay ! fakesink`
Removing e...This pipeline fails with a not-negotiated error about 75% of the time, but succeeds randomly:
`gst-launch-1.0 videotestsrc ! compositor ! video/x-raw,width=1920,height=1080 ! timeoverlay ! compositor name=overlay ! fakesink`
Removing either compositor, or the timeoverlay, makes it work reliably. The negotiation error is related to trying to output GstVideoOverlayComposition meta through the capsfilter that disallows it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/748compositor: transition output frame looks ugly2021-09-24T14:36:32ZBugzilla Migration Usercompositor: transition output frame looks ugly## Submitted by Seungha Yang
**[Link to original bug (#796770)](https://bugzilla.gnome.org/show_bug.cgi?id=796770)**
## Description
Dynamic layout change (e.g., g_object_set(GstCompositorPad, ...)) produces ugly frame(s) since GstC...## Submitted by Seungha Yang
**[Link to original bug (#796770)](https://bugzilla.gnome.org/show_bug.cgi?id=796770)**
## Description
Dynamic layout change (e.g., g_object_set(GstCompositorPad, ...)) produces ugly frame(s) since GstCompositorPad's member variables might be modified while aggregate_frame() is running.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/753gldownload of RGB buffers broken on GLES 2.0 contexts2021-09-24T13:25:50ZLucas Stachgldownload of RGB buffers broken on GLES 2.0 contextsOn GLES 2.0 contexts the only way to get the Pixel data is via glReadPixels. As per the spec this function supports only two valid format values: `GL_RGBA` and the format returned by `GL_IMPLEMENTATION_COLOR_READ_FORMAT`. Most GLES imple...On GLES 2.0 contexts the only way to get the Pixel data is via glReadPixels. As per the spec this function supports only two valid format values: `GL_RGBA` and the format returned by `GL_IMPLEMENTATION_COLOR_READ_FORMAT`. Most GLES implementations allow the user to create GL_RGB textures, but will use an internal format of `GL_RGBA`, as that is what the hardware supports. As `GL_IMPLEMENTATION_COLOR_READ_FORMAT` is defined to return the preferred read format for the framebuffer object, those implementations will return `GL_RGBA` when asked for the read format, as this is the format that allows them to implement the glReadPixels with the least amount of data transformations.
This causes the format check in gst_gl_memory_read_pixels() to fail. So while the pipeline happily negotiated `format=RGB`, the gldownload is unable to download the pixel data.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/749camerabin: Fix elements_created state tracking2021-09-24T14:36:33ZBugzilla Migration Usercamerabin: Fix elements_created state tracking## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796790)](https://bugzilla.gnome.org/show_bug.cgi?id=796790)**
## Description
This fixes error recovery in Cheese application.## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796790)](https://bugzilla.gnome.org/show_bug.cgi?id=796790)**
## Description
This fixes error recovery in Cheese application.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/756decodebin3: Limiting buffer size to the interleave is too strict for streams ...2021-09-24T13:25:51ZSebastian Drögedecodebin3: Limiting buffer size to the interleave is too strict for streams with frame reorderingdecodebin3 tries (very successfully) to keep the amount of buffering as minimal as possible, and as close to the interleave as possible. This however has problems with frame reordering: the decoder would need more frames than the contain...decodebin3 tries (very successfully) to keep the amount of buffering as minimal as possible, and as close to the interleave as possible. This however has problems with frame reordering: the decoder would need more frames than the container interleave before it can output something. Not having enough buffering would cause the pipeline to never pre-roll then.
In theory this could be gotten from the decoders if they report the latency correctly, but latency reporting is optional in non-live pipelines so that also can't be relied upon.
The same problem would also happen if a decoder decides to not output frames for other reasons (e.g. they're too corrupted). With ffmpeg we get that information quite reliable, with other decoders not so much (OMX :scream: )
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/116#note_505785https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/759playbin3: Add a mechanism to avoid requiring apps to connect synchronously to...2022-04-30T07:08:13ZThibault Sauniertsaunier@igalia.complaybin3: Add a mechanism to avoid requiring apps to connect synchronously to the bus to do stream selectionRight now the correct way to select streams with playbin3/decodebin3/uridecodebin3 is by connecting synchronously on the bus to listen to the `STREAM_COLLECTION` signal, and from that callback, send a `SELECT_STREAMS` event to the elemen...Right now the correct way to select streams with playbin3/decodebin3/uridecodebin3 is by connecting synchronously on the bus to listen to the `STREAM_COLLECTION` signal, and from that callback, send a `SELECT_STREAMS` event to the elements. While this work it is not ideal as the idea of having a pipeline bus is to hide threading away from the application, which is not the case here.
This was discussed on IRC and I am pasting here the conversation verbatim:
```
bilboed: Was the SELECT_STREAM message design to be answered on an async bus
handler ? I observed that it was needed to be done synchronously which it a bit
cumbersome for apps
bilboed message ? There's only an event
slomo you mean the STREAM_COLLECTION message?
and based on that you'd like to do the initial SELECT_STREAM event to get a
SELECTED_STREAMS message with the streams you wanted, without having the
element first select its own default selection? then you need to handle it
from a sync handler indeed
bilboed and yes, ideally it should be answered synchronously. But if you
*already* have preferences (like, you prefer french audio), it's quite fast to
match, no ? you can always preroll first :)
slomo that's rather awkward too though, you'd have to handle all the pads that
appear. select things. pads might disappear, new ones might appear, etc. and
you'd need to remove sinks potentially without deadlocking i think the only way
to handle that cleanly is via a sync message handler for now
bilboed pads might disappear ? Not unless you decide to disable a certain stream
type (like no audio)
thiblahute Right, I meant STREAM_COLLECTION, where you supposedly need to answer
with a select-stream event.
bilboed: How soon are we supposed to be able to send the event? (I am porting
GES and I actually know it even before the pipeline start)
bilboed you don't *need* to answer with a SELECT_STREAM event you can just let
it do its automatic/default selection
slomo bilboed: yes, you might only care about video for example :)
thiblahute Well in case you want to select streeams... obviously :-) (And
forcing a special stream type is basically what I fixed in my last MR :-))
bilboed thiblahute, you can't really send that SELECT_STREAM event before
there's something to handle that event :) So yes, the earliest would be when a
collection is posted on the bus note that for GES you want something else in
addition you want to do *DISABLE* completely certain streams selecting streams
!= other streams are completely disabled
thiblahute Right, so yes it needs to be sync, which is not ideal for apps fmpov
(in GES it is not a big deal)
bilboed: Well at least no decoder is plugged, how do you completely disable
streams then?
slomo maybe there should be a flag that it does not default selection at all,
and waits for the application to do so?
bilboed a flag ... on what/where ?
slomo bilboed: not sure, on urisourcebin/dbin it would only stop those from
doing default selection... but wouldn't prevent e.g. a demuxer from doing a
default selection
bilboed also ... how would you prevent all the streaming threads from moving
forward ? By blocking them ? Like ... in a synchronous handler of some sort ? (a
bus message handler maybe ? :)
slomo bilboed: maybe some kind of GstContext on the pipeline, the standard
solution ;) that could also carry some default stream selection ("no audio
streams") or whatever if that seems useful to have
bilboed: if there was such a flag, i'd expect the elements to block until the
know which streams to output. not sure how well that works though, was just an
idea for how it could be easier for the application
bilboed why is it so hard to handle things in a synchronous message handler ?
thiblahute Well, the whole idea of the bus is to hide threads away from the app,
and fmpov we should try hard to make that a reality in all context
slomo multithreading is hard, applications often fail with getting these details
right in gstreamer. which is why we have the bus at all, why we have the
property notification messages (instead of just the notify signal), etc. the
videooverlay interface is an existing example where it makes things difficult
for applications
thiblahute (And I bet many people will answer from an async handler and not
understand what is going on)
slomo (and why we implemented it in playbin with caching and stuff so many
applications don't have to care)
generally we should try to not make it a requirement for new APIs that
applications have to handle things from random threads, more often than not they
get it wrong and things misbehave
thiblahute: i think a sync bus handler is also potentially problematic in python
with the GIL? it would kind of serialize the pipeline startup
* bilboed cries
thiblahute Yeah, I guess you could avoid that by connecting to
sync-message::stream-collection (or mitigate that at least)
bilboed ok, so how about this : have in playbin a sync handler delegator of
sorts
slomo thiblahute: indeed, that should work here. another footgun though :)
bilboed (note: "in playbin", not the default behaviour) requiring elements to do
more than just "post collection on bus, from that moment expect SELECT_STREAMS
event to potentially arrive" is going to be a burden slomo it would have to be
opt-in also (and even if just for backwards compatibility, the streams API is
stable) i don't know, needs some thinking. could also just be handled in
GstPlayer and if someone uses playbin directly we assume they know how to handle
threads
bilboed that too the problem is that the core (longer term) goal is to avoid any
un-needed processing/io/mem. And there's only one place/way you can do that : in
the element that can expose/handle those streams and *before* it decides what to
expose/output
slomo thiblahute: maybe create an issue for this so it's not forgotten? i don't
think we're going to come up with a solution now :)
bilboed: and another problem with it not outputting anything until the
STREAM_SELECT message is... that outputting something might be necessary
so that further downstream can know what streams it could output. or not?
bilboed "it" ?
__tim don't we have messages that you can post where the post() blocks til the
app has handled (or ignored) the message?
bilboed __tim, no we're not going down that road
slomo, the moment a stream provider (i.e. what posts collection and can handle
SELECT_STREAM events) has decided (or knows) what it's going to output, it posts
the STREAMS_SELECTED message on the bus
slomo __tim: yes in theory, but i don't think it works the way it would be
needed here. it's all a bit strange :)
bilboed slomo, let me triple-check, but it should be before any data is
outputted from db3
slomo bilboed: maybe a demuxer knows about a video stream, and posts the
message. further downstream at some point h264parse sees a CC stream in there
and extends the message. or container-in-container scenarios
bilboed slomo, that needs the capability for elements to notify the presence of
a stream within another (i.e. sub-streams) slomo, I have a plan for that
slomo bilboed: ack, i remember we talked about that at least once
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/755srt: Refactor plugin to support non-blocking SRT APIs2021-09-24T14:36:34ZBugzilla Migration Usersrt: Refactor plugin to support non-blocking SRT APIs## Submitted by Seungha Yang
**[Link to original bug (#796842)](https://bugzilla.gnome.org/show_bug.cgi?id=796842)**
## Description
Add support "srt://localhost:port" style uri, and change the
default host to "localhost"## Submitted by Seungha Yang
**[Link to original bug (#796842)](https://bugzilla.gnome.org/show_bug.cgi?id=796842)**
## Description
Add support "srt://localhost:port" style uri, and change the
default host to "localhost"https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/760gl: add binding friendly version of GST_GL_COLOR_CONVERT_FORMATS2021-09-24T13:25:52ZVíctor Manuel Jáquez Lealgl: add binding friendly version of GST_GL_COLOR_CONVERT_FORMATSAnd perhaps for GST_GL_MEMORY_VIDEO_FORMATS_STR too
This is similar to https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/676
And it was noted by @slomo on https://gitlab.freedesktop.org/gstreamer/gst-plugins-ba...And perhaps for GST_GL_MEMORY_VIDEO_FORMATS_STR too
This is similar to https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/676
And it was noted by @slomo on https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/678https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/761gldeinterlace: does not mention interlace-mode on its src pad2021-09-24T13:25:53ZRussel Windergldeinterlace: does not mention interlace-mode on its src padThe deinterlace element, and indeed many other elements, state what the interlace-mode is on the src pad. It seems that the gldeinterlace element does not given the evidence of a pipeline diagram that includes a gldeinterlace element.The deinterlace element, and indeed many other elements, state what the interlace-mode is on the src pad. It seems that the gldeinterlace element does not given the evidence of a pipeline diagram that includes a gldeinterlace element.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/758multiudpsink and udpsink ipv6 support for the "clients" property2021-09-24T13:33:56Zbicbenmultiudpsink and udpsink ipv6 support for the "clients" propertyWhen I'm using udpsink element with ipv6 addresses it works fine if I define the destination through "host" and "port" properties but when I'm using the "clients" property in both udpsink and multiudpsink the elements don't send anything...When I'm using udpsink element with ipv6 addresses it works fine if I define the destination through "host" and "port" properties but when I'm using the "clients" property in both udpsink and multiudpsink the elements don't send anything.
If I run a simple debug pipeline like `GST_DEBUG=*udpsink*:5 gst-launch-1.0 videotestsrc ! udpsink clients="2001:8db6:85a3:8d3:1319:8a2e:370:7348:5004"` the debug output says that the udpsink is trying to send data to host 2001 with port 8. In other words it reacts to the first colon symbol as an end of host address and a start of the port number.
I was trying surround the host part with square brackets, shoving "\\" before the colon symbols and many other things.
Moreover if I use the "add" signal to add a new destination it adds ipv6 addresses in the same manner as in the pipeline described above.
I understand that there IS a method to use ipv6 addresses in "clients" property because the source code of those elements clearly have methods to use and sort them but there are no documentations and/or tutorials about the proper syntax or manner of using the ipv6 addresses so it is too obscure for me. Hope you understand, thank you.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/759gstreamer pipeline cannot put tags into m4a file2023-08-14T07:59:56Zsezanzebgstreamer pipeline cannot put tags into m4a fileMaybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstr...Maybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstreamer-pipeline-cannot-put-tags-into-m4a-file
Using the following pipeline
```
gst-launch-1.0 filesrc location="/home/mango/Desktop/gst-test/input.mp3" name=src \
! decodebin \
! audioconvert \
! faac \
! mp4mux \
! filesink location="/home/mango/Desktop/gst-test/output.m4a" \
```
I get
`0:00:00.046300293 8742 0x7f4e340779e0 WARN audioencoder gstaudioencoder.c:965:gst_audio_encoder_finish_frame:<faac0> Can't copy metadata because input buffer disappeared`
It also happens with avenc_aac.
mp4mux is in plugins_good, decodebin in plugins_base and faac in plugins_bad according to gst-inspect-1.0, so I don't know which repo to use to post this issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/763videoconvert: disregards downstream preferences for the format2021-09-24T13:25:53ZMathieu Duponchellevideoconvert: disregards downstream preferences for the formatWith such a pipeline:
```
src ! videoconvert ! glupload ! glcolorconvert ! filter_element_expecting_BGRA
```
Videoconvert gets to fixate these caps:
```
video/x-raw, format=BGRA; video/x-raw, format = {all, the, formats, glcolorconver...With such a pipeline:
```
src ! videoconvert ! glupload ! glcolorconvert ! filter_element_expecting_BGRA
```
Videoconvert gets to fixate these caps:
```
video/x-raw, format=BGRA; video/x-raw, format = {all, the, formats, glcolorconvert, supports}
```
When fixating however, videoconvert ignores the higher preference level expressed by having two separate structures in the caps, as it simply flattens all the pixel formats and picks one according to its scoring heuristic.
Ideally, videoconvert should consider each structure independently, unclear however whether this will break existing scenarios.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/760avimux: should error out if video input caps are missing2021-09-24T13:33:57ZFolkert van Heusdenavimux: should error out if video input caps are missing[gst.cpp](/uploads/3fcf33cdf08cb6cc2ee1b01ec38147b9/gst.cpp)
When running this program, you'll end up with test.avi which has resolution 0x0 and > 30 fps.[gst.cpp](/uploads/3fcf33cdf08cb6cc2ee1b01ec38147b9/gst.cpp)
When running this program, you'll end up with test.avi which has resolution 0x0 and > 30 fps.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/759hlssink/hlssink22021-09-24T14:36:34ZBugzilla Migration Userhlssink/hlssink2## Submitted by ign..@..ent.be
**[Link to original bug (#796907)](https://bugzilla.gnome.org/show_bug.cgi?id=796907)**
## Description
This is a request for more control over segment name formatting (i.e. the "location" property of h...## Submitted by ign..@..ent.be
**[Link to original bug (#796907)](https://bugzilla.gnome.org/show_bug.cgi?id=796907)**
## Description
This is a request for more control over segment name formatting (i.e. the "location" property of hlssink/hlssink2)
Currently, segment names are stored as absolute paths if a different playlist-root is specified. This makes no sense to clients that have only access to the folder containing the playlist and segments, but not the full filesystem. This is a regression introduced coming from the fix of 687133 that prepends the location-root if it is available, but also uses the same path as entry in the m3u8.
Common use case would be a HLS client connecting through a webserver, which would read the segment path and request it through the webserver. The suggestion is to have either an option to force just the segment name as configured by the "location" property, instead of prepending it with the playlist-root, or an additional configurable pattern property that can be set based on pipeline properties (see next paragraph).
Another nice-to-have would be to allow segment filenames to be tored in mockup folder structures (.e.g depending on the encoding caps) of each .ts. The mockup name can be resolved by the webserver internally. This would add additional security to the service, and also allow for loadbalancing in dynamic streaming situations.
Kind regards,
Ignace
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/760rsvg: Add animated SVG support2021-09-24T14:36:34ZBugzilla Migration Userrsvg: Add animated SVG support## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796909)](https://bugzilla.gnome.org/show_bug.cgi?id=796909)**
## Description
The following pipeline output EOS but no buffer:
```
gst-validate-1.0 uride...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796909)](https://bugzilla.gnome.org/show_bug.cgi?id=796909)**
## Description
The following pipeline output EOS but no buffer:
```
gst-validate-1.0 uridecodebin uri=https://gitlab.gnome.org/GNOME/pitivi/uploads/8dd8d9d988b5eb6cc38f871196caac6f/Titel-Tafel3.2_anim.svg ! imagefreeze ! identity silent=false ! videoconvert ! checksumsink
```
It should output the exact animation described in the SVG.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/765audioresample: add OpenPOWER ppc64 support2021-09-24T13:25:53ZDaniel Pocockaudioresample: add OpenPOWER ppc64 supportaudioresample includes some custom assembly
There is growing interest in the OpenPOWER architecture.
IBM is currently offering bounties to developers who will port free software projects to OpenPOWER
Providing an implementation of the...audioresample includes some custom assembly
There is growing interest in the OpenPOWER architecture.
IBM is currently offering bounties to developers who will port free software projects to OpenPOWER
Providing an implementation of the code for OpenPOWER ISA appears to be a good idea for a bounty
Alternatively, could the custom assembly be managed as part of liborc?
A bounty was offered for similar work in ffmpeg libswscale and a developer has provided a solution for that
https://www.bountysource.com/issues/34315232-power8-vsx-vectorization-libswscale-input-c
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1585056463-7934-1-git-send-email-pestov.vyach@yandex.ru/https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/761ttml: Do not ignore style elements2021-09-24T14:36:34ZBugzilla Migration Userttml: Do not ignore style elements## Submitted by joonyoung.kwak
**[Link to original bug (#796911)](https://bugzilla.gnome.org/show_bug.cgi?id=796911)**
## Description
In the previous version, the style set of the "style"
tag was ignored although including the "st...## Submitted by joonyoung.kwak
**[Link to original bug (#796911)](https://bugzilla.gnome.org/show_bug.cgi?id=796911)**
## Description
In the previous version, the style set of the "style"
tag was ignored although including the "style" tag in a element.
In order to apply the style set of included "style" tag
to the element, the recursion is required to merge style of child elements.