Recherche avancée

Sur d’autres sites (6545)

• libavutil/hwcontext_d3d11va : adding more texture information to the D3D11 hwcontext API

  20 août 2021, par Artem Galin

  libavutil/hwcontext_d3d11va : adding more texture information to the D3D11 hwcontext API
  Microsoft VideoProcessor requires texture with D3DUSAGE_RENDERTARGET flag as output.
  
  There is no way to allocate array of textures with D3D11_BIND_RENDER_TARGET flag
  
  and .ArraySize > 2 by ID3D11Device_CreateTexture2D due to the Microsoft limitation.
  
  Adding AVD3D11FrameDescriptors array to store array of single textures
  
  instead of texture with multiple slices resolves this.
  Signed-off-by : Artem Galin <artem.galin@intel.com>
  

  • [DH] doc/APIchanges
  • [DH] libavutil/hwcontext_d3d11va.c
  • [DH] libavutil/hwcontext_d3d11va.h
  • [DH] libavutil/hwcontext_qsv.c
  • [DH] libavutil/version.h

• FFMPEG encoding 16bit video data results in 10bit

  12 mars 2023, par Jl arto

  I want to compress a depth map that has 16 bits of information per pixel. In general, such depth maps can be stored in different ways, e.g. p016le, gray16le, yuv420p16le, yuv444p16le, ... but for simplicity, let's assume the depth map is a yuv420p16le (where the y-channel contains the depth).

  


  For some reason when encoding with hevc_nvenc (I use an NVIDIA GTX 1660 Ti GPU), ffmpeg (the command line tool) changes the pixel format to a 10 or 12 bit variant (p010le, gray12le, yuv420p10le, yuv444p12le, ...), but I would like to keep the full 16 bits, since this affects the quality of the depth stored.

  


  For example :

  


  ffmpeg.exe -s:v 1920x1080 -r 30 -pix_fmt yuv420p16le -i depth_yuv420p16le.yuv -c:v hevc_nvenc -pix_fmt yuv444p16le output.mp4


  


  If I use ffprobe on the output.mp4, it tells me that the underlying pixel format is actually yuv444p10le. (Decoding and looking at the raw pixel data, I can confirm that the precision has decreased from 16 bits to 10 bits).

  


  I hope 16 bit compression is possible, since according to

  


  ffmpeg -h encoder=hevc_nvenc


  


  the supported pixel formats are :

  


  hevc_nvenc: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11


  


  But p016le results in a p010le output, and yuv444p16le in yuv444p10le.

  


  Does anyone know where the problem could lie ? Should I re-install ffmpeg (version 4.3.2-2021-02-27-essentials_build-www.gyan.dev) ? Is it because of Windows 10 having limited encoding/decoding capabilities ? Will buying the HEVC Video Extensions help solve this problem ?

  


  Additional info : using libx256 does not look like it will work for this purpose, since the supported pixel formats are :

  


  libx256 : yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le


  


  Any help would be greatly appreciated.

  


• Fragmented MP4 : TrackFragHeader TFHD must have TrackID, is this in the spec ?

  27 juillet 2021, par Penquin

  I'm building a fragmented mp4 muxer and noticed that the track id is repeated inside the TFHD.
If the video does not have this undocumented track id, it will simply not play.

  


  Here's an example of a muxer adding it :
https://github.com/edgeware/mp4ff/blob/bb9320744777dc97f18034c8aed45a9bcdbaa995/mp4/tfhd.go#L154

  


  I was relying on the open spec provided by Microsoft :
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstr/513ea48c-9a57-4792-a32a-fb6202ce2a58

  


  Is this an addition to the spec ? Is the spec provided by Microsoft wrong ?