Recherche avancée

Sur d’autres sites (15582)

• Android sws_scale RGB Frame taking long time and cause of latency in the video

  17 avril 2018, par AJit

  I am reading frames from FFMPEG and try to directly draw to surface window in Native android, If i scale image to exact size what we are getting from camera and apply YUV420P to RGBA it take 1ms to scale through av_image_fill_arrays but if i try to scale image what i need for surface, then i take 25 to 30ms to scale same frame. so latency is the problem.

  In below example getting YUV420P pixel format.

  Low latency :[ 1ms by sws_scale]

  swsContext = sws_getContext(videoCodecContext->width,
  
                                      videoCodecContext->height,
  
                                      videoCodecContext->pix_fmt,
  
                                      videoCodecContext->width,
  
                                      videoCodecContext->height,
  
                                      AV_PIX_FMT_RGB0,
  
                                      SWS_FAST_BILINEAR, NULL, NULL, NULL);
  
  av_image_fill_arrays()
  
  av_read_frame()
  
  avcodec_decode_video2(
  
  sws_scale(swsContext,
  
            (const uint8_t *const *) videoFrame->data,
  
            videoFrame->linesize,
  
            0,
  
            videoCodecContext->height,
  
            pictureFrame->data,
  
            pictureFrame->linesize);
  
  ANativeWindow_lock()
  
  Write all buffer bytes to window.
  
  ANativeWindow_unlockAndPost()

  Low latency :[ 30ms by sws_scale]

  [videoContext Width: 848 Height: 608]
  
  swsContext = sws_getContext(videoCodecContext->width,
  
                                      videoCodecContext->height,
  
                                      videoCodecContext->pix_fmt,
  
                                      1080,
  
                                      608,
  
                                      AV_PIX_FMT_RGB0,
  
                                      SWS_FAST_BILINEAR, NULL, NULL, NULL);

  Whenever we change context width and height other then videoContext it will take more then 30ms and we are delaying the video.

  TRY 1 : Pass the buffer from JNI to Java and create bitmap there to scale later on but createBitmap itself take 500ms so no useful.

  TRY 2 : Direct YUV420P to RGB conversion. still long time then sws_scale.

  TRY 3 : Direct write YUV to window bites but it show without color(If anyone have solution here will might helpful).

  TRY 4 : Use yuvlib, no luck.

  TRY 5 : Different color combinations and flags in swsContext.

  Any help would appreciated.

• Detection of virtual background on video using ffmpeg

  28 juillet 2021, par Marcos G

  I am trying with ffmpeg to detect the use of a virtual background on a video, like the ones used in Google Meet. I got some ideas, but none seem to work :

  


  

  • Egde color : When using a chroma key you can get shades of green/blue on the outline of the subject. This is called spill, and can be detectable, but gets discarded by the fact that you dont need a chroma key to fake a background (example : Google Meet).

  


  • Still image : Most of virtual backgrounds are a still image pasted behind the subject. The problem with detecting this is that most of the real backgrounds also are like still images, without much movement.

  


  • Blur : When faking a background without a chroma key the outline of the subject becomes very blurry (this is more noticeable when the subject moves), but I can't find a way to detect it using ffmpeg.

  


  


  How can I do this ? I'm open to trying other tecniques such as AI.

  


  Thanks in advance.

  


• Stop ffmpeg from concealing corrupt frames

  22 mai 2021, par Dominic Mason

  To those who know the answer...

  


  I've been piping ffmpeg to aomenc quite successfully. Problem is, I'm sometimes getting source files for ffmpeg with false I-frames. I've loaded the files into virtualdub, and got the same result. There are some dummy frames, usually fake I-frames in a few of the files I have. So obviously, I want ffmpeg to simply drop such frames. I added the -err_detect aggressive -fflags discardcorrupt flags, but ffmpeg isn't having it. At the front of one vid I have a false I frame, but instead of dropping it I get :

  


  [h264 @ 0000000002ab8c00] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame


  


  The result is I have a grey colored frame at the front of the video. So, I've read the other answers. Is there any other way than discardcorrupt of forcing ffmpeg to automatically drop these frames, or do I have to manually remove them ? I'm using a windows build of ffmpeg from gyandev in case that matters, compiled about a month ago.