Recherche avancée

Sur d’autres sites (4600)

• ffmpeg and ffserver, rc buffer underflow ?

  25 février 2018, par Dove Devic

  I am attempting to write a simple streaming server for a project. I have an AWS Linux machine that will be running ffserver. Curently, as it stands, my config file looks like the following :

  #Server Configs
  
  HTTPPort 8090
  
  HTTPBindAddress 0.0.0.0
  
  MaxHTTPConnections 2000
  
  MaxClients 1000
  
  MaxBandwidth 1000
  
  CustomLog -
  
  
  
  #Create a Status Page
  
  <stream>
  
  Format status
  
  ACL allow localhost
  
  ACL allow 255.255.255.255 #Allow everyone to view status, for now
  
  </stream>
  
  
  
  #Creates feed, only allow from self
  
  <feed>
  
  File /tmp/feed1.ffm
  
  FileMaxSize 50M
  
  ACL allow 127.0.0.1
  
  ACL allow 
  
  </feed>
  
  
  
  #Creates stream, allow everyone
  
  <stream>
  
  Format mpeg
  
  Feed feed1.ffm
  
  VideoFrameRate 30
  
  VideoSize 640x480
  
  AudioSampleRate 44100
  
  </stream>

  I then am capturing my Webcam and sending it up to the server using the following command :

  ffmpeg -f dshow 
  
         -i video="Webcam C170":audio="Microphone (Webcam C170)" 
  
         -b:v 1400k  
  
         -maxrate 2400k  
  
         -bufsize 1200k  
  
         -ab 64k  
  
         -s 640x480  
  
         -ac 1  
  
         -ar 44100  
  
         -y http://:8090/feed1.ffm

  When I run this however, I get the following output from my console :

  Guessed Channel Layout for  Input Stream #0.1 : stereo
  
  Input #0, dshow, from 'video=Webcam C170:audio=Microphone (Webcam C170)':
  
    Duration: N/A, start: 12547.408000, bitrate: N/A
  
      Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 640x480, 30 tbr, 10000k tbn, 30 tbc
  
      Stream #0:1: Audio: pcm_s16le, 44100 Hz, 2 channels, s16, 1411 kb/s
  
  Output #0, ffm, to ':8090/feed1.ffm':
  
    Metadata:
  
      creation_time   : 2017-04-26 14:55:27
  
      encoder         : Lavf57.25.100
  
      Stream #0:0: Audio: mp2, 44100 Hz, mono, s16, 64 kb/s
  
      Metadata:
  
        encoder         : Lavc57.24.102 mp2
  
      Stream #0:1: Video: mpeg1video, yuv420p, 640x480, q=2-31, 64 kb/s, 30 fps, 1000k tbn, 30 tbc
  
      Metadata:
  
        encoder         : Lavc57.24.102 mpeg1video
  
      Side data:
  
        unknown side data type 10 (24 bytes)
  
  Stream mapping:
  
    Stream #0:1 -> #0:0 (pcm_s16le (native) -> mp2 (native))
  
    Stream #0:0 -> #0:1 (rawvideo (native) -> mpeg1video (native))
  
  Press [q] to stop, [?] for help
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflowtime=00:00:01.13 bitrate= 404.8kbits/s dup=13 drop=0 speed=2.22x
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflowtime=00:00:01.63 bitrate= 361.1kbits/s dup=13 drop=0 speed=1.61x
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflowtime=00:00:02.13 bitrate= 368.6kbits/s dup=13 drop=0 speed= 1.4x
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflowtime=00:00:02.66 bitrate= 344.1kbits/s dup=13 drop=0 speed=1.32x
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflowtime=00:00:03.16 bitrate= 331.1kbits/s dup=13 drop=0 speed=1.25x
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  [mpeg1video @ 02e95180] rc buffer underflow
  
  [mpeg1video @ 02e95180] max bitrate possibly too small or try trellis with large lmax or increase qmax
  
  frame=  117 fps= 36 q=31.0 Lsize=     156kB time=00:00:03.86 bitrate= 330.5kbits/s dup=13 drop=0 speed= 1.2x
  
  video:118kB audio:27kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.659440%
  
  Exiting normally, received signal 2.

  And on my viewer, I just get a black screen.

  Is there something I’m missing ? Searching lead to nothing on "increasing qmax" or anything similar to what ffmpeg complained about. There have been questions asked here, but nothing has been done/answered.

  Thanks in advance

• Piwik Analytics becomes Matomo to reflect Users’ Privacy Focus

  10 janvier 2018, par Matomo Core Team

  One of the world’s leading analytics software platforms is changing its name. Piwik is the sixth most-used web and mobile analytics computer solution worldwide. It is now changing its name to Matomo.

  The name change comes after 10 years of Piwik building its top analytics software, with great success. It is already used on over one million websites in more than 170 countries. Matomo will build on that success, and focus even more on privacy.

  ‘Privacy has become a huge concern worldwide’, says Matomo’s creator, Matthieu Aubry. ‘Privacy legislation is being developed in Europe, and we will be ahead of the game in being ready for those changes. We’ll grow in line with the law and regulation changes.’

  Matomo will lead the way in openness and transparency for its users. Its new name means honesty in Japanese.
  ‘Matomo will always be free and community-driven, just as Piwik was’, says Matthieu Aubry. ‘We have worked with hundreds of people to create the best open digital analytics solution in the world. We’re committed to giving every user full control of their data.’

  The change of name is appropriate as the Matomo platform moves into a new stage of growth. But for its community, little will obviously change. The same people will still be involved, and users will still get useful data to improve their own website. That data includes who visits their site, what they do there, how long they stay, and what they buy.
  Matomo is an all-in-one analytics solution that gives companies a 360 degree view of their users.

  ‘They can grow their business while still keeping 100% ownership of their data, and being fully compliant with privacy laws’, says Matthieu Aubry. ‘We’re more motivated than ever to building on that, so that Matomo stays ahead of the pack.’

  The platform can be fully customised with hundreds of plug-ins, integrations and configurations.

  Matomo’s updated website and new logo is now available on https://matomo.org.
  For further information, please contact the Matomo Team on hello@matomo.org

  The post Piwik Analytics becomes Matomo to reflect Users’ Privacy Focus appeared first on Analytics Platform - Matomo.

• http: block while waiting for reconnecting

  2 janvier 2018, par wm4

  http: block while waiting for reconnecting
  It makes no sense to return an error after the first reconnect, and then
  
  somehow resume the next time it's called. Usually this will lead to
  
  demuxer errors. Make reconnecting block instead, until it has either
  
  successfully reconnected, or given up.
  Also make the wait reasonably interruptible. Since there is no mechanism
  
  for this in the API, polling is the best we can do. This behaves roughly
  
  the same as other interruptible network functions in libavformat.
  (The original code would work if it returned AVERROR(EAGAIN) or so,
  
  which would make retry_transfer_wrapper() repeat the read call. But I
  
  think having an explicit loop for this is better anyway.)
  I also snuck in a fix for reconnect_at_eof. It has to check for
  
  AVERROR_EOF, not 0.
  

  • [DH] libavformat/http.c
  • [DH] libavformat/network.c
  • [DH] libavformat/network.h