Recherche avancée

Sur d’autres sites (10324)

• How to parallelize this for loop for rapidly converting YUV422 to RGB888 ?

  16 avril 2015, par vineet

  I am using v4l2 api to grab images from a Microsoft Lifecam and then transferring these images over TCP to a remote computer. I am also encoding the video frames into a MPEG2VIDEO using ffmpeg API. These recorded videos play too fast which is probably because not enough frames have been captured and due to incorrect FPS settings.

  The following is the code which converts a YUV422 source to a RGB888 image. This code fragment is the bottleneck in my code as it takes nearly 100 - 150 ms to execute which means I can’t log more than 6 - 10 FPS at 1280 x 720 resolution. The CPU usage is 100% as well.

  for (int line = 0; line < image_height; line++) {
  
      for (int column = 0; column < image_width; column++) {
  
          *dst++ = CLAMP((double)*py + 1.402*((double)*pv - 128.0));                                                  // R - first byte           
  
          *dst++ = CLAMP((double)*py - 0.344*((double)*pu - 128.0) - 0.714*((double)*pv - 128.0));    // G - next byte
  
          *dst++ = CLAMP((double)*py + 1.772*((double)*pu - 128.0));                                                            // B - next byte
  
  
  
          vid_frame->data[0][line * frame->linesize[0] + column] = *py; 
  
  
  
          // increment py, pu, pv here
  
  
  
      }

  ’dst’ is then compressed as jpeg and sent over TCP and ’vid_frame’ is saved to the disk.

  How can I make this code fragment faster so that I can get atleast 30 FPS at 1280x720 resolution as compared to the present 5-6 FPS ?

  I’ve tried parallelizing the for loop across three threads using p_thread, processing one third of the rows in each thread.

  for (int line = 0; line < image_height/3; line++) // thread 1
  
  for (int line = image_height/3; line < 2*image_height/3; line++) // thread 2
  
  for (int line = 2*image_height/3; line < image_height; line++) // thread 3

  This gave me only a minor improvement of 20-30 milliseconds per frame.
  What would be the best way to parallelize such loops ? Can I use GPU computing or something like OpenMP ? Say spwaning some 100 threads to do the calculations ?

  I also noticed higher frame rates with my laptop webcam as compared to the Microsoft USB Lifecam.

  Here are other details :

  • Ubuntu 12.04, ffmpeg 2.6
  • AMG-A8 quad core processor with 6GB RAM
  • Encoder settings :
    • codec : AV_CODEC_ID_MPEG2VIDEO
    • bitrate : 4000000
    • time_base : (AVRational)1, 20
    • pix_fmt : AV_PIX_FMT_YUV420P
    • gop : 10
    • max_b_frames : 1

• ffmpeg filter_complex multiple overlays - why are they not syncing properly

  28 décembre 2023, par howdood

  I'm setting up live streaming using three overlaid inputs in ffmpeg. O:v is a webcam directly connected to the streaming box (a headless linux box) while 2:v and 3:v are ultra-low latency UDP streams from two remote R-Pis.

  


  The filter_complex argument I'm using (that works, with all three video inputs perfectly in sync) is
[0:v] fifo [v1] ;[2:v] fifo [v2] ; [3:v] fifo [v3] ;[v1]setpts=PTS-STARTPTS[sync1] ;[v2]setpts=PTS-STARTPTS[sync2] ; [v3]setpts=PTS-STARTPTS+5/TB [sync3] ;[sync1][sync2] overlay=x=W-w:y=H-h [out1] ;[out1][sync3] overlay=x=0:y=H-h [vfinal]

  


  Two questions about this :

  


  


  1. Why am I having to add +5/TB to [sync3] via setpts (in bold above) ? If I omit that, [3:v] is synced in to the stream noticeably ahead of the other two inputs. My best guess is that this may be to compensate for the processing time of the first overlay [sync1][sync2] which is introducing extra latency into that part of the stream. Is that right ?

     


  


  2. Importantly - the value of the extra pts compensation has to be dialed in by hand and will be specific to the underlying hardware used. Is there a way of getting ffmpeg to calculate this automatically so I don't have to worry about keeping in dialed in, in production ?

     


  


  


  Thanks for reading ! I'm at the limit of the ffmpeg docs here...

  


• Chromecast HLS : Unable to derive timescale

  31 juillet 2020, par Scott

  I'm trying to get fmp4 HLS playing back on a new Chromecast (3rd gen I believe, not Ultra).

  


  I've tried encoding the content with ffmpeg using both x264 and h264 libraries.
The main profile initially gives me a codec not supported error, remove the codec list from the hls manifest fixes this issue.

  


  Switching to baseline (which is not ideal) doesn't give the codec error.

  


  Both then (after removing the codec definitions or using baseline) give the following error :

  


  Uncaught Error: Unable to derive timescale
    at Xl (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:344)
    at Y.$e (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:337)
    at Y.k.processSegment (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:340)
    at Am.k.processSegment (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:384)
    at Mj.$e (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:238)
    at Wj (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:236)
    at Oj (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:240)
    at Mj.fd (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:239)
    at Nc (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:39)
    at wi.Mc.dispatchEvent (www.gstatic.com/cast/sdk/libs/mediaplayer/1.0.0/media_player.js:38)