The new timeout is always going to be (timeout + delay), however, the
old behavior compared the current timeout to just (timeout), basically
being (delay) off.
This would happen if rtx-delay == rtx-retry-timeout, with the result that
a second rtx attempt for any buffers would be scheduled immediately instead
of after rtx-delay ms.
Simply calculate (new_timeout = timeout + delay) and then use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=773905
Commit 83e718 added a pad template to splitmux request
pads, which means that GstElement now releases the pads on
dispose, but after having removed all elements in the bin
and unlinked them. Make sure we can handle cleanup in that case
without throwing assertions.
https://bugzilla.gnome.org/show_bug.cgi?id=773784
qtdemux.c: In function ‘qtdemux_parse_tree’:
qtdemux.c:10139:16: error: ‘color_table_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (color_table_id != 0) {
^
qtdemux.c:10121:19: note: ‘color_table_id’ was declared here
guint16 color_table_id;
^~~~~~~~~~~~~~
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk.
It might also make sense to use similar numbers in general.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
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).
The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk. This will be handled in a follow-up commit.
https://bugzilla.gnome.org/show_bug.cgi?id=773217
It's required for ProRes to work with other software.
It is also in the MP4 standard, but inventing values here seems a bit
tricky for the general case and it does not really give any extra
information.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
Some buggy payloaders, e.g. rtph263pay, may use mode B for packets
that starts with a picture (or GOB) start code although it's not
allowed. Let's be nice and not drop these packets/frames.
https://bugzilla.gnome.org/show_bug.cgi?id=773516
Bump the bitstream parsing to TRACE log level so it doesn't flood the
output when trying to read the more useful DEBUG and LOG messages.
Also use GST_DEBUG_OBJECT instead of GST_DEBUG in various places
https://bugzilla.gnome.org/show_bug.cgi?id=773514
Altough commits 6a16be7, 64f9d08 and 0c7e3a8 fixed some issues they
introduced others. This patch fixes the leak of one macroblock for every
B fragment.
Macroblock structures must not be freed immediately after finding the
boundaries as they are stored and used later. However the inital dummy
structure (used for finding the first boundary) must be freed.
CID #1212156https://bugzilla.gnome.org/show_bug.cgi?id=773512
Instead of sending EOS when a source byes we have to wait for
all the sources to be gone, which means they already sent BYE and
were removed from the session. We now handle the EOS in the rtcp
loop checking the amount of sources in the session.
https://bugzilla.gnome.org/show_bug.cgi?id=773218
Improve RFC2326 - chapter C.3 compatibility:
In case just a single stream is specified in SDP and the control attribute
is missing do not drop the stream but rather assume "a=control:*"
https://bugzilla.gnome.org/show_bug.cgi?id=770568
I've seen problems where the `bytesused` field of `v4l2_buffer` would be
a silly number causing the later call to:
gst_memory_resize (group->mem[i], 0, group->planes[i].bytesused);
to result in this error to be printed:
(pulsevideo:11): GStreamer-CRITICAL **: gst_memory_resize: assertion 'size + mem->offset + offset <= mem->maxsize' failed
besides causing who-knows what other problems.
We make the assumption that this buffer has still been dequeued correctly
so just clamp to a valid size so downstream elements won't end up in
undefined behaviour.
The invalid `v4l2_buffer` I saw from my capture device was:
buffer = {
index = 0,
type = 1,
bytesused = 534748928, // <- Invalid
flags = 8260, // V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC | V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_DONE
field = 01330, // <- Invalid
timestamp = {
tv_sec = 0,
tv_usec = 0
},
timecode = {
type = 0,
flags = 0,
frames = 0 '\000',
seconds = 0 '\000',
minutes = 0 '\000',
hours = 0 '\000',
userbits = "\000\000\000"
},
sequence = 0,
memory = 2,
m = {
offset = 3537219584,
userptr = 140706665836544, // Could be nonsense, not sure
planes = 0x7ff8d2d5b000,
fd = -757747712
},
length = 2764800,
reserved2 = 0,
reserved = 0
}
This is from gdb with my own annotations added.
This was with gst-plugins-good 1.8.1, a Magewell XI100DUSB-HDMI video
capture device and kernel 3.13 using a dodgy HDMI cable which is great at
breaking HDMI capture devices. I'm using io-mode=userptr and have built
gst-plugins-good without libv4l.
https://bugzilla.gnome.org/show_bug.cgi?id=769765
Use the number of milliframes per second for integral and drop-frame
framerates, as suggested by the QT file format specification and other
places. We already did that for integral framerates before, but not for
drop-frame framerates. This now keeps precision better.
For all other framerates, check if it's close to a well-known framerate
and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=769041
While computing the x and y offsets, it's the video resolution and
resized overlay resolution to be used instead of actual overlay image
resoltuion. Due to this, the overlay image used to get wrongly overlayed
in undesired location
https://bugzilla.gnome.org/show_bug.cgi?id=757292
We consider there's a sifnificant difference when it's larger than on second
or than half the duration of the last processed fragment in case the latter is
larger.
https://bugzilla.gnome.org/show_bug.cgi?id=754230
Modify the caps string to allow width and height greater than 4096.
There is no need to restrict it since the matroska format allows the
width and height values to be up to eight bytes long.
https://bugzilla.gnome.org/show_bug.cgi?id=773582
souphttpsrc maintains two variables for the position:
* 'request_position' is where we want to be
* 'read_position' is where we are
During Normal operations both are updated in sync when data arrives. A seek
changes 'request_position' but not 'read_position'.
When the two positions get out of sync, then a new request is send and the
'Range' header is adjusted to the current 'request_position'.
Without this patch, if reading fails, then the source is destroyed. This
triggers a new request, but the range remains unchanged. As a result, the
old range is used and old data will be read.
Changing the 'read_position' to -1 makes it explicitly different from
'request_position' and as a result the 'Range' header is updated correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=773509
