Recherche avancée

Sur d’autres sites (10408)

• 10bit DPX to DNXHR_444 with FFmpeg causing colour shift

  15 août 2019, par Josh Northeast

  I’m trying to build a python application to convert a 10bit DPX sequence to a 4k DNXHR_444 MOV with a Arri to Rec709 lut, just as I would in Davcincci resolve.

  ffmpeg -f image2 -framerate 24 -pattern_type glob -i INPUT.dpx -c:v dnxhd -profile:v dnxhr_444 -vf lut3d=ArriAlexa_LogCtoRec709_Resolve.cube,colormatrix=bt601:bt709 -pix_fmt yuv444p10le -c:a pcm_s16le -y -timecode 00:00:41:16 OUTPUT.mov

  When comparing the output to the dpx in resolve with the lut on it, there is a slight colour shift making everything slightly more red. Even when i take the lut out of the ffmpeg code, there is still a slight redness. The colourmatrix helps a bit to get it closer but it isn’t close enough. Any ideas why I can’t get them to match ?

  LOG :

  ffmpeg -f image2 -framerate 24 -pattern_type glob -i /dpx/*.dpx -c:v dnxhd -profile:v dnxhr_444 -vf lut3d=/Arri/ArriAlexa_LogCtoRec709_Resolve.cube,colormatrix=bt601:bt709 -pix_fmt yuv444p10le -c:a pcm_s16le -y -timecode 00:00:41:16 /dpx/test.mov
  
  ffmpeg version 4.2-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2019 the FFmpeg developers
  
    built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  
    configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
  
    libavutil      56. 31.100 / 56. 31.100
  
    libavcodec     58. 54.100 / 58. 54.100
  
    libavformat    58. 29.100 / 58. 29.100
  
    libavdevice    58.  8.100 / 58.  8.100
  
    libavfilter     7. 57.100 /  7. 57.100
  
    libswscale      5.  5.100 /  5.  5.100
  
    libswresample   3.  5.100 /  3.  5.100
  
    libpostproc    55.  5.100 / 55.  5.100
  
  Input #0, image2, from '/dpx/*.dpx':
  
    Duration: 00:00:07.67, start: 0.000000, bitrate: N/A
  
      Stream #0:0: Video: dpx, gbrp10le, 4096x1716 [SAR 1:1 DAR 1024:429], 24 tbr, 24 tbn, 24 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (dpx (native) -> dnxhd (native))
  
  Press [q] to stop, [?] for help
  
  Output #0, mov, to '/dpx/test.mov':
  
    Metadata:
  
      timecode        : 00:00:41:16
  
      encoder         : Lavf58.29.100
  
      Stream #0:0: Video: dnxhd (DNXHR 444) (AVdh / 0x68645641), yuv444p10le, 4096x1716 [SAR 1:1 DAR 1024:429], q=2-1024, 200 kb/s, 0.04 fps, 12288 tbn, 24 tbc
  
      Metadata:
  
        encoder         : Lavc58.54.100 dnxhd
  
  frame=  184 fps=1.9 q=1.0 Lsize= 1117250kB time=00:00:07.62 bitrate=1200316.8kbits/s speed=0.0799x       
  
  video:1117248kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000187%

  Here is a :

  • JPG - reference of what the DPX + LUT should look like
  • DPX - a frame of the dpx sequence I’m trying to convert to DNXHR_444
  • the ArriLogC_to_Rec709 LUT to be applied to the DPX
    Let me know if you need anything else.

  https://drive.google.com/drive/folders/1j2Qq1sV5ZJJsMYe3DOFOV0dnQ3VIotcw

  Cheers,
  Josh

• lavc : stop using deprecated av_codec_next()

  14 avril 2020, par Josh de Kock

  lavc : stop using deprecated av_codec_next()
  Signed-off-by : Josh de Kock <josh@itanimul.li>
  

  • [DH] libavcodec/options.c
  • [DH] libavcodec/tests/utils.c

• libavcodec/libx264 : fix reference frame computation based on level

  16 avril 2020, par Josh Brewster

  libavcodec/libx264 : fix reference frame computation based on level
  The current implementation allows passing levels to libavcodec as
  
  integers (such as "31" instead of "3.1").
  However, in this case, the maximum reference frame value per level was
  
  ignored because libavcodec converted the string to 310 instead of 31.
  Since libx264 has correctly parsed the level to int
  
  (x4->params.i_level_idc), we should rely on this value instead of
  
  attempting to parse the level string on our own.
  Signed-off-by : Josh Brewster <josh.brewster@protonmail.com>
  
  Signed-off-by : Josh de Kock <josh@itanimul.li>
  

  • [DH] libavcodec/libx264.c