Recherche avancée

Sur d’autres sites (7649)

• Python ThreadedTCPServer : "Name or service not known"

  11 avril 2014, par Hal

  I was developing a ThreadedTCPServer to communicate with a PHP application also residing in this same machine. This is suppose to receive requests from this PHP app and to convert some videos locally using ffmpeg.

  Here's the code :

  # -*- coding: utf-8 -*- 
  
  import os
  
  import socket
  
  import threading
  
  import logging.config
  
  import SocketServer, time
  
  from queuev2 import QueueServer
  
  
  
  logging.basicConfig(format='[%(asctime)s.%(msecs).03d] %(message)s', datefmt='%Y-%m-%d %H:%M:%S', filename=os.path.join(os.path.dirname(os.path.realpath(__file__)), 'converter.log'), level=logging.INFO)
  
  
  
  class ThreadedTCPRequestHandler(SocketServer.BaseRequestHandler):
  
  
  
      def handle(self):
  
          data = self.request.recv(1024)
  
          cur_thread = threading.current_thread()
  
          response = "{}: {}".format(cur_thread.name, data)
  
          videoPool.add(data)
  
          print "Output! %s" % data
  
          self.request.sendall(response)
  
  
  
  class ThreadedTCPServer(SocketServer.ThreadingMixIn, SocketServer.TCPServer):
  
      pass
  
  
  
  if __name__ == "__main__":
  
  
  
      logging.info("Initializing...")
  
      videoPool = QueueServer()
  
      HOST, PORT = "localhost", 6666
  
  
  
      server = ThreadedTCPServer((HOST, PORT), ThreadedTCPRequestHandler)
  
      ip, port = server.server_address
  
  
  
      # Start a thread with the server -- that thread will then start one
  
      # more thread for each request
  
      server_thread = threading.Thread(target=server.serve_forever)
  
  
  
      # Exit the server thread when the main thread terminates
  
      server_thread.daemon = True
  
      server_thread.start()
  
  
  
      print("Server loop running in thread: %s" % server_thread.name)
  
  
  
      # "Groundhog day" time
  
      while True:
  
          time.sleep(999)
  
          pass
  
  
  
      #server.shutdown()

  This works well in my development laptop, but on the server i'm getting the following error :

  Traceback (most recent call last):
  
    File "server.py", line 31, in <module>
  
      server = ThreadedTCPServer((HOST, PORT), ThreadedTCPRequestHandler)
  
    File "/usr/lib/python2.7/SocketServer.py", line 408, in __init__
  
      self.server_bind()
  
    File "/usr/lib/python2.7/SocketServer.py", line 419, in server_bind
  
      self.socket.bind(self.server_address)
  
    File "/usr/lib/python2.7/socket.py", line 224, in meth
  
      return getattr(self._sock,name)(*args)
  
  socket.gaierror: [Errno -2] Name or service not known
  
  </module>

  I'm guessing it has to do with the port I'm using (6666), but I've tried others and it hasn't been working. Would Unix Domain Sockets be of use here ? Can you give me an example ?

• How to http stream video from a frequently updated image

  27 avril 2017, par alez

  How can I obtain an HTTP video stream from a single image file that is frequently updated (every 50ms) ?

  The file is on a Windows 7 machine, I can use C# but I can also send a potential stream to a linux machine.

  I would try whith vlc and the fake module, but it seems not more supported. I’ve tried also with a pipe from ffmpeg (also over an udp localhost stream) but it doesn’t work.

• Progress with rtc.io

  12 août 2014, par silvia

  At the end of July, I gave a presentation about WebRTC and rtc.io at the WDCNZ Web Dev Conference in beautiful Wellington, NZ.

  

  Putting that talk together reminded me about how far we have come in the last year both with the progress of WebRTC, its standards and browser implementations, as well as with our own small team at NICTA and our rtc.io WebRTC toolbox.

  

  One of the most exciting opportunities is still under-exploited : the data channel. When I talked about the above slide and pointed out Bananabread, PeerCDN, Copay, PubNub and also later WebTorrent, that’s where I really started to get Web Developers excited about WebRTC. They can totally see the shift in paradigm to peer-to-peer applications away from the Server-based architecture of the current Web.

  Many were also excited to learn more about rtc.io, our own npm nodules based approach to a JavaScript API for WebRTC.

  

  We believe that the World of JavaScript has reached a critical stage where we can no longer code by copy-and-paste of JavaScript snippets from all over the Web universe. We need a more structured module reuse approach to JavaScript. Node with JavaScript on the back end really only motivated this development. However, we’ve needed it for a long time on the front end, too. One big library (jquery anyone ?) that does everything that anyone could ever need on the front-end isn’t going to work any longer with the amount of functionality that we now expect Web applications to support. Just look at the insane growth of npm compared to other module collections :

  

  For those that – like myself – found it difficult to understand how to tap into the sheer power of npm modules as a font end developer, simply use browserify. npm modules are prepared following the CommonJS module definition spec. Browserify works natively with that and “compiles” all the dependencies of a npm modules into a single bundle.js file that you can use on the front end through a script tag as you would in plain HTML. You can learn more about browserify and module definitions and how to use browserify.

  For those of you not quite ready to dive in with browserify we have prepared prepared the rtc module, which exposes the most commonly used packages of rtc.io through an “RTC” object from a browserified JavaScript file. You can also directly download the JavaScript file from GitHub.

  

  So, I hope you enjoy rtc.io and I hope you enjoy my slides and large collection of interesting links inside the deck, and of course : enjoy WebRTC ! Thanks to Damon, JEeff, Cathy, Pete and Nathan – you’re an awesome team !

  On a side note, I was really excited to meet the author of browserify, James Halliday (@substack) at WDCNZ, whose talk on “building your own tools” seemed to take me back to the times where everything was done on the command-line. I think James is using Node and the Web in a way that would appeal to a Linux Kernel developer. Fascinating !!

  The post Progress with rtc.io first appeared on ginger’s thoughts.