| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787254
|
|
|
|
| |
From f980fd9 to 742c09d
|
|
|
|
|
|
|
| |
Causes problems with the new gtk-doc 1.26 otherwise,
but is a good idea in any case.
https://bugzilla.gnome.org/show_bug.cgi?id=786364
|
|
|
|
|
|
|
|
|
|
| |
Since 1.6, the transfer function for BT2020 has been changed from BT709
to BT2020_12. It's the same function, but with more precision. As a side
effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
GStreamer ended up making a guess, it would not match anything supported
by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
BT2020 transfer function in replacement of BT709 whenever a 4K
resolution is detected.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The last entry will most likely get new samples added to it in "robust"
muxing mode, changing the samples_per_chunk and thus making it wrong to
keep the last two entries merged. It will run into an assertion later
when adding a new sample to the chunk.
Thanks to gdiener@cardinalpeak.com for the analysis of the bug and
proposal for a solution.
|
|
|
|
|
|
|
|
|
|
| |
There might be other chunks after the data chunk, so clipping the chunk
size with the data size can lead to a negative number and all following
calculations go wrong and cause crashes or worse.
This was introduced in 3ac119bbe2c360e28c087cf3852ea769d611b120.
https://bugzilla.gnome.org/show_bug.cgi?id=783760
|
|
|
|
| |
There could be multiple video tracks with timecodes.
|
|
|
|
| |
return not-OK
|
|
|
|
|
|
|
|
| |
Timecode trak is only supported for mov right now, not for mp4. That
code would otherwise create an invalid trak if the muxed video contained
timecode metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=782684
|
|
|
|
|
|
| |
This reverts commit 6578c44a92a92b922ef45871097eb60831807173.
This commit is not relevant for 1.10.
|
|
|
|
|
|
| |
This reverts commit 84cb0852e1184176ab953bda459b811a050dfcd1.
It actually requires further changes to qtdemux.
|
|
|
|
|
|
|
|
|
|
|
|
| |
They should have ideally the same timescale of the video track, which we
can't guarantee here as in theory timecode configuration and video
framerate could be different. However we should set a correct timescale
based on the framerate given in the timecode configuration, and not just
use the framerate numerator.
Different than the 1.12 version of the patch, this uses the previous,
suboptimal calculation of the timescale for video tracks to be
consistent with the video track.
|
|
|
|
|
|
| |
Since mss has no moov, default stsd entry should be created with media-caps.
https://bugzilla.gnome.org/show_bug.cgi?id=782042
|
|
|
|
|
|
| |
If gst_segment_do_seek() fails, we shouldn't try seeking on that
resulting segment but just error out. Crashes further down the line
otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no clock was provided directly by rtspsrc. This behaviour was removed
by f8013487c91a6ffc552a4b25aa1a70f0bd5377f8 and results in rtspsrc not
providing the system clock via the rtpjitterbuffer.
As a result, if another element like an audio sink, provides a clock,
the pipeline would select that (when going to PAUSED/PLAYING again later).
Audio clocks usually don't progress in PAUSED, and thus our live source
won't be able to use the clock to produce data, making the sink never
preroll and everything is stuck.
|
|
|
|
|
|
| |
... unless the muxer uses the same audio pad template name as
splitmuxsink. We can't request a pad called "audio_0" on a muxer that
wants pads to be "sink_%d".
|
|
|
|
|
|
| |
Fix unit test failure
https://bugzilla.gnome.org/show_bug.cgi?id=781362
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780478
|
|
|
|
|
|
|
|
|
|
|
|
| |
TFDTs with time 0 are being ignored since commit 1fc3d42f. They're
mistaken with the case of not having TFDT, but those two cases
must be distinguished in some way.
This patch passes an extra boolean flag when the TFDT is present.
This is now the condition being evaluated, instead of checking for
0 time.
https://bugzilla.gnome.org/show_bug.cgi?id=780410
|
| |
|
|
|
|
|
|
|
| |
This reverts commit eeea2a7fe88a17b15318d5b6ae6e190b2f777030.
It breaks EOS in some sender pipelines, see
https://bugzilla.gnome.org/show_bug.cgi?id=773218#c20
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780040
|
|
|
|
|
|
|
|
|
| |
Previously we were switching from one chunk to another on every single
buffer. This wastes some space in the headers and, depending on the
software, might depend in more reads (e.g. if the software is reading
multiple samples in one go if they're in the same chunk).
https://bugzilla.gnome.org/show_bug.cgi?id=771478
|
|
|
|
|
|
|
|
| |
Take into account the atoms at the end of the 'trak' atom when
recovering it. So that its size (already computed and added in the trak
size) isn't making offsets wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=771478
|
|
|
|
|
|
|
| |
Return before that to preserve our successfull results, otherwise no
moov recovery information would be written
https://bugzilla.gnome.org/show_bug.cgi?id=771478
|
|
|
|
|
|
|
| |
Skip more atoms at the header until it finds the 'mdat' to continue the
moov recovery
https://bugzilla.gnome.org/show_bug.cgi?id=771478
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=779858
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In function rtp_jitter_buffer_calculate_pts: If gap in incoming RTP
timestamps is more than (3 * jbuf->clock_rate) we call
rtp_jitter_buffer_reset_skew which resets pts to 0. So components down
the pipeline (playes, mixers) just skip frames/samples until pts becomes
equal to pts before gap.
In version 1.10.2 and before this checking was bypassed for packets with
"estimated dts", and gaps were handled correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=778341
|
|
|
|
|
|
| |
The functions from math.h may be implemented in libm.
https://bugzilla.gnome.org/show_bug.cgi?id=774876
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Let libsoup handle redirection automatically.
And then, to figure out redirection uri, extract it on "restarted"
callback which will be fired before soup_session_send() is returned.
https://bugzilla.gnome.org/show_bug.cgi?id=778428
|
|
|
|
|
|
|
|
|
| |
Update the image size according the amount of data we are going to
read/write. This workaround bugs in driver where the sizeimage provided
by TRY/S_FMT represent the buffer length (maximum size) rather then the expected
bytesused (buffer size).
https://bugzilla.gnome.org/show_bug.cgi?id=775564
|
|
|
|
|
|
| |
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=778815
|
|
|
|
|
|
|
|
| |
Set MAY_BE_LEAKED flag on static pads returned by gst_v4l2_object_get_*_caps()
functions. Made functions thread safe by using g_once_init[enter|leave]
funtions.
https://bugzilla.gnome.org/show_bug.cgi?id=778453
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In gst_v4l2_allocator_qbuf(), the memory is referenced after the
buffer is queued. Once queued (VIDIOC_QBUF), the buffer might be handled
by the V4L2 driver (e.g. decoded) and dequeued (gst_v4l2_allocator_dqbuf),
through a different thread, before the memory is referenced (gst_memory_ref).
In this case, in gst_v4l2_allocator_dqbuf(), the memory is unreferenced
(gst_memory_unref) before having been referenced: the memory refcount
reaches 0, and the memory is freed.
So, to avoid this crossing case, in gst_v4l2_allocator_qbuf(), the
memory shall be referenced before the buffer is queued.
https://bugzilla.gnome.org/show_bug.cgi?id=777399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit 1ea9735a I see these error while using the webcam
integrated in my laptop:
GStreamer-CRITICAL **: gst_value_list_get_size: assertion 'GST_VALUE_HOLDS_LIST (value)' failed
The issue is gst_v4l2src_value_simplify() was doing its job of
generating a single value, rather than the original list. That why,
when getting the list size, a critical warning was raised.
This patch takes advantage of the compiler optimizations to verify
first if the list was simplified, thus use it directly, otherwise,
if it is a list, verify its size.
https://bugzilla.gnome.org/show_bug.cgi?id=776106
|
|
|
|
|
|
|
|
|
|
|
| |
If for some reason we fail to probe formats (all try_fmt calls fail, for
example), this is not a critical error, but we end up with an empty list
of interlace modes. This causes all subsequent negotiation to fail.
This patch fixes interlace-mode setting to be skipped if we failed to
detect any.
https://bugzilla.gnome.org/show_bug.cgi?id=775702
|
| |
|
| |
|
|
|
|
|
|
| |
This goes around the inefficient control message based filtering and
does all the filtering kernel-side. Unfortunately this is Linux-only and
there is no IPv6 variant of it (yet).
|
|
|
|
|
|
|
|
|
|
|
| |
Some radio streams uses StreamTitle='' to reset the title after a
track stopped playing, e.g. while the host talks between tracks or
during news segments.
This change forces an empty tag object to be distributed if
StreamTitle or StreamUrl is received with empty value, thus allowing
downstream elements to get notified about this.
https://bugzilla.gnome.org/show_bug.cgi?id=778437
|
|
|
|
|
|
| |
Used signed calculations when measuring the max_ts of an input
fragment, so as to calculate the correct duration and offset
when buffers have timestamps preceding their segment
|
|
|
|
|
|
| |
Fixes crash with fuzzed file.
https://bugzilla.gnome.org/show_bug.cgi?id=777940
|
| |
|
| |
|