[FFmpeg-trac] #4287(avcodec:new): lossless libx264rgb data corruption with image2 input

[FFmpeg]

#4287: lossless libx264rgb data corruption with image2 input
-------------------------------------+-------------------------------------
             Reporter:  pcordes      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  libx264rgb   |               Blocked By:
  x264 corruption lossless image2    |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by pcordes):

 Neither do I, with just a single PNG as input.  If I said "always
 corrupts", I meant when varying anything except the 16 frames of the
 Sintel trailer I was feeding it.  I haven't tested other inputs, to see if
 maybe full-range RGB is the problem, or anything specific to the Sintel
 trailer is the problem.

 I **do** still see corruption with only 2 frames of input.

 {{{
 mkdir -p "gtest-$HOSTNAME";
 for opt in subme={0,3}; do
   sframe=13 fr=2 crf=0 pr=ultrafast;
   s="gtest-$HOSTNAME/ffmpeg.frame$sframe+$fr.from-png.$pr.$opt";
   FFREPORT=file="'$s.log'" ffmpeg -sws_flags +print_info  -framerate 24
 -start_number $sframe -i 1080/sintel_trailer_2k_00%d.png -c:v libx264rgb
 -crf $crf -preset $pr -frames $fr -x264-params "$opt" "$s.mkv";
   ffmpeg -i "$s.mkv" -pix_fmt rgb24 -f framemd5
 "${s/ffmpeg/framemd5.rgb24}"; done

 md5sum gtest-tesla/framemd5.rgb24.* | sort
 40dcf9e04347a6558866d3e126e5bb3a  gtest-tesla/framemd5.rgb24.frame13+2
 .from-png.ultrafast.subme=0
 40dcf9e04347a6558866d3e126e5bb3a  gtest-
 tesla/framemd5.rgb24.threads1.frame13+2.from-png.ultrafast.subme=0
 d813854b43e44ec7efaf5bb44d5b99e1  gtest-tesla/framemd5.rgb24.frame13+2
 .from-png.ultrafast.subme=3
 d813854b43e44ec7efaf5bb44d5b99e1  gtest-
 tesla/framemd5.rgb24.threads1.frame13+2.from-png.ultrafast.subme=3
 }}}

 -threads 1 had no effect, not even combined with x264-params
 threads=1:$opts.  (-threads doesn't get passed on to libx264, which still
 autodetects and uses multiple threads.)

 The framemd5 of the corrupted frame (the 2nd one, which is also the first
 non-black frame), is the same as when running ffmpeg starting from frame
 !#1.  So whatever the problem is, it gets the same wrong answer with many
 or just one black frame before 0014.png (frame 13 of the video, counting
 from zero).

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4287#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker