Recherche avancée

Sur d’autres sites (12347)

• How to effectly record and encode from udp stream(4K HECV) in real time with ffmpeg ?

  25 janvier 2021, par Sa Mei

  I have a serious problem about ffmpeg to solve.
My task is to record from udp stream(4K HECV) and encode it to a mxf file.
My CPU is Intel(R) Xeon(R) Gold 5122 CPU@3.60GHz
The situation of CPU when it is recording from udp stream

  


  The situation of the udp stream

  


  The ffmpeg I used from https://github.com/BtbN/FFmpeg-Builds/commit/86af523883173be93c69d1170d1f78f79dc5e9f8 .
The command I used is :
ffmpeg -y -threads 6 -i "udp ://@225.1.2.150:6150 ?overrun_nonfatal=1&fifo_size=50000000" -threads 32 -qscale:v 2 -alternate_scan 1 -f mxf "G :\4k.xmf"

  


  Now the speed is lower than 1.0x after running for a while(about 10minutes). Maybe this is due to the temperature of the cpu gradually increasing.
The picture above displays the performance of CPU when we specify threads=6 for decoding and threads=32 for encoding.
I found that the speed would be 1.0x if I just recorded it to a .hecv file. But now I want to encode the stream to a .mxf file in real time. But as you can see, if I tried to encode it in real time, the speed of decoding and encoding would always be lower than 1.0x (around 0.98x). After running this command for about 3 hours, the recording and encoding process will be stopped.

  


  How to solve it ? I expect that the speed is 1.0x by speeding up encoding or other ways.
Or anyone knows that how to record the udp stream without re-encoding to a .hecv file and meanwhile encode the .hecv file to a .mxf file ?

  


• Anomalie #3185 (Nouveau) : Problème avec les hooks de SVN sur la zone

  13 mars 2014, par Sylvain Lesage

  Salut,

  j’ai foiré un commit (http://zone.spip.org/trac/spip-zone/changeset/81171/_plugins_/tickets/trunk), j’ai envoyé sans message.

  Pour récupérer le coup, j’ai tenté de faire :

      svn propedit -r 81171 —revprop svn:log
  

  et de rentrer le message, mais je reçois

      svn : Revprop change blocked by pre-revprop-change hook (exit code 1) with output :
      /var/svn-repos/spip-zone/hooks/pre-revprop-change : 108 : /svnlook : not found
      /var/svn-repos/spip-zone/hooks/pre-revprop-change : 109 : /svnlook : not found
      /var/svn-repos/spip-zone/hooks/pre-revprop-change : 110 : cannot open 0 : No such file
      /var/svn-repos/spip-zone/hooks/pre-revprop-change : 110 : diffSec : not found
      Changing svn:log can only be performed by the original submitter 3 hours from commit.
      Please contact the administrator for further assistance.
  

  J’aurais donc le droit de changer mon message durant les 3 heures qui suivent le commit, mais ça ne marche pas. Est-il possible de régler le problème ?

  Pour info, le message du commit est :

  tickets - config des objets qu’on peut lier aux tickets.
  Et fonction d’autorisation pour "associertickets".
  
  Par défaut, aucun type d’objet ne peut être lié aux tickets
  
  (tous desactivés). A noter : a priori, on n’interdit pas
  
  de lier des tickets à d’autres tickets.
  

• Correcting errors and inefficiency when concatenating hundreds of clips with time offsets in FFMPEG

  16 juillet 2023, par Timmortal

  I am attempting to automate multicam editing with FFMPEG. Basically there is some number of time-synced videos, typically up to 7. There is also a list of "clips" from the source videos (e.g. Camera 1 from 0-4sec, Camera 2 from 4-5.5sec, Camera 1 from 5.5-8sec). I have tried two methods to render a final video : overlay and concat and I have not had success with either.

  


  Attempted Method 1 : Overlays

  


  The idea here was for each source video to be an input, then create a large filter of overlays to take place each cut/clip at the correct time. The audio is given as the first input and a black screen is given as the second input.

  


  FFMPEG command :

  


  ffmpeg -y -i audio.flac -f lavfi -i color=c=black:s=1920x1080 \
  -i video1.mp4 -i video2.mp4 -i video3.mp4 -i video4.mp4 -i video5.mp4 \
  -filter_complex_script ffmpeg_filters.txt -map "[edit289]" -map 0:a \
  -vcodec libx264 -c:a copy -t 4629 "output.mp4"



  


  Example ffmpeg_filters.txt :

  


  [1:v][2:v]overlay=enable='between(t,0,4.99229)'[edit1];
[edit1][3:v]overlay=enable='between(t,4.99229,10.0078)'[edit2];
[edit2][2:v]overlay=enable='between(t,10.0078,14.0016)'[edit3];
[edit3][5:v]overlay=enable='between(t,14.0016,15.9985)'[edit4];
...
[edit287][2:v]overlay=enable='between(t,4503,4624)'[edit288];
[edit288][4:v]overlay=enable='between(t,4624,4629.99)'[edit289]


  


  The issue here is that it renders at something like 0.04x speed. The final video is something like 1-2 hours, so it would take well over 24 hours to render. This seems absurdly slow. Additionally the documentation specifically says You can chain together more overlays but you should test the efficiency of such approach. So perhaps this is not a good way to do it. Is there any way to speed this method up ?

  


  Attempted Method 2 : Render Clips and Concatenate

  


  Since the first method was proving to be far too slow, I attempted to render each clip into its own file named edit###.mp4 and then concatenate them, but I ran into issues there, as well.

  


  Rendering clips to files (with no audio) :

  


  ffmpeg -y -i video1.mp4 -ss 0 -t 4.99229 -an -c:v libx264 edit000.mp4
ffmpeg -y -i video2.mp4 -ss 4.99229 -t 5.01551 -an -c:v libx264 edit001.mp4
ffmpeg -y -i video1.mp4 -ss 10.0078 -t 3.99383 -an -c:v libx264 edit002.mp4
...
ffmpeg -y -i video3.mp4 -ss 4624 -t 209.001 -an -c:v libx264 edit288.mp4


  


  This appears to mostly work, however, some of the resulting files are under 1K and are not valid video files. I believe they may be too short. I can work around that, so I'm not worried about that part.

  


  Concatenating clips :

  


  ffmpeg -y -i audio.flac -f lavfi -i color=c=black:s=1920x1080 -safe 0 \
  -f concat -i input_clips.txt -filter_complex_script clip_filters.txt \
  -map [0:a] -map "[outv]" -c:v libx264 -t 4833 -c:a aac output_clips.mp4


  


  Since the list of input files is so long, I put them into input_clips.txt. clip_filters.txt contains all the time offsets for each input file.

  


  input_clips.txt

  


  file 'edit000.mp4'
file 'edit001.mp4'
file 'edit002.mp4'
...
file 'edit288.mp4'


  


  clip_filters.txt

  


  [2:v]setpts=PTS-STARTPTS+0/TB[v0];
[3:v]setpts=PTS-STARTPTS+4.99229/TB[v1];
[4:v]setpts=PTS-STARTPTS+10.0078/TB[v2];
[5:v]setpts=PTS-STARTPTS+14.0016/TB[v3];
...
[290:v]setpts=PTS-STARTPTS+4624/TB[v288];
[v0][v1][v2][v3]...[v290]concat=n=289:v=1[outv]


  


  This call causes an error :

  


  ...
Input #2, concat, from 'input_clips.txt':
  Duration: N/A, start: 0.000000, bitrate: 4781 kb/s
  Stream #2:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 4781 kb/s, 59.94 fps, 59.94 tbr, 60k tbn
    Metadata:
      handler_name    :  GoPro AVC
      vendor_id       : [0][0][0][0]
      encoder         : Lavc60.2.100 libx264
      timecode        : 10:20:07:10
  Stream #2:1: Unknown: none
Invalid file index 3 in filtergraph description [2:v]setpts=PTS-STARTPTS+0/TB[v0];
[3:v]setpts=PTS-STARTPTS+4.99229/TB[v1];
[4:v]setpts=PTS-STARTPTS+10.0078/TB[v2];
[5:v]setpts=PTS-STARTPTS+14.0016/TB[v3];
...


  


  Is it having problems reading in the 'input_clips.txt' or something ? It's not clear to me what is causing the errors. I have tried using full paths, relative paths, no paths (as shown), and using file file:edit###.mp4 syntax.

  


  Bottom Line

  


  

  • Since neither of these methods have been too successful, is there a better way to go about rendering these time-offset cuts to a single video ?

  


  • Is there any way to speed up the overlay render ?

  


  • What is causing the error in the concat method ?