- Oct 02, 2018
-
-
Tim-Philipp Müller authored
- Sep 27, 2018
-
-
... and fallback to gst_audio_info_set_format for not yet supported layouts. Fix audio playback on iOS 12. Based on patch from Byron Schiel <byron@canary.is> https://bugzilla.gnome.org/show_bug.cgi?id=796919
-
- Sep 22, 2018
-
-
Currently matroskademux does not emit no-more-pads until the first Cluster is parsed, even though the Tracks have already been parsed and from that point on there can be no more tracks. This is important in MSE because the browser needs to know when the MSE initialization segment has been completely parsed so that it can expose the tracks to the user. Some applications depend on this been done before they feed frames to the demuxer. As a consequence, historically WebKit has relied on hacks such as listening to the `pad-added` event, which made impossible to support multiple tracks in the same file. Let's fix that. https://bugzilla.gnome.org/show_bug.cgi?id=797187
-
- Sep 21, 2018
-
-
This patch allows matroskademux to parse a second Tracks element, erroring out if the tracks are not compatible (different number, type or codec) and emitting new caps and tag events should they have changed. https://bugzilla.gnome.org/show_bug.cgi?id=793333
-
This splits gst_matroska_demux_add_stream() into: * gst_matroska_demux_parse_stream(): will read the Matroska bytestream and fill a GstMatroskaTrackContext. * gst_matroska_demux_parse_tracks(): will check there are no repeated tracks. * gst_matroska_demux_add_stream(): creates and sets up the pad for the track. https://bugzilla.gnome.org/show_bug.cgi?id=793333
-
This is necessary for MSE, where a new MSE initialization segment may be appended at any point. These MSE initialization segments consist of an entire WebM file until the first Cluster element (not included). [1] Note that track definitions are ignored on successive headers, they must match, but this is not checked by matroskademux (look for `(!demux->tracks_parsed)` in the code). Source pads are not altered when the new headers are read. This patch has been splitted from the original patch from eocanha in [2]. [1] https://www.w3.org/TR/mse-byte-stream-format-webm/ [2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212 https://bugzilla.gnome.org/show_bug.cgi?id=793333
-
- Sep 16, 2018
-
-
Tim-Philipp Müller authored
- Sep 11, 2018
-
-
Jan Schmidt authored
The stream context was holding a reference to the internal queue and pads, with pad probes that were in turn holding references to the stream context. This lead to a leak if the request pads weren't explicitly released. https://bugzilla.gnome.org/show_bug.cgi?id=796893
-
Jan Schmidt authored
When handling input with timestamps that repeat, sometimes splitmuxsink would get confused and ignore a keyframe. The logic in question is a holdover from before the cmd queue moved the file cutting to the multiqueue output side and made it deterministic, so it's no longer needed on the input here. https://bugzilla.gnome.org/show_bug.cgi?id=796773
-
Always wait with starting the RTCP thread until either a RTP or RTCP packet is sent or received. Special handling is needed to make sure the RTCP thread is started when requesting an early RTCP packet. We want to wait with starting the RTCP thread until it's needed in order to not send RTCP packets for an inactive source. https://bugzilla.gnome.org/show_bug.cgi?id=795139
-
This fixes an assertion when the driver implement CROPCAP but does not set the PAR.
-
- Sep 07, 2018
-
-
Nirbheek Chauhan authored
Bad backport, host_system is not defined in this branch.
-
Nirbheek Chauhan authored
The speex headers assume that WIN32 will always be defined when building on Windows, but this is only true by default on MinGW. Always set it explicitly.
-
Nirbheek Chauhan authored
The mpg123 headers now contain a definition for ssize_t and building with MSVC fails because of a redefinition for ssize_t
-
- Aug 31, 2018
-
-
Nicolas Dufresne authored
The propose allocation was offering a pool even in DMABUF_IMPORT or USERPTR mode. These pool are internal only.
-
- Aug 21, 2018
-
-
The desired colorimetry is logged with all parameters (colorpsace, range, matrix, and transfer function), but of the values actually set by the driver, only colorspace is logged. Complete the debug log message to display all colorimetry parameters: Desired colorspace is 8:1:1:1 Got format of 640x480, format YU12, nb planes 1, colorspace 8 -> Desired colorspace is 8:1:1:1 Got format of 640x480, format YU12, nb planes 1, colorspace 8:0:0:0 https://bugzilla.gnome.org/show_bug.cgi?id=796940
-
gstjpegdec sets 1:4:0:0 colorimetry (full range BT.601 YCbCr encoding with unknown primaries and unknown transfer function). This currently gets translated to bt601 or bt709 depending on resolution. Both cases result in a negotiation failure: ERROR: from element /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: Device '/dev/video0' does not support 1:4:0:0 colorimetry Improve the guessing game by selecting JPEG colorimetry (JPEG colorspace with sRGB transfer function) under these specific conditions, and loosen the matching so that 1:4:0:0 input gets accepted if the device is actually configured to 1:4:7:1 (V4L2_PIX_FMT_JPEG default). https://bugzilla.gnome.org/show_bug.cgi?id=796940
-
Setting the priv field to a magic value stops V4L2 core from zeroing the extended colorimetry fields quantization, ycbcr_enc, and xfer_func for non-mplane queues. https://bugzilla.gnome.org/show_bug.cgi?id=796940
-
- Aug 17, 2018
-
-
- Aug 16, 2018
-
-
Nicolas Dufresne authored
-
- Aug 12, 2018
- Aug 08, 2018
-
-
This tests APIs that don't exist any longer and also doesn't work at all, and was last touched in a meaningful way in 2006.
-
- Aug 02, 2018
-
-
The input from an v4l2 device that was used the first time was remembered for next times, and set again always the pipeline is set to READY state. This was making that users wasn't able to select a different input without having to create a new pipeline. This patch makes that v4l2src element forget previous used input when going to NULL state, so it will check again for the current selected input when going again to READY state. Users can change to NULL state, select a new input with a VIDIOC_S_INPUT ioctl and change to PLAYING again. https://bugzilla.gnome.org/show_bug.cgi?id=796908
-
Sebastian Dröge authored
This triggers immediate re-sending of the configuration data in-band. https://bugzilla.gnome.org/show_bug.cgi?id=796877
-
Sebastian Dröge authored
Just write it with a duration of 0, no samples, etc.
-
- Aug 01, 2018
-
-
Nicolas Dufresne authored
All these were copy pasted and would lead to assertion when chained with rtpmux. This commit rewrite the negotiation with downstream. This also drop the fallback to ancient names if the pad is unlinked. This was completly arbitrary decision that made no sense. https://bugzilla.gnome.org/show_bug.cgi?id=796809
-
Matthew Waters authored
Otherwise there may be no valid typedef of GLsync. ... /usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:93:24: note: in definition of macro 'GST_GL_EXT_FUNCTION' ret (GSTGLAPI *name) args; ^~~~ /usr/include/gstreamer-1.0/gst/gl/glprototypes/sync.h:33:23: error: 'GLsync' has not been declared (GLsync sync)) ^~~~~~ ... https://bugzilla.gnome.org/show_bug.cgi?id=796879
-
- Jul 25, 2018
-
-
Just remove the code. It's not doing anything useful anyways. The modified caps are the result of a caps query, so either not used afterwards of a reference to some internal caps of another element that should not be modified. https://bugzilla.gnome.org/show_bug.cgi?id=796837
-
Sebastian Dröge authored
PTS can start again from a different offset while the running time is increasing. The only thing that matters here is the running time. https://bugzilla.gnome.org/show_bug.cgi?id=796807
-
- Jul 19, 2018
-
-
Tim-Philipp Müller authored
- Jul 18, 2018
-
-
This was the last remaining place where modifying/unreffing the input stream was not protected by the lock https://bugzilla.gnome.org/show_bug.cgi?id=796639
-
- Jul 14, 2018
-
-
Nicolas Dufresne authored
When the pool is started, we allocate and release buffer, expecting the pool release-buffer handler to queue them. Though, as we rely on release function, there is no direct way to detect that this process didn't work. To check this, validate that the number of queued buffer is the same as the number of allocated buffers. This allow returning an error when buffer importation was refused by the driver. https://bugzilla.gnome.org/show_bug.cgi?id=583890
-
Nicolas Dufresne authored
This will avoid sending EOS on v4l2src when a driver sends an empty buffers. This case would be a bug in the driver, but yet the camera should keep running. This also removes the check for corrupted buffers, as this check is already done later. https://bugzilla.gnome.org/show_bug.cgi?id=794842
-
-