Age | Commit message (Collapse) | Author | Files | Lines |
|
This element is intended to produce a video with transparency
by combining a video stream with an alpha channel encoded as
a GRAY8 stream.
|
|
That tends to crash.
|
|
The API was reverted. Just use the plain
gst_video_colorimetry_to_string() function.
|
|
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
|
|
GES relies on the EOS event having the seqnum of the seek that
caused it.
|
|
Handle not-linked as for other fatal errors and post it
onto the bus so the app knows
|
|
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;
^~~~~~~~~~~~~~
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=773217
|
|
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
|
|
This is also required by some software to handle ProRes files.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
|
|
And also 4444 in the muxer.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=772181
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=772181
|
|
This was also wrong for JPEG2000. Also write it for all MOV files and
JPEG2000, not only for ProRes.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
|
|
This is working around some broken software.
https://bugzilla.gnome.org/show_bug.cgi?id=769048
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=769048
|
|
These required atoms are: colorimetry, field information, spatial/temporal
quality, and vendor.
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
|
|
Fix leaking caps when downstream has not-fixed caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773515
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=773514
|
|
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 #1212156
https://bugzilla.gnome.org/show_bug.cgi?id=773512
|
|
queue is not empty
Add a check to verify all the output buffers were empty for the
session in a timout and log an error.
https://bugzilla.gnome.org/show_bug.cgi?id=773269
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=772610
|
|
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
|
|
Take the maximum video timescale, or if no video track is present the
previous value of 1800.
https://bugzilla.gnome.org/show_bug.cgi?id=769041
|
|
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
|
|
This information is hidden in a small chunk of data.
Format found at https://developer.apple.com/standards/qtff-2001.pdf,
page 92, "Video Sample Description", under table 3.1.
https://bugzilla.gnome.org/show_bug.cgi?id=767771
|
|
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
|
|
|
|
different than the time in the last sample
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
|
|
|
|
|
|
|
|
|
|
Gst struct v4l2object->extra_controls is created if user sets appropriate
option but it is not freed on destruction of v4l2object.
https://bugzilla.gnome.org/show_bug.cgi?id=773580
|
|
This reverts commit 8816764112408766889c8b680a3af51115df4bf5.
It causes issues with the timeouts, and causes connections to be closed
without actual reason. Needs further investigation.
https://bugzilla.gnome.org/show_bug.cgi?id=773509
|
|
Otherwise we'll run into an assertion on specially crafted files.
https://bugzilla.gnome.org/show_bug.cgi?id=773643
|
|
These checks are done inside the meson.build files for each plugin.
|
|
Needs a Meson patch to filter out the useless -lpthread
https://github.com/mesonbuild/meson/pull/962
|
|
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
|
|
G_OS_WIN32 is only set when not building with cygwin, but
ipi_spec_dest is missing both with and without cygwin.
https://bugzilla.gnome.org/show_bug.cgi?id=773114
|
|
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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=773114
|
|
This solves a hanging mainloop in following scenario:
* connect to source
* network/server drops
* pipeline set to NULL (and connection to flushing as part)
* pipeline set to PAUSED/PLAYING (connection to non-flushing, but not recorded)
* [connecting still not possible]
* pipeline set to NULL => mainloop hangs (since no actual flushing is done)
|
|
The pacing of the overall muxing is controlled
by the video GOPs arriving, so we can only handle
1 video stream, and the request pad is named accordingly.
Ignore a request for a 2nd video pad if there's already
an active one.
|