Recherche avancée

Sur d’autres sites (8160)

• when concatenating video segments ffmpeg shows error : "Media type mismatch between the parsed_overlay_20"

  27 janvier 2018, par user2642511

  773/5000
  I’m trying to apply a scaling and chromakey effect to different segments of a video and then combine those segments again into one.

  To improve the time and performance I have developed a program that creates all the filters in a single command.

  The plan is simple, I have a video * .mov recorded with a green screen and a background * .jpg,

  1. I first prepare a couple of backgrounds with blur effect from the JPG image
  2. I then apply chromakey to make the green part of the video transparent
  3. I trim the video to which I applied the chromakey in several time segments and to each segment I applied a scale and crop and I overlay it to one of the backgrounds prepared in step 1
  4. Concatenate all segments already processed.

  When I execute the resulting command it gives me the error

  the command is this :

  ffmpeg -i "C:\ffmpeg\pruebas\FFBlue_ProjectsFiles\chroma\green1.mov" -i C:\ffmpeg\pruebas\FFBlue_ProjectsFiles\fondos\sc.jpg -filter_complex " [1:v]scale=iw*3:-1,crop=w=iw/3:h=ih/3:y=(ih-oh)/3:x=((iw-ow)/2)+(ow/2-ow/3),boxblur=7:2[fondo_3IZQ] ; [1:v]scale=iw*4:-1,crop=w=iw/4:h=ih/4:y=(ih-oh)/3:x=(in_w-out_w)/2,boxblur=6:2[fondo_4CEN] ; [1:v]scale=iw*5:-1,crop=w=iw/5:h=ih/5:y=(ih-oh)/3:x=((iw-ow)/2)+(ow/2-ow/3),boxblur=5:2[fondo_5IZQ]  ; [0]chromakey=color=#83BD46:similarity = 0.1 : blend = 0.05,selectivecolor=reds=0 0 0 -1:yellows=0 0.1 0 -0.5:greens=0 0 -1 0:whites=0 0 0 -0.7 [vid]  ;  [vid] trim=start=0:duration=0,setpts=PTS-STARTPTS,scale=iw*4:-1,crop=w=iw/4:h=ih/4:y=(ih-oh)/3:x=((iw-ow)/2)+(ow/2-ow/3)[vid_0] ; [fondo_4CEN][vid_0]overlay[toma_0] ; [vid] trim=start=0:duration=3.41933,setpts=PTS-STARTPTS,scale=iw*3:-1,crop=w=iw/3:h=ih/3:y=(ih-oh)/3:x=(in_w-out_w)/2[vid_1] ; [fondo_3IZQ][vid_1]overlay[toma_1] ; [vid] trim=start=3.41932988166809:duration=2.85067,setpts=PTS-STARTPTS,scale=iw*5:-1,crop=w=iw/5:h=ih/5:y=(ih-oh)/3:x=(in_w-out_w)/2[vid_2] ; [fondo_5IZQ][vid_2]overlay[toma_2]  ; [toma_0] [toma_1] [toma_2] concat=n=3:v=1:a=1:unsafe=1 [v_concatenado][a_concatenado]" -map [v_concatenado]  -map [a_concatenado] "C:\ffmpeg\pruebas\FFBlue_ProjectsFiles\chroma\green1_FINAL.mov"

  when I execute it ffmpeg says :

  [Parsed_overlay_20 @ 0000000000404100] Media type mismatch between the 'Parsed_o
  
  verlay_20' filter output pad 0 (video) and the 'Parsed_concat_26' filter input p
  
  ad 1 (audio)
  
  [AVFilterGraph @ 0000000003527a00] Cannot create the link overlay:0 -> concat:1
  
  Error initializing complex filters.
  
  Invalid argument

• Delay in setting RTP packets using FFMpeg [on hold]

  25 janvier 2018, par rurtle

  So, I’m trying to stream video using FFMpeg from my embedded box to VLC media player on a PC. While doing so, I’m noticing lots of video freezing. VLC is reporting -
  pulse audio output debug: underflow. I’m using the following command to start streaming with FFMpeg -

  ./ffmpeg -stream_loop -1 -re -i generic.ts -acodec copy -vcodec copy -f rtp_mpegts rtp://239.224.0.1:5000?pkt_size=200

  When I set the pkt_size to 400, streaming performance is a lot worse. FFMpeg version : 3.4.

  Accidentally, I found that if I start ping from PC to my box, the performance improves dramatically. I am using Linux on the dev box.

  So, my questions are -

  1. Is there any command line option that I can use on FFMpeg to improve streaming ?
  2. How ping can affect the streaming performance ?

  Thanks in advance !

• Why is ffmpeg transcoding speed going down over time ?

  24 mars 2021, par Nikola R.

  I'm executing basic ffmpeg command to transcode input MP4 video to output MP4 video (both using H264 as video codec, and stripping out audio, for simplicity) :

  



  ffmpeg -i input-video.mp4 -b:v 20000k -an -vcodec libx264 output-video.mp4


  



  Transcoding is initially pretty fast (around 60-70 fps for first 20 or so frames), and then starts dropping steadily, ending at around 30 fps after 5000 frames.

  



  Is this inherent behavior ? If so, why does it happen ?
Also, is there any better option for the command line that would improve speed (besides using -threads) ?

  



  Would it be better to cut the input video and process it as smaller chunks, getting overall higher speed per sequence ? (I'm afraid that chunking might affect encoder's RD optimization)