Lively Video Reporting Project

We’re interrupting our scheduled programming to bring you this important update

Sadly, I have to postpone restoring the world order *chuckles*, bringing back the adequate public discourse with a (free forever for real this time) replacement of the (eX) Cheerper technology:

Filling the Gaping Hole: now, me too!

— since something else came up (it’s financial issues, of course), apologies to the public discourse, it will have to wait.

And since the market just won’t get back to normal — you know, making genuine technological advances (tough times mean careful projects) — and won’t offer us any decent thoroughly commercial projects to work on at the moment, let’s cook a potentially commercial one ourselves:

Personal Media Automation Demo

(self-server-based) zer0-UI Video Publishing for Smart Phone Users

Audience: tech-savvy-ish individual video producers (of the less visually creative kind*)

Purpose: offer a minimal complete “stack” (component set) for an individual end-to-end media production and for other integrations

This multi-component integration — including a sample smart phone vendor and a sample video publishing platform — will:

1. initialise with user’s credentials for iCloud and YouTube;
   which will happen once in whenever those vendors like it to
2. monitor user’s iCloud for new videos;
   when user has the default iCloud sync on, of course
3. recognise new videos for publishing automation;
   e.g. by a QR code of the channel URL shot at the end of a short video; the idea being (for whatever reason, you’re recording a “near-live” video) — to provide minimal yet adequate control over media publishing — at the very time of recording
4. publish recognised videos after automatic preprocessing;
   according to preset definition for publication channel:
   + applying some video template, e.g. with background music, image filters etc
   + including YouTube publication details, e.g. description, tags etc

Advantages:

• efficient UX for a casual vlogger (this particular integration may not be for everyone, but it’s tikker than a tik-tokkie)
• not an app (and independent of any particular vendor at any level)
• self-server and peer-sourcing (something on the subject) advantages:
  + unlimited extendibility (hack yourself, hack with your friends, hack for profit)
  + unlimited usage (you use, you run, you admin)
  + unlimited distribution (they use, they run, they admin)
  + unrestricted functionality (inherently legal system with end-user permissions)

*there are very many cases where an author would just not like to invest too much in editing some videos, but would very much like for them to be published as soon as they’re recorded, so, a certain footage format within a certain montage template should do the trick for those, especially for one-shots (e.g. TikTok thing)

Implementation notes

Self server “comps” in this integration:

• drv/youtube (publishing etc) — optional, if Google provides enough API
  + talks to YouTube
• drv/icloud (discovery, retrieval etc) — optional, if Apple provides…
  + talks to iCloud
  + emits “new icloud video” events in “near real time”
• usr/icloud-vlogger (vlogging composition automation) — required, stage 1
  + listens for drv/icloud events
  + generates (and commits) “.pub.video” “log entries” off new relevant videos
• usr/vlog-youtuber (vlogging production automation) — required, stage 2
  + registers and manages (CRUD) channels for publishing automation, including
  + run-time authenticating Google/YouTube API appropriately (Create or Update)
  + listens to core/git messages from the ‘log’ repo and checks them for .pub.video "log entry" commits
  + tries and publishes those “YouTube-unpublished” with drv/youtube, and then, augments* them log entries
• self server’s personal logging stack (git-based) — exists
  + notifies usr/vlog-youtuber of new commits containing “.pub.video”s
• std/awww (end-user WWW usage emulation) — optional, if drv/* needs it
  + low-level infrastructure for those robot-unfriendly internet services

*generates a FFmpRb file according to the src: section of a .pub.video if needed (media montage script used by FFmpRb module) and on success, replaces a known user-entered channel URL with the newly published video's URL in pub: section of .pub.video, or on failure, provides details in line, after which, commits

.pub.video file (semi-formal-language man-machine interface)

Whenever a user of — or, on the user’s behalf, an automated “comp” of user’s — “self server” would like to publish a video with their system, they’d define this video publication in a VIDEO-NAME.pub.video file, which may or may not be committed to the user’s special ‘log’ (“captain’s log”) git repo.

This is an opportunity for any semi-formal-language-capable users to have a decent (efficient) user interface instead of an inherently lame “GUI”, while the others will either (1) use no interface at all, with everything automated as described above, or (2) use “GUI”d (emotionally supportive, and thus, moneymaking) helper tools handling these files internally — when this turns into a thoroughly commercial project.

A sample (e.g. ~/log/2022/12/10/chang-wash-fun.pub.video)

Chang Wash Fun, winter 2022, Chiang Mai, Thailand

src:
- media/2022/12/10/IMG_4092.MOV: https://icloud.com/photos

pub:

Hapless Tourists Washing Elephants in Thailand - this could be you if you weren't careful and didn't stay home instead!

#chiangmai, thailand, 2022, live

- https://www.youtube.com/channel/UCd0oX6P6TxDN1-kYam2RoFQ

p.s. This project will not be open-source, but I’ll document key implementation moments in this blog and shall provide components’ git repos access freely to interested peers.