Sur d’autres sites (6316)

• Run same task (with different parameters) on each async request

  3 octobre 2017, par captain.murphy

  I need to execute new ffmpeg process each time when someone make a request on specific endpoint.

  Tech stack : Sanic + Celery + nginx-rtmp-module/hls + ffmpeg + subprocess

  Celery worker started with :

  celery multi start w2 -A celery_app -P eventlet -c 1000 -l info --pidfile=/var/run/celery/%n.pid --logfile=/var/log/celery/%n%I.log

  This code snippets execute only one ffmpeg process and doesn’t let me to spawn another process at the same time.

  app.py

  @app.route('/stream')
  
  async def test(request):
  
      timeout = request.args['timeout'][0]
  
      name = request.args['name'][0]
  
      task_id = uuid()
  
      start_stream.apply_async(args=(name, timeout), task_id=task_id)
  
      # start_stream.delay(name, timeout)
  
      return text('Started - {}'.format(task_id))

  tasks.py

  @taskapp.task
  
  def start_stream(name, timeout):
  
      ffmpeg = ['ffmpeg',
  
                '-f',
  
                'v4l2',
  
                '-i',
  
                '/dev/video0',
  
                '-c:v',
  
                'libx264',
  
                '-an',
  
                '-f',
  
                'flv',
  
                '-t',
  
                '00:00:{}'.format(timeout),
  
                'rtmp://127.0.0.1:1935/live/{}'.format(name)]
  
      subprocess.Popen(ffmpeg, stdout=subprocess.DEVNULL, stderr=subprocess.STDOUT)

  Please, any help ? Thanks to all.

• lavc/flacdsp : optimise RVV vector type for lpc16

  14 mai 2024, par Rémi Denis-Courmont

  lavc/flacdsp : optimise RVV vector type for lpc16
  This calculates the optimal vector type value at run-time based on the
  
  hardware vector length and the FLAC LPC prediction order. In this
  
  particular case, the additional computation is easily amortised over
  
  the loop iterations :
  T-Head C908 :
  
      C     V before  V after
  
   1   48.0    214.7     95.2
  
   2   64.7    214.2     94.7
  
   3   79.7    213.5     94.5
  
   4   96.2    196.5     94.2 #
  
   5  111.0    195.7    118.5
  
   6  127.0    211.2    102.0
  
   7  143.7    194.2    101.5
  
   8  175.7    193.2    101.2 #
  
   9  176.2    224.2    126.0
  
  10  191.5    192.0    125.5
  
  11  224.5    191.2    124.7
  
  12  223.0    190.2    124.2
  
  13  239.2    189.5    123.7
  
  14  253.7    188.7    139.5
  
  15  286.2    188.0    122.7
  
  16  284.0    187.0    122.5 #
  
  17  300.2    186.5    186.5
  
  18  314.0    185.5    185.7
  
  19  329.7    184.7    185.0
  
  20  343.0    184.2    184.2
  
  21  358.7    199.2    183.7
  
  22  371.7    182.7    182.7
  
  23  387.5    181.7    182.0
  
  24  400.7    181.0    181.2
  
  25  431.5    180.2    196.5
  
  26  443.7    195.5    196.0
  
  27  459.0    178.7    196.2
  
  28  470.7    177.7    194.2
  
  29  470.0    177.0    193.5
  
  30  481.2    176.2    176.5
  
  31  496.2    175.5    175.7
  
  32  507.2    174.7    191.0 #
   # Power of two boundary.
  With 128-bit vectors, improvements are expected for the first two
  
  test cases only. For the other two, there is overhead but below noise.
  
  Improvements should be better observable with prediction order of 8
  
  and less, or on hardware with larger vector sizes.
  

  • [DH] libavcodec/riscv/flacdsp_init.c
  • [DH] libavcodec/riscv/flacdsp_rvv.S

• Stream RTSP to HTML5 Video - which is the best approach ?

  13 janvier 2020, par Daniel

  As this task is very complicated I’ve created two approaches and I’d like to know which is the better approach for my purpose.

  Approach 1 :

  H264 frames are grabbed out of RTSP stream on the server (i.e. by ffmpeg), then they are put into a websocket and sent to the client. Client uses mp4box.js to fragment the h264 and then HTML5 video can render it with MSE.

  Approach 2 :

  H264 frames are grabbed out of RTSP stream and also fragmented on the server (i.e. by ffmpeg), then they are transferred directly to the client’s HTML5 video to render it with MSE.
  Here is an example for this approach.

  If we consider today’s client devices (modern phones, notebooks), we can state approach1 would be a better solution because it would prevent the central load on the server.

  However I have not really found any good resource or material on how to use approach1, hence I could not yet tried it out.

  I would like to know if approach1 is really better than approach2 ?

  because maybe grabbing and fragmenting would not put much higher load on the server than grabbing only

  (why I’m asking this ? because for approach2 I’ve a concrete example, whereas for approach1 I don’t. If approach1 is really better, I’ll go for it and implement the whole thing.)

  To put it more exact : does ffmpeg stress the server more if it grabs and fragments an rtsp-h264 stream to fmp4 than when it only grabs the frames from rtsp-h264 stream ?