A very common use case is that you don't want to waste time using a video editor that requires you to open it up and manually import the video clip and audio clip, then manually delete the old audio track and import the video and new audio. That's too much work and time since we don't want to go through the hassle.
ffmpeg is our solution, all we have to do is specify 3 variables and we're done!
-i Windows2019-Server-Noaudio.mp4 is our in........
When things go wrong your video is basically unplayable or the first video plays fine and then freezes when moving on to the next. Generally if both videos weren't produced with the exact 100% same settings you will have issues. You can try the basic concat but it often won't work right.
Solution for me:
My example uses 3 videos in total so "n=3" and a=1 to include audio.
ffmpeg -threads 12 -i file1.mp4 -........
The only way I've found in mdadm to make 2 drives perform like a proper RAID 1 (eg. the read speed should be 2x that of a single drive) is to use the --layout=f2 (far 2).
mdadm raid10 performance issues.
Be very aware that mdadm seems to default to layout=n2 (which means near). In this scenario it means it is like mdadm RAID 1 performance (you get maximum read speeds of a single drive).
dd if=/dev/md126 of=/dev/null bs=1M cou........
The first is a dual CPU AMD Opteron 2373EE (4 cores x 2) and I think it did bad because it has some old 250GB SATAs which can only do about 65MB/s max sequential reads. I think it should have blown away the second (AMD X4 640 Quad Core).
[root@fs12home unixbench-4.1.0-wht-2]# ./Run
make: Entering directory `/root/unixbench-4.1.0-wht-2'
Checking distribution of files
This was unbelievable how much the Xen kernel slows things down, keep in mind both tests were done on the hostnode, one was with the Openvz-Xen hybrid kernel and the other was just OpenVZ. You can see the performance difference is nearly 300% better when not using the Xen kernel.
OpenVZ-Xen Kernel Test Results (I was wondering what was wrong/so slow with my Core i5!)
# # # # # #&n........
The results are still not flattering and are nothing close to native performance. Unless GlusterFS has a "DRBD-like" option to delay writes over the network and to only read from the client side, I don't see how performance can ever improve much more.
After doing some client optimizations Iadded more to the score:
Start Benchmark Run: Sun Nov 29 00:37:44 PST 2009
00:37:44 up 3 min, 1 user, load average: 0.01........
You might remember my original GluserFS/OpenVZ benchmark which produced a horrible 29.8
This is the exact same system, but using the latest 2.0.8 (with some small files patch which speeds up performance) you can see it is about 25% faster.
I also haven't tuned my config files at all, but there are some settings that should increase performance on small files which I believe i........
This is very disappointing since GlusterFS markets itself as a solution to deploy VPS servers on. On the HNitself I get a Unixbench of about 360.
I'm also using an SSH tunnel to secure the communications, but even before that, things seemed very slow.
# # # # # # # #####&n........