Recherche avancée

Sur d’autres sites (7053)

• arm : Detect 32 bit cpu features on ARMv8 when running on a 64 bit kernel

  23 juin 2014, par Martin Storsjö

  arm : Detect 32 bit cpu features on ARMv8 when running on a 64 bit kernel
  When running on a 64 bit kernel, /proc/cpuinfo lists different
  
  optional features than on 32 bit kernels (because some of them
  
  are mandatory in the 64 bit implemenations).
  The kernel does list the old features properly if they are queried
  
  via /proc/self/auxv though - however this file is not always readable
  
  (e.g. on most android systems). The getauxval function could also
  
  provide the same info as /proc/self/auxv even if this file isn’t
  
  readable, but this function is not always available (and thus would
  
  need to be loaded with dlsym for compatibility with older android
  
  versions).
  The android cpufeatures library does this slightly differently,
  
  by assuming that these are available if the "CPU architecture"
  
  line is >= 8, see [1] for details.
  It has been suggested to include the old, non-optional features in
  
  /proc/cpuinfo as well, but that suggested patch never was merged.
  
  See [2] for the discussion around this suggestion.
  [1] https://android-review.googlesource.com/91380
  
  [2] http://marc.info/?l=linux-arm-kernel&m=139087240101974
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavutil/arm/cpu.c

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• avcodec/mips : MSA (MIPS-SIMD-Arch) optimizations for HEVC copy and hv mc functions

  22 avril 2015, par Shivraj Patil

  avcodec/mips : MSA (MIPS-SIMD-Arch) optimizations for HEVC copy and hv mc functions
  Incorporated review comment.
  
  Removed "__" from volatile.
  Signed-off-by : Shivraj Patil <shivraj.patil@imgtec.com>
  
  Reviewed-by : Nedeljko Babic <Nedeljko.Babic@imgtec.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/mips/hevcdsp_init_mips.c
  • [DH] libavcodec/mips/hevcdsp_mips.h
  • [DH] libavcodec/mips/hevcdsp_msa.c
  • [DH] libavutil/mips/generic_macros_msa.h