Recherche avancée

Sur d’autres sites (8516)

• swscale/aarch64 : use multiply accumulate and increase vector factor to 4

  17 novembre 2019, par Sebastian Pop

  swscale/aarch64 : use multiply accumulate and increase vector factor to 4
  This patch implements ff_hscale_8_to_15_neon with NEON fused multiply accumulate
  
  and bumps the vectorization factor from 2 to 4.
  
  The speedup is of 25% on Graviton1 A1 instances based on A-72 cpus :
  $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null -
  
  before : t:0.040303 avg:0.040287 max:0.040371 min:0.039214
  
  after :  t:0.032168 avg:0.032215 max:0.033081 min:0.032146
  The speedup is of 39% on Graviton2 m6g instances based on Neoverse-N1 cpus :
  
  $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null -
  
  before : t:0.019446 avg:0.019423 max:0.019493 min:0.019181
  
  after :  t:0.014015 avg:0.014096 max:0.015018 min:0.013971
  Tested with `make check` on aarch64-linux.
  Signed-off-by : Sebastian Pop <spop@amazon.com>
  
  Reviewed-by : Jean-Baptiste Kempf <jb@videolan.org>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libswscale/aarch64/hscale.S

• Trying to grab video stream from a 802W device

  1er juin 2015, par brentil

  A group of us in the RC hobby forums had started trying to use a device called the 802W, it takes RCA in and then broadcasts it back out over a WiFi you connect to via an Android or iOS device. They’re typically used for backup camera addon systems for vehicles. We want to use it to do FPV (First Person Video/View) with using smartphones instead of buying more expensive FPV goggles.

  802W device example (plenty of clones online)

  http://www.amazon.com/Wireless-Backup-Camera-Transmitter-Android/dp/B00LJPTJSY

  The problem is you can only use their application WIFI_AVIN or WIFI_AVIN2 from the app stores to connect to it because they don’t publish the information about how to grab the stream data. We want to write our own apps that can use the stream to better show the information. We’ve tried using VLC to grab the stream from an Android phone or a Windows PC but we’ve had no success so far. I was hoping someone could look at the Wireshark outputs and might understand what they’re looking at better than I am. I "think" it’s a UDP multicast being broadcasted but I just don’t know enough to be sure. We’ve tried using VLC to connect to network streams directly on the device or from udp ://@ type addresses but I think part of the issue too might be we’re missing the file path of the stream file.

  Attempting to reverse engineer their code for learning purposes showed that ffmpeg is inside a compiled .so library which also seems to be where the actual connection code happens which we were unable to dig into.

  In the images 192.168.72.33 is my phone and 192.168.72.173 is the 802W device.

  Image of what I believe is a UDP broadcast of the video information.
  

  This is what the stream turns into when the device connects using the WIFI_AVIN application.
  

• 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 ?