Recherche avancée

Sur d’autres sites (12761)

• lavu : fix memory leaks by using a mutex instead of atomics

  14 novembre 2014, par wm4

  lavu : fix memory leaks by using a mutex instead of atomics
  The buffer pool has to atomically add and remove entries from the linked
  
  list of available buffers. This was done by removing the entire list
  
  with a CAS operation, working on it, and then setting it back again
  
  (using a retry-loop in case another thread was doing the same thing).
  This could effectively cause memory leaks : while a thread was working on
  
  the buffer list, other threads would allocate new buffers, increasing
  
  the pool’s total size. There was no real leak, but since these extra
  
  buffers were not needed, but not free’d either (except when the buffer
  
  pool was destroyed), this had the same effects as a real leak. For some
  
  reason, growth was exponential, and could easily kill the process due
  
  to OOM in real-world uses.
  Fix this by using a mutex to protect the list operations. The fancy
  
  way atomics remove the whole list to work on it is not needed anymore,
  
  which also avoids the situation which was causing the leak.
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavutil/buffer.c
  • [DH] libavutil/buffer_internal.h

• Expanding media capabilities of Win Embedded CE 6.0

  1er décembre 2014, par Simo Erkinheimo

  I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than

  • .NET 3.5 Compact Framework scripting that’s invoked from various events from the main application
  • Adding files to the device.

  The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.

  I’ve already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.

  I’m totally new with this stuff and I have tons of (stupid) questions. I’ll try to narrow them down :

  • The OS is based on WinCE, but as far as I’ve understood, it’s actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right ? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.

  • Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there’s the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work ?

  • If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK ? Do I REALLY need the whole SDK for creating a simple executable that uses only base types ? I’m using VS2010, which doesn’t even support smart device dev anymore and I’d hate to downgrade just for testing purposes.

  • Above questions are prequel to my actual idea : Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments ?

  • If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance ? I mean.. is C# THAT much slower ?

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