The age is very big only then starts to learn the programming __ programming

20080309, so old to start learning programming, not dislike, because things too much, too playful.

from http:// Www.linuxforum.netLiniux Forum to see the Yayong, from four years ago he began to study the compendium, it should be very strong now, then four years ago I was doing,,, to prepare a senior test of the turtle, now my education is the past in the old society of poor farmers, not the working class is not the bourgeoisie, not the present The cadre of the party of the turtle.

Recently busy looking for some information to see the video development of the book, because now the unit engaged in a flame analysis of the temperature software, but the search for a night there is no good things. Storm audio and video did not find the source code. What to do. /。

Not a clue.

Some of the joins found.

About:

Amd

The AMD performance Library is a collection of popular software routines designed to accelerate application, D ebugging, and optimization on x86 class processors. Spanning simple arithmetic routines to rich domains such as image and signal processing, it provides a quick path to high Performance development. APL is available as a static library for 32-or 64-bit versions of Visual C/C + + 8.0, GCC 4.1.2 and Sun Studio, and as a 32-or 64-bit Dynamic Library for the linux®, Solaris and microsoft®windows®operating systems

BLOG

Http://blog.csdn.net/yayong a man who has made progress.

Linux

Http://www.linuxforum.net/forum/showthreaded.php? cat=&board=linuxk&number=615853&page=0&view=collapsed&sb=5&o=31&fpart=

USB Camera Driver Development in Linux system USB camera driver USB photo The image head is widely used for its good performance and low price. At the same time because of its flexible and convenient
Features that are easily integrated into embedded systems. However, it is difficult to make full use of the USB bandwidth, the frame speed is not high, and the real-time monitoring is not easy to use if the existing driver with the video-for Linux standard is combined with the common application. This paper first introduces the general method of USB camera driver in Linux system, and then explains how to improve the frame speed on this basis.
USB device drivers fully conform to common device-driven guidelines, unlike the kernel, which provides special API functions that facilitate driver registration and destroy themselves, such as Usb_resister () and Usb_deresister () 2. The 4 version of the kernel also provides support for HotPlug.

1. 1 USB Camera-driven general writing method
The camera belongs to the video class device. In the current Linux core, video is the standard for Linux (short v4l). This standard actually defines a set of interfaces that the kernel, the driver, and the application use to communicate with the standard. The current v4l covers video, audio stream capture and processing, and USB camera is also part of its support. Therefore, the USB camera driver should be linked to the video drive provided by the kernel. That is, first declare a video_device structure in the drive and assign it an array of file action function pointers. FoPs, register to the system. When the application issues related commands for file operations, the core calls the corresponding functions based on those pointers and passes the struct as a parameter to them. This completes the communication between the driver and the core. For example:

static struct Video_device vdev_template = {...};//Declaration Video_device, indicating hook driven static struct File_operations = {... ...} ;//Declare this driven file action function pointer struct Video_device*vdev = video_devdata (file)//Extract Video_device structure from file pointer

In the Video_device structure, there is a private pointer priv that can be pointed to a piece of reserved memory. In this block of memory, the relevant initialization information of the driver and the device is kept. This block of memory applications, initialization, pointer pointing, and so on are all in the USB-driven enumeration function. Probe. Thus, after the enumeration function returns control to the system, the driver retains its own information because the kernel does not destroy the reserved memory. This is similar to the WDM drivers in Windows systems. Of course, in the driver unload function, the requested blocks of memory should be freed entirely. 1 . 2 using dual URB Alternating communicationAs we all know, USBL. The 1 bus standard defines four kinds of pipes, such as control, interruption, batch, etc. For video capture applications with strong timing but not high accuracy requirements, the camera should use the same time transmission mode. In order to get the image data as quickly as possible, you should specify the USB_ISO_ASAP flag in the URB.

Urb->transfer_flags = USB_ISO_ASAP/Send out the URB as soon as possible

Any USB transmissions in Linux systems are implemented through URB. In order to improve the speed, we can consider enlarging the URB buffer, which can reduce the proportion of handshake information in each USB transaction and improve the transmission speed of valid data. However, limited by bus bandwidth and specific USB device chips, simply enlarging the URB buffer cannot solve the problem indefinitely. The implementation of USB transmission in the operating system is analyzed concretely: Each transmission must include the URB, issuing, recycling, data sorting and so on, these time does not produce the valid data. As a result, two URB can be created, waiting for a URB to be recycled, when the image is being sampled by the sensor, processing, initializing another URB, and sending it immediately after the recycle. Two URB alternate use, greatly reducing the extra time. The workflow is shown in Figure 1. This process is implemented in the completion routines of the URB, there are two points to note: First of all, the initialization of the code time can not be long, otherwise it will result in the completion of the routine, if it is not too late, you can set the flag in the completion routine, such as "good data Acquisition" semaphore by the application blocking IOCTL () To query the semaphore and do the processing, and second, because the CPU may stay in the completion routine for a long time, the system is heavier, you can. The Open function initializes two URB and emits them, with limited ease of system burden. 1 . 3 use double frame buffering to improve efficiencyIn a Linux system, file operations are usually done by system calls such as read, write, and so on. The solution to these system calls is to use Copy_to_user (), Copy_from_user () and other functions to copy each other in both the kernel and the user memory space. However, for large quantities of image data, the method of using copy obviously increases the time cost, so it is solved by the method of memory mapping. First, the Vmalloc () is used to request a large enough kernel memory as the image data buffer space, the image data that two URB brings back is stored here, and then the Remap_page_range () function is used to map it to the user space. The user-State image processing program uses the mmap () function to directly read and write the kernel-state image buffer memory, which greatly reduces the extra overhead. Image data processing may take a long time, different algorithms for data retention time requirements are not the same. Therefore, you can apply for two frame image buffering, while processing a frame image, the two URB data back to the other frame buffer, which can save time conflict trouble. It is noteworthy that this method requires that the current frame number, the starting address of each frame should be held at all times, and the two-frame image cannot be confused. This information can be saved in reserved memory, and the data collation and ordinal change of the current frame is implemented in the URB completion routine. Second, v4l improvement of the standardV4L Standard has now developed to the second edition of V4l2, the basic ideas and v4l the same. 2 . 1 Standard AnalysisAccording to the V4L standard, the CPU trend is shown in Figure 2 when a frame image is needed for a user-state program. The CPU completes a loop in 123456 order. Here, there is a detail that is ignored: in the completion routine, that is, step 6 in Figure 2, the URB is immediately issued, but because the user program is blocking wait, no way to get the image of the application, so in the judgement of the new request, the result of the decision is not currently requested, resulting in the next URB The data brought back is driven to discard, because of the nuclear State, user-state switching requires a certain amount of time, coupled with the cost of the user-state process synchronization, wait until the application can again send a picture of the application, there are more than one URB back of the data is discarded, these URB contains data is exactly the beginning of a new frame image. Therefore, the driver must wait until the next frame of the image to save the data and buffer. In this way, the loss of a frame of image, the frame speed at least half down. 2 . 2 Improved thinking: Continuous acquisitionTo solve this problem, can improve v4l standard, make it add new function: Through new parameters, let Ioetl () function notice drive uninterrupted collection, buffer image data, in turn save in two frame buffer, and after a frame of image collection, set "image collection good" semaphore. The user-state program only needs to issue a "get image" request, it can be blocked waiting for the semaphore, and constantly get the image. At the end of the collection, the new parameters are passed again, so that the driver can stop buffering. The CPU workflow flowchart is shown in Figure 3. Note that in Figure 2, Figure 3, the difference between two "judgments with no new requests," You can find that the new method assumes that there is always a request, so do not discard the data that each URB brings back, and keep it in a two frame buffer in turn. V4L has been supported by the kernel as a conventional standard, so if you use new parameters, the workload will be huge and not compatible with existing applications. Considering that the existing image acquisition application uses vidiocmcapture as a parameter and provides a frame number, it requires the driver to save the image to the frame buffer of the specified ordinal number. Because the drive usually provides only a few frame buffers, the serial number is not greater than a number, such as 10. Therefore, you can continue to use the Vidiocmcapture parameter, with a larger number to represent the new features, such as 10000 and 10001来 respectively to start and stop the buffer image data requirements. The driver checks the serial number after receiving the Vidiocmcapture request. If less than 10000, the normal method is followed, otherwise the improved method is followed. This kind of thinking can solve the compatibility problem effectively. 2 . 3 Experimental Results
In Celeron 366, USBL. 1 interface computer platform, using the above continuous acquisition to improve the V4L standard, with double URB, double frame buffer and other methods, frame speed increased by more than twice times, the effective data transmission speed of 960kb/s, close to the same time transmission mode of the bandwidth limit of the USB bus.

Absrtact: This paper analyzes the architecture of the multimedia device driver and the driver design scheme of the video capture and decompression card. The processing flow of kernel mentality driver is described, and the design idea and specific algorithm of user state driver are provided.

Keywords: driver IRP (Input output request package) Driver Object Device Object

The structure of Windows NT determines that an application cannot directly manipulate hardware devices, and it can read and control devices only through an intermediate layer, which is the driver. The driver is located at the lowest level of the computer software (the HAL is the hardware abstraction layer) and is directly associated with the characteristics of the hardware device. Writing drivers not only to understand the characteristics of the device, but also to understand the structure of the operating system, more difficult. This paper analyzes the driver design of video capture and decompression card in detail.
1 video capture and decompression card driver structure
Multimedia equipment relative to the device, there are two characteristics: large data flow, the deadline is high (ie, real-time requirements are higher). For multimedia devices such as video capture and decompression cards, drivers are written in a specific way. The structure of the multimedia driver is shown in Figure 1. Generally, the level of privilege that is run according to its code can be divided into two tiers: a kernel-mindset driver and a user-state driver. The kernel mentality of the driver is running in core mode. You can execute privilege level directives, have full access to any I/O device, and access any virtual address and control virtual memory hardware.
The user-mode driver is essentially a dynamic-link library (DLL). It runs in the user state, and the application sends a message to the interface requesting a certain operation. They call the WIN32 function and kernel-mode driver communication (the WIN32 function also invokes functions provided by the NT executor, which provide context conversion from user state to kernel mentality). The user-mode driver takes the appropriate action based on the received message and returns the result to the application after the operation completes. But this structure is only suitable for extracting a picture of the bitmap, not suitable for the acquisition and decompression of the device generated video stream.
This card must be collected and extracted, if the design with standard mode, it is necessary to write video capture and video decompression driver, which also to the decompression program to transform, writing complex, especially debugging will be very difficult. In this case, the design scheme can not only meet the requirements, but also reduce the design difficulty.
Kernel-mode drivers are not as different from general drivers as they are for reading data and for device control. User-mode drivers handle most transactions. In the decompression, the driver to the device to write the data to be extracted, from the device to obtain the extracted data, the application to provide an image of RGB data. The data obtained from the device is the 4:2:2 YCRCB format data stored in the field, and the driver converts each frame of data into a row format, which is combined into a complete frame of data (QCIF) for delivery to the application.
2 kernel-mode driver design
Because of the large amount of data in the multimedia, the design of the conventional method (using IRP packet for data transmission) will face an unresolved problem--the interrupt too fast driver will be too late to process. Therefore, a new method must be adopted: to establish two buffers (respectively for reading and writing) in the driver, and the application-layer driver to share the buffer with the core-layer driver. When a device outage occurs, it is processed according to the interrupt that occurred. In the case of a read interrupt, read the data from the device to the buffer, emit a DPC (deferred procedure Call), and notify the application-tier driver that the buffer data is available and that the data can be taken away. In the case of a write interrupt, the data in the buffer is written to the FIFO of the device, and then a DPC is issued notifying the user that the buffer data is invalid and needs to be written to the new data.
The kernel mode exposes the DriverEntry (the driver must have a full journey) interface, the rest of the entire process does not have a fixed name, in order for the I/O Manager to find these routines, the DriverEntry routines are responsible for building these function pointers. The I/O Manager allocates an IRP from non-paged system memory, responds to an I/O request, and transmits the IRP to the appropriate driver dispatch routines based on the user-specified I/O function, dispatch routines to check the parameters of the request, if they are valid, Set up device actions using the content of the IRP. When the operation completes, store the final status code in the IRP and send it back to the I/O manager; the I/O Manager uses the information in the IRP to complete the request and sends the final status to the requester.

When the driver is loaded into the system, the I/O Manager creates a driver object (representing a standalone driver in the system and records the address of each driver's dispatch routine for I/O Management), and then invokes its initialization routine.
The tasks that are accomplished in the DriverEntry this initialization routine are:
• Put the driver's entry into the driver object.
• Use the Vid and did of the device to check each slot on each bus, find this image compression decompression card, and IoCreateDevice create the device object, use Iocreatesymboliclink to establish symbolic connection.
• Initializes the individual components in the device extension placed in the non-paged area. Includes an IRP for reading and writing, and a spin lock to protect the respective queues.
• The device has two proprietary memory and must convert its bus-related address to a system-wide address and map it to the system virtual space. For I/O ports, convert their bus-related addresses to system-wide addresses.
• Allocate two nonpaged caches with ExAllocatePool () and map them to the user's address.
Before the driver reads and writes to the device, it must be further initialized to indicate the purpose of the device driver: decode or encode. The upper driver calls DeviceIoControl to set the working mode, the driver receives this IRP to set the working mode of the compression decompression chip and the parameters of the video acquisition chip and the bus interface chip. The upper driver must call the DEVICEIOC before starting encoding or decoding.

Http://blog.csdn.net/roger_77/archive/2006/03/30/644391.aspx

A

Message is a notification from Windows telling the application that something has happened. For example, clicking a mouse, changing the window size, and pressing a key on the keyboard will cause Windows to send a message to the application. The message itself is passed as a record to the application, which contains the type of message and other information. For example, for a message that is generated by a mouse click, the record contains the coordinates of the mouse click. This record type is called Tmsg, and

is declared this way in the Windows unit:
Type
Tmsg = packed record
hwnd: hwnd;  / /Window handle
message: uint; / /message constant identifier
wparam: wparam ; //  Specific additional information for 32-bit Messages
Specific additional information for lparam: lparam ; // 32 bit messages
time: dword; / / The time at which the message was created
pt: tpoint; / /the mouse position at the time the message was created
end; What is in the

message.
Whether you think the information in a message record is like Greek. If so, take a look at the following explanation:
Hwnd&