Recherche avancée

Sur d’autres sites (11271)

• Gstreamer : Hauppauge HD PVR and Multi-video file output

  7 juin 2014, par user3716978

  I have very specific requirements for a Gstreamer pipeline that I can’t seem to create. I’m running Linux Mint Mate 14 (Nadia).

  I have an HD PVR, which records in MPEG TS. It presents, as its interface, a V4L2 device at /dev/video0. What I need is to somehow have it output the captured video to multiple files. That is, like dvgrab’s autosplit, it would output, say, 1800 frames, then create a new output file, then capture another 1800, and on and on.

  I’ve tried numerous methods. First, using multifilesink with the keyframe next-file option does what I want, but it doesn’t seem to add stream headers to the segment files, so that they cannot play properly and/or are missing their initial keyframe.

  I’ve tried limiting each individual capture length using num-buffers, and just restarting the capture after the previous one ends. This works for maybe 30 or 40 files but all the switching on and off eventually locks up the HD PVR, and it has to be power-cycled.

  I could also have it dump images to the disk and work with the individual frames, but this is very slow with MPEG TS since it has to demux, decode, and reencode every frame. It eats up 100% cpu and drops about 60% of the frames on my computer.

  ffmpeg doesn’t work, because the HD PVR driver doesn’t support ioctl. I can’t seem to get mencoder to stream it this way either, but maybe it’s possible ?

  What I need is to :

  • Have a single capture stream, to avoid pissing off the HD PVR
  • Have it split the stream into multiple files which can be individually analyzed
  • Have those multiple files be valid videos
  • Not eat up 100% of my CPU (although high utilization is ok, it needs to run at full speed). Since the stream is 1920x1080x60fps, anything to do with reencoding won’t work. It pretty much needs to be a stream copy.

  Thank you

• 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 !!

• Piwik IRC Meetup on Tuesday

  10 février 2014, par Fabian Becker — Community, Development

  With the release of Piwik 2.0 and the Piwik Marketplace we are focusing on the community aspect of Piwik Development. In order to give users and developers a chance to get involved in Piwik we decided to have IRC meetups every two weeks, where we discuss current and future plans of Piwik development.

  Why should I join ?

  This is the chance for everyone to directly talk to developers and discuss issues and feature ideas. It is also good if you want to get involved in development and pick up smaller features to get to know the code base.

  Next Piwik meetup

  • Date : Tuesday February 11th, 7.30pm UTC
  • Duration : 30min
  • IRC #piwik channel (irc.freenode.net)

  Topics are :

  • 2.1 release (closed tickets)
  • open tickets for Piwik 2.2

  To join the chat, you can use the website : http://webchat.freenode.net/ (or join with your IRC client of choice) – See also what will be the time in your country at 7.30pm UTC. You will find us in the Freenode channel #piwik.