On Fri, May 30, 2025 at 4:27 PM Andrew Randrianasulu <[email protected]> wrote:
пт, 30 мая 2025 г., 15:55 Terje J. Hanssen <[email protected]>:
Den 30.05.2025 00:15, skrev Andrew Randrianasulu:
пт, 30 мая 2025 г., 00:30 Andrew Randrianasulu <[email protected]>:
чт, 29 мая 2025 г., 23:42 Terje J. Hanssen via Cin <[email protected]>:
Is it possible with CinGG's Record utility (via FFMPEG) to record a stream to file segments of same duration or file size and use auto-naming?
Typical example: Record a video/audio input stream (i.e from playing a camcorder tape cassette) and encode to output file segments of 10 minutes or 10 GB each and auto-name file numbers.
Similar example code using an input file instead at https://unix.stackexchange.com/questions/1670/how-can-i-use-ffmpeg-to-split-...
Just use what is built into ffmpeg to do exactly this.
ffmpeg -i invid.mp4 -threads 3 \ -vcodec copy -f segment -segment_time 10:00 \ -reset_timestamps 1 \ cam_out_h264_%02d.mp4
This will split it into roughly 10-minute chunks, split at the relevant keyframes, and will output to the files cam_out_h264_01.mp4, cam_out_h264_02.mp4, etc.
Very interesting question! Never tried this, did not even know it existed!
As long as this -f just ordinary avformat muxer you probably can copy your favourite ffmpeg video/audio profiles with new .seg name and put "segmented" at very first line there , where "mov" or "matroska" or other format name was, and add rest of options. And add pattern (%02d) into name just as with ffmpeg-based image lists.
I'll try this with termux's version, but I do not have audio here so it will be incomplete.
so I created this file:
cat ffmpeg/video/mpeg2.seg segment mpeg2video segment_format=mpeg segment_time=00:10 reset_timestamps=1 trellis=2 mbd=rd cmp=2 subcmp=2 b=4000000
and it worked! in sense it created six segments, each with corresponding increasing timecode. But they all uneven duration, probably due to mpeg2 codec placing keyframes at will.
You can try to modify it back to 10:00 segment time and see how it work for longer encode?
As I'm not sure if and how you applied your file above with regards to Cingg Record,
just put file where other video profiles live? (ffmpeg/video folder of your cingg installation)
Attaching test profile trying to utilize segmented muxer for mpeg system streams Put them according to their content into /usr/share/cin/ffmpeg/video and /usr/share/cin/ffmpeg/audio for standard rpm/deb cinelerra install make sure they readable by your user (chown -R your_username:users /usr/share/cin/ffmpeg might fix weird issues like "bad file format") In cingg shift-R, select seg from dropdown menu, select both audio and video encoding (there will be grand total of one choice in each category), then put filename like /dev/shm/file%02d.mpeg and try to render It will give you files: root@slax:~# ls -la /dev/shm/seg* -rw-r--r-- 1 guest users 0 мая 31 06:19 /dev/shm/seg%02d.mpeg -rw-r--r-- 1 guest users 0 мая 31 05:57 /dev/shm/seg%02d.seg -rw-r--r-- 1 guest users 2375680 мая 31 06:19 /dev/shm/seg00.mpeg -rw-r--r-- 1 guest users 1980416 мая 31 06:19 /dev/shm/seg01.mpeg -rw-r--r-- 1 guest users 1947648 мая 31 06:19 /dev/shm/seg02.mpeg -rw-r--r-- 1 guest users 2009088 мая 31 06:19 /dev/shm/seg03.mpeg -rw-r--r-- 1 guest users 2170880 мая 31 06:19 /dev/shm/seg04.mpeg -rw-r--r-- 1 guest users 2205696 мая 31 06:19 /dev/shm/seg05.mpeg -rw-r--r-- 1 guest users 2535424 мая 31 06:19 /dev/shm/seg06.mpeg -rw-r--r-- 1 guest users 1966080 мая 31 06:19 /dev/shm/seg07.mpeg -rw-r--r-- 1 guest users 1945600 мая 31 06:19 /dev/shm/seg08.mpeg -rw-r--r-- 1 guest users 2023424 мая 31 06:19 /dev/shm/seg09.mpeg -rw-r--r-- 1 guest users 2101248 мая 31 06:19 /dev/shm/seg10.mpeg -rw-r--r-- 1 guest users 1026048 мая 31 06:19 /dev/shm/seg11.mpeg Now you can play all fo them gapless with mpv: root@slax:~# mpv /dev/shm/se*.mpeg Playing: /dev/shm/seg%02d.mpeg Failed to recognize file format. Playing: /dev/shm/seg00.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AO: [pulse] 48000Hz stereo 2ch s16 VO: [gpu] 720x576 => 768x576 yuv420p AV: 00:00:02 / 00:00:02 (97%) A-V: 0.000 Playing: /dev/shm/seg01.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg02.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg03.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg04.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg05.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg06.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:02 / 00:00:02 (98%) A-V: 0.000 Playing: /dev/shm/seg07.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg08.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg09.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg10.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:01 / 00:00:01 (98%) A-V: 0.000 Playing: /dev/shm/seg11.mpeg (+) Video --vid=1 (mpeg2video 720x576 25.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) AV: 00:00:00 / 00:00:01 (91%) A-V: 0.000 Exiting... (Some errors happened) I've verified that at least audio track exist, but you better to run your own liestening test to hear if audio get desynchronized over longer runs
What worries me is audio. If segmented audio muxer cut it differently from video we will get desync.
May be setting labels at specific intervals and then using "write new file at label" checkbox is better idea?
I simply did a test with my system's ffmpeg segment muxer: https://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-...
Input file: hdv09_04_h264.mp4 Duration: 00:03:58.88, start: 0.000000, bitrate: 8963 kb/s
Tried 1 minute segment time:
ffmpeg -hide_banner -i hdv09_04_h264.mp4 -threads 3 \ -vcodec copy -f segment -segment_time 01:00 \ -reset_timestamps 1 \ cam_out_h264_%02d.mp4
[segment @ 0x563c2874fa80] Opening 'cam_out_h264_01.mp4' for writingeed=52.1x [segment @ 0x563c2874fa80] Opening 'cam_out_h264_02.mp4' for writingeed=55.5x [segment @ 0x563c2874fa80] Opening 'cam_out_h264_03.mp4' for writingeed= 57x [out#0/segment @ 0x563c28727680] video:257421KiB audio:3749KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame= 5972 fps=1445 q=-1.0 Lsize=N/A time=00:03:58.80 bitrate=N/A speed=57.8x [aac @ 0x563c28721a40] Qavg: 454.522
68M cam_out_h264_00.mp4 63M cam_out_h264_01.mp4 59M cam_out_h264_02.mp4 68M cam_out_h264_03.mp4 --------
Duration: 00:01:00.38, start: 0.058000, bitrate: 9394 kb/s Duration: 00:01:00.00, start: 0.000000, bitrate: 8672 kb/s Duration: 00:01:00.60, start: 0.000000, bitrate: 8104 kb/s Duration: 00:00:57.93, start: 0.000000, bitrate: 9705 kb/s
In total: 00:03:58.93 which is 00:00:00.03 (=3/100 sek) more than the input file which I think is good enough for practical purposes (editing and backup/preservation/archival)
I wonder if it is within or out of our reach to make some targeted profiles for backup/preservation? I.e would it be of interest and possible to utilize/integrate/use oss tools and scripts as found here: https://avpres.net/Bash_AVpres/ https://avpres.net/FFmpeg/im_FFV1.html
Up to interested party, I guess.
The programs dvgrab and possibly the newer vrecord can also autosplit by scenes https://linux.die.net/man/1/dvgrab https://github.com/amiaopensource/vrecord https://github.com/mipops/dvrescue
Yes, I was thinking about this, but unfortunately without any testable idea. Sorry.