[FFmpeg-trac] #6814(undetermined:new): Nondeterministic corruption outputting h.265 /w threading enabled

[FFmpeg]

#6814: Nondeterministic corruption outputting h.265 /w threading enabled
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  audiotoaster                       |                 Priority:  normal
               Status:  new          |                  Version:
            Component:               |  unspecified
  undetermined                       |               Blocked By:
             Keywords:               |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Have been trying to track down a problem with random corruption for about
 a month when converting ~1080 video from h.264 to h.265.

 Tried various versions of ffmpeg 3.3, 3.4 and various nightlies from
 zeranoe including 32-bit and 64-bit versions.  All seem to produce similar
 results.

 Problem is seemingly completely random.  It can happen as often as
 multiple times within an hour of outputted video or once every several
 hours.

 When corruption is found simply re-encoding same video using same process
 results in either no corruption or corruption somewhere else in the output
 video.

 No errors are ever displayed in the ffmpeg output related to corrupt
 output.

 Only solution I have found which has completely resolved the problem for
 me is to disable thread pools in libx265.

 Currently:

 {{{
 ffmpeg version N-88514-gd5995c531d Copyright (c) 2000-2017 the FFmpeg
 developers

 built with gcc 7.2.0 (GCC)
 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib
 --ena
 ble-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-
 libbluray
  --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-
 libopus
 --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora
 --enabl
 e-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp
 --enable-libx2
 64 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma
 --enable-zli
 b --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda
 --enable-cuv
 id --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
 --enable-lib
 mfx
 libavutil      56.  0.100 / 56.  0.100
 libavcodec     58.  1.100 / 58.  1.100
 libavformat    58.  0.102 / 58.  0.102
 libavdevice    58.  0.100 / 58.  0.100
 libavfilter     7.  0.101 /  7.  0.101
 libswscale      5.  0.101 /  5.  0.101
 libswresample   3.  0.101 /  3.  0.101
 libpostproc    55.  0.100 / 55.  0.100
 }}}

 System is Win7 /w Intel i7 4770k.  Quad core /w HT enabled.

 Example CLI where random corruption occurs

 {{{
 ffmpeg -i "sourceh264.mkv" -vf crop=1440:1072:240:4  -c:v libx265 -crf 19
 -map_metadata -1 -sn "outputh265.mkv"
 }}}

 Example CLI with no corruption (threading disabled)

 {{{
 ffmpeg -i "sourceh264.mkv" -vf crop=1440:1072:240:4  -c:v libx265 -crf 19
 -x265-params frame-threads=1:pools=none -map_metadata -1 -sn
 "outputh265.mkv"
 }}}

 Problem appears to be completely independent of input video.  In my case
 input is always h264.  The crop parameters vary with each input video.

 Since disabling threading solves the problem for me changed workflow
 slightly to run a half dozen instances of ffmpeg concurrently to keep all
 cores busy.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6814>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker