Recherche avancée

Sur d’autres sites (5269)

• Support building C++ files with MSVC

  13 avril 2017, par Aaron Levinson

  Support building C++ files with MSVC
  Made appropriate changes to be able to successfully
  
  build C++ files using a Visual C++ build on Windows.
  Based on an earlier patch by Kyle Schwarz.
  Comments :
  — compat/w32pthreads.h : Made appropriate changes to w32pthreads.h to
  
     get it to build when it is being included in a C++ file and built
  
     with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
  
     described above.
  — configure :
  
  a) Now calling set_ccvars CXX to cause the various CXX_ variables to
  
     be setup properly.  For example, with MSVC (Microsoft Visual C++),
  
     this causes CXX_O to be set to -Fo$@ instead of using the default
  
     value.  The default value does not work with Visual C++.  This
  
     change will also have the impact of correcting CXX_O (and possibly
  
     CXX_C) for other compilers, although this is really only relevant
  
     for the Intel compiler, in addition to MSVC.
  
  b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
  
     currently only relevant for building the
  
     Blackmagic/Decklink-related files under avdevice.
  Signed-off-by : Hendrik Leppkes <h.leppkes@gmail.com>
  

  • [DH] compat/w32pthreads.h
  • [DH] configure

• Working directory in Dockerfile is not what is expected to be

  31 mai 2022, par user1765862

  I have following Dockerfile

  


  FROM public.ecr.aws/lambda/dotnet:6 AS base

FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim as build
WORKDIR /src
COPY ["AWSServerless.csproj", "AWSServerless/"]
RUN dotnet restore "AWSServerless/AWSServerless.csproj"

WORKDIR "/src/AWSServerless"
COPY . .
RUN dotnet build "AWSServerless.csproj" --configuration Release --output /app/build

FROM build AS publish

RUN apt-get update && apt-get install -y apt-utils libgdiplus libc6-dev

RUN apt-get install -y ffmpeg

RUN dotnet publish "AWSServerless.csproj" \
            --configuration Release \ 
            --runtime linux-x64 \
            --self-contained false \ 
            --output /app/publish \
            -p:PublishReadyToRun=true  

FROM base AS final
WORKDIR /var/task

CMD ["AWSServerless::AWSServerless.LambdaEntryPoint::FunctionHandlerAsync"]
COPY --from=publish /app/publish .


  


  As per ffmpeg docs In order to use ffmpeg I need to set its binary folder
for example with

  


  {
  "BinaryFolder": "/var/task",
  "TemporaryFilesFolder": "/tmp"
}


  


  Error

  


  


  An error occurred trying to start process './ffmpeg' with working
directory '/var/task'. No such file or directory

  


  


  What is the working directory here ?

  


  Update :
Actual error is being thrown when I try to execute following command (FFMpegCore package) from my api controller

  


  public class MyController : ControllerBase&#xA;{&#xA;    public async Task<string> Get()&#xA;    {    &#xA;         await FFMpegArguments&#xA;               .FromPipeInput(new StreamPipeSource(myfile))&#xA;               .OutputToPipe(new StreamPipeSink(outputStream), options => options&#xA;                  .WithVideoCodec("vp9")&#xA;                  .ForceFormat("webm"))&#xA;                  .ProcessAsynchronously();&#xA;         ...&#xA;    }    &#xA;}&#xA;</string>

  


• avutil/libm : correct isnan, isinf compat hacks

  15 novembre 2015, par Ganesh Ajjanagadde

  avutil/libm : correct isnan, isinf compat hacks
  isnan and isinf are actually macros as per the standard. In particular,
  
  the existing implementation has incorrect signature. Furthermore, this
  
  results in undefined behavior for e.g double values outside float range
  
  as per the standard.
  This patch corrects the undefined behavior for all usage within FFmpeg.
  Note that long double is not handled as it is not used in FFmpeg.
  
  Furthermore, even if at some point long double gets used, it is likely
  
  not needed to modify the macro in practice for usage in FFmpeg. See
  
  below for analysis.
  Getting long double to work strictly per the spec is significantly harder
  
  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
  
  extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
  
  On the other hand, any potential future usage of long double is likely
  
  for precision (when a platform offers extra precision) and not for range, since
  
  the range anyway varies and is not as portable as IEEE 754 single/double
  
  precision. In such cases, the implicit cast to a double is well defined
  
  and isinf and isnan should work as intended.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/libm.h