Recherche avancée

Sur d’autres sites (6380)

• FFmpeg decode raw buffer with avcodec_decode_video2

  29 octobre 2014, par Martin Schlott

  I am receiving a h264 stream where I at least know the size of one frame. The stream is coming in right as I can store it in a file and playback with vlc. Playing back a file is no problem for me as I include the libavformat. But libavformat gives me back an AVPacket which I can directly give to avcodec_decode_video2. In this case I got a bytestream. How can I give the raw h264 stream to the avcodec_decode_video2 ? How can I wrap my data into a AVPacket. VLC does not need to guess any data.

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

• asm SIMD sniffer

  1er août 2023, par Андрей Тернити

  There is x264.
It use a lot of x86 asm files. For example pixel-32.asm.
This files can use different SIMD instruction set : mmx, 3DNow !, sse family, others

  


  I need the simple way to automatically analyze every file. I want get which SIMD family in which file are used. How ?

  


  I think every asm file must contain information about which SIMD family it use (or information that no SIMD). Without this information it is very bad idea try to use this files...
  
I am angry, my x86 CPU support mmx and 3DNow ! only, but x264 try call sse, so I get "Illegal instruction" sometimes. I plan to make patch for x264.

  


  P.S. If you can make issues in official repo let me know.

  


  P.P.S. This thread on Doom9 (mirror).