Match Inbox Events Against Schedule #3340
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lkiesow
force-pushed
the
inbox-schedule
branch
from
d7e03a6
to
7d5ae2c
Compare
|
This pull request has conflicts ☹ |
Opencast's inbox allows you to add zipped media packages which may
contain arbitrary metadata but are very complex or to add simple files,
which file names will end up as the new event's title. It would be nice
if it would be possible to extract a few more basic metadata from the
filename.
File names like these are commonly generated by capture devices:
```
2020-02-07-hs1-Introduction to Biology.mp4
| | | | | |
year | | | +----------+----------+
month | | |
day | title
location
```
To improve the situation, and to be as flexible as necessary, we would
like to allow for specifying regular expressions as matchers for a few
basic metadata.
This resolves opencast#3239
Capture agents often record to filenames containing metadata which allows us to identify an event by looking at a specific time in the schedule of a certain location (capture agent). If `created` and `spatial` metadata could be identified, this patch allows us to look up the schedule, using all available event data fram there if we had a unique match. Data taken from the schedule, overwriting inbox data are: - All metadata - Workflow definition - Workflow configuration Notes: - This patch fixes opencast#3240. - This is based on opencast#3327. - You want opencast#3339 for this.
In addition to the metadata extraction from the file name, this patch allows users to have ffprobe run on the media files to get some additional metadata from the media container. The extracted metadata are creation time and duration, which may help to match scheduled events. With the media file now having a duration, there is now also an additional option allowing to filter out some events which are barely conflicting (imaging two back to back recordings and the second one starts a minute early).
lkiesow
force-pushed
the
inbox-schedule
branch
from
7d5ae2c
to
9799e46
Compare
gregorydlogan
approved these changes
Jan 26, 2022
modules/ingest-service-impl/src/main/java/org/opencastproject/ingest/scanner/Ingestor.java
Show resolved
Hide resolved
...ngest-service-impl/src/main/java/org/opencastproject/ingest/scanner/InboxScannerService.java
Show resolved
Hide resolved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Capture agents often record to filenames containing metadata which
allows us to identify an event by looking at a specific time in the
schedule of a certain location (capture agent).
If
createdandspatialmetadata could be identified, this patchallows us to look up the schedule, using all available event data fram
there if we had a unique match.
Data taken from the schedule, overwriting inbox data are:
Notes:
Addition: Use ffprobe to get additional metadata
In addition to the metadata extraction from the file name, this patch
allows users to have ffprobe run on the media files to get some
additional metadata from the media container.
The extracted metadata are creation time and duration, which may help to
match scheduled events.
With the media file now having a duration, there is now also an
additional option allowing to filter out some events which are barely
conflicting (imaging two back to back recordings and the second one
starts a minute early).
Your pull request should…