Recherche avancée

Sur d’autres sites (6704)

• Fast green screen video processing on android device

  17 mars 2015, par Si-N

  I have written an app in iOS that takes two video sources, one with moving character on a green screen and any other video. The program then uses the GPUImage framework to add a chroma key shader via OpenGL ES 2 and then merges each frame (so the bottom frame now shows where the green pixels are) and outputs to a new video file. This happens very quickly, faster than real time.

  I have now been tasked with porting the app to Android. I thought it would be fairly straightforward. After doing some research I think I am wrong. There is an Android port of GPUImage but it does not handle video at the moment. I have done some research and come up with a very basic idea.

  I was wondering if you think this approach is feasible :

  Convert one video file to match resolution and type of other video using ffmpeg or JavaCV wrappers.

  Read frame by frame of each video using ffmpeg as MediaMetadataRetriever is very slow and convert into some RGB format. Use shader to apply chroma key effect so both frames are merged.

  Use ffmpeg to output result to a new file.

  This sounds slow, but if it sounds feasible I will try it out. I am not at all sure about making sure the 2 video resolutions / bitrate etc match. One video will be fixed at 1280 * 720 and the other video source will come from the camera on the device so will be variable. Also I think ffmpeg means using NDK which is a whole world of pain I wanted to avoid.

  I have a headache thinking about it. Any advice would be greatly appreciated.

• avcodec/tiff : Restrict tag order based on specification

  20 août 2020, par Michael Niedermayer

  avcodec/tiff : Restrict tag order based on specification
  "The entries in an IFD must be sorted in ascending order by Tag. Note that this is
  
   not the order in which the fields are described in this document."
  This way various dimensions, sample and bit sizes cannot be changed at
  
  arbitrary times which reduces the potential for bugs.
  
  The tag reading code also on various places assumes that numerically previous
  
  tags have already been parsed, so this needs to be enforced one way or another.
  If this commit causes problems with real world files which are not easy to fix
  
  then some other form of checks are needed to ensure the various dependencies
  
  in the tag reading are not violated.
  Fixes : out of array access
  
  Fixes : 24825/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6326925027704832
  Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/tiff.c

• To get OpenCV VideoWriter work across platforms consistently for MP4 container with H264 encoding

  28 mars 2019, par Moh

  I am trying to get OpenCV VideoWriter work across platform consistently for MP4 container with H246 encoding.

  Target platforms in order of importance - Ubuntu, Raspbian, OSX

  Basically, my shortcoming at this point is not understanding the relationship of FourCC code (as a parameter to OpenCV VideoWriter) to the FFMPEG backend and its requirements. I am interested to understand the game in play rather than discussing a piece of code.

  What I want to know is when I specify ’X264’ as FourCC code trying to write an x.MP4 file (FFMPEG backend) and the request is marshalled to FFMPEG what requirements/dependencies need to be satisfied by the OS for it to success.

  So far I have got my python stack writing MP4 video files across Raspbian/Ubuntu/OSX, with a hack.

  On my Raspbian stretch installation, I use 0x00000021 as the fourCC code.
  On Ubuntu (VM on OSX) and on OSX, AVC1 works.

  Days of Googling only delivered those hacks, not a good understanding of the problem.

  The x264 as FourCC code leads to one of - failure, non-portable video file + annoying FFMPEG warning.

  I am trying to get to the bottom of it.

  The code,

      #self.__fourCC = cv2.VideoWriter_fourcc('x', '2', '6', '4')
  
      self.__fourCC = cv2.VideoWriter_fourcc('a', 'v', 'c', '1')
  
      if PlatformUtils.isRunningOnRaspberryPi():
  
          self.__fourCC = 0x00000021

  I have control over the version both OpenCV and FFMPEG (if required GStreamer too). I can and have built them for Ubuntu/Raspbian.