GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2019-08-10T13:09:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/635Build fails with glibc 2.30 on x86_64: error: conflicting types for gint64/gu...2019-08-10T13:09:39ZEmerson BernierBuild fails with glibc 2.30 on x86_64: error: conflicting types for gint64/guint64Build fails against recently released glibc 2.30 on x86_64 arch:
```
FAILED: sys/v4l2/ee6e745@@gstvideo4linux2@sha/gstv4l2allocator.c.o
cc -Isys/v4l2/ee6e745@@gstvideo4linux2@sha -Isys/v4l2 -I../sys/v4l2 -I. -I../ -I../gst-libs -I/usr/i...Build fails against recently released glibc 2.30 on x86_64 arch:
```
FAILED: sys/v4l2/ee6e745@@gstvideo4linux2@sha/gstv4l2allocator.c.o
cc -Isys/v4l2/ee6e745@@gstvideo4linux2@sha -Isys/v4l2 -I../sys/v4l2 -I. -I../ -I../gst-libs -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/libffi-3.2.1/include -I/usr/include/orc-0.4 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -fvisibility=hidden -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Winit-self -Wmissing-include-dirs -Wno-multichar -Wvla -Wpointer-arith -Wmissing-prototypes -Wdeclaration-after-statement -Wold-style-definition -Waggregate-return -O2 -g -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -pthread -DHAVE_CONFIG_H -MD -MQ 'sys/v4l2/ee6e745@@gstvideo4linux2@sha/gstv4l2allocator.c.o' -MF 'sys/v4l2/ee6e745@@gstvideo4linux2@sha/gstv4l2allocator.c.o.d' -o 'sys/v4l2/ee6e745@@gstvideo4linux2@sha/gstv4l2allocator.c.o' -c ../sys/v4l2/gstv4l2allocator.c
In file included from ../sys/v4l2/ext/videodev2.h:63,
from ../sys/v4l2/gstv4l2allocator.c:28:
../sys/v4l2/ext/types-compat.h:48:15: error: conflicting types for ‘gint64’
48 | #define __s64 gint64
| ^~~~~~
In file included from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from ../sys/v4l2/ext/types-compat.h:22,
from ../sys/v4l2/ext/videodev2.h:63,
from ../sys/v4l2/gstv4l2allocator.c:28:
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:61:21: note: previous declaration of ‘gint64’ was here
61 | typedef signed long gint64;
| ^~~~~~
In file included from ../sys/v4l2/ext/videodev2.h:63,
from ../sys/v4l2/gstv4l2allocator.c:28:
../sys/v4l2/ext/types-compat.h:44:15: error: conflicting types for ‘guint64’
44 | #define __u64 guint64
| ^~~~~~~
In file included from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from ../sys/v4l2/ext/types-compat.h:22,
from ../sys/v4l2/ext/videodev2.h:63,
from ../sys/v4l2/gstv4l2allocator.c:28:
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:62:23: note: previous declaration of ‘guint64’ was here
62 | typedef unsigned long guint64;
| ^~~~~~~
```
Tested against https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/tags/1.16.0
Full buildlog: https://freedesktop-sdk.gitlab.io/-/freedesktop-sdk/-/jobs/264205126/artifacts/cache/buildstream/logs/freedesktop-sdk/components-gstreamer-plugins-good/12ca1a1e-build.30054.logTim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/64rav1e: Depend on a specific git snapshot?2019-08-04T18:42:34ZPhilippe Normandrav1e: Depend on a specific git snapshot?The rav1e API seems to be a moving target currently, so it can trigger random CI failures here. Should we depend on a specific revision in order to have a more consistent CI?
OTOH it's good we catch those, so I'm not sure what to do.The rav1e API seems to be a moving target currently, so it can trigger random CI failures here. Should we depend on a specific revision in order to have a more consistent CI?
OTOH it's good we catch those, so I'm not sure what to do.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/645pipeline random crash when failed to negotiate with glimagesink.2020-11-04T07:58:05ZHe Junyanpipeline random crash when failed to negotiate with glimagesink.The pipeline
gst-launch-1.0 videotestsrc num-buffers=30 ! capsfilter caps=video/x-raw,format=P010_10LE,width=480,height=320 ! vaapipostproc format=bgr10a2-le ! glimagesink
random crash.
The negotiate will fail, which is expected, but t...The pipeline
gst-launch-1.0 videotestsrc num-buffers=30 ! capsfilter caps=video/x-raw,format=P010_10LE,width=480,height=320 ! vaapipostproc format=bgr10a2-le ! glimagesink
random crash.
The negotiate will fail, which is expected, but the crash is unexpected.
with setting the debug level to
export GST_DEBUG=*:INFO
The crash is easy to duplocatehttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/179gitlab runner may need more time to finish cerbero build test2019-08-02T11:42:05ZJustin Kimgitlab runner may need more time to finish cerbero build test> Job [#466281](https://gitlab.freedesktop.org/joykim/cerbero/-/jobs/466281) failed for 429a96d96a78ed7992b9bafe5769f815ecb6a0c9:
I think building for iOS would be done if there's no timeout (but not 100% sure)
Maybe some jobs, especia...> Job [#466281](https://gitlab.freedesktop.org/joykim/cerbero/-/jobs/466281) failed for 429a96d96a78ed7992b9bafe5769f815ecb6a0c9:
I think building for iOS would be done if there's no timeout (but not 100% sure)
Maybe some jobs, especially building, needs more time.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/72timeline serialization issue with the official builds on windows.2021-09-24T12:17:13ZDavid Ingtimeline serialization issue with the official builds on windows.# summary
I saved `xges` files from timelines that were constructed across 5 different scenarios. The scenarios are named like "02", "03", ..., "06".
In each scenario, I constructed a timeline and saved it by calling `ges_timeline_save...# summary
I saved `xges` files from timelines that were constructed across 5 different scenarios. The scenarios are named like "02", "03", ..., "06".
In each scenario, I constructed a timeline and saved it by calling `ges_timeline_save_to_uri`.
## linux vs. windows
I did this in Windows and Linux (Fedora 30). The scenarios are identical across operating systems (except file paths), yet the `xges` files are different. A quick diff of the two folders shows you that there is clearly a problem on Windows. Specifically the `clip` elements do not appear within the files from Windows, but instead there is some kind of malformed `xml` where the clip should be.
## effects are not serialized
All of my video clips have a `GESEffect` of type `videocrop` which do not appear in the serialized data.
## versions
Windows: 1.16.0-mingw
Fedora 30: 1.16.0
[xges_files.zip](/uploads/9d605471c990607e0efe26047be386d3/xges_repro.zip)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/420baseparse: drains data when handle_frame() does nothing2019-08-13T14:59:33ZOleksandrKvlbaseparse: drains data when handle_frame() does nothingI'm trying to dump video from rtsp session, here's my cmd line:
```
/opt/gstreamer/gst-uninstalled.py gst-launch-1.0 -v filesrc location=dump.pcap ! pcapparse src-ip=1.2.3.4. src-port=554 ! irtspparse channel_id=0...
```
It works in most...I'm trying to dump video from rtsp session, here's my cmd line:
```
/opt/gstreamer/gst-uninstalled.py gst-launch-1.0 -v filesrc location=dump.pcap ! pcapparse src-ip=1.2.3.4. src-port=554 ! irtspparse channel_id=0...
```
It works in most cases, but in one case it fails inside irstpparse in assertion that supposes that when we do nothing in handle_frame() and just return GST_FLOW_OK, we get at least the same or bigger buffer next time. As I understand it, baseparse should accumulate data until we skip it or call gst_base_parse_finish_frame(). And in good case it works in that way, but in bad case it removes data from frame that passed to hadle_frame().
I add more logs into baseparse and found difference between 'good' and 'bad' .pcap files, gst_base_parse_drain (parse) is called [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/master/libs/gst/base/gstbaseparse.c#L3215) more frequently, in good case log file is about 7MB and has 4 calls, in bad case it has 3 calls for the first 4-5 packets.
Where to look? Maybe it is a problem in pcapparse, but I don't see any code that deals with DISCONT flag there?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/213Tutorial #3 - link failing to the video element (Ubuntu 16.04)2019-08-01T09:27:27ZAlex LavrivTutorial #3 - link failing to the video element (Ubuntu 16.04)Hello, I am trying to add the video element to the tutorial -
I have made the following changes:
1. Added video sink and video converter fields to the CustomData struct.
2. Added these elements to the pipeline.
3. Made a link between th...Hello, I am trying to add the video element to the tutorial -
I have made the following changes:
1. Added video sink and video converter fields to the CustomData struct.
2. Added these elements to the pipeline.
3. Made a link between them.
4. In pad_added_handler I have checked if the new pad is 'video/x-raw', if so I am getting the static sink pad of the video converter.
When running, I am getting the next error:
> Type is 'video/x-raw' but link failed.
Is there a solution for this assignment so I can find my error? Thanks.
The source is attached.[basic-tutorial-3.c](/uploads/450398f551064030509340920114e696/basic-tutorial-3.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1042webrtcbin: Incorrect demonstration of usage of promise in webrtcbidirectional.c2019-12-31T13:22:30ZAshutosh Bhattwebrtcbin: Incorrect demonstration of usage of promise in webrtcbidirectional.cIn the test example "webrtcbidirectional.c", inside the `_on_answer_received` API, it is mentioned that there are two ways to tell webrtcbin that we don't want to be notified when the task is complete.
The second way shows the usage by ...In the test example "webrtcbidirectional.c", inside the `_on_answer_received` API, it is mentioned that there are two ways to tell webrtcbin that we don't want to be notified when the task is complete.
The second way shows the usage by interrupting a promise. Although the promise is created and interrupted in the code, it is never passed as a parameter in the emitted signal.
Refer : https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/tests/examples/webrtc/webrtcbidirectional.c#L102https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1041h265parse: fails to parse video for HEVC main still profile2021-09-24T14:37:39ZNvGIGABYTEJrh265parse: fails to parse video for HEVC main still profileIssue is coming from codecparser from gst-plugins-bad. Used the following command to decode the main still profile encoded stream.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! vaapih265dec ! ...Issue is coming from codecparser from gst-plugins-bad. Used the following command to decode the main still profile encoded stream.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! vaapih265dec ! filesink location=/storage/output/HoneyBee_3840x2160_MainStill.yuv
Also tried the following command just to make sure parser can read the stream properly and observed similar issue. We can confirm that this issue is not coming from gstvaapi decoder instead it's coming from h265 codec parser. Added the log observed when running GST_DEBUG for more information.
Example:
gst-launch-1.0 filesrc location= HoneyBee_3840x2160_MainStill.h265 ! h265parse ! filesink location=/storage/output/HoneyBee_3840x2160_MainStill.yuv
0:00:00.154077842 29689 0x8c6af0 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
Got context from element 'vaapidecode_h265-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
0:00:00.156583488 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:799:gst_h265_parser_parse_short_term_ref_pic_sets: value greater than max. value: 1, max 0
0:00:00.156632914 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:845:gst_h265_parser_parse_short_term_ref_pic_sets: error parsing "ShortTermRefPicSet Parameters"
0:00:00.156644478 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:1827:gst_h265_parse_sps: error parsing "Sequence parameter set"
0:00:00.156665437 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:799:gst_h265_parser_parse_short_term_ref_pic_sets: value greater than max. value: 1, max 0
0:00:00.156682636 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:845:gst_h265_parser_parse_short_term_ref_pic_sets: error parsing "ShortTermRefPicSet Parameters"
0:00:00.156692946 29689 0x7c3f70 WARN codecparsers_h265 gsth265parser.c:1827:gst_h265_parse_sps: error parsing "Sequence parameter set"
0:00:00.156707318 29689 0x7c3f70 WARN h265parse gsth265parse.c:624:gst_h265_parse_process_nal:<h265parse0> failed to parse SPS:
0:00:00.156735598 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 33 SPS, Size: 45 will be dropped
0:00:00.156823129 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 34 PPS, Size: 8 will be dropped
0:00:00.156897167 29689 0x7c3f70 WARN h265parse gsth265parse.c:1112:gst_h265_parse_handle_frame:<h265parse0> broken/invalid nal Type: 19 SLICE_IDR_W_RADL, Size: 36756 will be dropped
0:00:00.156966044 29689 0x7c3f70 WARN baseparse gstbaseparse.c:3626:gst_base_parse_loop:<h265parse0> error: No valid frames found before end of stream
ERROR: from element /GstPipeline:pipeline0/GstH265Parse:h265parse0: No valid frames found before end of stream
Additional debug info:
gstbaseparse.c(3626): gst_base_parse_loop (): /GstPipeline:pipeline0/GstH265Parse:h265parse0
ERROR: pipeline doesn't want to preroll.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/185Only half of num-buffers frames were decoded in AVC/JPEG decode2019-08-01T08:51:52ZNvGIGABYTEJrOnly half of num-buffers frames were decoded in AVC/JPEG decodeWe have a HSD issue where only half of the num-buffers sets in “filesrc” plugin were decoded. Observed issue when testing with Open Source gstvaapi + iHD.
Do you know if this is expected or is this a bug?
Eg: (AVC)
gst-launch-1.0 -v...We have a HSD issue where only half of the num-buffers sets in “filesrc” plugin were decoded. Observed issue when testing with Open Source gstvaapi + iHD.
Do you know if this is expected or is this a bug?
Eg: (AVC)
gst-launch-1.0 -v filesrc location=/mnt/video/sanity/littleGirl_320x240.h264 num-buffers=30 ! h264parse ! vaapih264dec ! filesink location=output/avcdec_320x240.yuv
>>> [Result] num-buffers=30, output number of frames=15
Eg: (JPEG)
gst-launch-1.0 -v filesrc location=/mnt/video/sanity/littleGirl_320x240.jpg num-buffers=30 ! jpegparse ! vaapijpegdec ! filesink location=output/jpegdec_320x240.yuv
>>> [Result] num-buffers=30, output number of frames=15https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/419pipeline random crash when failed to negotiate with glimagesink.2019-08-02T09:01:44ZHe Junyanpipeline random crash when failed to negotiate with glimagesink.The pipeline
gst-launch-1.0 videotestsrc num-buffers=30 ! capsfilter caps=video/x-raw,format=P010_10LE,width=480,height=320 ! vaapipostproc format=bgr10a2-le ! glimagesink
random crash.
The negotiate will fail, which is expected, but t...The pipeline
gst-launch-1.0 videotestsrc num-buffers=30 ! capsfilter caps=video/x-raw,format=P010_10LE,width=480,height=320 ! vaapipostproc format=bgr10a2-le ! glimagesink
random crash.
The negotiate will fail, which is expected, but the crash is unexpected.
with setting the debug level to
export GST_DEBUG=*:INFO
The crash is easy to duplocatehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1040Documentation sometimes incorrect after plugin renames2021-09-24T14:37:39ZLoïc YhuelDocumentation sometimes incorrect after plugin renamesIt seems there is a weird issue in the documentation due to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/9bc2b04d5c00874d01b9b906b149366271ce59ed and https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/0127...It seems there is a weird issue in the documentation due to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/9bc2b04d5c00874d01b9b906b149366271ce59ed and https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/012782239e0d11bf1e5b16641d543df7bf132aa3.
There are still pages with the old plugin names, mentioning older gstreamer versions.
The gmedec/neonhttpsrc element pages can link to (randomly ?) either the new or the old plugin pages.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-gmedec.html, links to https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-gmedec.html (version 1.12.0).
It should have linked to the correct https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-gme.html.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-neonhttpsrc.html correctly points to https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-neonhttpsrc.html.
But there is still https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-plugin-neon.html (version 1.9.0.1).
On Fedora, it leads to conflicts when trying to install multilib devel packages since the documentation is slightly different (see https://bugzilla.redhat.com/show_bug.cgi?id=1680233).
In this case, both packages contain the pages with old and new plugin names, but :
- in the i686 package, gmedec/neonhttpsrc element pages link to gme/neonhttpsrc plugin pages respectively (new plugin names)
- in the x86_64 package, gmedec/neonhttpsrc element pages link to gmedec/neon plugin pages respectively (old plugin names)https://gitlab.freedesktop.org/gstreamer/gst-template/-/issues/5Writing plugin according doc results in compile error2019-07-30T22:05:14ZHermann Stamm-WilbrandtWriting plugin according doc results in compile errorI worked with gstreamer on Raspbian in November 2017:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=197124#p1232038
I did not run "gst-launch-1.0 --version" at that time, so do not know what gstreamer version was on my Raspbi...I worked with gstreamer on Raspbian in November 2017:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=197124#p1232038
I did not run "gst-launch-1.0 --version" at that time, so do not know what gstreamer version was on my Raspbian at that point in time. I followed the instructions:
https://gstreamer.freedesktop.org/documentation/plugin-development/basics/boiler.html
and everything compiled and worked at that time, as documented.
Yesterday I followed the instructions again, and the generated template did not compile. Gstreamer version on my Raspbian Sketch is 1.10.4 today. Compiling errors out on missing defines for GST_LICENSE, GST_PACKAGE_NAME and GST_PACKAGE_ORIGIN.
Cause of the compiler error seems to be this 11yo checkin from Sebastian:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/e4476e15e02bdd7c40a4e4404ab6da71ad3ea4dd
It seems that was not effective on Raspbian gstreamer in 2017.
I did add the three defines to src/gstplugin.h and commented out the audio example. I had a hard time to learn that plugin gets blacklisted without a valid license and how to diagnose:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=247034&p=1509968#p1509968
So this is definitely a "does not compile bug".
Either the three defines need to be added to src/gstplugin.h and audio example.
Or boilerplate documentation needs to call to add the three defines and warn on having to use a valid license.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1039nvenc: build failure on msvc x862019-08-21T07:21:19ZTim-Philipp Müllertim@centricular.comnvenc: build failure on msvc x86Build on 32-bit MSVC fails like [this](https://gitlab.freedesktop.org/xclaesse/gst-ci/-/jobs/457499):
```
[3340/3809] Compiling C object subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.
FAILED: subprojects/gst-plu...Build on 32-bit MSVC fails like [this](https://gitlab.freedesktop.org/xclaesse/gst-ci/-/jobs/457499):
```
[3340/3809] Compiling C object subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.
FAILED: subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj
cl @subprojects/gst-plugins-bad/sys/5bc2b03@@gstnvcodec@sha/gstnvenc.c.obj.rsp
gstnvenc.c(53): error C2373: 'NvEncOpenEncodeSessionEx': redefinition; different type modifiers
nvEncodeAPI.h(3087): note: see declaration of 'NvEncOpenEncodeSessionEx'
gstnvenc.c(61): error C2373: 'NvEncDestroyEncoder': redefinition; different type modifiers
nvEncodeAPI.h(3024): note: see declaration of 'NvEncDestroyEncoder'
gstnvenc.c(68): error C2373: 'NvEncGetEncodeGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2001): note: see declaration of 'NvEncGetEncodeGUIDs'
gstnvenc.c(76): error C2373: 'NvEncGetEncodeProfileGUIDCount': redefinition; different type modifiers
nvEncodeAPI.h(2032): note: see declaration of 'NvEncGetEncodeProfileGUIDCount'
gstnvenc.c(85): error C2373: 'NvEncGetEncodeProfileGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2069): note: see declaration of 'NvEncGetEncodeProfileGUIDs'
gstnvenc.c(94): error C2373: 'NvEncGetInputFormats': redefinition; different type modifiers
nvEncodeAPI.h(2131): note: see declaration of 'NvEncGetInputFormats'
gstnvenc.c(102): error C2373: 'NvEncGetEncodePresetCount': redefinition; different type modifiers
nvEncodeAPI.h(2193): note: see declaration of 'NvEncGetEncodePresetCount'
gstnvenc.c(111): error C2373: 'NvEncGetEncodePresetGUIDs': redefinition; different type modifiers
nvEncodeAPI.h(2237): note: see declaration of 'NvEncGetEncodePresetGUIDs'
gstnvenc.c(120): error C2373: 'NvEncGetEncodePresetConfig': redefinition; different type modifiers
nvEncodeAPI.h(2276): note: see declaration of 'NvEncGetEncodePresetConfig'
gstnvenc.c(129): error C2373: 'NvEncGetEncodeCaps': redefinition; different type modifiers
nvEncodeAPI.h(2163): note: see declaration of 'NvEncGetEncodeCaps'
gstnvenc.c(137): error C2373: 'NvEncGetSequenceParams': redefinition; different type modifiers
nvEncodeAPI.h(2862): note: see declaration of 'NvEncGetSequenceParams'
gstnvenc.c(145): error C2373: 'NvEncInitializeEncoder': redefinition; different type modifiers
nvEncodeAPI.h(2361): note: see declaration of 'NvEncInitializeEncoder'
gstnvenc.c(152): error C2373: 'NvEncReconfigureEncoder': redefinition; different type modifiers
nvEncodeAPI.h(3182): note: see declaration of 'NvEncReconfigureEncoder'
gstnvenc.c(159): error C2373: 'NvEncRegisterResource': redefinition; different type modifiers
nvEncodeAPI.h(3117): note: see declaration of 'NvEncRegisterResource'
gstnvenc.c(166): error C2373: 'NvEncUnregisterResource': redefinition; different type modifiers
nvEncodeAPI.h(3148): note: see declaration of 'NvEncUnregisterResource'
gstnvenc.c(173): error C2373: 'NvEncMapInputResource': redefinition; different type modifiers
nvEncodeAPI.h(2959): note: see declaration of 'NvEncMapInputResource'
gstnvenc.c(180): error C2373: 'NvEncUnmapInputResource': redefinition; different type modifiers
nvEncodeAPI.h(2994): note: see declaration of 'NvEncUnmapInputResource'
gstnvenc.c(187): error C2373: 'NvEncCreateInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2392): note: see declaration of 'NvEncCreateInputBuffer'
gstnvenc.c(194): error C2373: 'NvEncLockInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2768): note: see declaration of 'NvEncLockInputBuffer'
gstnvenc.c(201): error C2373: 'NvEncUnlockInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2798): note: see declaration of 'NvEncUnlockInputBuffer'
gstnvenc.c(208): error C2373: 'NvEncDestroyInputBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2421): note: see declaration of 'NvEncDestroyInputBuffer'
gstnvenc.c(215): error C2373: 'NvEncCreateBitstreamBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2456): note: see declaration of 'NvEncCreateBitstreamBuffer'
gstnvenc.c(222): error C2373: 'NvEncLockBitstream': redefinition; different type modifiers
nvEncodeAPI.h(2704): note: see declaration of 'NvEncLockBitstream'
gstnvenc.c(229): error C2373: 'NvEncUnlockBitstream': redefinition; different type modifiers
nvEncodeAPI.h(2734): note: see declaration of 'NvEncUnlockBitstream'
gstnvenc.c(236): error C2373: 'NvEncDestroyBitstreamBuffer': redefinition; different type modifiers
nvEncodeAPI.h(2485): note: see declaration of 'NvEncDestroyBitstreamBuffer'
gstnvenc.c(243): error C2373: 'NvEncEncodePicture': redefinition; different type modifiers
nvEncodeAPI.h(2665): note: see declaration of 'NvEncEncodePicture'
```
(paths trimmed)
@seungha.yang any ideas? :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/634rtspsrc: rtcp interleaved over tcp+tls without prefix in v1.16.02019-08-06T09:01:07ZPierce Lopezrtspsrc: rtcp interleaved over tcp+tls without prefix in v1.16.0I'm using rtsp over tls, with interleaved transport, like so: `rtspsrc name=mux location=rtsps://devbox:8556/test-pierce latency=0 protocols=tcp tls-validation-flags=0x58 do-rtcp=true`. (TLS validation disabled for my local debugging se...I'm using rtsp over tls, with interleaved transport, like so: `rtspsrc name=mux location=rtsps://devbox:8556/test-pierce latency=0 protocols=tcp tls-validation-flags=0x58 do-rtcp=true`. (TLS validation disabled for my local debugging server, `do-rtcp=true` is the default but I'm switching it periodically for debugging.) Interleaved transport sends rtp and rtcp over the same connection as the RTSP request/response, but each rtp/rtcp frame is prefixed with 4 bytes: "$", 1-byte channel, 2-bytes big-endian length.
In this specific setup, rtcp is sent without that 4-byte prefix, by gstreamer-1.16.0. (And then if I hack my server-side parser to accept that, something else fails on the client side about 100ms later.)
* This only happens for rtsps:// not for rtsp://
* This bug was not present in 1.14.x
* The source or trigger of the issue seems to be in gst-plugins-base, not gst-plugins-good: if I switch just gst-plugins-base between 1.16.0 and 1.14.4 I can see the issue come and go
* If I use `do-rtcp=false` all seems OK, the video stream continues playing for many minutes.
Here's some rather verbose logging from the rtspsrc:
```
0:00:01.762490000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5481:gst_rtspsrc_loop_interleaved:<mux> doing receive with timeout 8633 seconds, 521054 usec
0:00:01.762682000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5491:gst_rtspsrc_loop_interleaved:<mux> we received a server message
0:00:01.762693000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5524:gst_rtspsrc_loop_interleaved:<mux> got data message
0:00:01.762701000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5290:gst_rtspsrc_handle_data:<mux> pushing data of size 115 on channel 0
0:00:01.762725000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5481:gst_rtspsrc_loop_interleaved:<mux> doing receive with timeout 8633 seconds, 520819 usec
0:00:01.770797000 6577 0x7fdf2e857d90 DEBUG rtspsrc gstrtspsrc.c:3115:gst_rtspsrc_sink_chain:<mux> sending 84 bytes RTCP
0:00:01.770878000 6577 0x7fdf2e857d90 DEBUG rtspsrc gstrtspsrc.c:3117:gst_rtspsrc_sink_chain:<mux> sent RTCP, 0
0:00:01.781007000 6577 0x7fdf2e857ca0 DEBUG rtspsrc gstrtspsrc.c:2862:gst_rtspsrc_handle_src_event:<mux> pad mux:recv_rtp_src_0_2345423449_96 received event qos
0:00:01.781037000 6577 0x7fdf2e857ca0 DEBUG rtspsrc gstrtspsrc.c:2928:gst_rtspsrc_handle_internal_src_event:<'':internalsrc_0> received event qos
0:00:01.795760000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5491:gst_rtspsrc_loop_interleaved:<mux> we received a server message
0:00:01.795775000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5524:gst_rtspsrc_loop_interleaved:<mux> got data message
0:00:01.795785000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5290:gst_rtspsrc_handle_data:<mux> pushing data of size 84 on channel 1
0:00:01.795807000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5481:gst_rtspsrc_loop_interleaved:<mux> doing receive with timeout 8633 seconds, 487736 usec
0:00:01.795989000 6577 0x7fdf30807e80 WARN rtspsrc gstrtspsrc.c:5558:gst_rtspsrc_loop_interleaved:<mux> error: Could not receive message. (Parse error)
0:00:01.796028000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:6037:gst_rtspsrc_loop:<mux> pausing task, reason error
0:00:01.796036000 6577 0x7fdf30807e80 WARN rtspsrc gstrtspsrc.c:6054:gst_rtspsrc_loop:<mux> error: Internal data stream error.
0:00:01.796040000 6577 0x7fdf30807e80 WARN rtspsrc gstrtspsrc.c:6054:gst_rtspsrc_loop:<mux> error: streaming stopped, reason error (-5)
0:00:01.796111000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5939:gst_rtspsrc_loop_send_cmd:<mux> sending cmd WAIT
0:00:01.796116000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5964:gst_rtspsrc_loop_send_cmd:<mux> cancel previous request LOOP
0:00:01.796135000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5972:gst_rtspsrc_loop_send_cmd:<mux> connection flush busy LOOP
0:00:01.796139000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5090:gst_rtspsrc_connection_flush:<mux> set flushing 1
0:00:01.796143000 6577 0x7fdf30807e80 DEBUG rtspsrc gstrtspsrc.c:5093:gst_rtspsrc_connection_flush:<mux> connection flush
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:mux: Could not read from resource.
Additional debug info:
gstrtspsrc.c(5558): gst_rtspsrc_loop_interleaved (): /GstPipeline:pipeline0/GstRTSPSrc:mux:
Could not receive message. (Parse error)
Execution ended after 0:00:01.546659000
Setting pipeline to PAUSED ...
```
and here's what my custom rtsp server debug logs (server hacked to detect interleaved rtcp without prefix):
```
2019-07-29 21:13:09.441 D (rtsp_serve.c:536) LINE: PLAY rtsp://devbox:8556/test-pierce RTSP/1.0
2019-07-29 21:13:09.441 D (rtsp_serve.c:543) HDR: CSeq: 3
2019-07-29 21:13:09.441 D (rtsp_serve.c:543) HDR: User-Agent: GStreamer/1.16.0
2019-07-29 21:13:09.441 D (rtsp_serve.c:543) HDR: Range: npt=0-
2019-07-29 21:13:09.442 D (rtsp_serve.c:543) HDR: Session: 7xImOMpUZ6BzGJQ
2019-07-29 21:13:09.442 D (rtsp_serve.c:543) HDR: Date: Mon, 29 Jul 2019 21:13:09 GMT
2019-07-29 21:13:09.442 I (rtsp_serve.c:500) rtsp < PLAY rtsp://devbox:8556/test-pierce - rtsps-peer=172.30.1.1:60956
2019-07-29 21:13:09.442 D (rtsp_engine.c:346) Client request uri acceptable
2019-07-29 21:13:09.443 V (rtsp_engine.c:389) Auth accepted rtsps-peer=172.30.1.1:60956 uri=rtsp://devbox:8556/test-pierce need_players=0
2019-07-29 21:13:09.443 D (rtsp_engine.c:730) RTSP Play rtsps-peer=172.30.1.1:60956 rtsp://devbox:8556/test-pierce
2019-07-29 21:13:09.443 D (rtsp_media.c:151) media pool[0] found presentation at (/test-pierce)
2019-07-29 21:13:09.443 I (rtsp_serve.c:638) rtsp > 200 OK - rtsps-peer=172.30.1.1:60956
2019-07-29 21:13:09.444 V (rtsp_serve.c:675) rtsp connection now playing rtsps-peer=172.30.1.1:60956
2019-07-29 21:13:09.444 D (rtsp_serve.c:690) rtsp >
RTSP/1.0 200 OK
Server: avcore/1.7
CSeq: 3
RTP-Info: /test-pierce
Session: 7xImOMpUZ6BzGJQ
2019-07-29 21:13:09.445 I (rtsp_engine.c:1064) attempt to prepare burst, max=0.750000
2019-07-29 21:13:09.445 D (rtsp_engine.c:1086) consider burst for H264 : 1
2019-07-29 21:13:09.446 I (rtsp_engine.c:1100) h264 burst candidate pts=107.834133 dur=0.419211 pkts=61
2019-07-29 21:13:09.446 I (rtsp_engine.c:1138) sending burst, 61 pkts
2019-07-29 21:13:09.446 V (rtsp_auth.c:514) Sending media:play_start API request (127.0.0.1:8501/int/media/state?urn=%2Ftest-pierce)
2019-07-29 21:13:09.447 D (rtsp_engine.c:1162) finished H264 burst
2019-07-29 21:13:09.451 E (rtsp_auth.c:555) Failure response for media state request 400 /int/media/state?urn=%2Ftest-pierce
2019-07-29 21:13:10.952 W (rtsp_serve.c:403) received rtcp interleaved without prefix rtsps-peer=172.30.1.1:60956
2019-07-29 21:13:10.952 D (rtp_pkt.c:156) v=2 p=0 cnt=1 pt=RR len=32 ssrc=31c3ca9c
2019-07-29 21:13:10.953 W (rtsp_serve.c:403) received rtcp interleaved without prefix rtsps-peer=172.30.1.1:60956
2019-07-29 21:13:10.953 D (rtp_pkt.c:171) v=2 p=0 cnt=1 pt=SDES len=52 ssrc=31c3ca9c type=1
2019-07-29 21:13:10.990 D (rtsp_serve.c:536) LINE: TEARDOWN rtsp://devbox:8556/test-pierce RTSP/1.0
2019-07-29 21:13:10.991 D (rtsp_serve.c:543) HDR: CSeq: 4
2019-07-29 21:13:10.991 D (rtsp_serve.c:543) HDR: User-Agent: GStreamer/1.16.0
2019-07-29 21:13:10.991 D (rtsp_serve.c:543) HDR: Session: 7xImOMpUZ6BzGJQ
2019-07-29 21:13:10.991 D (rtsp_serve.c:543) HDR: Date: Mon, 29 Jul 2019 21:13:11 GMT
2019-07-29 21:13:10.992 I (rtsp_serve.c:500) rtsp < TEARDOWN rtsp://devbox:8556/test-pierce - rtsps-peer=172.30.1.1:60956
```
note that the stream works and the video shows up for half a second, before the gstreamer client attempts to send an rtcp receiver-report and SDES, and then dies (regardless of whether the server tolerates the un-prefixed rtcp).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1038Improve X11 capture with nvenc2019-08-21T07:21:19ZDan IslaImprove X11 capture with nvencWhen capturing from ximagesrc and encoding with NVENC, the RGB buffers from ximagesrc need to be converted to I420 before they can be used as a sink for the nvh264enc plugin. From what I can tell, there is no way to do this without the v...When capturing from ximagesrc and encoding with NVENC, the RGB buffers from ximagesrc need to be converted to I420 before they can be used as a sink for the nvh264enc plugin. From what I can tell, there is no way to do this without the videoconvert plugin, which is quite CPU intensive when streaming at 1080p, 60fps or better.
It looks like the NVENC API supports [ARGB and ABGR formats](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/nvcodec/nvEncodeAPI.h#L341), is it possible to use those formats with ximagesrc and eliminate the need for videoconvert? Alternatively, is there any way to move the color-space conversion to the GPU?
NVIDIA also has a [frame buffer capture SDK (NVFBC)](https://developer.nvidia.com/capture-sdk) which can capture and encode to H.264. This would be another way to free up the CPU and possibly improve capture performance.
The capture SDK comes with an example C program, it would be great to see that functionality as a source plugin.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/418GST_MESSAGE_DEVICE_CHANGED duplicates GST_MESSAGE_REDIRECT2019-08-06T10:08:10ZJan SchmidtGST_MESSAGE_DEVICE_CHANGED duplicates GST_MESSAGE_REDIRECTI just noticed that !84 introduced an API bug in 1.16.0 by adding a new message enum (GST_MESSAGE_DEVICE_CHANGED) with the same value as the existing (GST_MESSAGE_REDIRECT):
GST_MESSAGE_REDIRECT = GST_MESSAGE_EXTENDED + 6,
+...I just noticed that !84 introduced an API bug in 1.16.0 by adding a new message enum (GST_MESSAGE_DEVICE_CHANGED) with the same value as the existing (GST_MESSAGE_REDIRECT):
GST_MESSAGE_REDIRECT = GST_MESSAGE_EXTENDED + 6,
+ GST_MESSAGE_DEVICE_CHANGED = GST_MESSAGE_EXTENDED + 6,
Unfortunately I've noticed way too late as it's already released and can't be changed without breaking ABI.
A test that has a case statement with all possible GstMessage enum values would have caught this as a duplicate. If it has no default: statement, it'd also fail if people add new enums without adding them to the test.1.16.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1036player: Deadlock in uri-loaded signal when no signal dispatcher is supplied t...2021-09-24T14:37:37ZPhilippe Normandplayer: Deadlock in uri-loaded signal when no signal dispatcher is supplied to GstPlayerI'm actually not entirely sure it's a bug, one could argue it's an application-side issue, but here it goes. Attaching a test-case.
```
(gdb) t a a bt
Thread 2 (Thread 0x7ffff7414700 (LWP 20949)):
#0 0x00007ffff7ab2f59 in syscall () a...I'm actually not entirely sure it's a bug, one could argue it's an application-side issue, but here it goes. Attaching a test-case.
```
(gdb) t a a bt
Thread 2 (Thread 0x7ffff7414700 (LWP 20949)):
#0 0x00007ffff7ab2f59 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007ffff7c3a62c in g_mutex_lock_slowpath (mutex=mutex@entry=0x5555557c6088) at ../../../glib/gthread-posix.c:1320
#2 0x00007ffff7c3ae82 in g_mutex_lock (mutex=mutex@entry=0x5555557c6088) at ../../../glib/gthread-posix.c:1344
#3 0x00007ffff7f71f8e in gst_player_pause (self=0x5555557c6000 [GstPlayer]) at gstplayer.c:3190
#4 0x000055555555520d in uri_loaded_cb (player=0x5555557c6000 [GstPlayer], uri=0x7ffff001d0d0 "file:///home/phil/Videos/Agent 327.mp4", user_data=0x0) at /home/phil/player-deadlock.c:8
#8 0x00007ffff7cef97f in <emit signal ??? on instance 0x5555557c6000 [GstPlayer]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../../../gobject/gsignal.c:3447
#5 0x00007ffff7cd2c8d in g_closure_invoke (closure=0x5555557c8b90, return_value=0x0, n_param_values=2, param_values=0x7ffff7413aa0, invocation_hint=0x7ffff7413a20) at ../../../gobject/gclosure.c:810
#6 0x00007ffff7ce6365 in signal_emit_unlocked_R (node=node@entry=0x55555558a300, detail=detail@entry=0, instance=instance@entry=0x5555557c6000, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffff7413aa0) at ../../../gobject/gsignal.c:3635
#7 0x00007ffff7cef2be in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffff7413c70) at ../../../gobject/gsignal.c:3391
#9 0x00007ffff7f7900d in gst_player_signal_dispatcher_dispatch (self=<optimized out>, player=<optimized out>, emitter=0x7ffff7f6f3b0 <uri_loaded_dispatch>, data=0x7ffff0002040, destroy=0x7ffff7f6f200 <uri_loaded_signal_data_free>) at gstplayer-signal-dispatcher.c:46
#10 0x00007ffff7f76924 in gst_player_set_uri_internal (user_data=0x5555557c6000) at gstplayer.c:599
#11 0x00007ffff7bf0dd8 in g_main_dispatch (context=0x5555557c5c10) at ../../../glib/gmain.c:3182
#12 0x00007ffff7bf0dd8 in g_main_context_dispatch (context=context@entry=0x5555557c5c10) at ../../../glib/gmain.c:3847
#13 0x00007ffff7bf11c8 in g_main_context_iterate (context=0x5555557c5c10, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3920
#14 0x00007ffff7bf14c2 in g_main_loop_run (loop=0x5555557c3fd0) at ../../../glib/gmain.c:4116
#15 0x00007ffff7f76378 in gst_player_main (data=0x5555557c6000) at gstplayer.c:2970
#16 0x00007ffff7c19415 in g_thread_proxy (data=0x55555568d540) at ../../../glib/gthread.c:784
#17 0x00007ffff7b87fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#18 0x00007ffff7ab84cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7ffff7415b80 (LWP 20885)):
#0 0x00007ffff7aad819 in __GI___poll (fds=0x5555557c8ce0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007ffff7bf1136 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x5555557c8ce0, timeout=<optimized out>, context=0x555555565730) at ../../../glib/gmain.c:4221
#2 0x00007ffff7bf1136 in g_main_context_iterate (context=0x555555565730, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3915
#3 0x00007ffff7bf14c2 in g_main_loop_run (loop=0x555555566930) at ../../../glib/gmain.c:4116
#4 0x00005555555552bd in main (argc=2, argv=0x7fffffffe558) at /home/phil/player-deadlock.c:22
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1035d3d11videosink: 2-3 times slower than d3dvideosink when decoding to RGBA2019-12-05T03:20:24ZAaron Boxerd3d11videosink: 2-3 times slower than d3dvideosink when decoding to RGBATest file:
[test.mkv](/uploads/4cf4fa2efc0d5282a7da4719ec720822/test.mkv)
This pipeline:
`gst-launch-1.0.exe filesrc location=test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3d11videosink`
is significantly slower ...Test file:
[test.mkv](/uploads/4cf4fa2efc0d5282a7da4719ec720822/test.mkv)
This pipeline:
`gst-launch-1.0.exe filesrc location=test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3d11videosink`
is significantly slower than this one:
`gst-launch-1.0.exe filesrc location=c://temp//test.mkv ! matroskademux ! h264parse ! avdec_h264 ! videoconvert ! d3dvideosink`
on Windows 10, on VM and Coffee Lake bare metal
cc @seungha.yanghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1034openjpeg: proposal to remove support for OpenJPEG 1.X2019-07-28T18:23:49ZAaron Boxeropenjpeg: proposal to remove support for OpenJPEG 1.XVersions before `2.2` in fact are quite buggy and have significant security vulnerabilities.
Also, lossless encoding can be lossy. 1.5 is ancient.Versions before `2.2` in fact are quite buggy and have significant security vulnerabilities.
Also, lossless encoding can be lossy. 1.5 is ancient.