Recherche avancée

Sur d’autres sites (9132)

• x86 : simple_idct : 12bits versions

  12 octobre 2015, par Christophe Gisquet

  x86 : simple_idct : 12bits versions
  On 12 frames of a 444p 12 bits DNxHR sequence, _put function :
  
  C :         78902 decicycles in idct,  262071 runs,     73 skips
  
  avx :       32478 decicycles in idct,  262045 runs,     99 skips
  Difference between the 2 :
  
  stddev :    0.39 PSNR:104.47 MAXDIFF :    2
  This is unavoidable and due to the scale factors used in the x86
  
  version, which cannot match the C ones.
  In addition, the trick of adding an initial bias to the input of a
  
  pass can overflow, as the input coefficients are already 15bits,
  
  which is the maximum this function can handle.
  Overall, however, the omse on 12 bits samples goes from 0.16916 to
  
  0.16883. Reducing rowshift by 1 improves to 0.0908, but causes
  
  overflows.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/x86/idctdsp_init.c
  • [DH] libavcodec/x86/simple_idct.h
  • [DH] libavcodec/x86/simple_idct10.asm

• Merge branch ’scale-filter-factor’ of https://github.com/lkiesow/FFmpeg

  25 janvier 2014, par Michael Niedermayer

  Merge branch ’scale-filter-factor’ of https://github.com/lkiesow/FFmpeg
  * ’scale-filter-factor’ of https://github.com/lkiesow/FFmpeg:
  
    Documentation for scale filter factor
  
    Documentation for scale filter factor
  
    Fixed factor for scale filter
  
    Factors for scale filter
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] doc/filters.texi
  • [DH] libavfilter/vf_scale.c

• Why does ffmpeg hang indefinitely when composing videos ?

  11 octobre 2022, par Brendan Hill

  I am executing ffmpeg commands in a Java microservice (which runs dockerised in kubernetes in a temporary pod created by KEDA from an Amazon SQS queue... but unlikely to be relevant).

  


  About 30% of the time, the ffmpeg process hangs indefinitely :

  


  
/usr/local/bin/ffmpeg 
     -i /tmp/transcode-3b928f5f-3cd9-4cd6-9175-b7c1621aa7ce13592236077853079159/person1.mkv 
     -i /tmp/transcode-3b928f5f-3cd9-4cd6-9175-b7c1621aa7ce13592236077853079159/person2.mkv
     -filter_complex [0:v][1:v]hstack=inputs=2[v];[0:a]aresample=async=1000[0sync];[1:a]aresample=async=1000[1sync];[0sync][1sync]amix[a] 
     -map [v] 
     -map [a] 
     -c:v libx264 
     -crf 18 
     -ac 2 
     -vsync 1 
     -r 25 
     -shortest /tmp/transcode-3b928f5f-3cd9-4cd6-9175-b7c1621aa7ce13592236077853079159/composed.mp4



  


  This causes the Java code to wait indefinitely :

  


  
        Process proc = Runtime.getRuntime().exec(cmd);

        StreamConsumer outConsumer = new StreamConsumer(proc.getInputStream(), stdout);
        StreamConsumer errConsumer = new StreamConsumer(proc.getErrorStream(), stderr);

        // execute data read/write in separate threads
        outExecutor.submit(outConsumer);
        errorExecutor.submit(errConsumer);

        proc.waitFor() // Hangs indefinitely, with ~30% probability



  


  It is not specifically about the video files because they generally work on retry (with similar 30% failure probability so sometimes several retries are necessary). Of course, since it hangs indefinitely instead of exiting with failure, it has to wait hours before we risk another retry.

  


  


  1. Why is ffmpeg hanging indefinitely and how to fix ?

     


  


  2. Can I get ffmpeg to fail early instead of hanging indefinitely (so I can trigger retry immediately) ?

     


  


  3. I see many questions and posts about ffmpeg hanging indefinitely. Is ffmpeg inherently unstable ?