Recherche avancée

Sur d’autres sites (9017)

• ffmpeg fails to capture video running on screen

  21 septembre 2014, par Ralf

  I’m trying to capture a slide presentation as video. I’m using the following command to capture my screen

  ffmpeg \
  
     -f x11grab -s 1024x768 -r 25 -i $DISPLAY \
  
     -f alsa -i pulse \
  
     -vcodec libx264 -preset ultrafast -vb 1000k \
  
     -acodec libmp3lame -ab 128k \
  
     test.avi

  This works (application windows on the screen are visible and sound is recorded in test.avi), but the problem is : Any video shown on the screen (e.g. a youtube video running in a browser window, but also e.g. a video played by mplayer) only appears as an empty (e.g. green) box when I play the captured video (test.avi).

  I’m using ffmpeg version 0.8.16-4:0.8.16-0ubuntu0.12.04.1 on Ubuntu 12.04.5 LTS with the nvidia-331 driver (effect is the same with older nvidia-304).

  I would really appreciate any suggestions, thanks a lot !

• Transcoding Modern Formats

  17 août 2014

  I’ve noticed that this blog still gets a decent amount of traffic, particularly to some of the older articles about transcoding. Since I’ve been working on a tool in this space recently, I thought I’d write something up in case it helps folks unravel how to think about transcoding these days.

  The tool I’ve been working on is EditReady, a transcoding app for the Mac. But why do you want to transcode in the first place ?

  Dailies

  After a day of shooting, there are a lot of people who need to see the footage from the day. Most of these folks aren’t equipped with editing suites or viewing stations - they want to view footage on their desktop or mobile device. That can be a problem if you’re shooting ProRes or similar.

  Converting ProRes, DNxHD or MPEG2 footage with EditReady to H.264 is fast and easy. With bulk metadata editing and custom file naming, the management of all the files from the set becomes simpler and more trackable.

  One common workflow would be to drop all the footage from a given shot into EditReady. Use the "set metadata for all" command to attach a consistent reel name to all of the clips. Do some quick spot-checks on the footage using the built in player to make sure it’s what you expect. Use the filename builder to tag all the footage with the reel name and the file creation date. Then, select the H.264 preset and hit convert. Now anyone who needs the footage can easily take the proxies with them on the go, without needing special codecs or players, and regardless of whether they’re working on a PC, a Mac, or even a mobile device.

  If your production is being shot in the Log space, you can use the LUT feature in EditReady to give your viewers a more traditional "video levels" daily. Just load a basic Log to Video Levels LUT for the batch, and your converted files will more closely resemble graded footage.

  Mezzanine Formats

  Even though many modern post production tools can work natively with H.264 from a GoPro or iPhone, there are a variety of downsides to that type of workflow. First and foremost is performance. When you’re working with H.264 in an editor or color correction tool, your computer has to constantly work to decompress the H.264 footage. Those are CPU cycles that aren’t being spent generating effects, responding to user interface clicks, or drawing your previews. Even apps that endeavor to support H.264 natively often get bogged down, or have trouble with all of the "flavors" of H.264 that are in use. For example, mixing and matching H.264 from a GoPro with H.264 from a mobile phone often leads to hiccups or instability.

  By using EditReady to batch transcode all of your footage to a format like ProRes or DNxHD, you get great performance throughout your post production pipeline, and more importantly, you get consistent performance. Since you’ll generally be exporting these formats from other parts of your pipeline as well - getting ProRes effects shots for example - you don’t have to worry about mix-and-match problems cropping up late in the production process either.

  Just like with dailies, the ability to apply bulk or custom metadata to your footage during your initial ingest also makes management easier for the rest of your production. It also makes your final output faster - transcoding from H.264 to another format is generally slower than transcoding from a mezzanine format. Nothing takes the fun out of finishing a project like watching an "exporting" bar endlessly creep along.

  Modernization

  The video industry has gone through a lot of digital formats over the last 20 years. As Mac OS X has been upgraded over the years, it’s gotten harder to play some of those old formats. There’s a lot of irreplaceable footage stored in formats like Sorensen Video, Apple Intermediate Codec, or Apple Animation. It’s important that this footage be moved to a modern format like ProRes or H.264 before it becomes totally unplayable by modern computers. Because EditReady contains a robust, flexible backend with legacy support, you can bring this footage in, select a modern format, and click convert. Back when I started this blog, we were mostly talking about DV and HDV, with a bit of Apple Intermediate Codec mixed in. If you’ve still got footage like that around, it’s time to bring it forward !

  Output

  Finally, the powerful H.264 transcoding pipeline in EditReady means you generate beautiful deliverable H.264 more rapidly than ever. Just drop in your final, edited ProRes, DNxHD, or even uncompressed footage and generate a high quality H.264 for delivery. It’s never been this easy !

  See for yourself

  We released a free trial of EditReady so you can give it a shot yourself. Or drop me a line if you have questions.

• w32threads : Use newer thread synchronization functions when targeting Vista

  6 août 2014, par Martin Storsjö

  w32threads : Use newer thread synchronization functions when targeting Vista
  When explicitly targeting Vista or newer (which only happens if the
  
  caller explicitly sets _WIN32_WINNT to a high enough value via the
  
  extra cflags option - otherwise configure script sets
  
   D_WIN32_WINNT=0x0502), we already unconditionally link to the
  
  ConditionVariable functions, since 4622f11f9.
  Similarly use the newer -Ex versions of CreateEvent, CreateSemaphore,
  
  InitializeCriticalSection and WaitForSingleObject, that all appeared
  
  in Vista. When building Windows Store applications, the older versions
  
  of these functions aren’t available, only the -Ex functions. When
  
  doing such a build, the user can set -D_WIN32_WINNT=0x0600 to
  
  forcibly use the newer functions instead.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] compat/w32pthreads.h