cargo-c will produce a pkg-config file making it easier to statically
link plugins.
Also add 'static' features for plugins depending on < 1.14 as this is the
minimal required version to use static linking because of ABI changes in
core.
Various SCC files have invalid drop frame timecodes.
Every full minute the first two timecodes are skipped, except for every
tenth minute, which means that e.g. "00:01:00;00" is not a valid
timecode and the next valid timecode would be "00:01:00;02".
There is no way to dynamically ask Cargo to build static or dynamic lib
so we have to build both and pick the one we care when doing the meson
processing.
Fix#88
Only two uses of unsafely setting the pad functions is left:
- fallbacksrc for overriding the chain function of the proxy pad of a
ghost pad
- threadshare for overriding the pad functions after creationg, which
probably needs some fixing at some point
I thought I could spare some bandwidth by letting renderers pick
the base row, but it turns out this triggers some unwanted behaviours
with compliant renderers.
Instead, we now follow the protocol laid out in EIA/CEA-608-B,
section B.8.1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/355>
Useful complement to cea708overlay, that can only render native
708.
The element isn't an aggregator, and simply parses and renders
closed caption meta on its input video buffers.
No property is exposed, the rendering is done using a monospace
font, over a 32 x 15 grid with the font size fitted to fill as
much of the viewport as possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/343>
In roll-up mode, the element expects input text without layout
(eg new lines), and the characters it outputs are displayed
immediately, without double-buffering as in pop-on mode.
Once the last column is reached, the element simply outputs
a carriage return and the text scrolls up, potentially splitting
words with no hyphenation.
The main advantage of this mode is its simplicity and the near-zero
latency it introduces.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/347>
- Report a latency:
By design, tttocea608 will output buffers in the "past" when
receiving an input buffer: we want the second to last buffer
in the buffer list that we output to have the same pts as the
input buffer, as it contains the end_of_caption control code
which determines when the current closed caption actually gets
displayed in pop_on mode. The previous buffers have timestamps
decreasing as a function of the framerate, for up to potentially
74 byte pairs (the breakdown is detailed in a comment).
The element thus has to report a latency, at 30 frames per second
it represents around 2.5 seconds.
- Refactor timestamping:
Stop using a frame duration, but rather base our timestamps on
a scaled frame index. This is to avoid rounding errors, and
allow for exactly one byte pair per buffer if the proper framerate
is set on the closed caption branch, and the video branch has
perfect timestamps, eg videorate. In practice, that one byte
pair per frame requirement should only matter for line 21 encoding,
but we have to think about this use case too.
- Splice in erase_display_memory:
When there is a gap between the end of a buffer and the start
of the next one, we want to erase the display memory (this
is unnecessary otherwise, as the end_of_caption control code
will in effect ensure that the display is erased when the
new caption is displayed). The previous implementation only
supported this imperfectly, as it could cause timestamps to
go backwards.
- Output last erase_display_memory:
The previous implementation was missing the final
erase_display_memory on EOS
- Output gaps
- Write more tests
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/314>
Contrary to what one might believe, this actually reduces the size of
the structs due to alignment constraints. On Linux x86-64 clang/gcc it
reduces the size of the caption_frame_t struct from 7760 bytes to 6800
bytes, on Windows x86-64 MSVC from 11600 bytes to 6800 bytes.
It also causes simpler and potentially faster assembly to be generated
as the values can be directly accessed as uint8_t instead of having to
extract the corresponding bits with bitwise operations.
It also gives us the same ABI with clang/gcc and MSVC.
