– 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 “lut=a=val*0.5[a];[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?
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)
I’v download it do a specific folder
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!
With the lastest versions!
FFMPEG & FFPROBE
SOME PROBLEMS ON OLD MACHINES
-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…
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
If you have been following along, we have recently been doing a series on command line video tools. Here I review a recent ffmpeg benchmark I performed. After reviewing the documentation and encoding a few sample videos, my questions were as follows:
- How long does each of the various ffmpeg preset take for h264 encoding?
- How much faster is the encoding with multiple threads?
- For a given variable bitrate, does a given preset make a difference in image quality?
- What is the optimal preset for ffmpeg?
When it comes to making collaboration technology such as high-definition video open and broadly available, it’s clear that the web browser plays an important role. The question is, how do you enable real-time video natively on the Web? It’s a question that folks are anxious to have answered.
WebRTC–a set of enhancements to HTML5–will address the issue head on. But, there is an important hurdle that must first be cleared, and that’s standardizing on a common video codec for real-time communications on the web – something the Internet Engineering Task Force (IETF) will decide next week.
The industry has been divided on the choice of a common video codec for some time, namely because the industry standard–H.264–requires royalty payments to MPEG LA. Today, I am pleased to announce Cisco is making a bold move to take concerns about these payments off the table.
We plan to open-source our H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet. Cisco will not pass on our MPEG LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use in WebRTC.
Read more: http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc