Recherche avancée

Sur d’autres sites (10914)

• NAB 2010 wrapup

  15 avril 2010

  Another year of NAB has come and gone. Making it out of Vegas with some remaining faith in humanity seems like a successful outcome. So, anything worth talking about at the show ?

  First off, there’s 3d. 3D is The Next Big Thing, and that was obvious to anyone who spent half a second on the show floor. Everything from camera rigs, to post production apps, to display technology was all 3d, all the time. I’m not a huge fan of 3d in most cases, but the industry is at least feigning interest.

  Luckily, at a show as big as NAB, there’s plenty of other cool stuff to see. So, what struck my fancy ?

  First off, Avid and Adobe were showing new versions of Media Composer and Premiere. Both sounded pretty amazing on paper, but I must say I was somewhat underwhelmed by both in reality. Premiere felt a little rough around the edges - the Mercurial Engine wasn’t the sort of next generation tech that I expected. Media Composer 5 has some nice new tweaks, but it’s still rather Avid-y - which is good for Avid people, less interesting for the rest of us.

  In other software news, Blackmagic Design was showing off some of what they’re doing with the DaVinci technology that they acquired. Software-only Da Vinci Resolve for $999 is a pretty amazing deal, and the demos were quite nice. That said, color correction is an art, so just making the technology cheaper isn’t necessarily going to dramatically change the number of folks who do it well - see Color.

  Blackmagic also has a pile of new USB 3.0 hardware devices, including the absolutely gorgeous UltraStudio Pro. Makes me pine for USB 3.0 on the mac.

  On the production side, we saw new cameras from just about everyone. To start at the high end, the Arri Alexa was absolutely stunning. Perhaps the nicest digital cinema footage I’ve seen. Not only that, but they’ve worked out a usable workflow, recording to ProRes plus RAW. At the price point they’re promising, the world is going to get a lot more difficult for RED.

  Sony’s new XDCam EX gear is another good step forward for that format. Nothing groundbreaking, but another nice progression. I was kind of hoping we’d see 4:2:2 EX gear from them, but I suppose they need to justify the disc based formats for a while longer.

  The Panasonic AG-AF100 is another interesting camera, bringing micro 4/3rds into video. The only strange thing is the recording side - AVCHD to SD cards. While I’m thrilled to see them using SD instead of P2, it sure would have been nice to have an AVCIntra option.

  Finally, Canon’s 4:2:2 XF cams are a nice option for the ENG/EFP market. Nothing groundbreaking, aside from the extra color sampling, but it’s a nice step up from what they’ve been doing.

  Speaking of Canon, it’s interesting to see the ways that the 5d and 7d have made their way into mainstream filmmaking. At one point, I thought they’d be relegated to the indie community - folks looking for nice DoF on a budget. Instead, they seem to have been adopted by a huge range of productions, from episodic TV to features. While they’re not right for everyone, the price and quality make them an easy choice in many cases.

  One of the stars of the show for me was the GoPro, a small waterproof HD camera that ships with a variety of mounts, designed to be used in places where you couldn’t or wouldn’t use a more full featured camera. No LCD, just a record button and a wide angle lens. I bought two.

  Those are the things that stand out for me. While there was plenty of interesting stuff to be seen, given the current economic conditions at the University, I wasn’t exactly in a shopping mindset. The show definitely felt more optimistic than it did last year, and companies are again pushing out new products. However, attendances was about 20% lower than 2008, and that was definitely noticeable on the show floor.

• lavu/x86 : add FFT assembly

  10 avril 2021, par Lynne

  lavu/x86 : add FFT assembly
  This commit adds a pure x86 assembly SIMD version of the FFT in libavutil/tx.
  
  The design of this pure assembly FFT is pretty unconventional.
  On the lowest level, instead of splitting the complex numbers into
  
  real and imaginary parts, we keep complex numbers together but split
  
  them in terms of parity. This saves a number of shuffles in each transform,
  
  but more importantly, it splits each transform into two independent
  
  paths, which we process using separate registers in parallel.
  
  This allows us to keep all units saturated and lets us use all available
  
  registers to avoid dependencies.
  
  Moreover, it allows us to double the granularity of our per-load permutation,
  
  skipping many expensive lookups and allowing us to use just 4 loads per register,
  
  rather than 8, or in case FMA3 (and by extension, AVX2), use the vgatherdpd
  
  instruction, which is at least as fast as 4 separate loads on old hardware,
  
  and quite a bit faster on modern CPUs).
  Higher up, we go for a bottom-up construction of large transforms, foregoing
  
  the traditional per-transform call-return recursion chains. Instead, we always
  
  start at the bottom-most basis transform (in this case, a 32-point transform),
  
  and continue constructing larger and larger transforms until we return to the
  
  top-most transform.
  
  This way, we only touch the stack 3 times per a complete target transform :
  
  once for the 1/2 length transform and two times for the 1/4 length transform.
  The combination algorithm we use is a standard Split-Radix algorithm,
  
  as used in our C code. Although a version with less operations exists
  
  (Steven G. Johnson and Matteo Frigo's "A modified split-radix FFT with fewer
  
  arithmetic operations", IEEE Trans. Signal Process. 55 (1), 111–119 (2007),
  
  which is the one FFTW uses), it only has 2% less operations and requires at least 4x
  
  the binary code (due to it needing 4 different paths to do a single transform).
  
  That version also has other issues which prevent it from being implemented
  
  with SIMD code as efficiently, which makes it lose the marginal gains it offered,
  
  and cannot be performed bottom-up, requiring many recursive call-return chains,
  
  whose overhead adds up.
  We go through a lot of effort to minimize load/stores by keeping as much in
  
  registers in between construcring transforms. This saves us around 32 cycles,
  
  on paper, but in reality a lot more due to load/store aliasing (a load from a
  
  memory location cannot be issued while there's a store pending, and there are
  
  only so many (2 for Zen 3) load/store units in a CPU).
  
  Also, we interleave coefficients during the last stage to save on a store+load
  
  per register.
  Each of the smallest, basis transforms (4, 8 and 16-point in our case)
  
  has been extremely optimized. Our 8-point transform is barely 20 instructions
  
  in total, beating our old implementation 8-point transform by 1 instruction.
  
  Our 2x8-point transform is 23 instructions, beating our old implementation by
  
  6 instruction and needing 50% less cycles. Our 16-point transform's combination
  
  code takes slightly more instructions than our old implementation, but makes up
  
  for it by requiring a lot less arithmetic operations.
  Overall, the transform was optimized for the timings of Zen 3, which at the
  
  time of writing has the most IPC from all documented CPUs. Shuffles were
  
  preferred over arithmetic operations due to their 1/0.5 latency/throughput.
  On average, this code is 30% faster than our old libavcodec implementation.
  
  It's able to trade blows with the previously-untouchable FFTW on small transforms,
  
  and due to its tiny size and better prediction, outdoes FFTW on larger transforms
  
  by 11% on the largest currently supported size.
  

  • [DH] libavutil/tx.c
  • [DH] libavutil/tx_priv.h
  • [DH] libavutil/x86/Makefile
  • [DH] libavutil/x86/tx_float.asm
  • [DH] libavutil/x86/tx_float_init.c

• Adding AY Files To The Game Music Website

  1er décembre 2013, par Multimedia Mike — General

  For the first time since I launched the site in the summer of last year, I finally added support for new systems for my Game Music Appreciation site : A set of chiptune music files which bear the file extension AY. These files come from games that were on the ZX Spectrum and Amstrad CPC computer systems.

  
   
  

  Right now, there are over 650 ZX Spectrum games in the site while there are all of 20 Amstrad CPC games. The latter system seems a bit short-changed, but I read that a lot of Amstrad games were straight ports from the Spectrum anyway since the systems possessed assorted similarities. This might help explain the discrepancy.

  Technically
  The AY corpus has always been low hanging fruit due to the fact that the site already supports the format courtesy of the game-music-emu backend. The thing that blocked me was that I didn’t know much about these systems. I knew that there were 2 systems (and possibly more) that shared the same chiptune format. Apparently, these machines were big in Europe (I was only vaguely aware of them before I started this project).

  Both the Spectrum and the Amstrad used Zilog Z-80 CPUs for computing and created music using a General Instruments synthesizer chip designated AY-3-8912, hence the chiptune file extension AY. This has 3 channels similar to the C64 SID chip. Additionally, there’s a fourth channel that game music emu calls “beeper” (and which Wikipedia describes as “one channel with 10 octaves”). Per my listening, it seems similar to the old PC speaker/honker. The metadata for a lot of the songs will specify either (AY) or (Beeper).

  Wrangling Metadata
  Large collections of AY files are easy to find ; as is typical for pure chiptunes, the files are incredibly small.

  As usual, the hardest part of the whole process was munging metadata. There seems to be 2 slightly different conventions for AY metadata, likely from 2 different people doing the bulk of the work and releasing the fruits of their labor into the wild. After I recognized the subtle differences between the 2 formats, it was straightforward to craft a tool to perform most of the work, leaving only a minimum of cleanup effort required afterwards.

  (As an aside, I think this process is called extract – transform – load, or ETL. Sounds fancy and complicated, yet it’s technically one of the first computer programming tasks I was ever paid to perform.)

  Collateral Damage
  While pushing this feature, I managed to break the site’s search engine. The search solution I developed was always sketchy (involving compiling a C program as a static binary CGI script and trusting it to run on the server). I will probably need to find a better approach, preferably sooner than later.