Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Research] Consider adding video support #19

Open
ruudw opened this issue Jul 23, 2020 · 1 comment
Open

[Research] Consider adding video support #19

ruudw opened this issue Jul 23, 2020 · 1 comment

Comments

@ruudw
Copy link
Member

ruudw commented Jul 23, 2020

In this day and age taking video's during Scouting activities becomes more common. Whilst these videos are uploaded to social media platforms to be viewed by others this remains an insufficient method for backing up these media items. From this point on it might be good to consider any of these following options:

  1. Keeping video data somewhere as "raw" data (no viewing options);

  2. Uploading video data to a known video platform (e.g. Youtube / Vimeo) and creating a link on our website/photobook to allow viewers to search through the separate archive;

  3. Uploading video data via an interface on our website directly onto a known video platform (e.g. Youtube / Vimeo) but keeping a record in our photobook (thus data is streamed directly from the video platform);

  4. Uploading and parsing the video data directly to the current photobook.

Obviously there might be intermediate options. Furthermore each option has their own (dis)advantages (e.g. data usage, bandwidth usage, privacy (video platforms don't always allow embedding for private videos), etc.) This issue should be regarded as a reseach ticket. Further building tickets should be created from here on if the chosen solution requires it.

@adminfriso
Copy link
Contributor

adminfriso commented May 31, 2023

looking at the 4 options.

  1. i guess a raw location could be google drive, but i recon that the storage provided will not be enough for video uploads. i guess the current form of (raw) video sharing is via whatsapp. another raw location could be a local disk somewhere someone needs to keep updated, but if we would take the effort to store all video's an own disk to store media, then why would we not directly look into option 4.

  2. this could be a viable option from a development perspective. We could also easily iframe the video so all the content is reachable within the photobook interface.
    uploading to an external platform could create a mess on which account the video will be uploaded and thus who will be the owner of the media. if a user removes a video on their own account the removal of media will not be automatically updated on the photobook which will result in invalid links over time.

  3. uploading to a youtube/vimeo platform via the photobook create a lot more technical depth. if we would like to work with youtube/vimeo uploads i recon it would be best to start with option 2 in such a way that it is possible to make a future improvement to upload to the related platform via the photobook. uploading via the photobook would take away the concern from option 2, we would link directly to our own accounts, which will make sure we have some sort of control.

  4. We would always be owner of the original "raw" video footage, thus we also have full control over viewing and uploading and deletion permissions. I would like @westerterp his opinion on this option due to the fact of that video media uses a lot more storage than imagery. From a development perspective i think we could still use the media library we already are using (https://spatie.be/docs/laravel-medialibrary/v10/introduction) , so it would not create a terrible big technical depth.

Personally i would be a fan of option 4 because we stay in control of access and deletion, the system will work in a closed environment with no external dependancies. There will never be an issue with deletion (which definitely will occur when we introduce youtube/vimeo) in case of avg compliance issues, and we would always be on top of our own media. the system would provide for us on its own

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants