Recherche avancée

Sur d’autres sites (4856)

• avfilter/vf_bwdif_cuda : CUDA accelerated bwdif deinterlacer

  30 août 2019, par Philip Langdale

  avfilter/vf_bwdif_cuda : CUDA accelerated bwdif deinterlacer
  I've been sitting on this for 3 1/2 years now(!), and I finally got
  
  around to fixing the loose ends and convincing myself that it was
  
  correct. It follows the same basic structure as yadif_cuda, including
  
  leaving out the edge handling, to avoid expensive branching.
  

  • [DH] Changelog
  • [DH] configure
  • [DH] doc/filters.texi
  • [DH] libavcodec/version.h
  • [DH] libavfilter/Makefile
  • [DH] libavfilter/allfilters.c
  • [DH] libavfilter/vf_bwdif_cuda.c
  • [DH] libavfilter/vf_bwdif_cuda.cu

• avformat/mov : avss box should be AV_CODEC_ID_CAVS

  7 juillet 2023, par Zhao Zhili

  avformat/mov : avss box should be AV_CODEC_ID_CAVS
  I cannot find the spec, but according to the original commit
  
  d4fdba0df71, it's CAVS. e571305a714 changed it to AVS by
  
  accident. Ten years on, nothing happened. We still have the
  
  sample [1], however, since there is no cavs_mp4tofoobar bsf, the
  
  cavs decoder doesn't work. I don't know if there is any use case.
  [1] https://samples.ffmpeg.org/AVS/AVSFileFormat/AVSFileFormat.mp4
  Signed-off-by : Zhao Zhili <zhilizhao@tencent.com>
  

  • [DH] libavformat/mov.c

• Of ctors and dtors

  18 février 2011, par Multimedia Mike — Programming, Sega Dreamcast

  I haven’t given up on the Sega Dreamcast programming. I was able to compile a bunch of homebrew code for the DC many years ago and I can’t make it work anymore. Again, I was working with a purpose-built, open source RTOS named KallistiOS (or KOS). I can make the programs compile but not run. I had ELF files left over from years ago which still executed. But when I tried to build new ELF files, no luck— the programs crashed before even reaching my main() function.

  I found the problem : ELF files are comprised of a number of sections and 2 of these sections are named ’.ctors’ and ’.dtors’ which stand for constructors and destructors. The KOS RTOS performs a manual traversal of .ctors section during program initialization and this is where things go bad. The traversal code doesn’t seem to account for a .ctors section that only contains a single entry. I commented out the function that does the traversal and programs started to work, at least until it was time to exit the program and return control to the program loader. That’s when the counterpart .dtors section traversal code ran and demonstrated the same problem. I’ll exhibit the problematic code at the end of this post.

  So I’m finally tinkering with Sega Dreamcast programming once again and with a slightly better grasp of software engineering than the first time I did this.

  Portable and Compatible C ?
  If nothing else, this low-level embedded stuff exposes you to some serious toolchain arcana, the likes of which you will likely never see working strictly in the desktop arena.

  Still, this exercise makes me wonder why C code from a decade ago doesn’t compile reliably now. Part of it is because gcc has gotten stricter about the syntax it will accept. In the case of this specific crashing problem, I suspect it comes down to a difference in the way the linker generates the final ELF file. I’ve written a list of items I have had to modify in the KOS codebase in order to get it to compile on more recent gcc versions. I wonder if it would be worth publishing the specifics, or if anyone would ever find the information useful ? Oh, who am I kidding ? Of course I’ll write it up, perhaps publish a new version of the code, if only because that’s the best chance I have of finding my own work again some years down the road.

  Problematic C Code
  See if this code makes any sense to you. It somehow traverse a list of 32-bit function pointers (in different directions, depending on constructors or destructors), executing each in turn. However, it appears to fall over if the list of pointers consists of a single entry.
  

  PLAIN TEXT

  C :

  1. typedef void (*fptr)(void) ;
  2.  
  3. static fptr ctor_list[1] __attribute__((section(".ctors"))) = { (fptr) -1 } ;
  4. static fptr dtor_list[1] __attribute__((section(".dtors"))) = { (fptr) -1 } ;
  5.  
  6. /* Call this to execute all ctors */
  7. void arch_ctors() {
  8.     fptr *fpp ;
  9.  
  10.     /* Run up to the end of the list (defined by crtend) */
  11.     for (fpp=ctor_list + 1 ; *fpp != 0 ; ++fpp)
  12.          ;
  13.  
  14.     /* Now run the ctors backwards */
  15.     while (—fpp> ctor_list)
  16.         (**fpp)() ;
  17. }
  18.  
  19. /* Call this to execute all dtors */
  20. void arch_dtors() {
  21.     fptr *fpp ;
  22.  
  23.     /* Do the dtors forwards */
  24.     for (fpp=dtor_list + 1 ; *fpp != 0 ; ++fpp )
  25.         (**fpp)() ;
  26. }