- Sep 08, 2021
- Sep 07, 2021
-
-
In case of interlaced JPEG file, we are doubling stride. The scratch scan line should take account of it as well. Part-of: <gstreamer/gst-plugins-good!1042>
-
- Sep 06, 2021
-
-
stop is not used after this point, nor do we create a new segment here since 84725d62 Part-of: <gstreamer/gst-plugins-good!1076>
-
This breaks the duration query and also the seeking query. Broke in 5f1a732b Part-of: <gstreamer/gst-plugins-good!1076>
-
Assignments copy by value, we don't need to memcpy... Part-of: <gstreamer/gst-plugins-good!1076>
-
Seek events are sent upstream on each sink, so if we receive multiple seeks with the same seqnum, we must only perform one seek, not N seeks where N = the number of sinks in the pipeline connected to rtspsrc. This is the same thing done by demuxers like qtdemux or matrsokademux. Part-of: <gstreamer/gst-plugins-good!1075>
-
Part-of: <gstreamer/gst-plugins-good!1074>
-
- Sep 02, 2021
-
-
This works around some AVI files storing byte-stream data in the codec_data. The previous workaround was only checking for 0x00000001 (4 bytes) instead of 0x000001 (3 bytes). Part-of: <gstreamer/gst-plugins-good!1073>
-
- Aug 28, 2021
-
-
When re-using streams, we *do* need to push a `stream-start` event downstream if we previously were EOS'd. Failure to do that would never remove the EOS status on all downstream elements and cause weird issues. Part-of: <gstreamer/gst-plugins-good!1068>
-
- Aug 24, 2021
-
-
Tim-Philipp Müller authored
Might be 24bpp in case an alpha channel is coded but the image is always opaque. Part-of: <gstreamer/gst-plugins-good!1062>
-
e.g. when exporting an opaque image, yet with alpha channel. Apple ProRes certification requires that, when a ProRes-writing application *knows* that the entire frame is opaque, the application writes only RGB without alpha even when the clip is RGBA. For that, this tiny change allows the app to override pixel depth when writing ProRes. Part-of: <gstreamer/gst-plugins-good!1062>
-
- Aug 23, 2021
-
-
Updating of codec_data in the caps is important to propagate changes in sps/pps/vps via NALs. Without this, downstream does not renegotiate when upstream changes resolution. The comment referring to rtph264pay is from 2015 and is out of date. rtph264pay stopped doing that in 2017 with commit dabeed52 Part-of: <gstreamer/gst-plugins-good!1025>
-
- Aug 15, 2021
-
-
souphttpsrc: Always use the content decoder but set `Accept-Encoding: identity` if no compression should be used Some servers respond with gzip-encoded responses regardless of whether the request allowed it to be used in the response. By always having the content decoder enabled, these invalid responses can be decoded correctly while for well-behaving servers the `compress` property selects between allowing compressed responses or not. Fixes gstreamer/gst-plugins-good#833 Part-of: <gstreamer/gst-plugins-good!1054>
-
- Jul 08, 2021
-
-
Mostly for completeness. Part-of: <gstreamer/gst-plugins-good!1027>
-
They're based on per-stream information and that should be reset whenever going to READY state. Part-of: <gstreamer/gst-plugins-good!1027>
-
SO_SNDBUF has been undefined on Windows because of missing WinSock2.h include. And don't use native socket functions (e.g., setsockopt()) if code is expected to be built on Windows. We don't link ws2_32.lib for this plugin. Part-of: <gstreamer/gst-plugins-good!1026>
-
- Jun 11, 2021
-
-
We don't know exactly when QML will stop using them but it should be safe to unref them after at least 2 more buffers were bound. Part-of: <gstreamer/gst-plugins-good!1009>
-
- Jun 03, 2021
-
-
The only other place where these queued buffers are removed, is in setCaps() but that is not called at all on shutdown so this list of buffers could not be removed. Part-of: <gstreamer/gst-plugins-good!1005>
-
- Jun 02, 2021
-
-
Tim-Philipp Müller authored
On Windows with MSVC, jpeg_header_size would end up 2 bytes larger than it should be. This then leads to the first 2 bytes of the actual jpeg image data to be dropped, because we think those belong to the header, which results in an undecodable image when reconstructed in the depayloader. What happens is that when the compiler evaluates jpeg_header_size = mem.offset + read_u16_and_inc_offset_by_2(&mem); it actually uses the mem.offset value after it has been increased by the function call on the right hand size of the equation. From section 6.5 of the C99 spec: 3. The grouping of operators and operands is indicated by the syntax [74]. Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified. Fixes gstreamer/gst-plugins-good#889 Part-of: <gstreamer/gst-plugins-good!1003>
-
- Jun 01, 2021
-
-
Like other basetransform subclasses are doing, drop field which can be converted by deinterlace. Part-of: <gstreamer/gst-plugins-good!1001>
-
Progressive with field-order doesn't make sense Part-of: <gstreamer/gst-plugins-good!1001>
-
Tim-Philipp Müller authored
So we don't rely on NUL terminators inside the data. Part-of: <gstreamer/gst-plugins-good!1000>
-
Tim-Philipp Müller authored
We were passing the size of the adtl chunk to the note/labl sub-chunk parsing function, which means we may memdup lots of data after the chunk string's NUL terminator that doesn't really belong to it. Part-of: <!1000>
-
Tim-Philipp Müller authored
Could be rewritten as lsize > (size - 8) a well, but the extra check seems clearer. Doesn't look like it was problematic, lsize wasn't actually used when parsing the sub-chunks. Part-of: <!1000>
-
- May 14, 2021
- Apr 30, 2021
-
-
qtmux attempts to choose between writing a 32-bit stco chunk offset table when it can, but switch to a 64-bit co64 table when file offsets go over 4GB. This patch fixes a problem where the atom handling code was checking mdat-relative offsets instead of the final file offset (computed by adding the mdat position plus the mdat-relative offset) - leading to problems where files with a size between 4GB and 4GB+offset-of-the-mdat would write incorrect STCO tables with some samples having truncated 32-bit offsets. Smaller files write STCO correctly, larger files would switch to co64 and also output correctly. Part-of: <!972>
-
skip_try_fmt_probes is set to TRUE for v4l2src to skip interlace-mode and colorimetry when probe caps. gst_v4l2_object_set_format_full() will add colorimetry back to caps when iterating over the negotiated caps. There is one case that v4l2src is first in preview state then starts recording. v4l2src caps will change with an additional interlace-mode structure after renegotiation, then v4l2src needs to reset. But this camera driver can't orphan buffer pool, it causes require buffer failed as streaming is still in active state. To fix this, also need to add interlace-mode back to caps for camera to avoid reset. Part-of: <!971>
-
- Apr 22, 2021
- Apr 20, 2021
-
-
We need to save the seek seqnum before the flush stop event since that will start the basesrc task which may send the segment event before we're ready. Part-of: <!957>
-
- Apr 14, 2021
-
-
It might've been set to FLUSHING between the last check and the waiting, and in that case we'd be waiting here forever now. Part-of: <!948>
-
- Apr 13, 2021
-
-
The transport has no relation to whether a media can be seeked. The range response having a duration is the correct thing to check for. Part-of: <!947>
-
Part-of: <!947>
-
This code can be fragile, since it is very exacting in the timestamps that it will accept. Add more logging so it's easier to debug issues and figure out whether it's a bug in the calculation or something wrong in the incoming buffers. Part-of: <!946>
-
volatile is not sufficient to provide atomic guarantees and real atomics should be used instead. GCC 11 has started warning about using volatile with atomic operations. https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719 Discovered in gstreamer/gst-plugins-good#868 Part-of: <gstreamer/gst-plugins-good!941>
-
- Apr 01, 2021
-
-
Some streams have unknown colorimetry in caps, but v4l2object sets default values for each primaries. It will cause check colorimetry fail when do gst_v4l2_video_colorimetry_matches(). To fix this, need to keep the unknown colorimetry in caps same as the default value set by v4l2object. Part-of: <!930>
-
- Mar 25, 2021
-
-
video-info sets gst colorimetry to default value when colorimetry in caps is unparsable or invalid. Then v4l2object uses this gst colorimetry to do mapping with v4l2 colorimetry. This may cause colorimetry mismatch when check mapped gst colorimetry with that read from caps directly. To fix this, need to correct gst colorimetry as that parsed from video-info when check gst_v4l2_video_colorimetry_matches(). Part-of: <!922>
-
Colorimetry of hdr10 video is bt2100-pq with transfer as GST_VIDEO_TRANSFER_SMPTE2084. So map GST_VIDEO_TRANSFER_SMPTE2084 to V4L2_XFER_FUNC_SMPTE2084 to support hdr10 stream playback. Part-of: <!921>
-