Incredible robotic creation device. Just imagine if we had swarms of synced devices.
Tired of screen-scraping the output of ffmpeg and/or mplayer to get the parameters / clip info for a media file?
This hook attempts to remedy this by printing simple information about the passed in video from the cmd line.
It will also print out whether or not the clip is using “rectangular pixels”.
Well, the easiest examples are DVDs. You only want to buy a DVD if it says one of two standard phrases on it — “Enhanced for 16:9 TVs” or “Anamorphic widescreen“. They both mean the same thing — namely that the video on the DVD disk is wider than 4:3 aspect (pretty much all films are ratio 16:9 or even wider like ratio 2.35:1) *and* that it didn’t *waste* any DVD bytes by encoding “top/bottom black bars”. (If it doesn’t say those code phrases, it’s an older, crappy/low budget produced, or worse a “pan-n-scan” chopped film (where they lop off the left and right sides of each frame to fit into a 4:3 TV!) Worst yet, if the DVD only says something like “widescreen version”, though it sounds good, it means while they didn’t cut off the picture, they wasted 25% (or more!) of the pixels encoding “black bars” on the top and bottom. So you have less pixels in the DVD encoding the picture compared to an “anamorphic” version of the same thing. Hello crappy quality!)
Now look at this:
4:3 video == 1.33 ratio == 640×480 pixels image
16:9 video == 1.78 ratio == 854×480 pixels image
so what is 720×480? it’s almost perfectly in the middle of those two — math: 720/480 = 1.5
So the “encoded transport image size” is neither 16:9, nor 4:3 — it’s right in the middle, capable to encode either a 4:3 video (like non-high def TV, many computer screens) or 16:9 video (high def TV, some digital video). I like to think of it as “how the formats that came out right before HDTV took off, compromised to hedge there bets to be between 4:3 and 16:9″.
The final critical bit of information about a DVD is the “aspect ratio” (not of the overall image, confusingly, but of each encoded *pixel*!) This says “wait, this pixel isn’t square, literally, like you’d think if you just read the image — it’s actually supposed to be stretched to make the *overall image* either 640 pixels wide (squoosh down from 720) or 854 (stretch wider to 854). So the video track is “flagged” with a “pixel aspect” (often referred to as PAR (Pixel Aspect Ratio), SAR (Sample Aspect Ratio), or DAR (Display Aspect Ratio) — some of those have some slight nuances/differences, but that’s digging too deep). Anyway, neat, huh? Your anamorphic DVD is a changeling! (maybe “anamorphic” makes more sense mnemonically now 8-) (PS: “DV” video — the most common format that digital camcorders that write to tape use — is similar. 720×480 pixels/image plus a “flag” for what each pixel “shape” is).
This hook I wrote will output information about the clip (like “ffmpeg -i” will do, but in a format easier to parse) as well as information about the pixels (unlike ffmpeg). So you can then know more about a clip if you are going to do things like pull single frames/thumbnails from it or convert it to another format. We have been using this at Internet Archive for our movies for over a year and a half now and it works great!
There are some instructions for compiling with an ffmpeg source at the top of the C code. (There is also an ubuntu-on-AMD compiled “.so” at that link by changing the suffix from “.c” to “.so”, FWIW)
CODE:
Recent Comments