gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2021-09-24T13:21:24Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/201GstVideoEncoder could expose a "max-keyframe-distance" property2021-09-24T13:21:24ZBugzilla Migration UserGstVideoEncoder could expose a "max-keyframe-distance" property## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751554)](https://bugzilla.gnome.org/show_bug.cgi?id=751554)**
## Description
From IRC:
`<Mathieu_Du>` Hm I've got an interesting issue here, so youtube says "...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751554)](https://bugzilla.gnome.org/show_bug.cgi?id=751554)**
## Description
From IRC:
`<Mathieu_Du>` Hm I've got an interesting issue here, so youtube says "key-int-max" should be half the framerate, I'd like to have that in the preset, seems a bit involved tho
`<__tim>` you can't really specify that currently
`<Mathieu_Du>` Yep that's understandable
`<Mathieu_Du>` Alternate solution would be to have a key-int-max / framerate ratio in x264enc, but that might be a little too specific ?
`<Mathieu_Du>` (as a new prop)
`<__tim>` max-keyframe-distance in nanosecs perhaps
[snip]
__tim> the encoder base class can probably "enforce" that even if the encoder supports forcing keyframes
[snip]
`<__tim>` the encoder can still set key-int-max based on that property
`<__tim>` the base class handling is just a fallback really
So yep, being able to specify a maximum keyframe distance in nanoseconds would be a valuable addition, and putting that in the baseclass would indeed allow enforcability, what do you folks think ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/198encodebin: Add a profile-string property.2021-09-24T13:21:23ZBugzilla Migration Userencodebin: Add a profile-string property.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751469)](https://bugzilla.gnome.org/show_bug.cgi?id=751469)**
## Description
This code was written by Thibault Saunier, and used in
GES and gst-devtools.
Th...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751469)](https://bugzilla.gnome.org/show_bug.cgi?id=751469)**
## Description
This code was written by Thibault Saunier, and used in
GES and gst-devtools.
The documentation is lifted from gst-devtools.
It is write-only for now, I don't yet see a use-case for
serialization.
This will allow encodebin to be used from the command-line,
and allow removing code in devtools and GES.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/197playbin: try to auto-load subtitles2021-09-24T13:21:23ZBugzilla Migration Userplaybin: try to auto-load subtitles## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#751445)](https://bugzilla.gnome.org/show_bug.cgi?id=751445)**
## Description
As a result of the discussion in [bug 745292](https://bugzilla.gnome.org/sho...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#751445)](https://bugzilla.gnome.org/show_bug.cgi?id=751445)**
## Description
As a result of the discussion in [bug 745292](https://bugzilla.gnome.org/show_bug.cgi?id=745292), this patch enables the same
functionality but in the playbin itself.
### See also
* [Bug 745292](https://bugzilla.gnome.org/show_bug.cgi?id=745292)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/194tools: gst-play: Print artist/album/title tags2021-09-24T13:21:20ZBugzilla Migration Usertools: gst-play: Print artist/album/title tags## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#750721)](https://bugzilla.gnome.org/show_bug.cgi?id=750721)**
## Description
Created attachment 304992
Patch file
Print artist/album/title information for ea...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#750721)](https://bugzilla.gnome.org/show_bug.cgi?id=750721)**
## Description
Created attachment 304992
Patch file
Print artist/album/title information for each track played.
**Patch 304992**, "Patch file":
[0001-tools-gst-play-Print-artist-album-title-tags.patch](/uploads/182292dc6b55409965f69a05585473e9/0001-tools-gst-play-Print-artist-album-title-tags.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/191tcpclientsink: setting socket send buffer size2021-09-24T13:21:19ZBugzilla Migration Usertcpclientsink: setting socket send buffer size## Submitted by Prashant Gotarne
**[Link to original bug (#750328)](https://bugzilla.gnome.org/show_bug.cgi?id=750328)**
## Description
Set the socket send buffer size option >= size of buffer
to be render to improve the performa...## Submitted by Prashant Gotarne
**[Link to original bug (#750328)](https://bugzilla.gnome.org/show_bug.cgi?id=750328)**
## Description
Set the socket send buffer size option >= size of buffer
to be render to improve the performance.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/190tcpclientsrc: add buffer-size property for element2021-09-24T13:21:18ZBugzilla Migration Usertcpclientsrc: add buffer-size property for element## Submitted by Prashant Gotarne
**[Link to original bug (#750320)](https://bugzilla.gnome.org/show_bug.cgi?id=750320)**
## Description
tcpclientsrc element always sends the fix buffer size < 4096
If server sends larger data, tcpc...## Submitted by Prashant Gotarne
**[Link to original bug (#750320)](https://bugzilla.gnome.org/show_bug.cgi?id=750320)**
## Description
tcpclientsrc element always sends the fix buffer size < 4096
If server sends larger data, tcpclientsrc elements takes lot of
time to read it.
Buffer created by the tcpclientsrc element are always <= 4096.
Even though tcpclientsrc is derived from basesrc element,
the blocksize property of the basesrc is not applied to tcpclientsrc.
This is because the basesrc element's "create" virtual function is hidden
by the pushsrc element's "create" virtual function.
tcpclientsrc implements the pushsrc element's "create" function.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/189encodebin: Force restriction caps to be exactly constant when dynamic output ...2021-09-24T13:21:18ZBugzilla Migration Userencodebin: Force restriction caps to be exactly constant when dynamic output is disabled## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#750266)](https://bugzilla.gnome.org/show_bug.cgi?id=750266)**
## Description
Created attachment 304416
encodebin: Force restriction caps to be exactly consta...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#750266)](https://bugzilla.gnome.org/show_bug.cgi?id=750266)**
## Description
Created attachment 304416
encodebin: Force restriction caps to be exactly constant when dynamic output is disabled
Otherwise a change of restriction caps can lead to a change in the encoded stream which leads to not negotiated error as the output is forced to be constant.
**Patch 304416**, "encodebin: Force restriction caps to be exactly constant when dynamic output is disabled":
[0001-encodebin-Force-restriction-caps-to-be-exactly-const.patch](/uploads/28877a4f1d4d75ca68a810466a253291/0001-encodebin-Force-restriction-caps-to-be-exactly-const.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/188multi*: Could handle properly ES KEYFRAME combined with headers2021-09-24T13:21:16ZBugzilla Migration Usermulti*: Could handle properly ES KEYFRAME combined with headers## Submitted by Nicola `@drakkan`
**[Link to original bug (#749649)](https://bugzilla.gnome.org/show_bug.cgi?id=749649)**
## Description
Please take a look at the file here:
http://195.250.34.59/temp/734124.gdp
and use a p...## Submitted by Nicola `@drakkan`
**[Link to original bug (#749649)](https://bugzilla.gnome.org/show_bug.cgi?id=749649)**
## Description
Please take a look at the file here:
http://195.250.34.59/temp/734124.gdp
and use a pipeline like this:
filesrc ! gdpdepay ! h264parse ! video/x-h264,stream-format=avc,alignment=au ! fakesink silent=false
you will see that all keyframes have header flag too
fakesink0:sink) (338607 bytes, dts: 0:00:15.118625403, pts: 0:00:15.152625403, duration: 0:00:00.033333333, offset: 7302216, offset_end: -1, flags: 00000400 header ) 0x7f47f008cb20
in h264parse, here
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/videoparsers/gsth264parse.c#n1878
both h264parse->keyframe and h264parse->header are true, since there is no explicit flag for a keyframe how is supposed an app to find them? I based my code on the one from multihandlesink
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/tcp/gstmultihandlesink.c#n1140
that will not recognize keyframes in this casehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/186avsamplebuffersink: support CM and CV metas2021-09-24T13:21:15ZBugzilla Migration Useravsamplebuffersink: support CM and CV metas## Submitted by Ilya Konstantinov
**[Link to original bug (#748990)](https://bugzilla.gnome.org/show_bug.cgi?id=748990)**
## Description
avsamplebuffersink currently doesn't use CMSampleBuffer or CVPixelBuffer metas if present in th...## Submitted by Ilya Konstantinov
**[Link to original bug (#748990)](https://bugzilla.gnome.org/show_bug.cgi?id=748990)**
## Description
avsamplebuffersink currently doesn't use CMSampleBuffer or CVPixelBuffer metas if present in the GstBuffer, instead reconstructing the CVPixelBuffer and CMSampleBuffer.
For buffers coming from other applemedia elements, this needlessly locks them into CPU memory. (And also needlessly does CV and CM housekeeping structure allocations.)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/182crop handling in gl plugins (gleffect, glimagesink, glshader, .....)2021-09-24T13:21:13ZBugzilla Migration Usercrop handling in gl plugins (gleffect, glimagesink, glshader, .....)## Submitted by Jian Li
**[Link to original bug (#748163)](https://bugzilla.gnome.org/show_bug.cgi?id=748163)**
## Description
Is there a plan to support video cropping in gl plugins?
Although this can be done when you uploading ...## Submitted by Jian Li
**[Link to original bug (#748163)](https://bugzilla.gnome.org/show_bug.cgi?id=748163)**
## Description
Is there a plan to support video cropping in gl plugins?
Although this can be done when you uploading the pixel data into texture, there is still cases that you can use some extension to bind a buffer to the texture, such as eglimage, dma-bufer or some private extensions. If decoder needs padding or alignment when output video into this buffer, the gl plugins need to handle it correctly.
I tried to support it, but have below question:
1. How to get the video buffer width and height?
I can get crop info from GstVideoCropMeta, but how can I get the buffer width and height? We can get real video width/height from GstVideoInfo, but can't get the buffer widht/height after padding/aligned. One way I found is like below for I420 and NV12 video:
videometa = gst_buffer_get_video_meta (buf);
bufw = videometa->stride[0];
bufh = videometa->offset[1] / bufw;
Is there a better way to get this info?
2. Supporting crop handling only need to recalculate the texture coordinate, but I found every gl plugin has their own vertices definition, this means I need to modify everywhere to support this.
Is there a plan to make it into a common module?
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/181videotestsrc: add a 'max-duration' property2021-09-24T13:21:13ZBugzilla Migration Uservideotestsrc: add a 'max-duration' property## Submitted by Swen Kooij
**[Link to original bug (#748105)](https://bugzilla.gnome.org/show_bug.cgi?id=748105)**
## Description
Created attachment 301900
videotestsrc: add a 'max-duration' property
This patch adds a new pro...## Submitted by Swen Kooij
**[Link to original bug (#748105)](https://bugzilla.gnome.org/show_bug.cgi?id=748105)**
## Description
Created attachment 301900
videotestsrc: add a 'max-duration' property
This patch adds a new property to the `videotestsrc` element that allows you to set the maximum duration. After the specified time (in nano seconds) the `videotestsrc` will push EOS onto it's src pad.
There are other ways to do this of course, but I found this the most accurate method. So, I am not entirely sure this change is an acceptable one.
Tested on Linux/Debian x64 (patch file was generated on Windows). Patch is against master.
**Patch 301900**, "videotestsrc: add a 'max-duration' property":
[0001-videotestsrc-added-max-duration-property.patch](/uploads/7911527669868ca23e050b319beac952/0001-videotestsrc-added-max-duration-property.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/177EXIF tags: should write strings as UTF-8 by default, not Latin12021-09-24T13:21:11ZBugzilla Migration UserEXIF tags: should write strings as UTF-8 by default, not Latin1## Submitted by Tim Müller `@tpm`
**[Link to original bug (#747315)](https://bugzilla.gnome.org/show_bug.cgi?id=747315)**
## Description
+++ This bug was initially created as a clone of [Bug 723252](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#747315)](https://bugzilla.gnome.org/show_bug.cgi?id=747315)**
## Description
+++ This bug was initially created as a clone of [Bug 723252](https://bugzilla.gnome.org/show_bug.cgi?id=723252) +++
Currently we seem to write all EXIF tag strings in Ascii/Latin1 format, which is rather suboptimal. We should investigate how to write strings in UTF-8 or some other unicode variant.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/176alsa: add uri handler2021-09-24T13:21:11ZBugzilla Migration Useralsa: add uri handler## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746762)](https://bugzilla.gnome.org/show_bug.cgi?id=746762)**
## Description
Created attachment 300296
GstUri interface on alsa
Add a uri interface to alsa. ...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746762)](https://bugzilla.gnome.org/show_bug.cgi?id=746762)**
## Description
Created attachment 300296
GstUri interface on alsa
Add a uri interface to alsa.
Code was written against 1.4.5 (after being used internally for 2 years) with gsturi from git (in gstreamer-core).
~~**Patch 300296**~~, "GstUri interface on alsa":
[0001-Add-uri-handler-for-alsasrc-and-alsasink-elements.patch](/uploads/3d7b4f5bc3944840a4c14cc45ee9dc2c/0001-Add-uri-handler-for-alsasrc-and-alsasink-elements.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/173tests: Add unit test for alpha manipulation in video-converter2021-09-24T13:21:10ZBugzilla Migration Usertests: Add unit test for alpha manipulation in video-converter## Submitted by RaviKiran
**[Link to original bug (#746142)](https://bugzilla.gnome.org/show_bug.cgi?id=746142)**
## Description
Add unit test for alpha manipulation in video-converter.## Submitted by RaviKiran
**[Link to original bug (#746142)](https://bugzilla.gnome.org/show_bug.cgi?id=746142)**
## Description
Add unit test for alpha manipulation in video-converter.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/168video: support YUYV fourcc as alias for YUY22021-09-24T13:21:08ZBugzilla Migration Uservideo: support YUYV fourcc as alias for YUY2## Submitted by Aleix Conchillo Flaqué
**[Link to original bug (#745639)](https://bugzilla.gnome.org/show_bug.cgi?id=745639)**
## Description
Calling gst_video_format_from_fourcc with YUYV returns GST_VIDEO_FORMAT_UNKNOWN,
YUYV...## Submitted by Aleix Conchillo Flaqué
**[Link to original bug (#745639)](https://bugzilla.gnome.org/show_bug.cgi?id=745639)**
## Description
Calling gst_video_format_from_fourcc with YUYV returns GST_VIDEO_FORMAT_UNKNOWN,
YUYV is an alias for YUY2 so it should return YUY2 safely.
I've found this by reading the pixelformat from v4l2.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/166gst-play: load local subtitles2021-09-24T13:21:07ZBugzilla Migration Usergst-play: load local subtitles## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#745292)](https://bugzilla.gnome.org/show_bug.cgi?id=745292)**
## Description
I don't want to bloat gst-play, but, at same time, I think this little snipp...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#745292)](https://bugzilla.gnome.org/show_bug.cgi?id=745292)**
## Description
I don't want to bloat gst-play, but, at same time, I think this little snippet
might be useful as implementation reference.
Basically it mimics mplayer's functionality, loading the subtitle file if it
is present in the same path of the media file with 'srt' extension.
### See also
* [Bug 751445](https://bugzilla.gnome.org/show_bug.cgi?id=751445)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/162gl: add selection of backing pixel formats/config attributes2021-09-24T13:21:05ZBugzilla Migration Usergl: add selection of backing pixel formats/config attributes## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#744187)](https://bugzilla.gnome.org/show_bug.cgi?id=744187)**
## Description
All the GL platforms (egl, glx, cgl, wgl, etc) allow the possibility of selecting the p...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#744187)](https://bugzilla.gnome.org/show_bug.cgi?id=744187)**
## Description
All the GL platforms (egl, glx, cgl, wgl, etc) allow the possibility of selecting the pixel format for the window that is rendered into as well as miscellaneous context config options. We should expose that.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/161Vertical position of subtitles playbin and subtitleoverlay2021-09-24T13:21:05ZBugzilla Migration UserVertical position of subtitles playbin and subtitleoverlay## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#744056)](https://bugzilla.gnome.org/show_bug.cgi?id=744056)**
## Description
Created attachment 296209
01- patch for subtitleoverlay
Two nights ago I wen...## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#744056)](https://bugzilla.gnome.org/show_bug.cgi?id=744056)**
## Description
Created attachment 296209
01- patch for subtitleoverlay
Two nights ago I went to an event hosted by a spanish academy where they projected a spanish film at a pub. Since most of the people in the room are learning spanish, they had english subtitles for educational purposes. And since the venue wasn't designed for this (group of chairs in flat floor) most people had their view of the bottom of the screen blocked. After some failed starts somebody changed a setting in the video player to move the subtitles to the top of the screen, and everybody could read them and was happy.
This made me think doing this in playbin is not possible. I don't think there are any GStreamer players that offer this feature.
I attach a solution for this :)
(some people call it opera-style subtitles since the same solution has been used in the opera)
**Patch 296209**, "01- patch for subtitleoverlay":
[0001-subtitleoverlay-add-vertical-position-property.patch](/uploads/735bf7bb46506ac352ff8164e64c43f3/0001-subtitleoverlay-add-vertical-position-property.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/155support for alsa compress API2021-09-24T13:21:03ZBugzilla Migration Usersupport for alsa compress API## Submitted by Qais Yousef
**[Link to original bug (#743192)](https://bugzilla.gnome.org/show_bug.cgi?id=743192)**
## Description
As per the thread on gstreamer mailing list [1], I'm looking at adding support for alsa compress API....## Submitted by Qais Yousef
**[Link to original bug (#743192)](https://bugzilla.gnome.org/show_bug.cgi?id=743192)**
## Description
As per the thread on gstreamer mailing list [1], I'm looking at adding support for alsa compress API. Any direction on what's the advised method of adding this support? To start up I'm wondering whether the support should be an extension of existing alsasink component or whether to add it as a separate component (which I think is the better option).
Thanks,
Qais
[1] http://gstreamer-devel.966125.n4.nabble.com/ALSA-Compress-Offload-support-td4670153.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/153GstEncodingProfile should take multiple presets2021-09-24T13:21:02ZBugzilla Migration UserGstEncodingProfile should take multiple presets## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#742831)](https://bugzilla.gnome.org/show_bug.cgi?id=742831)**
## Description
The encoding API provided by GstEncodingProfile only allows for a single GstPreset to be at...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#742831)](https://bugzilla.gnome.org/show_bug.cgi?id=742831)**
## Description
The encoding API provided by GstEncodingProfile only allows for a single GstPreset to be attached to it. This means that we must know, before hand, what encoder will be used, which defeats the point of the encoding API.
Ideally, we should allow the provision of multiple presets to the GstEncodingProfile, probably with an associated GstElementFactory name. This would allow us to select the appropriate preset based on what is available on the system, and apply that.
Even better would be for the saved preset itself to have the associated factory name -- that way we would just walk down the list of provided presets and try to apply them till one works.
Relatedly, the GstEncoding*Profile should probably use properties for initialisation and getting/setting parameters.