Recherche avancée

Sur d’autres sites (7958)

• avconv stops streaming after some time

  4 juin 2014, par Dhrumil Doshi

  I am using raspberry-pi board and a usb camera attached with it. i use avconv tool to capture live video from camera and streaming it on network using rtp protocol.

  My command on server(raspberry-pi board) is as below :

  avconv -f video4linux2 -s 160x120 -i /dev/video0 -vcodec mpeg2video -r 25 -pix_fmt yuv420p -me_method epzs -b 2600k -bt 256k -f rtp rtp ://192.168.1.141:8554

  streaming works successfully using this command. Here IP address 192.168.1.141 is the ip address of my client pc. i can play live streaming on client side using vlc successfully.

  But Issue is after some time encoding and streaming on server stop automatically. And command hangs there.

  Output on server is as below :

  $ avconv -f video4linux2 -s 160x120 -v debug -i /dev/video0 -vcodec mpeg2video -r 25 -pix_fmt yuv420p -me_method epzs -b 2600k -bt 256k -f rtp rtp://192.168.1.141:8554
  
  avconv version 0.8.10-6:0.8.10-1+rpi1, Copyright (c) 2000-2013 the Libav developers
  
    built on Mar 22 2014 02:13:15 with gcc 4.6.3
  
    configuration: --arch=arm --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.10-1+rpi1' --libdir=/usr/lib/arm-linux-gnueabihf --prefix=/usr --disable-yasm --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --enable-libx264 --enable-libxvid --shlibdir=/usr/lib/arm-linux-gnueabihf --enable-shared --disable-static
  
    libavutil    51. 22. 2 / 51. 22. 2
  
    libavcodec   53. 35. 0 / 53. 35. 0
  
    libavformat  53. 21. 1 / 53. 21. 1
  
    libavdevice  53.  2. 0 / 53.  2. 0
  
    libavfilter   2. 15. 0 /  2. 15. 0
  
    libswscale    2.  1. 0 /  2.  1. 0
  
    libpostproc  52.  0. 0 / 52.  0. 0
  
  [video4linux2 @ 0x54d7a0] [4]Capabilities: 84000001
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver changed the pixel format from 0x32315559 to 0x56595559
  
      Last message repeated 1 times
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver changed the pixel format from 0x50323234 to 0x56595559
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver set input_id: 0, input: Camera 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition separate: 1; 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition combined: 1; 1
  
  [video4linux2 @ 0x54d7a0] All info found
  
  [video4linux2 @ 0x54d7a0] Estimating duration from bitrate, this may be inaccurate
  
  Input #0, video4linux2, from '/dev/video0':
  
    Duration: N/A, start: 21891.364784, bitrate: 9216 kb/s
  
      Stream #0.0, 1, 1/1000000: Video: rawvideo, yuyv422, 160x120, 1/30, 9216 kb/s, 30 tbr, 1000k tbn, 30 tbc
  
  [buffer @ 0x54f220] w:160 h:120 pixfmt:yuyv422
  
  [avsink @ 0x54d740] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
  
  [scale @ 0x54f7e0] w:160 h:120 fmt:yuyv422 -> w:160 h:120 fmt:yuv420p flags:0x4
  
  [mpeg2video @ 0x54ea60] err{or,}_recognition separate: 1; 1
  
  [mpeg2video @ 0x54ea60] err{or,}_recognition combined: 1; 1
  
  [mpeg2video @ 0x54ea60] detected 1 logical cores
  
  [mpeg2video @ 0x54ea60] Unsupported bit depth: 0
  
  [rawvideo @ 0x54f860] err{or,}_recognition separate: 1; 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition combined: 1; 1
  
  Output #0, rtp, to 'rtp://192.168.1.141:8554':
  
    Metadata:
  
      encoder         : Lavf53.21.1
  
      Stream #0.0, 0, 1/90000: Video: mpeg2video, yuv420p, 160x120, 1/25, q=2-31, 2600 kb/s, 90k tbn, 25 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (rawvideo -> mpeg2video)
  
  SDP:
  
  v=0
  
  o=- 0 0 IN IP4 127.0.0.1
  
  s=No Name
  
  c=IN IP4 192.168.1.141
  
  t=0 0
  
  a=tool:libavformat 53.21.1
  
  m=video 8554 RTP/AVP 32
  
  b=AS:2600
  
  
  
  Press ctrl-c to stop encoding
  
  *** drop!
  
      Last message repeated 1 times
  
  *** 1 dup!
  
  *** 16 dup! fps= 25 q=2.0 size=    1027kB time=5.24 bitrate=1605.2kbits/s dup=1 drop=2    
  
  *** drop!
  
      Last message repeated 11 times
  
  *** drop!49 fps= 26 q=2.0 size=    1059kB time=5.92 bitrate=1464.9kbits/s dup=17 drop=14    
  
      Last message repeated 2 times
  
  *** drop!76 fps= 25 q=2.0 size=    2022kB time=11.00 bitrate=1505.7kbits/s dup=17 drop=17    
  
  *** drop!48 fps= 25 q=2.0 size=    4086kB time=21.88 bitrate=1529.8kbits/s dup=17 drop=18    
  
  *** 1 dup!
  
  *** 1 dup!0 fps= 25 q=2.0 size=    4171kB time=22.36 bitrate=1528.2kbits/s dup=18 drop=19    
  
  *** 1 dup!1 fps= 25 q=2.0 size=    4859kB time=26.00 bitrate=1530.8kbits/s dup=19 drop=19    
  
  *** 1 dup!0 fps= 25 q=2.0 size=    5152kB time=27.56 bitrate=1531.5kbits/s dup=20 drop=19    
  
  *** 1 dup!3 fps= 25 q=2.0 size=    5250kB time=28.08 bitrate=1531.7kbits/s dup=21 drop=19    
  
  *** drop!64 fps= 25 q=2.0 size=    7215kB time=38.52 bitrate=1534.5kbits/s dup=22 drop=19    
  
  *** 1 dup!6 fps= 25 q=2.0 size=    7306kB time=39.00 bitrate=1534.6kbits/s dup=22 drop=20    
  
  *** drop!07 fps= 25 q=2.0 size=    8288kB time=44.24 bitrate=1534.7kbits/s dup=23 drop=20    
  
  *** 1 dup!0 fps= 25 q=2.0 size=   10054kB time=53.56 bitrate=1537.8kbits/s dup=23 drop=21    
  
  *** 1 dup!9 fps= 25 q=2.0 size=   10342kB time=55.12 bitrate=1537.1kbits/s dup=24 drop=21    
  
      Last message repeated 1 times
  
  *** drop!93 fps= 25 q=1.6 size=   10445kB time=55.68 bitrate=1536.7kbits/s dup=26 drop=21    
  
  *** 1 dup!
  
  *** 7036829 dup! 25 q=2.0 size=   10630kB time=56.68 bitrate=1536.4kbits/s dup=27 drop=22 

  Any ideas ?

  Thanks in advance.

• Achieving very poor fps for my iphone app for decode + display h264 frames using ffmpeg and opengl

  29 décembre 2015, par sam18

  I have three steps process for my application which display h264 frame on iPhone screen.

  1. decode using ffmpeg.
  2. scale and colorspace conversion (scale to 256 X 256 Opengl ES 1 texture and convert colospace from yuv420p to rgb565 using sws_Scale from ffmpeg).
  3. Render opengl 1 texture to frame buffer to render buffer

  after these three step process, I got my picture on iPhone screen.

  When I was testing the performance for 720 X 576 resolution frames, I obtain very poor FPS. It is reaching max to 180 milliseconds and hence resulting into 5 to 6 FPS.

  Any direction will be grateful.

• Greed is Good ; Greed Works

  25 novembre 2010, par Multimedia Mike — VP8

  Greed, for lack of a better word, is good ; Greed works. Well, most of the time. Maybe.

  Picking Prediction Modes
  VP8 uses one of 4 prediction modes to predict a 16x16 luma block or 8x8 chroma block before processing it (for luma, a block can also be broken into 16 4x4 blocks for individual prediction using even more modes).

  So, how to pick the best predictor mode ? I had no idea when I started writing my VP8 encoder. I did not read any literature on the matter ; I just sat down and thought of a brute-force approach. According to the comments in my code :

  // naive, greedy algorithm :
  //   residual = source - predictor
  //   mean = mean(residual)
  //   residual -= mean
  //   find the max diff between the mean and the residual
  // the thinking is that, post-prediction, the best block will
  // be comprised of similar samples
  

  After removing the predictor from the macroblock, individual 4x4 subblocks are put through a forward DCT and quantized. Optimal compression in this scenario results when all samples are the same since only the DC coefficient will be non-zero. Failing that, when the input samples are at least similar to each other, few of the AC coefficients will be non-zero, which helps compression. When the samples are all over the scale, there aren’t a whole lot of non-zero coefficients unless you crank up the quantizer, which results in poor quality in the reconstructed subblocks.

  Thus, my goal was to pick a prediction mode that, when applied to the input block, resulted in a residual in which each element would feature the least deviation from the mean of the residual (relative to other prediction choices).

  Greedy Approach
  I realized that this algorithm falls into the broad general category of "greedy" algorithms— one that makes locally optimal decisions at each stage. There are most likely smarter algorithms. But this one was good enough for making an encoder that just barely works.

  Compression Results
  I checked the total file compression size on my usual 640x360 Big Buck Bunny logo image while forcing prediction modes vs. using my greedy prediction picking algorithm. In this very simple test, DC-only actually resulted in slightly better compression than the greedy algorithm (which says nothing about overall quality).

  prediction mode	quantizer index = 0 (minimum)	quantizer index = 10
  greedy	286260	98028
  DC	280593	95378
  vertical	297206	105316
  horizontal	295357	104185
  TrueMotion	311660	113480

  As another data point, in both quantizer cases, my greedy algorithm selected a healthy mix of prediction modes :

  • quantizer index 0 : DC = 521, VERT = 151, HORIZ = 183, TM = 65
  • quantizer index 10 : DC = 486, VERT = 167, HORIZ = 190, TM = 77

  Size vs. Quality
  Again, note that this ad-hoc test only measures one property (a highly objective one)— compression size. It did not account for quality which is a far more controversial topic that I have yet to wade into.