README
vue-ffmpeg-proto
About
This is a WIP / POC. This project aims at interfacing some functionalities of FFMPEG.wasm (only ffmpeg core available at time of writing) with a nice UI for the AFP journalists.
For now the only use-case is simple: a journalist needs to extract a few seconds from a (possibly quite long) video, to promote it on diverse (social) platforms. Hence it should also be cropped/resized to match the technical implications of said platforms.
It involves a step-by-step process, which should aim to be as modular as possible (hopefully, for future developement of similar tools).
Components
Batcher (FfmpegBatcher.vue)
This is the main component. It is responsible for:
Creating the worker which will use FFMPEG.wasmMaintaining a queue with all the Operations (VideoData + params (ffmpeg video-editing params)) that are fed to the worker one after the other.Passing data from step to step
The Steps
There are 3 types of Steps for now:
- One initial step (StepImport here)
- Several intermediary steps, which are the operations that the user care about (StepCut and StepCrop for now)
- One final step (StepSave) The aim is to be able to re-organize or create additional intermediary steps, in order to create different work-flow (and so different use-cases, with an identical or similar code-base).
Import Step (StepImport.vue)
This is the step where the user manually import the video(s) he wants to modify.
It's only one video for now, but we could imagine a multiple imports possibility in the case we would want to combine videos.
This should output objects of data-type VideoData (the same type that the intermediary Steps take as input/output)
Save Step (StepSaver.vue)
This is the last step. The user should . The user should be able to:
- See the items queued from the previous step (loaders),
- Vaguely inspect the output files,
- Download them seperately or in a single zip file.
Intermediary Steps (StepCut.vue, StepCrop.vue, ...)
These are the steps where the user actually modify/edit the video(s).
These should have as much feedback as possible on the immediate result(s) of the editing.
These steps should take the same data-type as input and output. (for now VideoData objects)
To be discussed:
- History of operations? Cached results? to be able to go back and forth (Operations as { VideoData, params })
- How to use a promised-based (or not) data-strucure to display loaders (specifically for the StepSave)?
- 3 angles on the ffmpeg.run() logic:
- queue ffmpeg operation(s) on every step validation, and wait for the operation(s) to finish in order to start the next step (synchronous, easy to use same data-type as inputs and outputs, BUT not very reactive => not a good UX)
- queue ffmpeg operation(s) on every step validation, in the background, and instantaneously show next step.
Work on the next step using a video "edited" with javascript imitating the result of the ffmpeg command (much more work, must manage the edition-params in a complex way, but should result in a smooth UX)
=> still need clarifications (when is the result(s) of ffmpeg re-introduced in the workflow/UI? only at the save step? if so, the javascript should be ablet to keep the edits/params history and preview them correctly at all time)
=> also the queue should be canceled if the user navigate back to previous step - keep track of all the edit-params in Javascript, and run ffmpeg only once, at the last step
Project setup
npm install
Compiles and hot-reloads for development
npm run serve
Compiles and minifies for production
npm run build
To publish to npm (for toolkit integration)
npm run build && npm version patch && npm publish
Lints and fixes files
npm run lint
npm run lint --fix