Setting SEEK and LENGTH on movie and audio

[mellbergsimon]

Seek and Length

Description

This PR attempts to add functionality for setting the seek and length options for caspar. This enables the user to quickly select where to start and end the video or audio.

Changes

I needed to add 2 more variables to the item.data field. Specifically:

data: {
  name: item.name,
  caspar: {
  server: item?._filter?.serverId,
  target: item.name,
  ...(DEFAULT_VALUES[item.type] || {})
  },
  duration: asset.calculateDurationMs(item),
+ medialength: Number.parseInt(item?.duration),
+ framerate: asset.frameRateFractionToDecimal(item?.framerate)          
}

Not the most beautiful implementation and I appreciate tips how to improve this.

The Seek field itself is expected by Caspar to be in frames:

This is not the most intuitive solution and I know we discussed there being some sort of drop down selector for these in the future.

General usage:

3 points of selection. Left (seek), right (length) and the entire bar. Small rounding error can occur when dragging bar from start to end.

general.usage.mov

I tried to limit the amount of userefs and divide the component into smaller manageable chunks. But I am still a little bit unsure about the SUIT naming convention. I really tried my best with the naming scheme in this, but I am sure I have made mistakes.

Fixes #68

New issue?

I tried to implement that if the duration is changed, the length setting should follow but after changing the duration field it seems to lock until the item in the rundown is pressed once again.

duration.locks.after.editing.mov

My though process was that we could clamp the duration so that it would not be possible to write a larger value than what the media actually has. But the duration field could also used in making counters with a defined time so I am not sure what the best solution going forward would be.

White theme

The colors i selected does not look good on white theme. I would like some assistance selecting a good color palate that works on all themes.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

I have tested it against my own Linux caspar server filled with different testing media.

Test Configuration:

• Firmware version: Bridge 1.0.0-beta.10
• Hardware: Bridge running on Macbook pro. CasparCG 2.5 on ubuntu 24
• Toolchain: n/a
• SDK: n/a

Checklist:

• I confirm that I wrote and/or have the right to submit the contents of my PR, by agreeing to the Developer Certificate of Origin (see https://github.com/svt/open-source-project-template/blob/master/docs/CONTRIBUTING.adoc[docs/CONTRIBUTING]).
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)

[axelboberg]

This is great Simon, well done!

The next release of Bridge will include a timeline and I'd very much like to include this feature with that. However, I think we should think twice about introducing the media length property, as that would be a second parameter that would need to be updated by any plugin wanting to change or create media items (and this is such a basic function that I think it should be generic for almost anything).

One way I've though about it is to add the following properties:
inPoint – houses the offset from the start of the clip in ms when playback should start, if not set this will be 0
outPoint – houses the offset from the start of the clip in ms when playback should end, if not set this will equal duration
duration – stays unchanged, allowing for backwards compatibility

Then there would be a new API function for calculating the effective playback duration of any item in the rundown. Logically resolving to the duration if no in or out points are set. What do you think about that approach?

Then of course the challenge still persists with connecting a frame rate to each Caspar media file (bridge.caspar.playable). Let's say you're changing media files by just writing the name. A frame rate property wouldn't be updated automatically. Could one option be to set it as a property for the server that would act as default?

Here's a sneak peek of the new timeline, but I think your UI should still be in the inspector.

[mellbergsimon]

One way I've though about it is to add the following properties: inPoint – houses the offset from the start of the clip in ms when playback should start, if not set this will be 0 outPoint – houses the offset from the start of the clip in ms when playback should end, if not set this will equal duration duration – stays unchanged, allowing for backwards compatibility

Then there would be a new API function for calculating the effective playback duration of any item in the rundown. Logically resolving to the duration if no in or out points are set. What do you think about that approach?

You are correct that duration can be static and essentially be the total duration available in the clip. I did not want to change too much and therefore added another essentially static duration. Could you explain how the API function part? Essentially creating a new duration in parallell which will be used by the gui to show correct duration?

Then of course the challenge still persists with connecting a frame rate to each Caspar media file (bridge.caspar.playable). Let's say you're changing media files by just writing the name. A frame rate property wouldn't be updated automatically. Could one option be to set it as a property for the server that would act as default?

A default frame rate could work. I guess normally most operators have the same frame rates. But it could be that setting 24fps and then trying to play a 60fps clip.

I did not think about users writing the name of a file directly but of course that is possible. I guess right clicking in the rundown and adding a caspar playable. One thought I had was that if there is a server default frame rate setting. If it is not set it could be automatically set in the background. Based on the majority of clips with a certain frame rate or similar. But that could cause confusion why the inpoint and outpoints are not exact.