Recherche avancée

Sur d’autres sites (6774)

• avr32 : remove explicit support

  9 juin 2024, par Rémi Denis-Courmont

  avr32 : remove explicit support
  The vendor has long since switched to Arm, with the last product
  
  reaching their official end-of-life over 11 years ago. Linux support for
  
  the ISA was dropped 7 years ago. More importantly, this architecture was
  
  never supported by upstream GCC, and the vendor fork is stuck at version
  
  4.2, which FFmpeg no longer supports (as per C11 requirement).
  Presumably, this is still the case given the lack of vendor support.
  
  Indeed all of the code being removed here consisted of inline assembler
  
  scalar optimisations. A sane C compiler should be able to perform those
  
  automatically nowadays (with the sole exception of fast CLZ detection),
  
  but this is moot as this architecture is evidently dead.
  

  • [DH] configure
  • [DH] libavcodec/avr32/mathops.h
  • [DH] libavcodec/mathops.h
  • [DH] libavutil/avr32/intreadwrite.h
  • [DH] libavutil/intreadwrite.h

• Back porting ffmpeg.dll from electron for windows xp by disassembling

  28 juillet 2024, par Oosuke Ren

  I've recently gotten into a really interesting project of having a fully functional (and as futuristic as possible) physical retro gaming machine with windows xp. I had found One Core Api that successfully works to allow for some programs to work that otherwise wouldn't have. One of them is electron (5.0.13). Thanks to a vast testing between a VM with the kernel extender and a vanilla XP, I found out that the only thing stopping me from succeeding is because it's dependent on an EXTREMELY specific version/fork of ffmpeg (Chromium fork of ffmpeg 4.1) . Due to that being a relatively old fork/version, the build tools/links for some of the stuff are nonexistent right now, so even if I do have the fork locally with all the instructions, I can't build it. (and if I do I have to patch Win Vista+ Api functions, with one custom stub dll I have)

  


  AcquireSRWLockExclusive InitializeConditionVariable SleepConditionVariableSRW InitOnceBeginInitialize InitOnceComplete InitializeSRWLock ReleaseSRWLockExclusive WakeAllConditionVariable WakeConditionVariable

  


  Since I can't custom build ffmpeg I have to patch it's calls by redirecting them to my custom dll that includes these back ported functions and more.

  


  I tried many different ways => IDA Pro, Ghidra, objconv, currently am the closest with "DLL to C"

  


  Ida Pro and Ghidra seem to not be creating assembly code that I'd be able to assemble back after patching.

  


  objconv produces a really accurate disassembly, but the issue is it doesn't have an assembler. And the produced .asm won't assemble with Fasm, masm or nasm

  


  As for DLL to C-> successfully created a quite presentable VS project, the project successfully compiles with only one warning, the byte sizes is quite similar, the problem is => the functions are getting wrongly directed (towards wrong functions in my dll- and thus the ones needed are undefined) And this is too deep to be able to tell if it's a VS version issue, wrong code implementation or if just DLL to C has wrongly disassembled the logic.

  


  Question is, is my last option remaining to manually edit the HEXES of the Import Address Table and Import Names so they get redirected ? (the problem is my knowledge in Assembly isn't too good, so I'm not sure if that's all I'd have to do, and even if so, I have a feeling I'd mess up the Virtual Addresses or something.

  


• Using SDL2 Render Pixels to create video using ffmpeg

  7 juillet 2024, par Riptide

  I made a small animation using SDL2 and I want to use ffmpeg to convert it to an h264 encoded video. I'm getting the texture RGBA pixels using SDL_RenderReadPixels and sending them to ffmpeg for rendering. The video does render, but is all messed up. The following is my code

  


  Spawning ffmpeg

  


  int child_pipe[2];

if (pipe(child_pipe) < 0) {
    perror("child_pipe");
}

printf("child_pipe[0]: %d, child_pipe[1]: %d\n", child_pipe[0], child_pipe[1]);

args.ffmpeg = &(FFMpeg){.std_in = child_pipe[WRITE_END]};

child_pid = fork();

printf("child: %d\n", child_pid);

if (child_pid == 0) {
    close(child_pipe[WRITE_END]);

    if (dup2(child_pipe[READ_END], STDIN_FILENO) < 0) {
        perror("dup2");
        return -1;
    }

    char *argv[] = {"ffmpeg",  "-loglevel", "verbose", "-y",   "-f",      "rawvideo", "-pixel_format", "rgba",      "-s",
                    "894x702", "-i",        "-",       "-c:v", "libx264", "-pix_fmt", "yuv420p",       "thing.mp4", NULL};

    int x = execvp("ffmpeg", argv);

    if (x != 0) {
        perror("execv");
        return x;
    }

    return -1;
}




  


  Here's how I render into SDL2 renderer. The rendering on SDL2 has no issues. In here I get the render pixels and send them to ffmpeg.

  


  void render_image(SDL_Renderer *renderer, int array[], size_t array_size, Image *image, FFMpeg *ffmpeg) {
    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
    SDL_RenderClear(renderer);

    for (int i = 0; i < array_size; i++) {
        paint_image_strip(renderer, image, i, array[i]);
    }

    if (ANIMATION_DELAY_MS > 0) {
        SDL_Delay(ANIMATION_DELAY_MS);
    }

    if (ffmpeg != NULL) {
        int size = image->width * image->height * sizeof(Uint32);
        Uint32 *pixels = (Uint32 *)malloc(size);

        if (pixels == NULL) {
            printf("Malloc failed. Buy more ram\n");
            return;
        }

        int ret = SDL_RenderReadPixels(renderer, NULL, SDL_PIXELFORMAT_RGBA8888, pixels, image->width * sizeof(Uint32));

        if (ret != 0) {
            fprintf(stderr, "SDL_RenderReadPixels failed: %s\n", SDL_GetError());
            free(pixels);
        }

        int n = write(ffmpeg->std_in, image->img_data, size);

        if (n < 0) {
            perror("write failed");
        }

        free(pixels);
    }

    SDL_RenderPresent(renderer);
}



  


  Here's the issue. Here is what I see in SDL2 window

  


  

  


  and this is what ffmpeg renders


  


  there are inklings of the original image here. I thought it was an issue with RGBA vs ARGB but on double checking that wasn't the case.

  


  Expecting proper ffmpeg rendering.