Writing a proper "depfile" to follow depending files, based on depfiles
generated by rustc.
This is based on work done while working on gobject-examples-rs
This allows for faster rebuild avoiding to run the target when nothing
changed.
This approach is not ideal as we should find a way to actually know when
to rebuild based on information from cargo itself but there seem to be
no way to do it at this point.
This plugin takes I420/YUV and appends an alpha plane to give YUVA/A420
to round the corners analogous to the border-radius in CSS. Other video
formats like NV12 not supported yet. Support for other planar formats
will follow.
Not all ways of specifying border-radius as in CSS are implemented at
the moment. Currently, we only support specifying it in pixels and it
gets applied uniformly to all corners.
csound-sys can detect the system lib using either pkg-config or using
the CSOUND_LIB_DIR env variable.
The former case just work but the second is trickier as we need to
ensure that CSOUND_LIB_DIR is defined when building.
So we no longer try to detect the lib using find_library() if user
didn't define the env variable as the build will fail later.
Also explicitly pass the env variable to cargo so user can now call
'CSOUND_LIB_DIR=/usr/lib64 meson build && ninja -C build'
and have it work without repassing the env variable to ninja.
Using ubuntu 20.04, the build was failing with version
cargo 0.47 / rustc 1.47.
Following this discussion:
https://github.com/rust-lang/cargo/issues/9340
it appears that rustc 1.52 is the minimum version.
The element expects an array of "commands", as GstStructures,
in the form:
operation, pattern=<pattern>, ...
The only operation implemented for now is replace-all, eg:
replace-all, pattern=foo, replacement=bar
Other operations can be implemented if useful in the future,
eg. "match" could post a message to the bus when the pattern
is encountered.
The main use case for this is automatic speech recognition,
as implemented by eg awstranscribe as users may want to replace
swear words with tamer language.
Commands are applied in order.
The interface is usable through the CLI with the usual escaping
strategies, though trying to pass in actual regular expressions
through it is a bit tricky, as this introduces yet another
level of escaping.
This new crate consists of two elements, jsongstenc and jsongstparse
Both these elements can deal with an ndjson based format, consisting
for now of two item types: "Buffer" and "Header"
eg:
{"Header":{"format":"foobar"}}
{"Buffer":{"pts":0,"duration":43,"data":{"foo":"bar"}}}
jsongstparse will interpret this by first sending caps
application/x-json, format=foobar, then a buffer containing
{"foo":"bar"}, timestamped as required.
Elements further downstream can then interpret the data further.
jsongstenc will simply perform the reverse operation.
We now have to run 'cbuild' and 'ctest' on each plugin individually.
Replace plugins_rep key by the source path so we can easily discard the
excluded plugins.
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
- 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>
Fix race when building from gst-build as we need to be sure that all
these deps have been built before starting building gst-plugins-rs which
will build gstreamer-rs.
