-threads:v:0 1
ffmpeg -threads:v:0 1 -i '/path/janefonduv01.mp4' -vsync 1 -
(etc)
-threads:v:0 1
ffmpeg -threads:v:0 1 -i '/path/janefonduv01.mp4' -vsync 1 -
(etc)
You might have to download the amd64 and not the i686!
Agenda
https://www.nginx.com/wp-content/uploads/2018/12/NGINX-Conf-2018-slides_Choi-streaming.pdf
– Introduction to streaming
– Turn NGINX into a streaming server
– HLS/DASH VOD by NGINX – How?
– Supporting HLS 7
– Encrypting HLS
– High-bitrate streaming (4K/8K UHD) by NGINX
– Low-latency live by NGINX
-filter_complex “[1]lut=a=val*0.5[a];[0][a]overlay=main_w-overlay_w-10:main_h-overlay_h-10“ -codec:v libx264 -r 29 -pix_fmt yuv420p -profile:v baseline -level 3 -b:v 3500k -s 320×240 -codec:a aac -strict experimental -ac 2 -b:a 64k
A few videos were being stucked on queue list… and I wasn’t finding the problem.
Looks like ffmpeg acts a little weird with “.
I’v replaced the ” with ‘ and the problem was fixed.
Some of my old scripts with ffmpeg… are now breaking apart …. returning, sometimes…
Please use -q:a or -q:v, -qscale is ambiguous
-q:v 0 is the solution!
ERROR:HLSError(code/url/msg)=1/http://www.domain.com/tutorials/laravel_facade/hls.m3u8/Cannot load M3U8: crossdomain access denied:Error #2048 VM1749:1 INFO:HLSNetStream:close
This is my crossdomain.xml example…
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" secure="false" /> <allow-http-request-headers-from domain="*" headers="*" secure="false"/> </cross-domain-policy>
So, in one of my projects/products/services, I need to execute ffmpeg via PHP…
Usually I use at do send the job to a queue list.. unfortunately in two different clients’ servers somehow PHP + exec and at doesn’t work well….
This is how we send a PHP exec to background
exec(command > /dev/null 2>/dev/null &);
ffmpeg -i source_path/movie.mpg -c:v libx264 -vsync 2 -strict -2 dest_path/movie.mp4
ffmpeg -i source_path/movie.mpg -vcodec libtheora -q:v 10 -codec:a libvorbis -q:a 5 -vsync 2 -threads 0 dest_path/movie.ogv
ffmpeg -i source_/movie.mpg -acodec libvorbis -aq 5 -ac 2 -qmax 25 -threads 2 dest_path/movie.webm
Download the latest FFmpeg Static Builds from http://johnvansickle.com/ffmpeg/.
How to know if we need to download the 32 or 64 bits?
Lets run:
cat /etc/*release*
CentOS release 6.6 (Final) LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Or using uname (more reliable)
uname -m
I’v download it do a specific folder
wget http://johnvansickle.com/ffmpeg/builds/ffmpeg-git-64bit-static.tar.xz
And the run the following command to uncompress it:
tar xf ffmpeg-git-64bit-static.tar.xz
To run ffmpeg or ffprobe we need to give the full path to them!
It worked!
With the lastest versions!
FFMPEG & FFPROBE
ROCK!
-bash-3.2$ tar -xf ffmpeg-git-64bit-static.tar.xz tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Read 5668 bytes from ffmpeg-git-64bit-static.tar.xz tar: Error exit delayed from previous errors
tar version (fuckz!)
tar (GNU tar) 1.15.1
Well, this machine, where I got this error, is a managed server…
I didn’t bored to ask support to upgrade TAR or install XZ… but if you want, you can install XZ and then…
xz -d archive.tar.xz tar xvf archive.tar
It might work! 🙂
Btw! On old machines kernel might not be compatible…
SH*T!
I had a 1h video, with about 400Mb…
My batch was taking HOURS (with a 8 core CPU) and creating a 5Gb mp4 file of the encoding….. wtf?
13442 www-data 22 2 1426m 361m 3884 R 614 4.5 2180:37 ffmpeg 14462 www-data 22 2 1773m 966m 3660 R 100 12.1 293:07.12 ffmpeg
I had to run the command manually and figure out the issue.
Metadata: creation_time : 2014-04-19 19:19:31 File 'video.mp4' already exists. Overwrite ? [y/N] y [mp4 @ 0x26a8ae0] Frame rate very high for a muxer not efficiently supporting it. Please consider specifying a lower framerate, a different muxer or -vsync 2 [libx264 @ 0x26c6ce0] using SAR=1/1 [libx264 @ 0x26c6ce0] MB rate (108000000) > level limit (2073600)
I had to add -vsync 2 to solve this.
/usr/bin/ffmpeg -i 14-18-14.mp4 -c:v libx264 -vsync 2 -threads 4 video.mp4