GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:21:54Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/264video: add explicit setter and getter for GstVideoCropMeta2021-09-24T13:21:54ZBugzilla Migration Uservideo: add explicit setter and getter for GstVideoCropMeta## Submitted by Arjen Veenhuizen
**[Link to original bug (#764987)](https://bugzilla.gnome.org/show_bug.cgi?id=764987)**
## Description
Created attachment 325851
Add setter and getter for GstVideoCropMeta
GstVideoCropMeta doe...## Submitted by Arjen Veenhuizen
**[Link to original bug (#764987)](https://bugzilla.gnome.org/show_bug.cgi?id=764987)**
## Description
Created attachment 325851
Add setter and getter for GstVideoCropMeta
GstVideoCropMeta does not have any setter and getter, making it impossible to set or get GstVideoCropMeta fields from Python via gi-introspection.
This patch adds the neccesary setter and getter.
**Attachment 325851**, "Add setter and getter for GstVideoCropMeta":
[add_setter_and_getter_for_GstVideoCropMeta.patch.txt](/uploads/1851560a974a4bb7ff8f2af3bfcbc2b2/add_setter_and_getter_for_GstVideoCropMeta.patch.txt)
### See also
* [Bug 764902](https://bugzilla.gnome.org/show_bug.cgi?id=764902)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/24GES: add reverse playback support2024-03-28T15:11:02ZBugzilla Migration UserGES: add reverse playback support## Submitted by kevin
**[Link to original bug (#764788)](https://bugzilla.gnome.org/show_bug.cgi?id=764788)**
## Description
Created attachment 325594
Little program which plays a file and reverses it after 10 seconds
I tried...## Submitted by kevin
**[Link to original bug (#764788)](https://bugzilla.gnome.org/show_bug.cgi?id=764788)**
## Description
Created attachment 325594
Little program which plays a file and reverses it after 10 seconds
I tried to reverse playback with playbin and it does work.
In my case, I need GStreamer Editing Service to insert files
in the timeline dynamically.
When I try to reverse, it seems like I receive an EOS message and
d3dvideosink render a 0 position, back to the beginning of the file,
when I was at 10 seconds.
**Attachment 325594**, "Little program which plays a file and reverses it after 10 seconds":
[Gstreamer_Reverse_GES.zip](/uploads/b7693d6e3d089eba20bf3d4253a49848/Gstreamer_Reverse_GES.zip)
Version: 1.8.0
### Depends on
* [Bug 770046](https://bugzilla.gnome.org/show_bug.cgi?id=770046)
* [Bug 770047](https://bugzilla.gnome.org/show_bug.cgi?id=770047)
* [Bug 769624](https://bugzilla.gnome.org/show_bug.cgi?id=769624)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/366dashdemux: apply suggestedPresentationDelay to seek and seek range2021-09-24T14:34:11ZBugzilla Migration Userdashdemux: apply suggestedPresentationDelay to seek and seek range## Submitted by Wojciech Przybyl
**[Link to original bug (#764728)](https://bugzilla.gnome.org/show_bug.cgi?id=764728)**
## Description
When seeking or querying a range of seek on a live stream,
suggestedPresentationDelay has to b...## Submitted by Wojciech Przybyl
**[Link to original bug (#764728)](https://bugzilla.gnome.org/show_bug.cgi?id=764728)**
## Description
When seeking or querying a range of seek on a live stream,
suggestedPresentationDelay has to be taken into account. Currently
it is only used in streams setup. As a result seeking to live position
discards suggestedPresentationDelay and seeks to earlier time than allowed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3042splitmuxsink: not sure GAP events are handled correctly2023-10-13T15:22:43ZBugzilla Migration Usersplitmuxsink: not sure GAP events are handled correctly## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764648)](https://bugzilla.gnome.org/show_bug.cgi?id=764648)**
## Description
Reading that code, I find 2 things supsicious:
- GAP events are not catched in...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764648)](https://bugzilla.gnome.org/show_bug.cgi?id=764648)**
## Description
Reading that code, I find 2 things supsicious:
- GAP events are not catched in handle_mq_input(), that means ctx->in_running_time won't be updated. In case of a long gap, that means it's going to queue other streams a lot because the stream with a gap won't be considered ready to let GOPs out. I think in_running_time should be set to gap's timestamp+duration, no?
- GAP's duration is not taken into account in handle_mq_output(). In the case of a long gap, that means out_running_time will stay in the past, and complete_or_wait_on_out() won't send EOS until we get the next buffer/gap on that stream which could freeze the pipeline for some time.
I'm not really sure how gap events works, so maybe I'm just wrong here.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/266qtdemux: Ensure stream duration by using stts box2021-09-24T13:31:39ZBugzilla Migration Userqtdemux: Ensure stream duration by using stts box## Submitted by Seungha Yang
**[Link to original bug (#764637)](https://bugzilla.gnome.org/show_bug.cgi?id=764637)**
## Description
qtdemux: Ensure stream duration by using stts box
Some files have incorrect stream duration val...## Submitted by Seungha Yang
**[Link to original bug (#764637)](https://bugzilla.gnome.org/show_bug.cgi?id=764637)**
## Description
qtdemux: Ensure stream duration by using stts box
Some files have incorrect stream duration value in mdhd box
So, we need to double check the stream duration.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/265splitmuxsink: deadlock when reference stream has low framerate2021-09-24T13:31:38ZBugzilla Migration Usersplitmuxsink: deadlock when reference stream has low framerate## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764635)](https://bugzilla.gnome.org/show_bug.cgi?id=764635)**
## Description
I'm using splitmuxsink with matroskamux and filesink.
I've got 3 input streams:...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#764635)](https://bugzilla.gnome.org/show_bug.cgi?id=764635)**
## Description
I'm using splitmuxsink with matroskamux and filesink.
I've got 3 input streams:
- video: 8 jpeg frames per sec, so all buffers are keyframes
- audio: normal mp4a
- subtitle: 1 buffer every second
1) During the 1s it waits for a subtitle buffer, check_queue_length() allows audio/video queues to grow because the subtitle queued_bufs is empty, see the /* If another stream is starving, grow */ case. The 7th GOP arrives at t=875ms.
2) At t=900ms (so between 2 GOPs), the subtitle buf arrives, it's blocked in handle_mq_input() waiting for the next GOP to complete, because max_in_running_time=875ms.
3) At t=1000ms the 8th GOP arrives, max_in_running_time is set to 1000ms.
4) The subtitle buffer enters the queue but cannot go out yet because max_out_running_time is still 875ms because audio/subtitle streams didn't catchup to 1000ms yet.
5) Since the subtitle queued_bufs is not empty anymore, the audio queue is not allowed to grow anymore. So next audio buffer needed to catchup to 1000ms are blocked because its queue is full.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2800qtdemux: Support sidx based seek in pull mode2023-07-11T09:58:12ZBugzilla Migration Userqtdemux: Support sidx based seek in pull mode## Submitted by Seungha Yang
**[Link to original bug (#764629)](https://bugzilla.gnome.org/show_bug.cgi?id=764629)**
## Description
qtdemux: Support sidx based seek in pull mode
tfra atom assists seeking to random access point....## Submitted by Seungha Yang
**[Link to original bug (#764629)](https://bugzilla.gnome.org/show_bug.cgi?id=764629)**
## Description
qtdemux: Support sidx based seek in pull mode
tfra atom assists seeking to random access point. Because it is not mandatory,
however, it is not desirable to rely only on it. In this context, sidx box
can help seek for fragmented file.
This patch enables qtdemux to seek for fragmented file if only sidx available
(i.e., there is no tfra box in a file).https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/26Use coded_width/height which is now also available from ffmpeg2021-09-24T12:52:19ZBugzilla Migration UserUse coded_width/height which is now also available from ffmpeg## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764544)](https://bugzilla.gnome.org/show_bug.cgi?id=764544)**
## Description
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192507.html
See [bug 752802](h...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764544)](https://bugzilla.gnome.org/show_bug.cgi?id=764544)**
## Description
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192507.html
See [bug 752802](https://bugzilla.gnome.org/show_bug.cgi?id=752802) (and probably others) where we could've made use of knowing the uncropped width/height.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/365RTMP send error 32 on Android2021-09-24T14:34:11ZBugzilla Migration UserRTMP send error 32 on Android## Submitted by Mimmo Grottoli
**[Link to original bug (#764471)](https://bugzilla.gnome.org/show_bug.cgi?id=764471)**
## Description
I'm trying to broadcast video and audio via rtmp from different Android devices, and I'm always ge...## Submitted by Mimmo Grottoli
**[Link to original bug (#764471)](https://bugzilla.gnome.org/show_bug.cgi?id=764471)**
## Description
I'm trying to broadcast video and audio via rtmp from different Android devices, and I'm always getting the following errors:
GStreamer+rtmp E 0:00:05.353780468 0x9f9496f0 :0: WriteN, RTMP send error 32 (136 bytes)
E 0:00:05.353919322 0x9f9496f0 :0: WriteN, RTMP send error 32 (54 bytes)
E 0:00:05.354330259 0x9f9496f0 :0: WriteN, RTMP send error 9 (42 bytes)
GStreamer+rtmpsink W 0:00:05.354410363 0x9f9496f0 gstrtmpsink.c:286:gst_rtmp_sink_render:`<rtmpsink0>` error: Failed to write data
I've tried using wowza and youtube as endpoint, but the error is exactly the same.
The pipeline is:
ahcsrc name=cam ! video/x-raw, width=1280, height=720, framerate=(fraction)24/1 \
! videoconvert \
! amcvidenc-omxqcomvideoencoderavc i-frame-interval=24 \
! h264parse \
! tee name=videoTee \
openslessrc ! audioconvert ! queue ! voaacenc \
! tee name=audioTee \
flvmux streamable=true name=flvmux \
! rtmpsink location=\"rtmp://RTMP_HOST:PORT\" \
videoTee. ! queue ! flvmux. \
audioTee. ! queue ! flvmux.
Note:
1) The issue does not happen when I use audiotestsrc instead of openslessrc as audiosource
2) If I remove the audio part from the pipeline the result is good too
3) If I replace flvmux + rtmpsink with mpegtsmux + udpsink I can publish the stream
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/166Add GST_EVENT_LATENCY_CHANGED2021-09-24T11:10:18ZBugzilla Migration UserAdd GST_EVENT_LATENCY_CHANGED## Submitted by Håvard Graff (hgr)
**[Link to original bug (#764396)](https://bugzilla.gnome.org/show_bug.cgi?id=764396)**
## Description
Created attachment 325055
suggested implementation
clipped from #gstreamer:
Lets s...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#764396)](https://bugzilla.gnome.org/show_bug.cgi?id=764396)**
## Description
Created attachment 325055
suggested implementation
clipped from #gstreamer:
Lets start with some history:
Back in 2008 we needed a dynamic jitterbuffer.
After discussing back and forth with wtay, we came to the conclusion that
the proper way to do this was to:
1. Change the latency property on the jitterbuffer
2. The jb would then post a latency message on the bus
3. in the bus-handler (in the application), this msg would be picked up,
and wtay added a new method gst_bin_recalculate_latency that the
application could emit on the main pipeline to have the whole pipeline
query its latency again (each sink sending upstream latency queries etc).
Now this has worked ok for us ever since, in Pexip we terminate the
latency in the mixers, not in the sinks, but other then that it works
exactly the same way as before. But lately we have discovered that this
has some horrific side-effects, in that with many participants connecting,
and latency changing often, we in fact, using this method,
are recalculating EVERYONES latency when we only want to reconfigure that
of a single participant. or more specifically the jitterbuffers with the
same cname belonging to that participant.
Now, I know the idea of "groups of sinks" have been mentioned before,
but we are at a stage now where we really need to be able to re-calculate
latency only for the affected sinks / mixers, and this is where I have a
concrete suggestions: a downstream "latency-changed" event that in turn
can trigger an upstream latency query, either from a sink or from a mixer.
If this was emitted from the jitterbuffer in the same place the
latency-message is emitted, it would mean all affected downstream
mixers/sinks would know "directly" that latency had changed somewhere
upstream from them, and could make decisions based on this.
For us it would mean re-sending latency-queries upstream from the mixers
that received this event, and then using this new latency in the mix.
For this sink-case, it would be the same way, only that with using
this "mode" the sinks would get their new latency "independent" of the
pipeline latency, and the "grouping" would then happen from whichever
sources decided to send this event.
So in the case of rtpbin, you are already changing latency for all the
jitterbuffers with the same cname as one "group", and hence all of them
would also be sending the latency event, ensuring lipsync at the
mixers/sinks.
**Patch 325055**, "suggested implementation":
[latency-changed-event.patch](/uploads/a930c05ad0605378d16153acfb7365ec/latency-changed-event.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/364h264parse removes padding from byte streams2021-09-24T14:34:11ZBugzilla Migration Userh264parse removes padding from byte streams## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding ...## Submitted by Georg Lippitsch
**[Link to original bug (#764372)](https://bugzilla.gnome.org/show_bug.cgi?id=764372)**
## Description
When using h264parse element without a conversion (bytestream to bytestream), it removes padding bytes from the original h264 stream. Producing a real constant bitrate is then not possible anymore.
This can be reproduced with the following command line (you need 10Bit libx264):
# gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080,format=I422_10LE,framerate=25/1 ! x264enc trellis=false option-string=avcintra-class=100 ! video/x-h264,stream-format=byte-stream ! h264parse ! mpegtsmux ! filesink location=test.ts
Every frame should then have exactly 568832 bytes. But checking the file test.ts with ffprobe gives different frame sizes for every frame. The frames sizes can be checked with:
# ffprobe -show_frames test.ts | grep pkt_size
Removing the "h264parse" element from the above pipeline and checking the frame sizes gives the expected size of 568832 bytes for every frame.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/165[2.0] GstUriHandler interface issue in vala2022-04-19T06:37:11ZBugzilla Migration User[2.0] GstUriHandler interface issue in vala## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstU...## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstURIHandlerInterface {
GTypeInterface parent;
/* vtable */
/*`< public >`*/
/* querying capabilities */
GstURIType (* get_type) (GType type);
const gchar * const * (* get_protocols) (GType type);
/* using the interface */
gchar * (* get_uri) (GstURIHandler * handler);
gboolean (* set_uri) (GstURIHandler * handler,
const gchar * uri,
GError ** error);
};
where some members don't have 'GstURIHandler * handler' parameter. with these interfaces, languages like Vala can't implement it because the language implement interface with this parameter by defaulthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/164structure: Large integer gets detected as double instead of int642021-09-24T11:10:20ZBugzilla Migration Userstructure: Large integer gets detected as double instead of int64## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#764288)](https://bugzilla.gnome.org/show_bug.cgi?id=764288)**
## Description
Created attachment 324893
Test case
Running the attached test case gives this ou...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#764288)](https://bugzilla.gnome.org/show_bug.cgi?id=764288)**
## Description
Created attachment 324893
Test case
Running the attached test case gives this output:
Serialized structure measurement, field1=(int)1000000000;
Structure didn't contain an int64 field1
Serialized structure measurement, field1=(double)10000000000;
Structure didn't contain an int64 field1
Why double? There's no decimal point anywhere, shouldn't it be detected as an int64 instead?
PS: I know it's leaky, it's just a small demo.
PS2: Why is there no GST_STRUCTURE_FORMAT ? Now I'm leaking the strings as well as the structures :(
**Attachment 324893**, "Test case":
[serializeme.c](/uploads/bacdbecb1cbec90725402844f731ed05/serializeme.c)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/163GstPreset: fix enum properties2022-11-10T09:20:46ZBugzilla Migration UserGstPreset: fix enum properties## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764240)](https://bugzilla.gnome.org/show_bug.cgi?id=764240)**
## Description
+++ This bug was initially created as a clone of [Bug 763814](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764240)](https://bugzilla.gnome.org/show_bug.cgi?id=764240)**
## Description
+++ This bug was initially created as a clone of [Bug 763814](https://bugzilla.gnome.org/show_bug.cgi?id=763814) +++
GstPreset has the same problem. Resulting in things like "frame-packing=Automatic (use incoming video information)" (this is from x264enc) in the generated preset files. Changing that one is more tricky as we need to keep backwards compatibility...https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/263glmemory: avoid creating a framebuffer every download/copy2021-09-24T13:21:53ZBugzilla Migration Userglmemory: avoid creating a framebuffer every download/copy## Submitted by comicfans44
**[Link to original bug (#764124)](https://bugzilla.gnome.org/show_bug.cgi?id=764124)**
## Description
Created attachment 324655
glmemory: avoid creating a framebuffer every download/copy
this is a...## Submitted by comicfans44
**[Link to original bug (#764124)](https://bugzilla.gnome.org/show_bug.cgi?id=764124)**
## Description
Created attachment 324655
glmemory: avoid creating a framebuffer every download/copy
this is a FIXME in glmemory, avoid creating a framebuffer every download/copy
**Patch 324655**, "glmemory: avoid creating a framebuffer every download/copy":
[0001-glmemory-avoid-creating-a-framebuffer-every-download.patch](/uploads/adbb5358bb47394065fd8f3923339943/0001-glmemory-avoid-creating-a-framebuffer-every-download.patch)
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/262audiosink: doesn't wait for ringbuffer to drain on EOS with sync=false2021-09-24T13:21:53ZBugzilla Migration Useraudiosink: doesn't wait for ringbuffer to drain on EOS with sync=false## Submitted by Topolsky
**[Link to original bug (#764120)](https://bugzilla.gnome.org/show_bug.cgi?id=764120)**
## Description
Created attachment 324653
concat cuttoff last part of second source
Concat element somehow cuts o...## Submitted by Topolsky
**[Link to original bug (#764120)](https://bugzilla.gnome.org/show_bug.cgi?id=764120)**
## Description
Created attachment 324653
concat cuttoff last part of second source
Concat element somehow cuts off 2 seconds of end of second input.
This can be triggered out by analysing output of this pipeline:
gst-launch-1.0 concat name=c audiotestsrc num-buffers=200 ! queue ! c. audiotestsrc num-buffers=200 volume=0.5 ! queue ! c. c. ! alsasink buffer-time=1000000 sync=false
The bug is easily reproducible and it happens every time.
I use branch 1.6 from 15.3 (gstreamer - commit c5ad081b9 about baseparse)
I recorded output of soundcard with audacity and I see that last part of second source (with volume 0.5) is much shorter than first source. Both audiotestsrc has num-buffers=200 so they should be equal.
**Attachment 324653**, "concat cuttoff last part of second source":
![concat-audtstsrc-cutoff](/uploads/763c550515be730cb8cc7fe82b96c46a/concat-audtstsrc-cutoff.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/261docs: add GstAudioVisualizer to documentation2021-09-24T13:21:52ZBugzilla Migration Userdocs: add GstAudioVisualizer to documentation## Submitted by Tim Müller `@tpm`
Assigned to **Luis de Bethencourt `@luisbg`**
**[Link to original bug (#764113)](https://bugzilla.gnome.org/show_bug.cgi?id=764113)**
## Description
Filing bug so we don't forget..## Submitted by Tim Müller `@tpm`
Assigned to **Luis de Bethencourt `@luisbg`**
**[Link to original bug (#764113)](https://bugzilla.gnome.org/show_bug.cgi?id=764113)**
## Description
Filing bug so we don't forget..https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/36Fail to vaapidecode mpegts streams starting between keyframes2021-10-22T07:40:50ZBugzilla Migration UserFail to vaapidecode mpegts streams starting between keyframes## Submitted by Tanner
**[Link to original bug (#764103)](https://bugzilla.gnome.org/show_bug.cgi?id=764103)**
## Description
Hi,
vaapidecode element has been unable to decode previously chunked ts files from filesrc and udpsrc...## Submitted by Tanner
**[Link to original bug (#764103)](https://bugzilla.gnome.org/show_bug.cgi?id=764103)**
## Description
Hi,
vaapidecode element has been unable to decode previously chunked ts files from filesrc and udpsrc. It appears the vaapidecode element doesn't deal with the garbage before a keyframe and bails.
Using the following pipeline I am unable to play a udpsrc mpegts stream and receive no valid frames before end of stream from the vaapidecode element.
gst-launch-1.0 -v udpsrc uri=(makeoneupmulticast) ! tsparse ! video/x-h264 ! h264parse ! vaapidecode ! vaapisink
However, if I modify the pipeline to use avdec_h264 and x264enc to feed into the vaapidecode element, then it is able to play the stream.
gst-launch-1.0 -v udpsrc uri=(makeoneupmulticast) ! tsparse ! video/x-h264 ! h264parse ! avdec_h264 ! x264enc ! vaapidecode ! vaapisink
To test the above, produce a test ts file and confirm you can play it with vaapidecode ! vaapisink. Next, use a multifilesink to chunk it into several pieces. Play the first chunk using a single filesrc (it should play). But then try playing one of the middle chunks. This should reproduce the error. If you chunk on keyframes, then you are less likely to experience the error so I suggest chunking on buffersize.
(I am unable to add attachments due to company policy)
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2704tag: exif: wrong parsing of ISO_SPEED and PHOTOGRAPHIC_SENSITIVITY tags2023-06-23T12:21:49ZBugzilla Migration Usertag: exif: wrong parsing of ISO_SPEED and PHOTOGRAPHIC_SENSITIVITY tags## Submitted by Paulo Neves
**[Link to original bug (#764093)](https://bugzilla.gnome.org/show_bug.cgi?id=764093)**
## Description
Created attachment 324607
A proposed patch.
The comments below take into account the standard ...## Submitted by Paulo Neves
**[Link to original bug (#764093)](https://bugzilla.gnome.org/show_bug.cgi?id=764093)**
## Description
Created attachment 324607
A proposed patch.
The comments below take into account the standard description summary found in
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
According to the site above:
0x8827 is ISO or PhotographicSensitivity in EXIF2.3
0x8833 is ISOSpeed (dependent of SensitivityType in ExifISOTag)
According to gstexif.c:
0x8827 is EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY
0x8833 is EXIF_TAG_ISO_SPEED
Then we have following in gstexif.c@373
/* don't need the serializer as we always write the iso speed alone */
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY,
EXIF_TYPE_SHORT, 0, NULL,
deserialize_add_to_pending_tags},
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_SENSITIVITY_TYPE, EXIF_TYPE_SHORT, 0,
serialize_sensitivity_type, deserialize_sensitivity_type},
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_ISO_SPEED, EXIF_TYPE_LONG, 0, NULL,
NULL},
Which means that EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY will have deferred parsing depending on the EXIF_TAG_SENSITIVITY_TYPE which is wrong as seen from the relation established before in the site.
Instead, the Tag dependent on EXIF_TAG_SENSITIVITY_TYPE should be EXIF_TAG_ISO_SPEED which is not happening.
This creates a bug that results in the ISO parameter never being parsed. A scenario where this happens is if Sensitivity Type is different than 3 (ISO Speed) and instead is 2 (Recommended Exposure Index). What will happen is that no EXIF_TAG_ISO_SPEED (0X8833) will exist because the type is 2 and the deferred EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY (0x8827) was discarded in the SensitivityType parsing because type is different than 3. No more ISO information can be retrieved from the file.
So assuming we now correctly make the EXIF_TAG_ISO_SPEED dependent on the EXIF_TAG_SENSITIVITY_TYPE and leave the EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY correctly represent the GST_TAG_CAPTURING_ISO_SPEED the problem outlined before does not happen because a standard compliant exif field will not even have EXIF_TAG_ISO_SPEED if the EXIF_TAG_SENSITIVITY_TYPE is different than 3. For the example above where the EXIF_TAG_SENSITIVITY_TYPE is 2, the exif will have a RecommendedExposureIndex (0x8832) tag which is currently not handled. The EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY would then be parseable and not dependent on anything.
The problem is that EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY is of size type EXIF_TYPE_SHORT which for a reason I do not understand does not have a function that parses shorts like parse_exif_`<type>`_tag. This happens with other types. I propose thus the following:
static void parse_exif_short_tag(GstExifReader * reader, const GstExifTagMatch tag, guint32 count, guint32 offset, const guint8 * offset_as_data)
This way in gstexif.c@parse_exif_long_tag we can parse EXIF_TYPE_SHORTs.
With everything together the problem is solved on my side.
I attach a proposed patch.
Hoping I was clear and thankful for Gstreamer
Paulo Neves
~~**Patch 324607**~~, "A proposed patch.":
[ISO_tag.patch](/uploads/610d2a895d79718c110f829dfded76ab/ISO_tag.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/162preset: Complains about not being able to serialize NULL string properties2023-02-03T20:53:50ZBugzilla Migration Userpreset: Complains about not being able to serialize NULL string properties## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764019)](https://bugzilla.gnome.org/show_bug.cgi?id=764019)**
## Description
It checks for gst_value_serialize() to return non-NULL to decide if a property was succe...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764019)](https://bugzilla.gnome.org/show_bug.cgi?id=764019)**
## Description
It checks for gst_value_serialize() to return non-NULL to decide if a property was successfully serialized or not. a NULL string is serialized as NULL though, which is probably correct.
Should probably add some special cases here to not fill the logs with useless things.
Another thing that should be added as a special case is the "parent" property. We can't realistically serialize that one anyway.