[FFmpeg-trac] #4638(avcodec:open): Multithreaded FLAC encoding

[FFmpeg]

#4638: Multithreaded FLAC encoding
-------------------------------------+-----------------------------------
             Reporter:  xtemp09      |                    Owner:  (none)
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  flac         |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-----------------------------------
Comment (by Warren Ondras):

 Apologies for waking up such an old ticket, but I wanted to mention an
 obscure use-case where FLAC encoding speed becomes quite important:

 The "Domesday Duplicator" project has a set of hardware/software tools for
 capturing and archiving of analog laserdiscs in a raw form, directly from
 the laser pickup. The "ld-decode" software stack is later used to extract
 and process the audio, video and data contained in the capture.

 Standard Domesday captures use 10-bit resolution at 40 MHz. A 30-minute
 side of a CAV laserdisc takes up 144 GB when stored as signed 16-bit
 integers (two bytes per sample), though the 10-bit values can be packed
 down to 90 GB in what are now called ".lds" files.

 By guesswork and luck, we discovered that FLAC does a surprisingly good
 job of compressing the 16-bit raw samples as audio. (The signal is
 modulated on on a 9 MHz carrier, so when slowed down by a factor of 1000,
 it sounds like a warbly whistle.) The final file size is usually around 50
 GB -- nearly half the size of the simple packing. These are now known as
 ".ldf" files.

 These compressed files are extremely useful for reducing storage
 space/cost when archiving multiple titles. Naturally, encoding of 144 GB
 takes a very long time. FFmpeg is the "gold standard" for this purpose,
 due to its reliability, and its willingness to deal with streams of this
 size. (The reference FLAC encoded flat-out refuses, I think due to a
 32-bit stream position pointer that overflows beyond a certain length.
 FFmpeg can wrap it in an .oga container, which avoids this problem.)

 There is a customized build of FlacCL called FlaLDF that makes it
 compatible as well, and it is much faster, but I find results to be
 inconsistent; this is especially true at the higher compression settings,
 which is where the speed is most needed.


 This may be a niche use by a handful of crazed data hoarders, but I wanted
 to mention it just in case it piques someone's interest. If not, I'll just
 say thanks for all the hard work you've already done and continue to do.
 Cheers!
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/4638#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker