Recherche avancée

Sur d’autres sites (4274)

• 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.

• avfilter/avf_showcqt : cqt_calc optimization on x86

  4 juin 2016, par Muhammad Faiz

  avfilter/avf_showcqt : cqt_calc optimization on x86
  on x86_64 :
  
          time    PSNR
  
  plain   3.303   inf
  
  SSE     1.649   107.087535
  
  SSE3    1.632   107.087535
  
  AVX     1.409   106.986771
  
  FMA3    1.265   107.108437
  on x86_32 (PSNR compared to x86_64 plain) :
  
          time    PSNR
  
  plain   7.225   103.951979
  
  SSE     1.827   105.859282
  
  SSE3    1.819   105.859282
  
  AVX     1.533   105.997661
  
  FMA3    1.384   105.885377
  FMA4 test is not available
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Muhammad Faiz <mfcc64@gmail.com>
  

  • [DH] libavfilter/avf_showcqt.c
  • [DH] libavfilter/avf_showcqt.h
  • [DH] libavfilter/x86/Makefile
  • [DH] libavfilter/x86/avf_showcqt.asm
  • [DH] libavfilter/x86/avf_showcqt_init.c

• swresample/resample : optimize exact_rational=on:linear_interp=on case

  24 novembre 2016, par Muhammad Faiz

  swresample/resample : optimize exact_rational=on:linear_interp=on case
  separate dsp.resample to dsp.resample_common and dsp.resample_linear
  
  and choose to call faster resample_common even when linear_interp=on
  
  when c->frac and c->dst_incr_mod are both zero
  speed up resampling when exact_rational and linear_interp are both
  
  enabled because exact_rational force c->frac and c->dst_incr_mod to
  
  be zero when soft compensation does not happen
  benchmark on exact_rational=on:linear_interp=on
  
          old     new
  
  real    8.432s  5.097s
  
  user    7.679s  4.989s
  
  sys     0.125s  0.107s
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Muhammad Faiz <mfcc64@gmail.com>
  

  • [DH] libswresample/arm/resample_init.c
  • [DH] libswresample/resample.c
  • [DH] libswresample/resample.h
  • [DH] libswresample/resample_dsp.c
  • [DH] libswresample/x86/resample_init.c