matt/vcr_capture
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update readme

Browse Source
This commit is contained in:
Matt
2025-09-20 14:28:45 -07:00
parent a08d8c9153
commit 3432e8ac9f
15 changed files with 457 additions and 257 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
README.md
View File

@ -1,21 +1,47 @@
This is an ansible role intended to be ran as a supplement to my server-base playbook upon request
This is an ansible role intended to be ran as the final step in the corresponding playbook to do what it says on the tin
Some considerations of this are the expectations of docker and samba already being installed and configured
If this is not ran as a part of the cosmos playbook, then some considerations here are the expectations of docker and samba already being installed and configured
This ansible task automatically builds out a matt-cloud debian system to be a VCR Ripping device
This ansible task automatically builds out a matt-cloud debian puck to be a VCR Ripping device
There is a hardware requirement of USB RCA Capture device, and this device must be configured in defauts/main.yaml
There is a hardware requirement of USB RCA Capture device, and this device must have its settings configured in defauts/main.yaml
There is an option to install a basic GUI and then display the feed in a browser kiosk
This platform requires too much processing power to be installed on weak systems. The RK3528A 4-core SBC loads up to 6 when this runs on it. Perhaps a future version of this will have a detector so that when it's installed on a wimpy ARM SBC it will do nothing except save the file; no MediaMTX or Jellyfin. Not important right now.
This process uses stages of different software to accomplish the goal of making capturing a VHS tape as automatic as possible
Most of the layers include:
- ffmpeg service to combine the video and audio of the USB capture device into a rtmp stream
- mediamtx to automatically save rtmp streams to a mp4 file
- a docker apache php container for the control site
- a python API service to control the ffmpeg streaming service
- a small helper script to monitor the elapsed time and stop streaming after the selected time
- a playbook to mount and format a sd card when using ARM based puck systems
The various pertinent services live at these ports:
- Control Panel at port 8081
- Local Read-Only File Index at 8080
- Preview livestream at 8888
- Jellyfin at 8096
Overview of layers:
- ffmpeg service to combine the video and audio of the USB capture device into a RTMP stream and mp4 file
- The RTMP stream is so the capture can be live-previewed
- This feed is pointed at the MediaMTX service
- Mediamtx to monitor current capture
- This service will only be used for its ability to view a RTMP stream live in a web browser
- Docker container with apache+php for the control site
- This runs the PHP site that controls the ffmpeg capture service
- Python API service to control the ffmpeg streaming service
- This Python API is used by the PHP site for controlling the service
- It also has the duration variable storage control API here
- This is stored locally in a JSON file
- Small helper script to monitor the elapsed time and stop streaming after the selected time
- This script kills the capture service after the duration has been reached
- It does this by reading the JSON file managed by the Python API
- Playbook to mount and format additional storage when present
- When a secondary storage is detected it will be mapped at the media storage path
- If there is a blank storage attached, it will be formatted so BE CAREFUL
- If there is no secondary storage, the videos will be stored on the root path
- Playbook to install the GUI when certain hardware is detected
- Right now it will just be a 2nd Gen MS Surface I have
- It will be identified by the "System Info" dmidecode data
- There is a variable in the defaults file for a list of these strings
Some additional notes on the storage handling task working_folder.yaml. This will mount additional local storage if present. It expects there to be a single additional storage device and will work with an SD Card or an NVMe. It will map if a valid GPT ext4 volume is present, and it will create a new ext4 volume if there are no volumes present on this storage. It should just fail in edge cases which is fine. It would be a bad idea to run this playbook on an inappropriate endpoint.