Recherche avancée

Sur d’autres sites (7659)

• Parsing An ArrayList of BufferedImages From FFmpeg

  4 juin 2015, par user3725743

  I am using FFmpeg in my java app to turn a video into an ArayList of BufferedImages. Im am using this code to split a video file into individual jpg frames :

  builder.command(FFmpeg, "-i", "<video url="url">", "-vf", "fps=5,scale=128:128,format=rgb8,format=rgb24", "out%d.jpg");
  
  </video>

  This produces a folder full of jpg frames, it works fine. But I would rather not write them to individual files, I would rather make that output turned into an ArrayList of BufferedImages, WITHOUT having to write each frame to a seperate file.

  This should be what the command line would look like for the above code :

  FFmpeg.exe -i <video url="url"> -vf fps=5,scale=128:128,format=rgb8,format=rgb24 out%d.jpg
  
  </video>

  If its not possible to parse the ArrayList directly, what other solutions do I have which would be more elegant ?

• Is there a way to eliminate seek time when decoding part of a video using ffmpeg ?

  17 décembre 2019, par Babis

  I’ve got some MKV videos encoded with FFV1. For each of the frames, I want to run some complex and time-intensive python or matlab code, so I’m using multithreading, where each thread works on an individual image.

  I’ve tried extracting a single frame from the video using -ss, but it’s terribly inefficient.

  The most efficient way is to decompress everything into images in one go, but then I’m writing to disk, and then I’ll be reading from disk, therefore it’s not ideal either.

  I’ve tried using a ram disk to export images to, and reading them from python/matlab, but it’s not great performance-wise either. Also, I have to split the export into several batches, as the video file is 20GB and all of the exported images will not fit into memory

  Is there a way to rapidly extract individual frames from ffmpeg directly into RAM (or ram disk), so that they can be used by another program ? For example using something like a lookup-table.

  For reference, each video is about 20GB, comprised of 50000 frames, and they are all keyframes (it’s for archival purposes)

• Google’s YouTube Uses FFmpeg

  9 février 2011, par Multimedia Mike — General

  Controversy arose last week when Google accused Microsoft of stealing search engine results for their Bing search engine. It was a pretty novel sting operation and Google did a good job of visually illustrating their side of the story on their official blog.

  This reminds me of the fact that Google’s YouTube video hosting site uses FFmpeg for converting videos. Not that this is in the same league as the search engine shenanigans (it’s perfectly legit to use FFmpeg in this capacity, but to my knowledge, Google/YouTube has never confirmed FFmpeg usage), but I thought I would revisit this item and illustrate it with screenshots. This is not new information— I first empirically tested this fact 4 years ago. However, a lot of people wonder how exactly I can identify FFmpeg on the backend when I claim that I’ve written code that helps power YouTube.

  Short Answer
  How do I know YouTube uses FFmpeg to convert multimedia ? Because :

  1. FFmpeg can decode a number of impossibly obscure multimedia formats using code I wrote
  2. YouTube can transcode many of the same formats
  3. I screwed up when I wrote the code to support some of these weird formats
  4. My mistakes are still present when YouTube transcodes certain fringe formats

  Longer Answer (With Pictures !)
  Let’s take a video format named RoQ, developed by noted game designer Graeme Devine. Originated for use in the FMV-heavy game The 11th Hour, the format eventually found its way into the Quake 3 engine as well as many games derived from the same technology.

  Dr. Tim Ferguson reverse engineered the format (though it would later be open sourced along with the rest of the Q3 engine). I wrote a RoQ playback system for FFmpeg, and I messed up in doing so. I believe my coding error helps demonstrate the case I’m trying to make here.

  Observe what happened when I pushed the jk02.roq sample through YouTube in my original experiment 4 years ago :

  
  
  

  Do you see how the canyon walls bleed into the sky ? That’s not supposed to happen. FFmpeg doesn’t do that anymore but I was able to go back into the source code history to find when it did do that :

  
  
  

  Academic Answer
  FFmpeg fixed this bug in June of 2007 (thanks to Eric Lasota). The problem had to do with premature colorspace conversion in my original decoder.

  Leftovers
  I tried uploading the video again to see if the problem persists in YouTube’s transcoder. First bit of trivia : YouTube detects when you have uploaded the same video twice and rejects the subsequent attempts. So I created a double concatenation of the video and uploaded it. The problem is gone, illustrating that the backend is actually using a newer version of FFmpeg. This surprises me for somewhat esoteric reasons.

  Here’s another interesting bit of trivia for those who don’t do a lot of YouTube uploading— YouTube reports format details when you upload a video :

  
  
  

  So, yep, RoQ format. And you can wager that this will prompt me to go back through the litany of unusual formats that FFmpeg supports to see how YouTube responds.