Recherche avancée

Sur d’autres sites (10625)

• Nix package : Pass build flag —extra-cflags to ffmpeg at compile time

  13 mai 2024, par catleeball

  I'm a little inexperienced with Nix and NixOS and am struggling a bit with this ffmpeg source build. Any advice is appreciated !

  


  Goal

  


  Build ffmpeg from source with --extra-cflags="-pipe -O3 -march=znver3 -ffat-lto-objects", ideally using a flake or overlay or similar so that I can build off the existing ffmpeg nix package and maybe even reproducible builds.

  


  Attempts

  


  I've been trying to follow different advice I've seen online, but looking at ffmpeg in nixpkgs, I'm not sure what I could patch or override. Since configureFlags happens inside the stdenv.mkderivation block, when I try to override it, it doesn't seem to have scope into this variable (and since the derivation explicitly sets onfigurePlatforms = [];, I'm not sure if that would clobber the override changes unless I tried to override the whole long derivation).

  


  Looking at the ffmpeg configure script, it seemed like environment variable cflags / cxxflags won't be respected, but it will take them from the --extra-cflags argument, but I could be missing something.

  


  Flake attempt

  


  Here's an example flake.nix I forked from an example I saw at this github repo

  


  {
  description = "A full build of ffmpeg, including the proprietary stuff";

  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
  inputs.flake-utils.url = "github:numtide/flake-utils";

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs {
          inherit system;
          config.allowUnfree = true;
        };

        overrides = {
          ffmpeg = pkgs.ffmpeg-full;
          # If this did work, I'm not sure how it would combine with the derivation in the existing package, e.g. if it would get overridden
          configureFlags = [ "--extra-cflags -march=znver3 -O3 -pipe -ffat-lto-objects" ];
          withHeadlessDeps = true;
          nonfreeLicensing = true;
          # more options here once things are working above
        };
      in
      rec {
        packages.ffmpeg-custom = pkgs.ffmpeg-full.override overrides;
        defaultPackage = packages.ffmpeg-custom;
      }
    );
}


  


  when building with nix profile install, I encounter the error :

  


         error: function 'anonymous lambda' called with unexpected argument 'configureFlags'

       at /nix/store/d9wpzgyjlpw1424kw2lyilah6690fnk3-source/pkgs/development/libraries/ffmpeg-full/default.nix:1:1:

            1| { lib, stdenv, buildPackages, ffmpeg, addOpenGLRunpath, pkg-config, perl, texinfo, yasm
             | ^
            2| /*


  


  presumably since configureFlags is defined in the derivation in the original package.

  


  Overlay in configuration.nix attempt

  


  I tried adding this to my /etc/nixos/configuration.nix also without success :

  


  nixpkgs.overlays = [
  (self: super: {
    ffmpeg-full = super.ffmpeg-full.override {
      configureFlags = [
        "--enable-hardcoded-tables"
        "--extra-cflags -march=znver3 -O3 -pipe -ffat-lto-objects"
      ] ++ super.ffmpeg-full.configureFlags;
    };
  })
];


  


  when building with nixos-rebuild switch I get the same error :

  


         error: function 'anonymous lambda' called with unexpected argument 'configureFlags'

       at /nix/store/amxbqlhq11xfrbs4vdsyi04fap0abx0v-nixos-23.11/nixos/pkgs/development/libraries/ffmpeg/generic.nix:3:1:

            2|
            3| { lib, stdenv, buildPackages, removeReferencesTo, addOpenGLRunpath, pkg-config, perl, texinfo, yasm
             | ^
            4|


  


  Context

  


  I have a NixOS machine that does very long-running ffmpeg encodes nearly all the time. I was hoping to rebuild headless ffmpeg with more aggressive cflags and maybe some extra options. I hope to benchmark performance differences between different builds.

  


  I'll probably use this as an excuse to also build ffmpeg with some extra nonfree dependencies too.

  


• Evolution #4280 : Affichage les états autres que "stable"

  28 janvier 2019, par RastaPopoulos ♥

  +1 c’est un super gros problème ergonomique. Je n’utilise pas souvent SVP, mais du coup même moi à chaque fois que j’y reviens je ne me souviens plus pourquoi ça fait ça et je ne comprends bien à ce qu’il se passe et si j’ai le droit de les installer. Déjà le truc de base : aucune information importante ne doit être faite uniquement par des styles graphiques, ça doit toujours être marqué explicitement. Mais en plus de ça, c’est même pas la norme graphique adapté à l’idée à véhiculer ! Grisé c’est habituellement utilisé pour indiquer un truc inactif (disabled), un truc sur lequel on ne peut PAS interagir. Alors que là il s’agit de plugin tout à fait ok avec notre version de SPIP et qu’on a le droit d’installer, donc aucun rapport.

• FPS from RTSP stream info does not match actual framerate

  17 mai 2021, par Krapow

  I have a 25FPS RTSP stream coming from an IP-camera. I can successfully display the video stream. But when analyzing the stream with ffmpeg (ffprobe actually), I observe fewer frames per second rate :

  


  $ ffprobe -rtsp_transport tcp -i rtsp://camera_ip:554/stream -select_streams v:0 -show_frames -show_entries frame=coded_picture_number,pkt_pts_time -of csv=p=0
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 640x480, 25 fps, 25 tbr, 90k tbn, 50 tbc
0.400000,0
0.080000,1
0.120000,2
0.200000,3
0.240000,4
0.320000,5
0.360000,6
0.440000,7
0.480000,8
0.560000,9
0.600000,10
0.680000,11
0.720000,12
0.800000,13
0.840000,14
0.920000,15
0.960000,16
1.040000,17
1.080000,18
1.160000,19
1.200000,20
1.280000,21
1.320000,22
1.400000,23
1.440000,24
1.520000,25
1.560000,26
1.640000,27
1.680000,28
1.760000,29
1.800000,30
1.880000,31
1.920000,32
2.000000,33


  


  We can clearly see the 80ms gap between some of the frames, resulting in a 16fps stream.

  


  I have observed the same framerate issue with GStreamer (printing information in the rtpjitterbuffer indicates the frame gap is sometimes 80ms and sometimes 40ms). But the weird thing is, I encountered the same issue with an HDMI-RJ45 decoder, and I doubt the same issue comes from 2 different devices.
I didn't get much more informations using -loglevel debug or trace.
Does anybody have an idea about what is going wrong in the stream ?

  


  (I used ffprobe 4.2.3 and the last "2021-05-09-git-8649f5dca6-full_build-www.gyan.dev" with the same results, and GStreamer 1.16.2 with a pipeline like "urisourcebin ! h264depay ! h264parse ! fakesink")

  


  EDIT : The camera skipping of frames was caused by the activation of a third stream in the options. I find it really weird that it skips exactly the same frames every seconds. However, I still haven't found the cause of the downrate on my RTSP encoder.
Anyway, this was actually hardware related and not software related.