Sur d’autres sites (12943)

• Files created with "ffmpeg hevc_nvenc" do not play on TV. (with video codec SDK 9.1 of nvidia)

  29 janvier 2020, par Dashhh

  Problem

  • Files created with hevc_nvenc do not play on TV. (samsung smart tv, model unknown)
    Related to my ffmpeg build is below.

  FFmpeg build conf

  $ ffmpeg -buildconf
  
      --enable-cuda
  
      --enable-cuvid
  
      --enable-nvenc
  
      --enable-nonfree
  
      --enable-libnpp
  
      --extra-cflags=-I/path/cuda/include
  
      --extra-ldflags=-L/path/cuda/lib64
  
      --prefix=/prefix/ffmpeg_build
  
      --pkg-config-flags=--static
  
      --extra-libs='-lpthread -lm'
  
      --extra-cflags=-I/prefix/ffmpeg_build/include
  
      --extra-ldflags=-L/prefix/ffmpeg_build/lib
  
      --enable-gpl
  
      --enable-nonfree
  
      --enable-version3
  
      --disable-stripping
  
      --enable-avisynth
  
      --enable-libass
  
      --enable-libfontconfig
  
      --enable-libfreetype
  
      --enable-libfribidi
  
      --enable-libgme
  
      --enable-libgsm
  
      --enable-librubberband
  
      --enable-libshine
  
      --enable-libsnappy
  
      --enable-libssh
  
      --enable-libtwolame
  
      --enable-libwavpack
  
      --enable-libzvbi
  
      --enable-openal
  
      --enable-sdl2
  
      --enable-libdrm
  
      --enable-frei0r
  
      --enable-ladspa
  
      --enable-libpulse
  
      --enable-libsoxr
  
      --enable-libspeex
  
      --enable-avfilter
  
      --enable-postproc
  
      --enable-pthreads
  
      --enable-libfdk-aac
  
      --enable-libmp3lame
  
      --enable-libopus
  
      --enable-libtheora
  
      --enable-libvorbis
  
      --enable-libvpx
  
      --enable-libx264
  
      --enable-libx265
  
      --disable-ffplay
  
      --enable-libopenjpeg
  
      --enable-libwebp
  
      --enable-libxvid
  
      --enable-libvidstab
  
      --enable-libopenh264
  
      --enable-zlib
  
      --enable-openssl

  ---

  ffmpeg Command

  • Command about FFmpeg encoding

  ffmpeg -ss 1800 -vsync 0 -hwaccel cuvid -hwaccel_device 0 \
  
  -c:v h264_cuvid -i /data/input.mp4 -t 10 \
  
  -filter_complex "\
  
  [0:v]hwdownload,format=nv12,format=yuv420p,\
  
  scale=iw*2:ih*2" -gpu 0 -c:v hevc_nvenc -pix_fmt yuv444p16le -preset slow -rc cbr_hq -b:v 5000k -maxrate 7000k -bufsize 1000k -acodec aac -ac 2 -dts_delta_threshold 1000 -ab 128k -flags global_header ./makevideo_nvenc_hevc.mp4

  Full log about This Command - check this full log

  The reason for adding "-color_ " in the command is as follows.

  • HDR video after creating bt2020 + smpte2084 video using nvidia hardware accelerator. (I’m studying to make HDR videos. I’m not sure if this is right.)

  How can I make a video using ffmpeg hevc_nvenc and have it play on TV ?

  ---

  Things i’ve done

  Here’s what I’ve researched about why it doesn’t work.
   The header information is not properly included in the resulting video file. So I used a program called nvhsp to add SEI and VUI information inside the video. See below for the commands and logs used.

  nvhsp is open source for writing VUI and SEI bitstrings in raw video. nvhsp link

  # make rawvideo for nvhsp
  
  $  ffmpeg -vsync 0 -hwaccel cuvid -hwaccel_device 0 -c:v h264_cuvid \
  
  -i /data/input.mp4 -t 10 \
  
  -filter_complex "[0:v]hwdownload,format=nv12,\
  
  format=yuv420p,scale=iw*2:ih*2" \
  
  -gpu 0 -c:v hevc_nvenc -f rawvideo output_for_nvhsp.265
  
  
  
  # use nvhsp
  
  $ python nvhsp.py ./output_for_nvhsp.265 -colorprim bt2020 \
  
  -transfer smpte-st-2084 -colormatrix bt2020nc \
  
  -maxcll "1000,300" -videoformat ntsc -full_range tv \
  
  -masterdisplay "G (13250,34500) B (7500,3000 ) R (34000,16000) WP (15635,16450) L (10000000,1)" \
  
  ./after_nvhsp_proc_output.265
  
  
  
  Parsing the infile:
  
  
  
  ==========================
  
  
  
  Prepending SEI data
  
  Starting new SEI NALu ...
  
  SEI message with MaxCLL = 1000 and MaxFall = 300 created in SEI NAL
  
  SEI message Mastering Display Data G (13250,34500) B (7500,3000) R (34000,16000) WP (15635,16450) L (10000000,1) created in SEI NAL
  
  Looking for SPS ......... [232, 22703552]
  
  SPS_Nals_addresses [232, 22703552]
  
  SPS NAL Size 488
  
  Starting reading SPS NAL contents
  
  Reading of SPS NAL finished. Read 448 of SPS NALu data.
  
  
  
  Making modified SPS NALu ...
  
  Made modified SPS NALu-OK
  
  New SEI prepended
  
  Writing new stream ...
  
  Progress: 100%
  
  =====================
  
  Done!
  
  
  
  File nvhsp_after_output.mp4 created.
  
  
  
  # after process
  
  $ ffmpeg -y -f rawvideo -r 25 -s 3840x2160 -pix_fmt yuv444p16le -color_primaries bt2020 -color_trc smpte2084  -colorspace bt2020nc -color_range tv -i ./1/after_nvhsp_proc_output.265 -vcodec copy  ./1/result.mp4 -hide_banner
  
  
  
  Truncating packet of size 49766400 to 3260044
  
  [rawvideo @ 0x40a6400] Estimating duration from bitrate, this may be inaccurate
  
  Input #0, rawvideo, from './1/nvhsp_after_output.265':
  
    Duration: N/A, start: 0.000000, bitrate: 9953280 kb/s
  
      Stream #0:0: Video: rawvideo (Y3[0][16] / 0x10003359), yuv444p16le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, 9953280 kb/s, 25 tbr, 25 tbn, 25 tbc
  
  [mp4 @ 0x40b0440] Could not find tag for codec rawvideo in stream #0, codec not currently supported in container
  
  Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
      Last message repeated 1 times

  Goal

  • I want to generate matadata normally when encoding a video through hevc_nvenc.

  • I want to create a video through hevc_nvenc and play HDR Video on smart tv with 10bit color depth support.

  ---

  Additional

  • Is it normal for ffmpeg hevc_nvenc not to generate metadata in the resulting video file ? or is it a bug ?

  • Please refer to the image below. (*’알 수 없음’ meaning ’unknown’)

    • if you need more detail file info, check this Gist Link (by ffprobe)
      

  • However, if you encode a file in libx265, the attribute information is entered correctly as shown below.

    • if you need more detail file info, check this Gist Link
      

  However, when using hevc_nvenc, all information is missing.

  • i used option -show_streams -show_programs -show_format -show_data -of json -show_frames -show_log 56 at ffprobe

• Merge remote-tracking branch ’cehoyos/master’

  7 mai 2015, par Michael Niedermayer

  Merge remote-tracking branch ’cehoyos/master’
  * cehoyos/master :
  
    lavf/img2dec : Autodetect qdraw images.
  
    lavc/qdrw : Also support real-world qdraw images.
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/qdrw.c
  • [DH] libavcodec/version.h
  • [DH] libavformat/Makefile
  • [DH] libavformat/allformats.c
  • [DH] libavformat/img2dec.c
  • [DH] libavformat/version.h

• arm : vp9 : Add NEON loop filters

  10 octobre 2016, par Martin Storsjö

  arm : vp9 : Add NEON loop filters
  This work is sponsored by, and copyright, Google.
  The implementation tries to have smart handling of cases
  
  where no pixels need the full filtering for the 8/16 width
  
  filters, skipping both calculation and writeback of the
  
  unmodified pixels in those cases. The actual effect of this
  
  is hard to test with checkasm though, since it tests the
  
  full filtering, and the benefit depends on how many filtered
  
  blocks use the shortcut.
  Examples of relative speedup compared to the C version, from checkasm :
  
                            Cortex       A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_neon :          2.72   2.68   1.78   3.15
  
  vp9_loop_filter_h_8_8_neon :          2.36   2.38   1.70   2.91
  
  vp9_loop_filter_h_16_8_neon :         1.80   1.89   1.45   2.01
  
  vp9_loop_filter_h_16_16_neon :        2.81   2.78   2.18   3.16
  
  vp9_loop_filter_mix2_h_44_16_neon :   2.65   2.67   1.93   3.05
  
  vp9_loop_filter_mix2_h_48_16_neon :   2.46   2.38   1.81   2.85
  
  vp9_loop_filter_mix2_h_84_16_neon :   2.50   2.41   1.73   2.85
  
  vp9_loop_filter_mix2_h_88_16_neon :   2.77   2.66   1.96   3.23
  
  vp9_loop_filter_mix2_v_44_16_neon :   4.28   4.46   3.22   5.70
  
  vp9_loop_filter_mix2_v_48_16_neon :   3.92   4.00   3.03   5.19
  
  vp9_loop_filter_mix2_v_84_16_neon :   3.97   4.31   2.98   5.33
  
  vp9_loop_filter_mix2_v_88_16_neon :   3.91   4.19   3.06   5.18
  
  vp9_loop_filter_v_4_8_neon :          4.53   4.47   3.31   6.05
  
  vp9_loop_filter_v_8_8_neon :          3.58   3.99   2.92   5.17
  
  vp9_loop_filter_v_16_8_neon :         3.40   3.50   2.81   4.68
  
  vp9_loop_filter_v_16_16_neon :        4.66   4.41   3.74   6.02
  The speedup vs C code is around 2-6x. The numbers are quite
  
  inconclusive though, since the checkasm test runs multiple filterings
  
  on top of each other, so later rounds might end up with different
  
  codepaths (different decisions on which filter to apply, based
  
  on input pixel differences). Disabling the early-exit in the asm
  
  doesn’t give a fair comparison either though, since the C code
  
  only does the necessary calcuations for each row.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-9x.
  This is pretty similar in runtime to the corresponding routines
  
  in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
  
  vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
  
  to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
  
  and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
  
  and vertical is flipped between the libraries.)
  In order to have stable, comparable numbers, the early exits in both
  
  asm versions were disabled, forcing the full filtering codepath.
                             Cortex           A7      A8      A9     A53
  
  vp9_loop_filter_h_16_8_neon :             597.2   472.0   482.4   415.0
  
  libvpx vpx_lpf_vertical_16_neon :         626.0   464.5   470.7   445.0
  
  vp9_loop_filter_v_16_8_neon :             500.2   422.5   429.7   295.0
  
  libvpx vpx_lpf_horizontal_edge_8_neon :   586.5   414.5   415.6   383.2
  
  vp9_loop_filter_v_16_16_neon :            905.0   784.7   791.5   546.0
  
  libvpx vpx_lpf_horizontal_edge_16_neon : 1060.2   751.7   743.5   685.2
  Our version is consistently faster on on A7 and A53, marginally slower on
  
  A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
  
  three tests in this particular test run).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/arm/Makefile
  • [DBH] libavcodec/arm/vp9dsp_init_arm.c
  • [DBH] libavcodec/arm/vp9lpf_neon.S