You can come up with a score based just on the numbers but at the end of the day it doesn’t mean a whole lot unfortunately. Somebody who encodes videos with an “overkill” bitrate setting would get a higher score by consuming more data, which means longer downloads and more file storage, but doesn’t mean better video. (i.e., I can take a 320×240 video with a web cam in horrid lighting, then resize it to 1080p and encode it at 10mbps bitrate… do I now magically have bluray quality HD video on my hands? Of course not!)

Likewise, motion and solid areas of color will present greatly varying video quality even at the same resolution and bitrate. For example: low motion (say, a slide show), will look great because the contents of the screen do not change often, compared to a high paced fast motion clip… or a cartoon for example will look better than “real life” video at the same bitrate because of larger areas of solid color. Codecs look for these things and handle slower/solid areas much more efficiently by design.

I think the first step is something that actually quantifies the “look” of the video… That’s the hard part… but I guess it can stop there because that’s the goal here. But to take it one step further, you could combine it with the actual bitrate numbers and you can also come up with an “efficiency” score. Say that first step ranks a video from 1 to 10. Work that score into a math formula with the bitrate. If somebody pulls off a “10″ at 1000kbps and somebody else pulls off a “10″ at only 400kpbs, the latter is more efficient – the end user gets top quality video on a quicker download. Ignore codecs all together, because some codecs that may be lower-tech on paper might actually pull off better subjective quality depending on the content of the video. The final efficiency score would be really useful to a viewer to know they’re getting high quality video and making best use of their bandwidth and disk space to get it!

Now, I think the art of coming up with a single number based on such values is called “fuzzy logic”, and it has quite some literature. You might want to take a look at that.

Cheers

Now, quality…
For the first step I’d go the pragmatic way:
If somebody creates a video in HD resolution, he will rarely intentionally squeeze it in low-bitrate files.
The standard shaky-badlight-badcontrast-manyartifacts-youtube video will be LD anyway.

For anything more I’d say you need either lots of calculating time or lots of superbrains, maybe both.
Especially to check several videos in a batch may be time consuming.
However, here are three ideas to perform the actual check:
1. artifact search:
search for 8×8px-blocks that are single-colored and surrounded by a rather different color. (the more the difference, the more the artifactiness
I assume that the blocks will be aligned to 8px-values, like in jpeg. maybe motion-compensation moves them?
2. edge detection:
both bad compression and up-scaling remove hard edges.
3. entropy testing
as entropy is the opposite of compressability, there is not a whole lot of entropy in over-compressed videos.
again, the 8×8 pixel-blocks need to be checked. this time we check how many different colors are in one block.
Thinking about it, this is the same as artifact search… The worst artifact is a block with an entropy of zero.
I remember an article that showed a picture of patterns (wavelets?) that are composed to more complex patterns.
The most basic pattern is empty. following are patterns with one vertical or horizontal gradient. (then more complex waves)
If you look at youtube videos, you may notice exactly those types of artifacts. (single-colored or 2-colored gradient)
If I remember correctly, usually those patterns are combined to more complex ones. But at low bitrates you only get one basic pattern.
so, maybe you would have to look for those patterns.
You can also use the concept of frequency. (which is just another way to look at entropy) low frequency means not a lot of change. High frequencies are cut of by compression.

The algorithms for those things are no secrets. (frequency, entropy, edge detections, artifact detection)
Knowledge about those things is not only used for video codecs but also for image editing, like in gimp.
So, a look at the gimp toolkit or imagemagick source codes may be enlightening. (Or hooking up with the devs there)

No matter which algorithm is used, it only can detect missing details if there *were* details.
So you can not just grab the first frame in the video, as it may be just black or blue with white font on it.
also, keyframes are not good candidates to look for bad quality I guess.

Counting pixels, bitrate, and codec is not too difficult. This can mostly be read out of the files metadata and if you generate some kind of algorithm where you give each of these criterias a weight, you can have a number telling how nice this video COULD HAVE BEEN.

Yes, because this number will not be able to say anything about the quality of the video. That all depends on where the video comes from. Was this originally shot with an HD camera, or is it a 50kb/s streaming video that has been uprezzed?

With this in mind, the first mentioned algorithm is totally meaningless. People will soon start fixing their bad videos just to get higher automatic ratings or better exposure in the system.

The only way to get around this and give the numbers meaning is to employ a system that can actually say something about the quality of the video. And it is possible. A system like this has as far as I know been developed in Norway. I will get back with more details as soon as I have it. I think it has been developed to monitor the quality of broadcast video.

So I say, just pick some numbers and try to tweak them to work well, and don’t worry about things like “optimal”.

Yes, using the Bayesian approach I suggested would require a crop of videos to compare to. If you can’t get or easily generate a database of files’ important attributes and whether they’re HD (e.g. they come from a pre-identified HD channel or non-HD channel), it may not be the best approach. (Though having estimates of the percentages themselves would work too, I doubt you would stumble upon statistics like that on the web.)

Some advantages would include that it can continue to “learn” by user or moderator feedback. Say, an HD video type with specs you didn’t think of comes around, you don’t need to re-code an algorithm. Instead, you mark a video (or a few videos) with those specs as HD and put that info in the database. Similarly, if something gets mis-identified as HD, then that error can be made less likely by continuing to add stats along with a “high/standard def” label to your database as time goes on. Since you said you want the software to help you in weeding out low-resolution video, it seems that having a system that progressively takes more and more load off of humans is a good fit.

Another advantage is mentioned a little in the previous paragraph, but you don’t have to rely on textbook definitions of what an HD video has.

I really think spam filter example demonstrates well how the system works, except that the spammers keep trying to trick Bayesian filters by obfuscating the things that would identify it as spam. In this usage, there seems to be no reason for video encoders to try to fool the system.

It may or may not be a good fit. I’m getting a degree in stats and this was the first thing that came to mind.