Recherche avancée

Sur d’autres sites (13461)

• FFmpeg creating multicast with multiple streams from one source (live source)

  1er mai 2018, par Netheme

  Hi :) I’m facing problems when creating multicast with multiple streams from one source (live source). The issue is that the encoding is slower than realtime. That is big issue for me as I’m processing live feed. The exact command and it’s output you can find here :

  Command

  ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -deint 2 -drop_second_field 1 -surfaces 10 -i 'udp://@239.10.150.2:5004?fifo_size=100000000&bitrate=12000000'  -map i:0xc77 -r:v:0 25 -filter:v:0 fps=25,scale_npp=640:360:format=same:interp_algo=lanczos -aspect:v:0 16:9 -g:v:0 80 -vcodec:v:0 h264_nvenc -b:v:0 400K -minrate:v:0 400k -maxrate:v:0 400k  -map i:0xc77 -r:v:1 25 -filter:v:1 fps=25,scale_npp=720:405:format=same:interp_algo=lanczos -aspect:v:1 16:9 -g:v:1 80 -vcodec:v:1 h264_nvenc -b:v:1 1000K -minrate:v:1 1000k -maxrate:v:1 1000k  -map i:0xc77 -r:v:2 25 -filter:v:2 fps=25,scale_npp=1280:720:format=same:interp_algo=lanczos -aspect:v:2 16:9 -g:v:2 80 -vcodec:v:2 h264_nvenc -b:v:2 2500K -minrate:v:2 2500K -maxrate:v:2 2500K  -map i:0xc77 -r:v:3 25 -filter:v:3 fps=25,scale_npp=1920:1080:format=same:interp_algo=lanczos -aspect:v:3 16:9 -g:v:3 80 -vcodec:v:3 h264_nvenc -b:v:3 4500K -minrate:v:3 4500K -maxrate:v:3 4500K  -map i:0xc7a -ab:a:0 128k -ar:a:0 48k -acodec:a:0 aac -ac:a:0 2  -map i:0xc7b -ab:a:1 128k -ar:a:1 48k -acodec:a:1 aac -ac:a:1 2  -map i:0xc7c -ab:a:2 128k -ar:a:2 48k -acodec:a:2 aac -ac:a:2 2  -map i:0xc7d -ab:a:3 128k -ar:a:3 48k -acodec:a:3 aac -ac:a:3 2  -f mpegts "udp://@239.100.0.23:3234?overrun_nonfatal_option=1&pkt_size=1316

  And the output (speed should be 1> i hope)

  Stream #0:0 -> #0:0 (h264 (h264_cuvid) -> h264 (h264_nvenc))
  
   Stream #0:0 -> #0:1 (h264 (h264_cuvid) -> h264 (h264_nvenc))
  
   Stream #0:0 -> #0:2 (h264 (h264_cuvid) -> h264 (h264_nvenc))
  
   Stream #0:0 -> #0:3 (h264 (h264_cuvid) -> h264 (h264_nvenc))
  
   Stream #0:1 -> #0:4 (mp2 (native) -> aac (native))
  
   Stream #0:2 -> #0:5 (mp2 (native) -> aac (native))
  
   Stream #0:3 -> #0:6 (mp2 (native) -> aac (native))
  
   Stream #0:4 -> #0:7 (mp2 (native) -> aac (native))
  
  Press [q] to stop, [?] for help
  
  Output #0, mpegts, to 'udp://@239.100.0.23:3234?overrun_nonfatal_option=1&pkt_size=1316':=  -0.0kbits/s speed=N/A    
  
   Metadata:
  
     encoder         : Lavf57.83.100
  
     Stream #0:0: Video: h264 (h264_nvenc) (Main), cuda, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 400 kb/s, 25 fps, 90k tbn, 25 tbc
  
     Metadata:
  
       encoder         : Lavc57.107.100 h264_nvenc
  
     Side data:
  
       cpb: bitrate max/min/avg: 400000/0/400000 buffer size: 800000 vbv_delay: -1
  
     Stream #0:1: Video: h264 (h264_nvenc) (Main), cuda, 720x405 [SAR 1:1 DAR 16:9], q=-1--1, 1000 kb/s, 25 fps, 90k tbn, 25 tbc
  
     Metadata:
  
       encoder         : Lavc57.107.100 h264_nvenc
  
     Side data:
  
       cpb: bitrate max/min/avg: 1000000/0/1000000 buffer size: 2000000 vbv_delay: -1
  
     Stream #0:2: Video: h264 (h264_nvenc) (Main), cuda, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 2500 kb/s, 25 fps, 90k tbn, 25 tbc
  
     Metadata:
  
       encoder         : Lavc57.107.100 h264_nvenc
  
     Side data:
  
       cpb: bitrate max/min/avg: 2500000/0/2500000 buffer size: 5000000 vbv_delay: -1
  
     Stream #0:3: Video: h264 (h264_nvenc) (Main), cuda, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 4500 kb/s, 25 fps, 90k tbn, 25 tbc
  
     Metadata:
  
       encoder         : Lavc57.107.100 h264_nvenc
  
     Side data:
  
       cpb: bitrate max/min/avg: 4500000/0/4500000 buffer size: 9000000 vbv_delay: -1
  
     Stream #0:4(cze): Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
  
     Metadata:
  
       encoder         : Lavc57.107.100 aac
  
     Stream #0:5(eng): Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
  
     Metadata:
  
       encoder         : Lavc57.107.100 aac
  
     Stream #0:6(hun): Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
  
     Metadata:
  
       encoder         : Lavc57.107.100 aac
  
     Stream #0:7(ron): Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
  
     Metadata:
  
       encoder         : Lavc57.107.100 aac
  
  frame= 2868 fps= 19 q=18.0 Lq=14.0 q=15.0 q=16.0 size=  134155kB time=00:01:55.88 bitrate=9484.0kbits/s speed=0.768x

  Does anyone have experiences with something like this ?

• Chiptune Database and API

  14 septembre 2012, par Multimedia Mike — General

  So I set out to create a website that allows people to easily listen to video game music directly through their web browser. I succeeded in that goal. However, I must admit that the project has limited appeal since the web player is delivered via Chrome’s Native Client technology, somewhat limiting its audience. I’m not certain if anyone really expects NaCl to take off in any serious way, but I still have a few other projects in mind.

  I recently realized that, as a side effect of this project, I accidentally created something of significant value to fans of old video games and associated music– a searchable database of chiptune music and metadata. To my knowledge, no one else has endeavored to create such a thing. I figured that I might as well make the database easily accessible with an API and see where it leads.

  To that end, I created 2 API entry points. First, there is the search API located at http://gamemusic.multimedia.cx/api/search/. This can be exercised by ending the URL with a URL-encoded search string, e.g. : http://gamemusic.multimedia.cx/api/search/super+mario. This returns JSON data containing an array of results in decreasing order of relevance. Each result has a game title, database ID, media URL, system type, and an SHA-1 hash. This is the same API that the site’s own search page uses.

  The database ID can be plugged into http://gamemusic.multimedia.cx/api/metadata/ to retrieve the song’s metadata in JSON format. E.g., the ID for Super Mario Bros. 3 on the NES is 161 : http://gamemusic.multimedia.cx/api/metadata/161.

  I recently read an article about sins against true RESTful API principles which led me to believe I’m almost certainly doing this web API stuff wrong. I don’t think it’s a huge deal, though, since I don’t think anyone actually listens to chiptunes any more. But if there are offline chiptune music players that are still in service and actively maintained, perhaps the authors would like to implement this API. It would require some type of HTTP networking library, a JSON parser, the embedded XZ decoder, and some new code to parse through my .gamemusic and .psfarchive formats.

  This database could be a significant value-add to chiptune playback software, and could help people experience classic game music much more easily.

• Having trouble obtaining the time from RTP Timestamps obtained through OpenCV

  24 août 2019, par Fr0sty

  I am finding it a bit difficult trying to understand whether or not the hack around with FFmpeg and OpenCV really provided a RTP timestamp. My last post helped a little bit but got me stuck in trying to validate the timestamps obtained through this work around by modifying ffmpeg and opencv.

  FFmpeg version : 4.1.0
  OpenCV version : 3.4.1

  import cv2
  
  import time
  
  from datetime import datetime, date
  
  
  
  uri = 'rtsp://admin:password@192.168.1.66:554/Streaming/Channels/101'
  
  cap = cv2.VideoCapture(uri)
  
  '''One is the offset between the two epochs. Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h.
  
  This leads to an offset equivalent to 70 years in seconds (there are 17 leap years between the two dates so the offset is'''
  
  time_offset = 2208988800 # (70*365 + 17)*86400 = 2208988800 (in seconds)
  
  # offset = 3775484294
  
  days = 43697
  
  pdat = "1900-01-01 00:00:00:00"
  
  mdat = "2019-08-23 22:02:44:00" # str(datetime.now()) + str(datetime.now().time())
  
  pdate = datetime.strptime(pdat, "%Y-%m-%d %H:%M:%S:%f").date()
  
  mdate = datetime.strptime(mdat, "%Y-%m-%d %H:%M:%S:%f").date()
  
  delta = (mdate - pdate).days
  
  offset = delta * 86400
  
  def time_delta(s):
  
      return (s - time_offset)
  
  
  
  while True:
  
      frame_exists, curr_frame = cap.read()
  
      if frame_exists:
  
          seconds = cap.getRTPTimeStampSeconds()
  
          fraction = cap.getRTPTimeStampFraction()
  
          timestamp = cap.getRTPTimeStampTs()
  
          unix_offset = seconds - time_offset
  
          msec = int((int(fraction) / 0xFFFFFFFF) * 1000.0)
  
          ts = float(str(unix_offset) + "." + str(msec))
  
          # print("Timestamp per Frame:%i" % timestamp)
  
          print((datetime.fromtimestamp(float(ts) + offset)))
  
  cap.release()

  My Output :

  On August 23, 2019 at 22:02

  ...
  
  2019-08-23 13:59:52.781000
  
  2019-08-23 13:59:52.726000
  
  2019-08-23 13:59:52.671000
  
  2019-08-23 13:59:52.616000
  
  2019-08-23 13:59:52.561000
  
  2019-08-23 13:59:52.506000
  
  2019-08-23 13:59:52.451000
  
  2019-08-23 13:59:52.396000
  
  2019-08-23 13:59:52.342000
  
  2019-08-23 13:59:52.287000
  
  2019-08-23 13:59:52.232000
  
  2019-08-23 13:59:52.177000
  
  2019-08-23 13:59:52.122000
  
  2019-08-23 13:59:52.067000
  
  2019-08-23 13:59:52.012000
  
  2019-08-23 13:59:53.570000
  
  2019-08-23 13:59:53.020000
  
  2019-08-23 13:59:53.847000
  
  2019-08-23 13:59:53.792000

  I’ve noticed how the time increments weirdly (that’s not suppose to happen in the real, current time), such as the last two lines and a few others in between in the output. A bit flabbergasted as to what went wrong. Also trying this out on multiple IP cameras, with each showing a different timestamp probably related to when they were turned on.