This is problematic in the current design at it seriously slow down
startup of applications. As of now, no known application uses the
colorimetry and the interlace-modes for anything (the two fields that
won't be probed). So let's disable it, in the long term we'll try and
find a way to interact with the provider so applicaiton could opt-in
these slow probing methods for more advance configuration.
The difference between mmap and mmap64 is the type of 'offset' argument.
mmap64 always uses a 64-bit interger as offset, while mmap uses off_t,
whose size can vary on different operating systems or architectures.
However, not all operating systems support mmap64. Fortunately, although
FreeBSD only has mmap, its off_t is always 64-bit regardless of
architectures, so we can simply use mmap when sizeof(off_t) == 8.
https://bugzilla.gnome.org/show_bug.cgi?id=791779
TOC support in mastroskamux has been deactivated for a couple of years. This commit updates it to recent GstToc evolutions and introduces toc unit tests for both matroska-mux and matroska-demux.
There are two UIDs for Chapters in Matroska's specifications:
- The ChapterUID is a mandatory unsigned integer which internally refers to a given chapter. Except for title & language which use dedicated fields, this UID can also be used to add tags to the Chapter. The tags come in a separate section of the container.
- The ChapterStringUID is an optional UTF-8 string which also uniquely refers to a chapter but from an external perspective. It can act as a "WebVTT cue identifier" which "can be used to reference a specific cue, for example from script or CSS".
During muxing, the ChapterUID is generated and checked for unicity, while the ChapterStringUID receives the user defined UID. In order to be able to refer to chapters from the tags section, we maintain an internal Toc tree with the generated ChapterUID.
When demuxing, the ChapterStringUIDs (if available) are assigned to the GstTocEntries UIDs and an internal toc mimicking the toc is used to keep track of the ChapterUIDs and match the tags with the appropriate GstTocEntries.
https://bugzilla.gnome.org/show_bug.cgi?id=790686
This way we can pass the pad name instead of the element for tracing
which helps identifying which v4l2object is used withing M2M element
like decoder, encoder and transform. For the reference, pads are name
<parent-name>:<pad-name>.
If we saw empty segments, we previously unconditionally pushed a
GAP event downstream regardless of the duration of that empty
segment.
In order to avoid issues with initial negotiation of downstream elements
(which would negotiate to something before receiving any data due to
that initial GAP event), check if there's at least a second of difference
(like we do for other GAP-related checks in qtdemux) before
deciding to push a GAP event downstream.
Sometimes all the buffers are received before the time we lock the
check_mutex, in which case g_cond_wait will wait forever for another
one. Just check if this is the case before waiting.
https://bugzilla.gnome.org/attachment.cgi?id=358397
Commit 1f31715c98 ("v4l2videodec: use visible size, not coded size,
for downstream negotiation filter") added support for removing the
padding obtained as the difference between width/height from G_FMT and
visible width/height from G_SELECTION from the probed caps obtained
via TRY_FMT.
This patch fixes the padding removal for drivers that only round up
height, but not width, to the padded frame size. This might happen
because horizontal padding can be handled by line stride (bytesperline),
but there is no such thing as plane stride in the V4L2 API for
single-buffer planar formats.
https://bugzilla.gnome.org/show_bug.cgi?id=791271
This patch simplifies the tests (44% less code) and
makes them much more readable.
The provided SessionHarness also makes it much easier
to write new tests for rtpsession.
https://bugzilla.gnome.org/show_bug.cgi?id=791070
Otherwise baseparse will incrementally send us bigger buffers until the
full header size is reached, which is not only pointless but also means
that baseparse will reallocate and copy into a bigger buffer for every
input buffers. In pull mode that's done in 64kb increments, in push mode
usually in much smaller increments, causing a lot of overhead for
example when parsing high-quality coverart.
