I want to concatenate some .flv files (each is h264/adpcm_swf encoded with the same settings). Ideally, I'd like to add something like a cut in between the files - a black screen for 1 or 2 seconds would suffice.
I've tried using avconv's "concat"-protocol, like this:
avconv -i concat:1.flv\|2.flv\|3.flv result.flv
That gives me a result, which contains only the contents of 1.flv and seems to be reencoded with the default flv-settings. That would be handable by giving appropriate output options, but in theory it should be possible to concatenate the files without much reencoding?
My avconv version:
avconv version 0.8.6-6:0.8.6-0ubuntu0.12.10.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:16 with gcc 4.7.2
avconv 0.8.6-6:0.8.6-0ubuntu0.12.10.1
libavutil 51. 22. 1 / 51. 22. 1
libavcodec 53. 35. 0 / 53. 35. 0
libavformat 53. 21. 1 / 53. 21. 1
libavdevice 53. 2. 0 / 53. 2. 0
libavfilter 2. 15. 0 / 2. 15. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 52. 0. 0 / 52. 0. 0
You can use ffmpeg for this concatenating movies. First check if you have ffmpeg installed by running ffmpeg. If the first line ends with "the FFmpeg developers", you're fine. If it is "the Libav developers", then ffmpeg is secretly an alias to avconv (this is the case on Ubuntu). If you don't have ffmpeg and the real ffmpeg is not in your repository, you have to compile ffmpeg yourself.
Now that you have the real ffmpeg, create the file inputs.txt with the following text:
file 1.flv
file 2.flv
file 3.flv
and run:
ffmpeg -f concat -i inputs.txt -c copy result.flv
Another way to concatenate files with ffmpeg without the need of store all the filenames in txt file is the following:
ffmpeg -f concat -i <(for f in *.flv; do echo "file '$f'"; done) -c copy result.flv
You could replace *.flv with whatever filetype you want. In that case do not forget to change the extension of the result file too.
Related
I'm trying to understand the following, maybe one of you guys can help me out by explaining on what exactly happens here:
My goal is to write a script, which copies files from the find-command, parallels rsync-commands and backup those, by re-creating the folder-structure from the source on the destination as well.
Somehow my initial script does not work like that, and i don't really have an idea on how to fix it to behave that way.
Initially, i've copied the files with "ls -1 /foldername" as sourceFolder, which is not best-practice. So i've tried to change it to using "find" as described beyond.
find "$sourceFolder" -maxdepth 2 -mindepth 2 -print0 | xargs --verbose -0 -I {} -P $maxThreads -n 1 rsync -valhP {}/ "$destFolder"/ --checksum --human-readable --stats --dry-run >> "$logDir"/result.log
--
If i run this script, it literaly would recopy the file(s), although those exist in the destination folder i would expect it to be.
sending incremental file list
.d..tp..... ./
>f+++++++++ macs.txt
Number of files: 2 (reg: 1, dir: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 242 bytes
Total transferred file size: 242 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.484 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 83
Total bytes received: 22
So as it turned out, sourceFolder and destFolder have to match, and i can't run anything like sourceFolder/folder1/folder1a destFolder/.
Can anyone help me out on what's wrong and why it behaves like that?
Thanks a Lot,
M.
I've been able to record .h264 files without a problem, both using raspivid and through Python, but whatever I try, I can't convert them to a .mp4, .mkv or .avi file.
I've tried converting using MP4box (suggested in several places) and mkvmerge, but to no avail.
When I use MP4box (MP4box -add <source.h264> <dest.mp4>), I get :
AVC-H264 import - frame size 1920 x 1080 at 25.000 FPS
WARNING: NAL Unit type 0 not handled - adding5/100)
AVC Import results: 44 samples - Slices: 3 I 41 P 0 B - 0 SEI - 3 IDR
Saving video.mp4: 0.500 secs Interleaving
Then I try to play this file using VLC, it doesn't give an error, but shows garbled data.
To be clear, the camera works fine (shows perfect video using Python code and raspistill outputs a perfect jpg file). I tried a different camera as well.
An attempt with mkvmerge :
pi#raspberrypi:~/cam $ raspivid -o test.h264 -fps 30 -t 15000 -w 1920 -h 1080
pi#raspberrypi:~/cam $ mkvmerge --default-duration 0:30p -o video.mkv test.h264
mkvmerge v31.0.0 ('Dolores In A Shoestand') 32-bit
'test.h264': Using the demultiplexer for the format 'AVC/h.264'.
'test.h264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
The file 'video.mkv' has been opened for writing.
Error: 'test.h264' track 0: mkvmerge encountered broken or unparsable data in this AVC/h.264 video track. Either your file is damaged (which mkvmerge cannot cope with yet) or this is a bug in mkvmerge itself. The error message was:
Success
pi#raspberrypi:~/cam $
This is on a Raspberry Pi 4.
A sample file can be found here : https://filebin.net/c40usz0crhgggadf
Created with : raspivid -t 30000 -w 640 -h 480 -fps 25 -b 1200000 -p 0,0,640,480 -o pivideo.h264
I'm going to respond to this myself. After doing an 'apt-get upgrade', the problem is gone.
If anyone wants to figure this out to find the root cause, this is what apt-get did :
The following packages will be upgraded:
bind9-host bluez-firmware firmware-atheros firmware-brcm80211 firmware-libertas firmware-misc-nonfree firmware-realtek libbind9-161 libdns-export1104 libdns1104 libgs9 libgs9-common libisc-export1100 libisc1100 libisccc161
libisccfg163 liblwres161 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 pi-bluetooth raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers raspi-config rpd-plym-splash
The following packages will be DOWNGRADED:
python3-pgzero
27 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
I want to run rdiff-backup and then switch of the raspberrypi it was running on.
I use the following script:
#!/bin/sh
date > /home/mik/rdiff-backup.log
echo "rsync start" >> /home/mik/rdiff-backup.log
rdiff-backup -v5 --print-statistics offlinebackup#server::/srv/backup /srv/datenserverBackup/backup >> /home/mik/rdiff-backup.log 2>&1
sync
date >> /home/mik/rdiff-backup.log
echo "rdiff-backup end" >> /home/mik/rdiff-backup.log
df -h >> /home/mik/rdiff-backup.log
sync
halt
The log file looks good (for the rdiff-backup part):
Sat 12 Aug 08:20:59 UTC 2017
rsync start
Unable to import win32security module. Windows ACLs
not supported by filesystem at /srv/backup
escape_dos_devices not required by filesystem at /srv/backup
Warning: name offlinebackup not found on system, dropping ACL entry.
Further ACL entries dropped with this name will not trigger further warnings
Using rdiff-backup version 1.2.8
Executing ssh -C offlinebackup#server rdiff-backup --server
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
Access control lists On
Extended attributes On
Windows access control lists Off
Case sensitivity On
Escape DOS devices Off
Escape trailing spaces Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Unable to import win32security module. Windows ACLs
not supported by filesystem at /srv/datenserverBackup/backup/rdiff-backup-data/rdiff-backup.tmp.0
escape_dos_devices not required by filesystem at /srv/datenserverBackup/backup/rdiff-backup-data/rdiff-backup.tmp.0
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
Ownership changing On
Hard linking On
fsync() directories On
Directory inc permissions On
High-bit permissions On
Symlink permissions Off
Extended filenames On
Windows reserved filenames Off
Access control lists On
Extended attributes On
Windows access control lists Off
Case sensitivity On
Escape DOS devices Off
Escape trailing spaces Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Backup: must_escape_dos_devices = 0
Starting increment operation /srv/backup to /srv/datenserverBackup/backup
Processing changed file .
Incrementing mirror file /srv/datenserverBackup/backup
Processing changed file abc
Incrementing mirror file /srv/datenserverBackup/backup/abc
Processing changed file abc/def
Incrementing mirror file /srv/datenserverBackup/backup/abc/def
Processing changed file abc/def/testfile.dxf
Incrementing mirror file /srv/datenserverBackup/backup/abc/def/testfile.dxf
--------------[ Session statistics ]--------------
StartTime 1502526061.00 (Sat Aug 12 08:21:01 2017)
EndTime 1502527913.72 (Sat Aug 12 08:51:53 2017)
ElapsedTime 1852.72 (30 minutes 52.72 seconds)
SourceFiles 151099
SourceFileSize 386321558216 (360 GB)
MirrorFiles 151097
MirrorFileSize 386321447731 (360 GB)
NewFiles 2
NewFileSize 110485 (108 KB)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 1
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 4
IncrementFileSize 0 (0 bytes)
TotalDestinationSizeChange 110485 (108 KB)
Errors 0
--------------------------------------------------
The backup is working, but then the script ends right there.
rdiff-backup.log contains the full report of rdiff-backup. But neither the line "rdiff-backup end", nor the output of "df -h".
How can I make it ran to the end?
Thanks for your answers
I finally found a workaround, that solves my problem.
My sciprt which is called after booting from /etc/init.d is calling the other script which does the actual work (i.e. backup my data, and write the log file) as a background task.
/etc/init.d/CallAfterBoot.sh
#!/bin/sh
sleep 30
/home/me/DoBackup.sh & # '&' starts the script in background
/home/me/DoBackup.sh is the script I posted above which is now runing correctly.
Same script running as the same user now behaves differently. There's got to be some bug somewhere, however, it works for me now.
I have some text files where I need to add 1 character to the beginning of every line of the file.
In windows, I found that a quick way to do this was by installing Cygwin and using the following command, which prepends the letter N to every line of the file:
$ sed 's/^/N/' inputFile.txt > outputFile.txt
What I found strange, was that after I added a new character to the front of each line, the file size was almost completely unchanged. I tested this further, to see if I could recreate the problem with the following steps:
Created a text file called "Test.txt", which had 10,000 lines with the word "TEST" on each line.
Created a text file called "TestWithNPrefix.txt" which had 10,000 lines with the word "NTEST" on each line.
Executed the following command to create another file which had 10,000 lines of "NTEST"
$ sed 's/^/N/' Test.txt > "SEDTest.txt"
Results
"Test" and "SEDTest" were almost the exact same size, while "TestWithNPrefix" was 10KB larger.
Test = 59,998 Bytes; SEDTest = 59,999 Bytes; TestWithNPrefix = 69,998 Bytes
When I ran the "fc" command in Command Prompt, it returned that there were no differences between "SEDTest" and "TestWithNPrefix". "FC" between "SEDTest" and "Test" returned "Resync Filed. Files are too different".
Can someone please help me understand what is causing these file size discrepancies?
EDIT: I created the files "Test.txt" and "TestWithNPrefix.txt" in UltraEdit. I just typed out the word "TEST"/"NTEST", then copied and pasted it 10,000 times.
Not an answer, but a comment with formatting:
You seem to be running into some odd situation with DOS versus Unix line endings. I have to ask: How are you creating the files? I would expect 10,000 lines of "TEST\r\n" would be exactly 60,000 bytes in size, not 59,999
On Linux (I don't have access to a cygwin environment at the moment):'
$ yes $'TEST\r' | head -n 10000 > Test
$ ll Test
-rw-r--r-- 1 jackman jackman 60000 Jan 8 13:06 Test
$ sed 's/^/N/' Test > SEDTest
$ ll *Test
-rw-r--r-- 1 jackman jackman 70000 Jan 8 13:06 SEDTest
-rw-r--r-- 1 jackman jackman 60000 Jan 8 13:06 Test
I am using the following Mencoder command as part of a perl script that burns subtitles for different MP4 videos.
mencoder -profile h264mp4 source_file.mp4 -subcp utf8 -sub subtitle_file.srt -o destination_file.mp4 >> /dev/null
This has been working for over a year without problems and it is now giving the following fatal error when run:
** MUXER_LAVF *****************************************************************
REMEMBER: MEncoder's libavformat muxing is presently broken and can generate
INCORRECT files in the presence of B-frames. Moreover, due to bugs MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
FATAL: Cannot initialize video driver.
ffmpeg version 0.7.15, Copyright (c) 2000-2013 the FFmpeg developers
built on Feb 22 2013 07:18:58 with gcc 4.4.5
configuration: --enable-libdc1394 --prefix=/usr --extra-cflags='-Wall -g ' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-avfilter --enable-libdirac --disable-decoder=libdirac --enable-libfreetype --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-libvpx --enable-librtmp --extra-libs=-lgcrypt --disable-altivec --disable-armv5te --disable-armv6 --disable-vis
libavutil 50. 43. 0 / 50. 43. 0
libavcodec 52.123. 0 / 52.123. 0
libavformat 52.111. 0 / 52.111. 0
libavdevice 52. 5. 0 / 52. 5. 0
libavfilter 1. 80. 0 / 1. 80. 0
libswscale 0. 14. 1 / 0. 14. 1
libpostproc 51. 2. 0 / 51. 2. 0
This are the contents of the h264mp4 profile:
[h264mp4]
profile-desc="H.264 MP4"
vf=pullup,softskip,pp=fd,hqdn3d,harddup
lavdopts=threads=2
ovc=x264=yes
x264encopts=crf=22:subq=6:frameref=6:qcomp=0.8:8x8dct=yes:weight_b=yes:me=umh:partitions=p8 x8,i4x4:nodct_decimate=yes:trellis=1:direct_pred=auto:level_idc=30:nocabac=yes:threads=auto
oac=faac=yes
faacopts=br=128:raw=yes:mpeg=4:tns=yes:object=2
of=lavf=yes
lavfopts=format=mp4
sws=9
ofps=24000/1001
srate=48000
I get the same error on my Debian Squeeze and on Amazon's Bitnami servers.
Both were updated recently so my guess is that the new packages don't like either the command line or the profile parameters.
The solution was to remove vf=pullup from the h264mp4 profile.
I found this by trial and error, I will elaborate on the answer as soon as I investigate on why this causes the Fatal error.
I am using openSUSE 13.2 x64 and had the same problem and managed to solve it by installing all libav* libraries (like: libavcodec) and libx264 from packman repository.
The problem was that I was installing libav* libraries from different repositories (some from packman and some from others).