Recherche avancée

Sur d’autres sites (10261)

• Video getting darker after Chromakey overlay with FFMPEG

  22 octobre 2020, par João Raimundo

  I'm trying to use FFMPEG to programatically put an overlay with greenscreen, and I'm using the following command :

  


  ffmpeg -i bg.mp4 -i gs.mp4 -filter_complex "[1:v]chromakey=0x1aa700:0.18:0.01 [ckout];[0:v][ckout]overlay[out]" -preset ultrafast -map "[out]" output.mp4


  


  My problem is that, in background videos bigger than the video with chromakey when the video with chromakey ends, the output video gets darker on black (depending on blend values), as seen in this video.

  


  The idea is to use this command with Python, so, if you know another way to remove chromakey and overlay vídeos with Python, I would like to know !

  


  Thank you in advance !

  


• avcodec/movtextenc : Simplify writing to AVBPrint

  15 octobre 2020, par Andreas Rheinhardt

  avcodec/movtextenc : Simplify writing to AVBPrint
  The mov_text encoder uses an AVBPrint to assemble the subtitles ;
  
  yet mov_text subtitles are not pure text ; they also have a binary
  
  portion that was mostly handled as follows :
      uint32_t size = /* calculation */ ;
  
      size = AV_RB32(&size) ;
  
      av_bprint_append_data(bprint, (const char*)&size, 4) ;
  Here AV_RB32() is a no-op on big-endian systems and a LE-BE swap
  
  on little-endian systems, making the output endian-independent.
  Yet this is ugly and unclean : On LE systems, the variable size from
  
  the snippet above won't contain the correct value any more. Furthermore,
  
  using this pattern leads to lots of small writes to the AVBPrint.
  This commit therefore changes this to using a temporary buffer instead :
      uint8_t buf[4] ;
  
      AV_WB32(buf, /* size calculation */) ;
  
      av_bprint_append_data(bprint, buf, 4) ;
  This method also allows to use bigger buffers holding more than one
  
  element, saving calls to av_bprint_append_data() and reducing codesize.
  Reviewed-by : Philip Langdale <philipl@overt.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/movtextenc.c

• avcodec/movtextdec : Fix immediately adjacent styles

  17 octobre 2020, par Andreas Rheinhardt

  avcodec/movtextdec : Fix immediately adjacent styles
  The checks for whether a style should be opened/closed at the current
  
  character position are as follows : A variable entry contained the index
  
  of the currently active or potentially next active style. If the current
  
  character position coincided with the start of style[entry], the style
  
  was activated ; this was followed by a check whether the current
  
  character position coincided with the end of style[entry] ; if so, the
  
  style was deactivated and entry incremented. Afterwards the char was
  
  processed.
  The order of the checks leads to problems in case the endChar of style A
  
  coincides with the startChar of the next style (say B) : Style B was never
  
  opened. When we are at said common position, the currently active style
  
  is A and so the start pos check does not succeed ; but the end pos check
  
  does and it closes the currently active style A and increments entry.
  
  At the next iteration of the loop, the current character position is
  
  bigger than the start position of style B (which is style[entry]) and
  
  therefore the style is not activated.
  The solution is of course to first check for whether a style needs to be
  
  closed (and increment entry if it does) before checking whether the next
  
  style needs to be opened.
  Reviewed-by : Philip Langdale <philipl@overt.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/movtextdec.c