Recherche avancée

Sur d’autres sites (11252)

• How do I use ffmpeg to concatenate 2 videos and add a period of silence + black screen between them ?

  29 avril 2022, par masotime

  There are several existing examples, but I'd like a single command that uses complex_filter to achieve the objective without doing extra things like generating blank video / audio files.

  


  Looking around, this is the best I've come up with so far :

  


  ffmpeg -i video1.mp4 -i video2.mp4 -filter_complex "color=black:s=960x540:d=1[b0];aevalsrc=0:d=1[s0];[0:v:0][0:a:0][b0][s0][1:v:0][1:a:0]concat=n=3:v=1:a=1[outv][outa]" -map '[outv]' -map '[outa]' out.mp4


  


  My understanding of the breakdown of such a command is

  


  

  1. specify 2 inputs

  


  2. define a complex filter

  


  3. define a black video stream of duration 1s and call it b0

  


  4. define a silent audio stream of duration 1s and call it s0

  


  5. pipe it through the concat filter with

  


  


  

  • First stream : [0:v:0][0:a:0] // video1.mp4

  


  • Second stream : [b0][s0] // stuff I defined earlier

  


  • Third stream : [1:v:0][1:a:0] // video2.mp4

  


  


  

  6. define 2 output streams [outv][outa] for video and audio respectively

  


  7. combine them into out.mp4

  


  


  All file inputs are correctly 960x540, all using the same audio and video codecs but ffmpeg gives me this error and starts using 100% CPU

  


  More than 1000 frames duplicated


  


  I think there's something wrong with the streams I'm defining in the filter - what's wrong ? Do I need to specify more parameters somewhere ?

  


  EDIT : Here's a MediaInfo printout of the input video's metadata

  


  Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/iso2/mp41)
File size                                : 7.82 MiB
Duration                                 : 31 s 449 ms
Overall bit rate                         : 2 086 kb/s
Writing application                      : Lavf59.16.100

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L3@Main
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 31 s 449 ms
Bit rate                                 : 1 973 kb/s
Maximum bit rate                         : 2 000 kb/s
Width                                    : 960 pixels
Height                                   : 540 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0 (Type 0)
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.159
Stream size                              : 7.40 MiB (95%)
Writing library                          : x265 3.4+31-6722fce1f:[Mac OS X][clang 12.0.0][64 bit] 8bit+10bit+12bit
Encoding settings                        : cpuid=1111039 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=960x540 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=2000 / qcomp=0.60 / qpstep=4 / stats-write=1 / stats-read=0 / slow-firstpass / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : hvcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 31 s 449 ms
Source duration                          : 31 s 492 ms
Source_Duration_LastFrame                : -17 ms
Bit rate mode                            : Constant
Bit rate                                 : 106 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 405 KiB (5%)
Source stream size                       : 406 KiB (5%)
Title                                    : Core Media Audio
Language                                 : English
Default                                  : Yes
Alternate group                          : 1


  


• What would cause video whose position is set and played at a certain millisecond, to not align with a video trimmed to that same millisecond position ?

  2 décembre 2020, par Cha Pa

  I have developed a windows C# application that allows you to cut clips of video that is synched to a transcript.

  


  The application has a video tuner that allows you to adjust the start and stops of the clip in .1, 1, 3 seconds and gives you a short 2 second preview of the start or 2 seconds leading up to the stop as a preview. Then you can cut that video into a small clip by pressing a create clip button.

  


  Because of of the nature of the provider of the videos, these videos are typically Mpeg1 that are over an hour long and are all varying in both in width/height dimensions as well as bitrate. Changing the format is not an option.

  


  My question is this. What would cause the video player to play earlier than where the video is cut using an ffmpeg wrapper ?

  


  I have developed a test version in winform with a mediaplayer control, a version in WPF with a mediacontrol player, and another winform with a vlcwrapper. All of them start early as compared to the ffmpeg cut. All of them start at a slightly different time from each other even though they are all provided the same millisecond time stamp. In fact testing directly with setting command line position to ffplay and vlc, they have slightly different start times when using the same position and both are different then the command line cut of ffmpeg.

  


  The infuriating thing is that when I compare the ffmpegwrapper exports they are dead on with another piece of software's playback preview and clip export. Every video I clip that has a different bitrate or resolution is sightly off to a differing number of milliseconds. One video may be .4 seconds off and another is 1.1. I would assume it was a delay due to the loading of the video and I can async await somehow, or assume it was a problem with the timer, except it starts EARLY not late. All 3 demos are some variation of the code below that grabs start time and end times and calls a timer to stop the video after playing the number of milliseconds calculated between the start and end. Even more peculiar, the shorter the timer, the shorter the start time appears to be off.

  


  Any thoughts on if it is an mpeg1 mpeg2 issue or a bitrate issue I can control to be consistent between videos without re-encoding every video ? Maybe even outside the box ways to put clips to memory stream or play the temp file quickly ?

  


  private void PreviewStartButton_Click(object sender, EventArgs e)
       {
           startPosition = Convert.ToSingle(startBox.Text);
           stopPosition = startPosition + 2; //gives you your 2 second preview of the star
           mediaPlayer.Ctlcontrols.currentPosition = origStartTime;
           mediaPlayer.Ctlcontrols.play();
           StopWmpPlayerTimer();
           StartWmpPlayerTimer();
       }


  


• h264_slice : Fix return of incomplete frames from decoder

  28 juin 2018, par John Stebbins

  h264_slice : Fix return of incomplete frames from decoder
  When not using libavformat for demuxing, AVCodecContext.has_b_frames
  
  gets set too late causing the recovery frame heuristic in h264_refs to
  
  incorrectly flag an early frame as recovered.
  This patch sets has_b_frames earlier to prevent improperly flagging the
  
  frame as recovered.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_slice.c