| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
From f980fd9 to 742c09d
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
HLS files can have arbitrary extra tags in them, and
those can be quite long lines. We need to search
further than 256 bytes sometimes just to get past the
first few lines of the file. Make the limit 4KB,
which matches a typical input block size and should
hopefully cover every crazy input.
https://bugzilla.gnome.org/show_bug.cgi?id=780559
|
|
|
|
|
|
|
|
|
|
|
| |
The GSource for dealing with timeouts in
gst_video_convert_sample_async() might be attached to a non-default
context, so we should not be using g_source_remove() on the returned ID.
The correct thing to do is to keep a reference to the actual GSource and
then call g_source_destroy() on it.
https://bugzilla.gnome.org/show_bug.cgi?id=780297
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=778432
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=777921
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=777525
|
|
|
|
|
|
| |
the last byte with '\0'
https://bugzilla.gnome.org/show_bug.cgi?id=777502
|
|
|
|
|
|
|
|
|
|
| |
There was already a check for that, but it failed because
subformat_guid[0] is a guint32 and that is then casted implicitely to a
guint16 when recursing... just that we checked the uncasted value.
This caused an infinite recursion and thus stack overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=777265
|
|
|
|
|
|
| |
Otherwise we might divide by zero or otherwise create invalid caps.
https://bugzilla.gnome.org/show_bug.cgi?id=777262
|
|
|
|
|
|
|
|
|
|
|
| |
formats with different vertical subsampling
E.g. the following pipelines fail because chroma values after the last
line are read (note: 486 % 4 == 2):
gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=UYVY" ! videoconvert ! "video/x-raw,format=I420" ! fakesink
gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=I420" ! videoconvert ! "video/x-raw,format=UYVY" ! fakesink
gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=I420" ! videoconvert ! "video/x-raw,format=AYUV" ! fakesink
|
| |
|
|
|
|
|
| |
When operating on framerates near 10000fps, at least keep 1
digit of precision for calculations
|
|
|
|
| |
Avoiding trying to use NULL pointers
|
|
|
|
|
|
|
| |
... as a sinkpad need not be called "sink", and it is not the case
for e.g. timeoverlay (and friends).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=776623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way special characters such as '@' can be used in
usernames or passwords, e.g.
rtsp://view:%40dm%4An@<IP-ADDR>/media/camera1
will now parse username and password into:
User: view
Pass: @dm:n
https://bugzilla.gnome.org/show_bug.cgi?id=758389
|
|
|
|
|
|
|
|
|
| |
Make sure ticks start with an accumulator value of 0 by incrementing it
after filling in samples instead of before and by resetting the accumulator
every time a tick begins. This prevents it from being discontinuous at the
beginning of the tick.
https://bugzilla.gnome.org/show_bug.cgi?id=774050
|
|
|
|
|
|
|
| |
This ensure that XInitThreads is called and so gl contexts are properly
initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=776403
|
|
|
|
|
|
|
|
|
|
| |
When plugging and then exposing a parser, don't fail
if it fails to send sticky events. The most likely
reason is that things were flushed due to the app
immediately doing a seek, but we can't detect flushing
separately to other error conditions without a
gst_pad_send_event_full() core function that returns
a GstFlowReturn.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
after a parser or demuxer
There are cases when there is no demuxer involved that could do the
buffering, e.g. HLS with raw MP3 or AAC. In this case we want to place
the buffering multiqueue after the parser.
Before this change, we've considered the first element after the
adaptive streaming demuxer as a parser. This is not always true, e.g.
id3demux. Instead we now wait until we actually have a parser (or
decoder).
Fixes playback on such HLS streams.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=775887
|
|
|
|
|
|
|
|
| |
When frames claim to have a footer, ensure they
are large enough to contain one to avoid an invalid
read overrun.
Spotted by Joshua Yabut
|
|
|
|
|
|
|
|
|
|
| |
Ensure that nothing is in any of the streaming thread functions
anymore when going from PAUSED to READY. While the parent's state change
function has deactivated all pads, there is nothing preventing
downstream from activating our srcpad again and calling the getrange()
function. Although we're in READY!
https://bugzilla.gnome.org/show_bug.cgi?id=775687
|
|
|
|
|
|
|
|
| |
Using the max 120 ms buffer size to ensure we have enough space
for decoded data meant that Opus could actually return 120 ms'
worth of data.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
|
|
|
|
|
|
|
|
| |
Always supply a buffer with max size to the decoder, as we
can't really decide how many samples will be in the lost packet
based on the timestamps we get.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
|
|
|
|
|
|
|
|
|
| |
This fixes missing audio when we get buffers with zero
duration, denoting unknown duration. When several such
buffers are received in a row, they're all at the same
timestamp, with zero duration.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=774908
|
|
|
|
|
|
|
|
|
|
| |
If a client gets dropped and the iteration gets restarted, bufpos is
incremented again for all clients that preceded the dropped one, causing
havoc.
Adjust the bufpos for all clients first before trying to drop any.
https://bugzilla.gnome.org/show_bug.cgi?id=774908
|
|
|
|
|
|
|
|
|
|
|
|
| |
max_buffer_usage is the index of the oldest buffer in the queue,
starting at zero, not the number of buffers queued.
find_limits returns the index of the oldest buffer that satisfies the
limits in its min_idx parameter, not the number of buffers needed. Fix
this use too in order to keep passing the tests that read
buffers-queued.
https://bugzilla.gnome.org/show_bug.cgi?id=775351
|
|
|
|
|
|
| |
this stream
https://bugzilla.gnome.org/show_bug.cgi?id=775459
|
|
|
|
|
|
| |
If getting multiple caps events.
https://bugzilla.gnome.org/show_bug.cgi?id=775480
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
subtitle renderer
https://bugzilla.gnome.org/show_bug.cgi?id=775224
|
|
|
|
|
| |
We're not going to get a buffer or GAP event anymore after EOS and would
wait forever otherwise.
|
|
|
|
|
|
| |
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
|
|
|
|
|
|
|
| |
afterwards
Otherwise we'll get a g_critical() before erroring out cleanly on
https://samples.mplayerhq.hu/A-codecs/ATRAC3/SND0.AT3
|