Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
VideoColorRange::Range0_255
|
|
|
|
|
|
In roll-up modes, we open new lines when the last column is reached.
This commit implements lookahead on a word basis, in order to avoid
splitting words unless absolutely necessary (when a word won't fit
on a full row)
|
|
|
|
|
|
|
|
In roll-up mode, we drop out of the loop and warn when the 32nd
character is reached, the warning is unnecessary when there were
no characters left to loop on.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/499>
|
|
Trying to write "" in order to erase characters in the caption
frame simply fails silently, the proper way to implement
delete_to_end_of_row and backspace was to memset the relevant
cells.
|
|
|
|
|
|
Undefined ssize_t is used in eia608.h file as well
|
|
|
|
|
|
Unlike webpdec from -bad, this element inherits from GstElement
and can decode animated webp data.
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/480>
|
|
This element outputs the same format expected by tttocea608 in
json mode.
It notably differs from cea608tott in that it only uses libcaption's
low-level API, as it needs to maintain its own view of the current
state of the screen, and make fine-grained decisions as to when
to output data and how to timestamp it.
It covers a large portion of the 608 spec, with the exception of
a few features that probably haven't ever seen widespread usage,
those are listed in a TODO list at the top.
It has been tested with a reference file produced by CEA and covers
all the features it demonstrates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/480>
|
|
Pushing the pending padding once we receive the following gap
or buffer means we will push it too late otherwise.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/480>
|
|
|
|
to 0.4
Also get rid of the funty workaround as nom now depends on the right
version.
|
|
|
|
When cc_type is 00 or 01 the CC is 608 data, the last bit only
denotes the field
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
Also expose a field property, to allow selecting CC for a
specific field when the information is available. Defaults
to automatically picking the first field encountered.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
We don't need to insert a space when starting a new line,
or before punctuation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
These can be controlled more precisely using json as the input
format, but exposing them as properties is still useful when
the input format is text.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/474>
|
|
See https://github.com/myrrlyn/funty/issues/3
|
|
|
|
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/139
|
|
Just don't output anything and log an error instead of panicking.
|
|
|
|
|
|
That mode has been mostly obsoleted by roll-up modes, but let's
include it for completeness' sake.
|
|
That new element can for example be used to serialize the output
of awstranscribe, ready for further editing
|
|
Up to now, tttocea608 supported text/utf8, and no interface to
control the positioning of closed captions apart from new lines
in the input text.
CEA 608 supports a larger set of features than that, such as
positioning CC precisely in its 32 x 15 grid, styling text,
switching from one mode to another, resetting the base row
in roll-up mode etc ..
A custom, JSON-based format is now supported by the element
(caps application/x-json, format=cea608), allowing users to
control those features in a pretty advanced manner.
A side effect of this is that the approach previously used
by the element to ensure frame-accurate CC display is now
untenable: where we knew before that an input buffer would
at most span 74 buffers and calculate a somewhat reasonable
latency based on that, this is no longer possible. Instead
we pick the approach most CC encoders seem to pick, and
accept a certain latency at display time: for example the
flipping of the back buffer to the display buffer for a
10-character text buffer will occur 7 frames after its
PTS. This has obvious benefits in terms of code complexity
and should generally be acceptable.
+ Removes a now irrelevant test, updates other tests
+ Extracts the Mode enum to the root of the crate, it will
be used by another element in a follow-up commit
|
|
|
|
style preambles look like:
|P|0|0|1|C|0|ROW| |P|1|N|0|STYLE|U|
and column preambles look like:
|P|0|0|1|C|0|ROW| |P|1|N|1|CURSR|U|
Both preambles go through eia608_row_pramble(), the value they
pass as the x parameter is supposed to hold 4 bits, either
0|STYLE
or 1|CURSR
This value then gets bit-shifted by 1 and or'd in the second byte.
The value is also and' with 0x1E to ensure it can't leak into
the upper bits.
The previous code resulted in x being a 5-bit value, 0x10 (0b10000).
This resulted in outputting a style preamble, as 0x10 << 1 & 0x1E
is 0b00000. When the indent was 0 (the usual case), this went
undetected, but with any other value it resulted in no indent being
applied, but the text getting colored or italicized.
This patch fixes x to have the correct value of 0x8 | indent.
|
|
A misplaced parenthesis was causing the odd parity bit to
be set based on an incomplete version of the preamble
|
|
encoder frames
|
|
|
|
|
|
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".
|
|
Also avoids an unwrap().
|
|
|