- 12 Mar, 2020 3 commits
-
-
Tim-Philipp Müller authored
-
-
-
- 11 Mar, 2020 2 commits
-
-
* Implement the GstURIHandlerInterface * Rework the locking * Implement backward seeking handling * Generate documentation
-
- 10 Mar, 2020 8 commits
-
-
Lower the verbosity of the 'sync' log message emitted each buffer from gst_v4l2src_create down to LOG(6) from INFO(4). This brings the logging behavior of v4l2src closer to the GStreamer guidelines, which recommend the INFO level be reserved for rare or one-off messages.
-
The caps received from qtdemux for AC-4 content are audio/x-gst-fourcc-ac_4 Based on patch by: Savinderjit Kaur Fixes gstreamer/gst-plugins-good#413
-
Matthew Waters authored
-
Matthew Waters authored
Ignore the return value of gst_pad_set_caps() so that setcaps will set a framerate that is usable. Fixes gstreamer/gst-plugins-good#705
-
Matthew Waters authored
They will be repropagated anyway.
-
-
- Refactored the planar transform method to support all video formats that are stored planar, independent of the used subsampling - Added support for Y444
-
-
- 09 Mar, 2020 1 commit
-
-
Sebastian Dröge authored
-
- 06 Mar, 2020 1 commit
-
-
gst_buffer_map () results in memcopying when a GstBuffer contains more than one GstMemory and when AVC (length-prefixed) alignment is used. This has quite an impact on performance on systems with limited amount of resources. With this patch the whole GstBuffer will not be mapped at once, instead each individual GstMemory will be iterated and mapped separately.
-
- 05 Mar, 2020 1 commit
-
-
By explictly including QtGui/qopengl.h we force the code path that defines GLsync in the Qt-specific way. Without that, some platforms failed to compile the qmlgl plugin, since neither Qt nor gstreamer defined GLsync then, leading to e.g.: ``` make[4]: Entering directory '/.../gst-plugins-good-1.16.1/ext/qt' CXX libgstqmlgl_la-qtitem.lo In file included from gstqtgl.h:32, from qtitem.h:27, from qtitem.cc:28: /.../usr/include/gstreamer-1.0/ gst/gl/gstglfuncs.h:93:17: error: expected identifier before ‘*’ token ret (GSTGLAPI *name) args; ^ /.../usr/include/gstreamer-1.0/ gst/gl/glprototypes/sync.h:27:1: note: in expansion of macro ‘GST_GL_EXT_FUNCTION’ GST_GL_EXT_FUNCTION (GLsync, FenceSync, ^~~~~~~~~~~~~~~~~~~ ```
-
- 04 Mar, 2020 4 commits
-
-
-
Håvard Graff authored
When calling gst_rtp_jitter_buffer_reset you pass in a seqnum. This is considered the starting-point for a new stream. However, the old behavior would unref this buffer, basically lying to the thread that is pushing out buffers saying that it can expect this buffer, when it would never arrive. The resulting effect being no more buffer pushed out of the jitterbuffer, and it would buffer incoming data indefinitely. By instead inserting the buffer in the gap_packets queue, the _reset() function will take responsibility for using that as the first buffer of the new stream. Fixes #703
-
In order to concatenate fragments, splitmuxsrc offsets the start of each fragment PTS to 0 to align it with the previous file. This means that DTS can go negative for the first fragment, with really bad results. Add a fixed offset to outgoing timestamp ranges to avoid that.
-
Vanilla mono video was generating a spurious warning into the debug log that's just misleading. Handle mono caps explicitly to avoid the warning.
-
- 03 Mar, 2020 6 commits
-
-
In this mode each field is carried using its own buffer. Allow deinterlace to negotiate caps with the Interlaced feature and adjust the algorithm fetching lines. Fix #620
-
No semantic change so far, will be used to implement alternate support.
-
The LINE2() macro already prevents out of bound indexes using CLAMP_HI() and CLAMP_LOW().
-
Output frames used to have their interlace mode set to the same one as the input. This breaks their field and comp heights when deinterlacing an alternate stream.
-
In interlace-mode=alternate the input buffers have half the size of the output ones as each field has its own buffer.
-
Each FLAC metadata block starts with a flag denoting whether it is the last metadata block. The existing flacparse code moves any existing VORBISCOMMENT block to immediately follow the STREAMINFO block without changing any block's last-metadata-block flag. If no VORBISCOMMENT block exists, it created one with the last-metadata-block flag set to true. This results in gstflacdec sometimes giving bad headers to libflac when trying to play perfectly valid FLAC files depending on the file's metadata ordering. Depending on the contents of the other metadata blocks, current versions of libflac may or may not return FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER when given this broken metadata. This is most noticeable with files that have a large cover art image attached where VORBISCOMMENT is the very last metadata block with no PADDING afterwards. This patch changes that behavior so that: 1. For FLAC files that already have a VORBISCOMMENT block, the metadata order is preserved. 2. For FLAC files that do not have a VORBISCOMMENT block, the generated dummy VORBISCOMMENT is placed immediately after STREAMINFO and inherits the last-metadata-block flag from STREAMINFO. gstreamer/gst-plugins-good#484
-
- 01 Mar, 2020 1 commit
-
-
Yeongjin Jeong authored
When using the testclock for determining clock in test, it is sometimes observed that the clock entry is not registered in time by the aggregator. So deadlock occurs between the aggregator and the test thread.
-
- 28 Feb, 2020 5 commits
-
-
qtdemux: Try to infer useful header values for raw audio if the sound sample descriptions contain zero values
-
Previously it was only used for in24.
-
Sometimes the headers contain useless, wrong or zero values for e.g. the sample size with these formats. There's only a single valid value for them so let's set these instead.
-
-
-
- 26 Feb, 2020 1 commit
-
-
Nirbheek Chauhan authored
We do not have a way to know the format modifiers to use with string functions provided by the system. G_GUINT64_FORMAT and other string modifiers only work for glib string formatting functions. We cannot use them for string functions provided by the stdlib. See: https://developer.gnome.org/glib/stable/glib-Basic-Types.html#glib-Basic-Types.description ``` ../gst/rtpmanager/gstrtpjitterbuffer.c: In function 'gst_jitter_buffer_sink_parse_caps': ../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: unknown conversion type character 'l' in format [-Werror=format=] || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1) ^~~~~~~~~~ In file included from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/gtypes.h:32, from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/galloca.h:32, from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib.h:30, from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/gst.h:27, from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/rtp/gstrtpbuffer.h:27, from ../gst/rtpmanager/gstrtpjitterbuffer.c:108: /home/nirbheek/cerbero/build/dist/windows_x86/lib/glib-2.0/include/glibconfig.h:69:28: note: format string is defined here #define G_GUINT64_FORMAT "llu" ^ ../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: too many arguments for format [-Werror=format-extra-args] || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1) ^~~~~~~~~~ ``` See also: gstreamer/gstreamer!379
-
- 25 Feb, 2020 2 commits
-
-
Sebastian Dröge authored
-
Usually something else is pulling it in somehow already, but not on Windows.
-
- 24 Feb, 2020 1 commit
-
-
- 21 Feb, 2020 2 commits
-
-
Previously we saved the buffer_timestamp straight into mux->cluster_time. Since the cluster time saved into the file does not have as high precision as GstClockTime depending on the timecodescale the rounding of relative_timestamp was invalid as mux->cluster_time which it was calculated relative to was not equal to the cluster time written to the matroska file. Example of "mkvinfo -v" of how it looks before and after this change in an scenario where previously timestamps got out of order because of this issue. Notice the timestamp of the SimpleBlock right before and right after the Cluster now being in order. The consequence of this however is that the cluster timestamp is not necessarily the same as the timestamp of the first buffer in the cluster however (in case it's rounded up). Before | + SimpleBlock (track number 1, 1 frame(s), timecode 126.922s = 00:02:06.922) | + Frame with size 432 | + SimpleBlock (track number 2, 1 frame(s), timecode 126.933s = 00:02:06.933) | + Frame with size 329 | + SimpleBlock (track number 2, 1 frame(s), timecode 126.955s = 00:02:06.955) | + Frame with size 333 |+ Cluster | + Cluster timecode: 126.954s | + Cluster previous size: 97344 | + SimpleBlock (key, track number 1, 1 frame(s), timecode 126.954s = 00:02:06.954) | + Frame with size 61239 | + SimpleBlock (track number 2, 1 frame(s), timecode 126.975s = 00:02:06.975) | + Frame with size 338 After | + SimpleBlock (track number 1, 1 frame(s), timecode 135.456s = 00:02:15.456) | + Frame with size 2260 | + SimpleBlock (track number 2, 1 frame(s), timecode 135.468s = 00:02:15.468) | + Frame with size 332 | + SimpleBlock (track number 2, 1 frame(s), timecode 135.490s = 00:02:15.490) | + Frame with size 335 |+ Cluster | + Cluster timecode: 135.489s | + Cluster previous size: 158758 | + SimpleBlock (key, track number 1, 1 frame(s), timecode 135.490s = 00:02:15.490) | + Frame with size 88070 | + SimpleBlock (track number 2, 1 frame(s), timecode 135.511s = 00:02:15.511) | + Frame with size 336
-
Disable session sharing and cookie jar when cookies property is set. The cookie jar actually replaces or removes any existing Cookie header set on the message, so the cookies property was effectively being ignored. There doesn't appear to be a way to inject the cookies into the jar without having to specify matching domains etc., so it's not possible to simulate the old behaviour of unconditionally sending the cookies with all messages, besides simply disabling the cookie jar.
-
- 20 Feb, 2020 2 commits
-
-
Comparing gst_rtspsrc_loop_interleaved and gst_rtspsrc_loop_udp, and investigating on timeout issues, it sounds like a piece of code has been originally copied from udp to the interleaved one. The timeout variable is never used inside the interleaved one. No side effect has been seen in the removed function calls. The debug message removed is pointless as the timeout used is "src->tcp_timeout" that is fixed. The presence of the two timeout drove my team in investigating if the reference to the tcp_timeout was correct (it is). Hence we removed the misleading reference to the local timeout variable.
-
Matthew Waters authored
we were setting the max-dropout-time to the value of the max-misorder-time which by default has a factor of 30 difference in value.
-