Recherche avancée

Sur d’autres sites (7159)

• Size Discrepany in the ‘du’ Command

  22 juin 2012, par Multimedia Mike — General

  I had a problem today while using the common Unix command ’du’. As a refresher, ’du’ stands for disk usage and is a handy tool for understanding how much disk space is being occupied.

  I think ’du’ is probably doing the right thing. The problem might be that I’m getting strange (read : 1/2 the expected number) when running the tool against directories on vmhgfs, the VMware filesystem.

  Science Project
  On an Ubuntu Linux VMware session, my home directory is on the main file system, which is ext4. The directory /mnt/hgfs is reported by ’mount’ to be of type vmhgfs and is shared with the host machine.

  Create a directory in the home directory and generate a 10 MiB file :

  mkdir /home/melanson/dir
  dd if=/dev/urandom of=/home/melanson/dir/random-file bs=1048576 count=10
  

  Create a directory on the shared drive and copy the same file :

  mkdir /mnt/hgfs/vmshare/dir
  cp /home/melanson/dir/random-file /mnt/hgfs/vmshare/dir
  

  Run ’du’ on each directory using the -k and -h options :

  du -k /home/melanson/dir /mnt/hgfs/vmshare/dir
  10244   /home/melanson/dir
  5120    /mnt/hgfs/vmshare/dir
  du -h /home/melanson/dir /mnt/hgfs/vmshare/dir
  
  11M    /home/melanson/directory
  
  5.0M   /mnt/hgfs/vmshare/directory
  

  I noticed this discrepancy when I was trying to pack a set of files (akin to ’tar’-ing) living in a directory in the shared location. I was going mad trying to understand why the original directory was only 2 MB as reported by ’du’ but the final packed file was 4 MB.

  To be fair, the man page for ’du’ succinctly states that the tool’s purpose is merely to "estimate file space usage".

• hevc : Track long and short term RPS size for VDPAU

  12 février 2016, par Philip Langdale

  hevc : Track long and short term RPS size for VDPAU
  Today, we track the short term RPS size for DXVA, but only if the
  
  SliceHeader RPS is being used. Otherwise it’s left uninitialized.
  NVIDIA’s VDPAU implementation requires that the size be accurately
  
  tracked even if an SPS RPS is being used. In this case, it’s really
  
  counting the size of the RPS idx information, but you end up with
  
  mangled output if the value is not accurate.
  VDPAU also needs the size of the long term RPS.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  
  Signed-off-by : Rémi Denis-Courmont <remi@remlab.net>
  
  Signed-off-by : Luca Barbato <lu_zero@gentoo.org>
  

  • [DBH] libavcodec/hevc.c
  • [DBH] libavcodec/hevc.h

• avcodec/nvenc : Declare support for P016

  25 février 2018, par Philip Langdale

  avcodec/nvenc : Declare support for P016
  nvenc doesn't support P016, but we have two problems today :
  1) We declare support for YUV444P16 which nvenc also doesn't support.
  
     We do this because it's the only pix_fmt we have that can
  
     approximate nvenc's internal format that is YUV444P10 with data in
  
     MSBs instead of LSBs. Because the declared format is a 16bit one,
  
     it will be preferrentially chosen when encoding >10bit content,
  
     but that content will normally be YUV420P12 or P016 which should
  
     get mapped to P010 and not YUV444P10.
  2) Transcoding P016 content with nvenc should be possible in a pure
  
     hardware pipeline, and that can't be done if nvenc doesn't say it
  
     accepts P016. By mapping it to P010, we can use it, albeit with
  
     truncation. I have established that swscale doesn't know how to
  
     dither to 10bits so we'd get truncation anyway, even if we tried
  
     to do this 'properly'.
  

  • [DH] libavcodec/nvenc.c
  • [DH] libavcodec/version.h