[FFmpeg-devel] Looking for a consultant
jramirez at baylibre.com
Fri Jun 22 09:40:27 EEST 2018
On 06/21/2018 11:59 PM, Carl Eugen Hoyos wrote:
> 2018-06-20 16:50 GMT+02:00, Ariel Frailich <ariel at websiteatelier.com>:
>> Input: mostly ProRes (10-20Gb), HD to 4K res, 90 mins average length.
>> Output: a set of .mp4 files at 5 different resolutions, up to 1080.
>> These are further processed (primarily bento4) to create multiple/
>> variable bitrate HLS and DASH streams, with encryption and DRM.
> (The most important information would be the target codec.)
>> On our office machine (iMac, 3.2 GHz Intel Core i5, 8Gb, macOS
>> Sierra), encoding typically takes 6-7 hours per film. Ideally, we
>> would like to cut this down to 1-2 hours.
>> WHAT WE NEED TO KNOW
>> 1. Hardware: what's a good hardware configuration for our needs?
> That depends on the question if you want hardware or software
> encoding (that nobody here can answer, only you).
>> CPUs, cores, RAM, RAM disk, graphics cards, etc.
> The more cpu cores the faster software encoding is, you
> will find information online about the performance of
> graphic cards for hardware encoding.
just for completeness Carl - although I doubt it applies to these high
performance/quality requirements- ffmpeg can deliver hardware encoding
support if the system on chip has a hardware encoder, runs Linux and
there is a v4l2 m2m kernel driver for it (this would bypass the need for
a graphic card). An example of a board that would meet these usability
performance and quality will vary from SoC to Soc.
>> Also, which version of Linux is recommended (or which to avoid).
> No limitations known.
> (musl 32bit is unsupported which we are not allowed to
> document but this will not hit you.)
>> 2. ffmpeg setup: how should ffmpeg be compiled to best take
>> advantage of the particular hardware configuration?
> $ ./configure --enable-gpl && make for hardware encoding,
> $ ./configure --enable-gpl --enable-libx264 && make for
> software encoding.
>> 3. Video processing: how should ffmpeg be run to maximize
>> speed and efficiency, and to produce the most suitable files
>> for our needs?
> I may misunderstand (and this is possibly not an FFmpeg-
> related question) but for software encoding, remember that
> threads do not scale well, single-threaded encoding (of
> multiple files at the same time) is always most efficient.
> Carl Eugen
> PS: In case you don't know: Hardware encoding is potentially
> faster than software encoding but provides worse quality for
> a given bitrate or larger files for a given quality.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel