像素是什么
分辨率是用于度量位图图像内数据量多少的一个参数，通常用像素来表示。简单地说，摄像头的分辨率是指摄像头解析图象的能力，也即摄像头的影像传感器的像素数。最高分辨率就是指摄像头能最高分辨图像能力的大小，即摄像头的最高像素数。现在市面上较多的30万像素CMOS的最高分辨率一般为640480像素，50万像素CMOS的最高分辨率一般为800600像素。分辨率的两个数字表示的是图片在长和宽上占的点数的单位，一张数码图片的长宽比通常是4：3。
在实际应用中，摄像头的像素越高，拍摄出来的图像品质就越好，但另一方面也并不是像素越高越好，对于同一画面，像素越高的产品它的解析图像的能力也越强，但相对它记录的数据量也会大得多，所以对存储设备的要求也就高得多。
其实，这些摄像头像素是通过软件插值提高的。举例的话，简单的说就是将640X480的图片拉大到1024X768，然后再利用软件计算图片分辨率点之间的色彩区别，把中间拉大的部分填入软件计算的颜色。这样做虽然输出的图片大了，但是图像的质量并没有得到真正有效的提高，甚至还有可能出现严重失真。
值得注意的一点：有些分辨率的标识是指这些产品利用软件所能达到的插值分辨率，虽然说也能适当提高所得图像的精度，但和硬件分辨率相比还是有着一定的差距的
所以，大家在选购摄像头时一定要牢记：摄像头像素的高低与图像的清晰度是没有绝对关系的。特别是对于那些通过软件插值而高达几百甚至几千万像素的摄像头来说，实际效果很有可能与几十万像素的差不多。总的来说，图像是否清晰，光看像素可是不行的，它还与镜头材质、软件处理等其它各方面息息相关。
摄像头的一些技术指标
1、 图像解析度/分辨率(Resolution)：
SXGA(1280 x1024)又称130万像素
XGA(1024 x768)又称80万像素
SVGA(800 x600)又称50万像素
VGA(640x480)又称30万像素(35万是指648X488)
CIF(352x288) 又称10万像素
SIF/QVGA(320x240)
QCIF(176x144)
QSIF/QQVGA(160x120)
2、图像格式(image Format/ Color space)
RGB24,I420是目前最常用的两种图像格式。
RGB24：表示R、G、B三种颜色各8bit，最多可表现256级浓淡，从而可以再现256*256*256种颜色。
I420：YUV格式之一。
其它格式有: RGB565，RGB444，YUV4:2:2等。
国足与摄像头上：国足，不可信，有时候却不得不看；摄像头像素，更不可信，有时候却又不得不买！总之，睁大自己的眼睛，认真理性选购才是目前最好的选择。
error LNK2001: unresolved external symbol _MEDIASUBTYPE_I420
错误原因：_MEDIASUBTYPE_I420 未定义。
解决方案：Link选项卡中需要添加某个特定的LIB文件。
-----------
参考微软开发论坛上的发帖，有人建议搜索含“：_MEDIASUBTYPE_I420”的代码，并且注释掉。
原帖地址为：http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2516288&SiteID=1
------------
附：
LINK2001的MSDN原文：
Linker Tools Error LNK2001
unresolved external symbol “symbol“
Code will generate this error message if it references something (like a function, variable, or label) that the linker can’t find in all the libraries and object files it searches. In general, there are two reasons this error occurs: what the code asks for doesn’t exist (the symbol is spelled incorrectly or uses the wrong case, for example), or the code asks for the wrong thing (you are using mixed versions of the libraries?some from one version of the product, others from another version).
Numerous kinds of coding and build errors can cause LNK2001. Several specific causes are listed below, and some have links to more detailed explanations.
Coding Problems
Mismatched case in your code or module-definition (.DEF) file can cause LNK2001. For example, if you named a variable “var1” in one C++ source file and tried to access it as “VAR1” in another, you would receive this error. The solution is to exactly match the case of the symbol in all references.
A project that uses function inlining yet defines the functions in a .CPP file rather than in the header file can cause LNK2001.
If you are using C++, make sure to use extern “C” when calling a C function from a C++ program. By using extern “C” you force the use of the C naming convention. Be aware of compiler switches like /Tp or /Tc that force a file to be compiled as a C (/Tc) or C++ (/Tp) file no matter what the filename extension, or you may get different function names than you expect.
Attempting to reference functions or data that don’t have external linkage causes LNK2001. In C++, inline functions and const data have internal linkage unless explicitly specified as extern.
A missing function body or variable will cause LNK2001. Having just a function prototype or extern declaration will allow the compiler to continue without error, but the linker will not be able to resolve your call to an address or reference to a variable because there is no function code or variable space reserved.
Name decoration incorporates the parameters of a function into the final decorated function name. Calling a function with parameter types that do not match those in the function declaration may cause LNK2001.
Incorrectly included prototypes will cause the compiler to expect a function body that is not provided. If you have both a class and non-class implementation of a function F, beware of C++ scope-resolution rules.
When using C++, make sure that you include the implementation of a specific function for a class and not just a prototype in the class definition.
Attempting to call a pure virtual function from the constructor or destructor of an abstract base class will cause LNK2001 since by definition a pure virtual function has no base class implementation.
Only global functions and variables are public.
Functions declared with the static modifier by definition have file scope. Static variables have the same limitation. Trying to access any static variables from outside of the file in which they are declared can result in a compile error or LNK2001.
A variable declared within a function (a local variable) can only be used within the scope of that function.
C++ global constants have static linkage. This is different than C. If you try to use a global constant in C++ in multiple files you get error LNK2001. One alternative is to include the const initializations in a header file and include that header in your .CPP files when necessary, just as if it was a function prototype. Another alternative is to make the variable non-constant and use a constant reference when assessing it.
Compiling and Linking Problems
The names of the Microsoft run-time and MFC libraries needed at link time are included in the object file module by the Microsoft compiler. If you use the /NOD (/NODEFAULTLIB) option, these libraries will not be linked into the project unless you have explicitly included them. Using /NOD will cause error LNK2001 in this case.
If you are using Unicode and MFC, you will get an unresolved external on _WinMain@16 if you don’t create an entrypoint to wWinMainCRTStartup. Use the /ENTRY option or type this value in the Project Settings dialog box. (To find this option in the development environment, click Settings on the Project menu, then click the Link tab, and click Output in the Category box.) See Unicode Programming Summary.
See the following Knowledge Base articles located in the Online Information System for more information. An easy way to reach an article is to copy a “Q“ number above, open the Search dialog box from the Help menu and select the Query tab, then paste the number into the first text box and press ENTER.
Q125750 “PRB: Error LNK2001: ’_WinMain@16’: Unresolved External Symbol“
Q131204 “PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16“
Q100639 “Unicode Support in the Microsoft Foundation Class Library“
Linking code compiled with /MT with the library LIBC.LIB causes LNK2001 on _beginthread, _beginthreadex, _endthread, and _endthreadex.
When compiling with /MD, a reference to “func“ in your source becomes a reference “__imp__func“ in the object since all the run-time is now held within a DLL. If you try to link with the static libraries LIBC.LIB or LIBCMT.LIB, you will get LNK2001 on __imp__func. If you try to link with MSVCxx.LIB when compiling without /MD you will not always get LNK2001, but you will likely have other problems.
Linking code compiled with an explicit or implicit /ML to the LIBCMT.LIB causes LNK2001 on _errno.
Linking with the release mode libraries when building a debug version of an application can cause LNK2001. Similarly, using an /Mxd option (/MLd, /MTd, or /MDd) and/or defining _DEBUG and then linking with the release libraries will give you potential unresolved externals (among other problems). Linking a release mode build with the debug libraries will also cause similar problems.
Mixing versions of Microsoft libraries and compiler products can be problematic. A new compiler version’s libraries may contain new symbols that cannot be found in the libraries included with previous versions. Use DUMPBIN to find out if a symbol is in a 32-bit object file or library.
There is currently no standard for C++ naming between compiler vendors or even between different versions of a compiler. Therefore linking object files compiled with other compilers may not produce the same naming scheme and thus cause error LNK2001.
Mixing inline and non-inline compile options on different modules can cause LNK2001. If a C++ library is created with function inlining turned on (/Ob1 or /Ob2) but the corresponding header file describing the functions has inlining turned off (no inline keyword), you will get this error. To prevent this problem, have the inline functions defined with inline in the header file you are going to include in other files.
If you are using the #pragma inline_depth compiler directive, make sure you have a value of 2 or greater set, and make sure you are using the /Ob1 or /Ob2 compiler option.
Omitting the LINK option /NOENTRY when creating a resource-only DLL will cause LNK2001.
Using incorrect /SUBSYSTEM or /ENTRY settings can cause LNK2001. For example, if you write a character-based application (a console application) and specify /SUBSYSTEM:WINDOWS, you will get an unresolved external for WinMain. For more information on these options and entry points, see the /SUBSYSTEM and /ENTRY linker options.
Export Problems
When you are porting an application from 16 to 32 bits, LNK2001 can occur. The current 32-bit module-definition (.DEF) file syntax requires that __cdecl, __stdcall, and __fastcall functions be listed in the EXPORTS section without underscores (undecorated). This differs from the 16-bit syntax, where they must be listed with underscores (decorated). For more information, see the description of the EXPORTS section of module-definition files.
Any export listed in the .DEF file and not found will cause LNK2001. This could be because it does not exist, is spelled incorrectly, or uses decorated names (.DEF files do not take decorated names).
This error message is followed by fatal error LNK1120.
YV12和I420的区别 yuv420和yuv420p的区别
YUV420， I420
意义:每像素12bit
或表示为IYUV,数码摄像机专用表示法.
这里需要注意的是，虽然YV12也是（4：2：0），但是YV12和I420的却是不同的，在存储空间上面有些区别。如下：
YV12 ： 亮度（行×列） + V（行×列/4) + U（行×列/4）
YUV420 ： 亮度（行×列） + U（行×列/4) + V（行×列/4）
可以看出，YV12和I420基本上是一样的，就是UV的顺序不同。
-I420
