Application-level SD card space management

Abstract

The present invention relates to an application-level SD card space management. An apparatus includes a removable media interface circuit and a processor. The removable media interface can be configured to read a file and write the file to a non-volatile storage medium. The processor can be configured to generate encoded data and manage file operations, which involve storing the encoded data on the non-volatile storage medium to minimize the number of file fragments.

Description

Technical Field

[0001] The present invention relates generally to storage interfaces, and more particularly to methods and / or apparatus for implementing application-level Secure Digital (SD) card space management. Background Art

[0002] When a digital video recorder (DVR) product encodes multiple streams, the streams are saved to a Secure Digital (SD) card simultaneously. When multiple streams are saved to the SD card simultaneously, the SD card can become very fragmented. Extensive fragmentation of the SD card will slow down the write speed. When the write speed is sufficiently reduced, the DVR product will not be able to write the video data to the SD card fast enough, resulting in loss of video data. DVR products write and delete files on the SD card very frequently. Frequent writing and deleting of files causes a lot of fragmentation of the SD card, which ultimately results in a lower write speed. Data loss then occurs.

[0003] It is desirable to implement application-level Secure Digital (SD) card space management that reduces fragmentation. Summary of the invention

[0004] The present invention encompasses aspects relating to an apparatus including a removable media interface circuit and a processor. The removable media interface may be configured to read a file and write the file to a non-volatile storage medium. The processor may be configured to generate encoded data and manage file operations involving storing the encoded data on the non-volatile storage medium to minimize the amount of file fragmentation.

[0005] In some embodiments of the apparatus aspects described above, the non-volatile storage medium may be formatted using a virtual file allocation table (vFAT) file system or an extended file allocation table (exFAT) file system.

[0006] In some embodiments of the apparatus aspects described above, the non-volatile storage medium may include a Secure Digital (SD) card.

[0007] In some embodiments of the apparatus aspects described above, the processor typically implements an application-level space management scheme to create, remove, overwrite, and resize files to avoid fragmentation of files. In some embodiments in which the processor implements the application-level space management scheme, the application-level space management scheme provides a user space application program interface to allocate and release space in a non-volatile storage medium using file block units.

[0008] In some embodiments of the apparatus aspects described above, the processor may be configured to encode the data into an MPEG-4 compliant file.

[0009] In some embodiments of the apparatus aspects described above, the processor may be configured to encode the video data into an MPEG-4 compliant video file.

[0010] In some embodiments of the apparatus aspects described above, the removable media interface circuit and the processor may be part of a digital recorder product.

[0011] In some embodiments of the apparatus aspects described above, the removable media interface circuit and processor may be part of a digital video recorder product.

[0012] In some embodiments of the apparatus aspects described above, the removable media interface circuit and the processor are part of a drive recorder product.

[0013] In some embodiments of the apparatus aspects described above, the removable media interface circuit and the processor are part of a digital camera system-on-chip (SoC) product.

[0014] In some embodiments of the apparatus aspects described above, the apparatus may further include an image sensor configured to generate video data and transmit the video data to the processor.

[0015] The present invention also covers aspects relating to a method of managing a storage medium, the method comprising: generating encoded data using a processor; and managing file operations involving storing the encoded data on a non-volatile storage medium using the processor to minimize the amount of file fragmentation.

[0016] In some embodiments of the method aspects described above, the non-volatile storage medium may be formatted using a virtual file allocation table (vFAT) file system or an extended file allocation table (exFAT) file system.

[0017] In some embodiments of the method aspects described above, the non-volatile storage medium may include a Secure Digital (SD) card.

[0018] In some embodiments of the method aspects described above, the processor may implement an application-level space management scheme to create, remove, overwrite, and resize files to avoid fragmentation of files. In some embodiments in which the processor implements the application-level space management scheme, the application-level space management scheme may provide a user space application program interface to allocate and release space in a non-volatile storage medium using file block units.

[0019] In some embodiments of the method aspects described above, the encoded data is encoded as an MPEG-4 compliant file.

[0020] In some embodiments of the method aspects described above, the encoded data includes video data and is encoded as a video file compliant with MPEG-4.

[0021] In some embodiments of the method aspects described above, the method further comprises: generating video data using the image sensor; and transmitting the video data to the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Embodiments of the invention will become apparent from the following detailed description, appended claims and accompanying drawings.

[0023] Figure 1 is a block diagram illustrating an example implementation of a file management layer according to an embodiment of the present invention in the context of a camera.

[0024] Figure 2 is a diagram illustrating a novel file management layer according to an example embodiment of the present invention.

[0025] Figure 3 is a flow chart illustrating a user space application program interface (API) for writing a file according to an example embodiment of the present invention.

[0026] Figure 4 is a flow chart illustrating a user space application program interface (API) for deleting a file according to an example embodiment of the present invention.

[0027] Figure 5 is a flow chart illustrating a user space application program interface (API) for creating a file according to an example embodiment of the present invention.

[0028] Figure 6 is a diagram showing a comparison between a conventional file management layer and a file management layer according to an exemplary embodiment of the present invention.

[0029] Figure 7 It is shown Figure 6 FIG. 5 is a diagram of an enlarged view of portion 504 of FIG. 5 , which illustrates fragmentation performance using a file management layer according to an example embodiment of the present invention.

[0030] Figure 8 It is shown Figure 7 FIG. 5 is a diagram of an enlarged view of portion 510 of FIG. 5 , which illustrates fragmentation performance for files indexed from 0 to 100 using a file management layer according to an example embodiment of the present invention.

[0031] Fig. 9 It is shown Figure 7 FIG. 5 is a diagram of an enlarged view of portion 512 of FIG. 5 , which illustrates fragmentation performance for files indexed from 600 to 700 using a file management layer according to an example embodiment of the present invention.

[0032] Fig.10 It is shown Figure 7 FIG. 5 is a diagram of an enlarged view of portion 514 of FIG. 5 , which illustrates fragmentation performance for files indexed from 1200 to 1300 using a file management layer according to an example embodiment of the present invention.

[0033] Fig.11 is a diagram of a camera system illustrating an example implementation of a computer vision system in which a file management layer according to an example embodiment of the present invention may be utilized. DETAILED DESCRIPTION

[0034] Embodiments of the present invention include providing application-level secure digital (SD) card space management, which can: (i) create file block units; (ii) provide an application program interface (API) that allows users to allocate / release space by file block units; (iii) eliminate file fragmentation; (iv) avoid write speed reduction; (v) provide create, delete and write commands to the upper layer of the storage protocol and / or (vi) be implemented as one or more integrated circuits.

[0035] Typically, there are two file writing scenarios in digital video recorder (DVR) products. In the first scenario, the size of the recorded file remains constant over time. The first scenario usually represents normal recording. In the second scenario, the size of the recorded file keeps changing. The second scenario usually represents manual recording controlled by the end user or event recording triggered by an emergency. When using vFAT (virtual file allocation table) as the file system, fallocate() is a recommended solution for scenario 1. However, fallocate() does not work for file writing scenarios where the size of the recorded file keeps changing (e.g., scenario 2).

[0036] In various embodiments, an application-level secure digital media (SD) card space management scheme designed to solve the problem in file writing situation 2 can be implemented. In various embodiments, an application-level secure digital media (SD) card space management scheme is provided to wrap a layer for users to create / delete / overwrite files / resize files, rather than directly using the vFAT file system application program interface (API). The application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention generally allows users to avoid file fragmentation that may occur when using the vFAT file system application program interface (API) directly. Typically, the application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention is used with vFAT and can also be extended to the exFAT (extended file allocation table) file system.

[0037] In an example, an application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention can be implemented in Linux. However, the application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention is not limited to Linux. The application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention can also be implemented for other operating systems that use vFAT / exFAT to record data (e.g., video data, sensor data, etc.) to protect data media (SD) cards. The application-level secure digital media (SD) card space management scheme according to an embodiment of the present invention can also be implemented for other types of media, including but not limited to universal serial bus (USB) storage devices, hard disk drives (HDDs), etc., as long as the specific type of media is formatted as vFAT / exFAT.

[0038] Traditional file management in video recorders directly calls the system API, resulting in very fragmented files when recording (for example, the following combined Figure 4 In various embodiments, a new file management layer (eg, referred to herein as Amba_File_Manager) is implemented to provide a new wrapped user space API and manage the file system to reduce and / or avoid fragmentation.

[0039] refer to Figure 1 , a block diagram illustrating an embodiment of the present invention in the context of a digital recorder 70 is shown. In an example embodiment, the digital recorder 70 can be coupled to a non-volatile storage medium 72. In an example, the non-volatile storage medium 72 can be implemented as a removable medium. In an example, the non-volatile storage medium 72 can include a secure digital media (SD) card. However, other types of media (e.g., a universal serial bus (USB) storage device, a hard disk drive (HDD), etc.) can be implemented accordingly. Typically, the storage medium 72 is formatted as vFAT / exFAT. In various embodiments, the digital recorder 70 can receive multiple data streams (e.g., DATASTREAM(S)). The stream DATASTREAM(S) can be received from various sources.

[0040] In an example, streams may be received from one or more video sources (or cameras) and / or one or more sensors (e.g., security, vehicle, etc.). In various embodiments, the streams may include multiple video streams from different video sources (e.g., cameras around a building, around a vehicle, etc.). In various embodiments, the digital recorder 70 may be implemented as a solid-state handheld camcorder, a sports camera, a dash cam in a vehicle, or part of an integrated digital video recorder or other digital recorder product. In some embodiments implementing a vehicle camera, the digital recorder 70 may be configured for single view and / or dual view camera configurations, thereby supporting video recording through the front windshield as well as through the rear window or vehicle interior.

[0041] In some embodiments, the stream may include multiple video streams having different resolutions and / or formats. In some embodiments, the stream may include multiple sensor data streams having different resolutions and / or formats. Typically, the mix / combination of data streams is not fixed and may vary based on the standards of a particular application or product. In various embodiments, the streams of data may be simultaneously recorded on the non-volatile storage medium 72 using a file management layer according to an embodiment of the present invention. Typically, the same file management layer according to an embodiment of the present invention may be applied regardless of where the stream of data is received from and what resolution and / or format the stream of data includes.

[0042] In some embodiments, the digital recorder 70 may include one or more circuits configured to implement a digital video recorder. In an example, the electronic components of the digital recorder 70 may be implemented as one or more integrated circuits. In an example, an application specific integrated circuit (ASIC) or a system on a chip (SoC) may be used to implement the processing portion of the digital recorder 70. In an example embodiment, the digital recorder 70 may include a block (or circuit) 74 and / or a block (or circuit) 76. The circuit 74 may implement a processor circuit. The circuit 76 may implement a non-volatile memory (NVM) interface (I / F). The digital recorder 70 may include other components (not shown). The number, type and / or function of the components of the digital recorder 70 may vary according to the design criteria of a specific implementation.

[0043] Processor circuit 74 may be implemented as an embedded processor (e.g., ARM, etc.). In some embodiments, processor 74 may include multiple hardware blocks (or units) configured for digital recording, computer vision tasks, and controlling one or more image processing operations (e.g., noise reduction, sharpening, etc.) performed on one or more data streams. In some embodiments, processor 74 may include block (or circuit) 78. Circuit 78 may be implemented as embodied software or firmware. Software or firmware embodied in circuit 78 may include portion (or code or routine) 100. Portion 100 may implement a file management layer according to an embodiment of the present invention.

[0044] refer to Figure 2 , a block diagram illustrating a file management layer according to an example embodiment of the present invention is shown. In an example, a digital recorder 70 may be configured to implement a digital video recorder (DVR) product. In an example, the DVR product may include an application 80, a system kernel 90, and a file management layer 100 according to an embodiment of the present invention. In an example, the application 80 may be implemented to write a file encoded in accordance with MPEG-4 to a removable storage medium (e.g., a non-volatile storage medium 72).

[0045] In an example, the removable storage medium may include a secure digital (SD) card. In an example, the application 80 may be configured to perform operations such as opening, closing, reading, writing, searching, etc. In an example, the application 80 may issue an open command (e.g., MP4_OPEN()) to request to open a file. In another example, the application 80 may issue a write command (e.g., MP4_WRITE()) to write to an already opened file. In various embodiments, the application 80 may transmit the commands MP4_OPEN and MP4_WRITE to the file management layer 100.

[0046] In various embodiments, the file management layer 100 may be configured to issue a system call to the system kernel 90 in response to a command received from the application 80. In an example, the system call may perform operations such as opening, closing, reading, writing, searching, file allocation, file splitting, etc. In an example, the system kernel 90 may be implemented as a Linux kernel of a Linux operating system. In various embodiments, the operation of the application 80 and the file management layer 100 typically occurs in user space.

[0047] In kernel space, system kernel 90 converts communications from file management layer 100 into operations in the physical layer of the digital video recorder product. In an example, system kernel 90 may direct file access requests to removable storage media (e.g., SD card) in the peripheral device space of the digital video recorder product (not shown).

[0048] In various embodiments, according to an example embodiment of the present invention, the file management layer 100 may include a DVR storage manager 102, a file I / O manager 104, and a file manager (e.g., AMBA_FILE_MANAGER) 106. In an example, the DVR storage manager 102 may be configured to manage storage space available for a DVR product. In various embodiments, the DVR storage manager 102 is generally responsible for issuing a user space delete command (e.g., AMBA_DELETE()) to reclaim a unit file from a file that is no longer needed. The unit file size is the minimum size managed by the DVR storage manager 102. In various embodiments, the DVR storage manager 102 generally transmits the user space delete command to the file manager 106.

[0049] In various embodiments, the unit file size is programmable. In an example, the unit file size can be set to 16MB, 32MB, etc. In various embodiments, the unit file size can be set based on a balance of predetermined criteria. In an example, the criteria for determining a specific unit file size can include the level of fragmentation and the space wasted per file. The final decision is usually a trade-off between these two criteria. In various embodiments, the unit file size selection strategy can depend on the specific features of the product.

[0050] In an example embodiment, a single stream can be recorded with different recording cycles. In the first case, a coded stream with a bit rate of 1Mbyte / s is recorded to a file every 15 seconds, and the size of one recorded file will be 1Mbyte / s*15s=15Mbytes. If a unit file size of 8Mbytes is selected, a unit file (file_record) of 8Mbytes will be created once the recording process starts. When the size of the write becomes larger than 8Mbytes, another unit file of 8Mbytes will be created and merged to "file_record". The recorded file will eventually contain a fragment, and 8Mbytes*2-15Mbytes=1Mbyte of storage space will be wasted. If a unit file size of 16Mbytes is selected, a unit file of 16Mbytes can be created each time the recording process is started. There will be no fragments within the file, and 16Mbytes-15 Mbytes=1Mbyte will be wasted due to the unit file size. If a unit file size of 32Mbytes is selected, a 32Mbyte file will be created each time the recording process is started. There will not be any fragmentation within the file and due to the unit file size, 32Mbytes - 15Mbytes = 17Mbytes will be wasted. In the above example, the option of selecting a unit file size of 16Mbytes appears to provide a better balance to the criteria.

[0051] In an example embodiment where two streams can be recorded at different recording periods, a first recording file (e.g., File_1) can be written every 32 seconds by a first encoded stream with a bit rate of 1 Mbyte / s, and a second recording file (e.g., File_2) can be written every 24 seconds by a second encoded stream with a bit rate of 1 Mbyte / s. In this example, the size of the first recording file File_1 will be 32s×1Mbytes / s=32Mbytes, and the size of the second recording file File_2 will be 24s×1Mbytes / s=24Mbytes. If a unit file size of 8Mbytes is selected, File_1 will contain 4 fragments, and File_2 will contain 3 fragments. In both cases, no space is wasted in either file. If a unit file size of 16Mbytes is selected, File_1 will contain 2 fragments, and File_2 will also contain 2 fragments. The result for File_1 is very good because no space is wasted. However, for File_2, 8Mbytes will eventually be wasted (e.g., 32Mbytes-24Mbytes=8Mbytes). If a unit file size of 15Mbytes is selected, File_1 will contain 3 fragments to cover the recording requirements, and File_2 will contain 2 fragments. For File_1, the amount of wasted space will be 15Mbytes×3-32Mbytes=13Mbytes. For File_2, the amount of wasted space will be 30Mbytes-24Mbytes=6Mbytes. Here, it is difficult to determine which unit file size is the best choice. For applications that are more tolerant of fragmentation, the first option can be determined as the best choice, while for applications that are more tolerant of wasted space, the second option can be determined as the best choice.

[0052] In various example embodiments, the file I / O manager 104 may be configured to receive commands (e.g., MP4_OPEN(), MP4_WRITE(), etc.) transmitted by the application 80 to the file management layer 100. The file I / O manager 104 is typically configured to generate a user space command for creating a file (e.g., AMBA_CREATE()) and a user space command for writing a file (e.g., AMBA_WRITE()) in response to the commands MP4_OPEN() and MP4_WRITE() received from the application 80, respectively. The file I / O manager 104 is typically configured to transmit the commands AMBA_CREATE() and AMBA_WRITE() to the file manager 106.

[0053] In various embodiments, the file manager 106 is generally configured to issue system calls (e.g., open, write, read, fallocate, split, etc.) to the system kernel 90. The file manager 106 may be configured to generate system calls such as open, write, read, fallocate, split, etc. in response to receiving one or more of the user space commands AMBA_DELETE(), AMBA_CREATE(), and AMBA_WRITE() from the DVR storage manager 102 and the file I / O manager, respectively.

[0054] refer to Figure 3 , a flowchart illustrating a process 200 for implementing a user space application program interface (API) for generating a system call for writing a file according to an example embodiment of the present invention is shown. In an example, the process (or method) 200 may include steps (or states) 202, 204, 206, 208, 210, 212, 214, 216, and 218. In step 202, the process 200 may receive an AMBA_WRITE command and associated parameters. In an example, the parameters may include, but are not limited to, a file descriptor (e.g., FD) for an open file, a source data buffer pointer (e.g., P_BUFFER), a size of data to be written to the open file (e.g., SIZE), and / or a full file path name (e.g., FULL_FILE_PATH_NAME) for an open file FD.

[0055] In step 204, the process may determine whether the file available size is greater than the size specified by the parameter SIZE of the AMBA_WRITE command. When the file available size is greater than the value specified by the parameter SIZE, the process 200 may move to step 206 to generate a system call to write the data identified by the parameters FD and P_BUFFER of the AMBA_WRITE command. Then, the process 200 may move to step 208 and terminate.

[0056] When the file available size is not greater than the value specified by the parameter SIZE, the process 200 may move to step 210. In step 210, the process 200 may determine whether the current unit file being managed by the DVR storage manager 102 is sufficient to enlarge the target file. When the current unit file being managed by the DVR storage manager 102 is sufficient to enlarge (or extend) the target file, the process 200 may move to step 212. When the current unit file being managed by the DVR storage manager 102 is insufficient to enlarge the target file, the process 200 may move to step 214.

[0057] In step 212, process 200 may merge unit files required to expand the target file to the end of the target file. Then, process 200 may move to step 206 to generate a system call to write the data identified by the parameters FD and P_BUFFER of the AMBA_WRITE command, and then move to step 208 to terminate. In an example, process 200 may use the SPLIT system call to split the file and merge (multiple) available units to the target file. In an example, a first file (e.g., A) may have 10KB, and a second file (e.g., B) may have 20KB. If 10Kb is to be split from file B to file A, a split command may be issued accordingly. After executing the split command, the size of file A will be 20KB, and the size of file B will be 10KB. Similarly, in order to merge the entire file B with file A, a split command may be issued, thereby specifying that 20KB of file B will be split to file A. After executing the split command, the size of file A will be 30KB, and file B will no longer exist.

[0058] In step 214, process 200 may determine whether the storage medium has available space for creating more unit files. When the storage medium has available space for creating more unit files, process 200 may move to step 216. Otherwise, process 200 may move to step 218. In step 216, process 200 may create multiple unit files required to issue a FALLOCATE() command, and then move to step 212 to merge the newly created unit files required to expand the target file to the end of the target file. Then, process 200 may move to step 206 to generate a system call to write the data identified by the parameters FD and P_BUFFER of the AMBA_WRITE command, and then move to step 208 to terminate. In step 218, process 200 may report an error due to a lack of available free space. Then, process 200 may move to step 208 to terminate.

[0059] refer to Figure 4, a flowchart illustrating a process 300 for implementing a user space application program interface (API) for generating a system call for deleting a file according to an example embodiment of the present invention is shown. In the example, the process (or method) 300 may include step (or state) 302, step (or state) 304, step (or state) 306, and step (or state) 308. In step 302, the process 300 may receive an AMBA_DELETE() command and move to step 304. In step 304, the process 300 may split the target file into a corresponding amount of unit files, and then move to step 306. In step 306, the process 300 may put the unit files into an internal management queue of the DVR storage manager 102 for reuse when a file extension (or enlargement) is required next time. Then, the process 300 may move to step 308 and terminate.

[0060] refer to Figure 5 , a flowchart illustrating a process 400 of a user space application program interface (API) for generating a system call for creating a file according to an example embodiment of the present invention is shown. In an example, the process (or method) 400 may include steps (or states) 402, 404, 406, 408, 410, and 412. In step 402, the process 400 may receive an AMBA_CREATE command and associated parameters, and return parameters associated with creating a new file. In an example, the parameters may include, but are not limited to, a file descriptor (e.g., FD) for an open file and / or a full file path name (e.g., FULL_FILE_PATH_NAME) for an open file FD.

[0061] In step 404, process 400 can determine whether the file already exists. When the file already exists, process 400 can move to step 406 to open the existing file. When the file does not yet exist, process 400 can move to step 408 to create a new empty file. After step 406 or step 408, process 400 can move to step 410 to return the file description. Then, process 400 can move to step 412 to terminate.

[0062] refer to Figure 6 , a graph 500 illustrating a comparison between a conventional file management layer and a simulation of a file management layer according to an example embodiment of the present invention is shown. In an example, similar write strategies may be applied to conventional file writes and file writes using the file management layer 100 according to an example embodiment of the present invention. Graph 500 generally illustrates different file fragmentation performance between a conventional file management layer and a file management layer 100 according to an example embodiment of the present invention.

[0063] Curve 502 generally illustrates the fragmentation performance of a conventional file manager. When a digital video recorder (DVR) product encodes multiple streams, the streams are simultaneously saved to a secure digital (SD) card. When multiple streams are simultaneously saved to the SD card, the SD card becomes increasingly fragmented. Section 504 contains a graph generally illustrating the fragmentation performance of the file management layer 100 according to an example embodiment of the present invention. In the example, a test file of size 400MB is applied to simulate both situations. The file management layer 100 sets the unit file size to 16MB, which means that the maximum number of fragments for each test file will be controlled below 26 (e.g., 400MB / 16MB+1=26). As can be seen by a simple inspection, the fragmentation performance provided by the file management layer 100 is significantly better than the fragmentation performance of conventional file management solutions.

[0064] refer to Figure 7 , showing Figure 6 504, which illustrates the fragmentation performance of the file management layer 100 according to an example embodiment of the present invention. Section 510 shows the fragmentation performance for files indexed from 0 to 100 using the file management layer 100 according to an example embodiment of the present invention. Section 512 shows the fragmentation performance for files indexed from 600 to 700 using the file management layer 100 according to an example embodiment of the present invention. Section 514 shows the fragmentation performance for files indexed from 1200 to 1300 using the file management layer 100 according to an example embodiment of the present invention.

[0065] refer to Figure 8 , showing Figure 7 , which illustrates a fragmentation performance simulation for files indexed from 0 to 100 using the file management layer 100 according to an example embodiment of the present invention. For files indexed from 0 to about 120, the SD card is completely empty and no unit files exist. Whenever a written file needs to be extended, a new unit file (e.g., Figure 3 Step 216 of ) and merge it into the target file (e.g., Figure 3 As expected, at this stage, the fragmentation of all files is controlled below 26 (400MB / 16MB+1=26).

[0066] refer to Fig. 9 , showing Figure 7, which illustrates a fragmentation performance simulation for files indexed from 600 to about 700 using the file management layer 100 according to an example embodiment of the present invention. For files indexed from 580 to about 720, the SD card is half full, and the AMBA_DELETE action (e.g., the above combined Figure 4 The unit files described above have been applied to the oldest files. In the example, some unit files generated by the AMBA_DELETE operation exist in the SD card. When the target file needs to be extended, step 210 or step 214 is a possible path to extend the target file, depending on whether the existing unit files are sufficient to meet the requirements (for example, Figure 3 As expected, at this stage, the fragments of all files are controlled below 26 (400MB / 16MB+1=26).

[0067] refer to Fig.10 , showing Figure 7 , which illustrates a fragmentation performance simulation for files indexed from 1200 to 1300 using the file management layer 100 according to an exemplary embodiment of the present invention. At the final stage of the simulation, the SD card becomes completely full, and there is no remaining space in the SD card to create more unit files (e.g., Figure 3 When the target file needs to be expanded, the only way is to call AMBA_DELETE to delete the oldest file to generate more unit files and merge the newly split (multiple) unit files into the target file. As expected, the fragmentation of all files is controlled below 26 (400MB / 16MB+1=26).

[0068] refer to Fig.11 , a diagram of a camera system 900 is shown, which illustrates an example implementation of a computer vision system in which a file management layer according to an example embodiment of the present invention may be implemented and / or deployed. In one example, the electronics of the camera system 900 may be implemented as one or more integrated circuits. In an example, the camera system 900 may be built around a processor / camera chip (or circuit) 902. In an example, the processor / camera chip 902 may be implemented as an application specific integrated circuit (ASIC) or a system on a chip (SOC). The processor / camera circuit 902 is typically combined with hardware and / or software / firmware that may be configured to implement the above combined Figures 1 to 10 Describe the circuit and process.

[0069] In an example, the processor / camera circuit 902 may be connected to a lens and sensor assembly 904. In some embodiments, the lens and sensor assembly 904 may be a component of the processor / camera circuit 902 (e.g., a SoC component). In some embodiments, the lens and sensor assembly 904 may be a separate component from the processor / camera circuit 902 (e.g., the lens and sensor assembly may be an interchangeable component compatible with the processor / camera circuit 902). In some embodiments, the lens and sensor assembly 904 may be part of a separate camera connected to the processor / camera circuit 902 (e.g., via a video cable, a high-definition media interface (HDMI) cable, a universal serial bus (USB) cable, an Ethernet cable, or a wireless link).

[0070] The lens and sensor assembly 904 may include a block (or circuit) 906 and / or a block (or circuit) 908. The circuit 906 may be associated with the lens assembly. The circuit 908 may be implemented as one or more image sensors. In one example, the circuit 908 may be implemented as an RGB sensor and / or an IR sensor. In another example, the circuit 908 may be implemented as an RGB-IR sensor. The lens and sensor assembly 904 may include other components (not shown). The number, type, and / or function of the components of the lens and sensor assembly 904 may vary according to the design criteria of a particular implementation.

[0071] The lens assembly 906 can capture and / or focus light input received from the environment surrounding the camera system 900. The lens assembly 906 can capture and / or focus light for (multiple) image sensors 908. The lens assembly 906 can implement one or more optical lenses. The lens assembly 906 can provide a zoom feature and / or a focusing feature. The lens assembly 906 can be implemented with additional circuitry (e.g., a motor) to adjust the direction, zoom, and / or aperture of the lens assembly 906. The lens assembly 906 can be oriented, tilted, translated, zoomed, and / or rotated to provide a target view of the environment surrounding the camera system 900.

[0072] Image sensor 908 may receive light from lens assembly 906. Image sensor 908 may be configured to convert the received focused light into digital data (e.g., a bit stream). In some embodiments, image sensor 908 may perform analog-to-digital conversion. For example, image sensor 908 may perform photoelectric conversion on the focused light received from lens assembly 906. Image sensor 908 may present the converted image data as a color filter array (CFA) formatted bit stream. Processor / camera circuit 902 may convert the bit stream into video data, video files, and / or video frames (e.g., human-readable content).

[0073] The processor / camera circuit 902 may also be connected to: (i) optional audio input / output circuitry including an audio codec 910, a microphone 912, and a speaker 914; (ii) memory 916, which may include dynamic random access memory (DRAM); (iii) non-volatile memory (e.g., NAND flash memory) 918, removable media (e.g., SD, SDXC, etc.) 920, one or more serial (e.g., RS-485, RS-232, etc.) devices 922, one or more universal serial bus (USB) devices (e.g., USB host) 924, and a wireless communication device 926.

[0074] In various embodiments, the processor / camera circuit 902 may include a plurality of blocks (or circuits) 930a-930n, a plurality of blocks (or circuits) 932a-932n, a block (or circuit) 934, a block (or circuit) 936, a block (or circuit) 938, a block (or circuit) 940, a block (or circuit) 942, a block (or circuit) 944, a block (or circuit) 946, a block (or circuit) 948, a block (or circuit) 950, a block (or circuit) 952, and / or a block (or circuit) 954. The plurality of circuits 930a-930n may be processor circuits. In various embodiments, the circuits 930a-930n may include one or more embedded processors (e.g., ARM, etc.). In various embodiments, one or more of the circuits 930a-930n may implement a file management layer according to an embodiment of the present invention. The circuits 932a-932n may implement a plurality of computer vision-related processor circuits. In an example, one or more of the circuits 932a-932n may implement various computer vision related applications. The circuit 934 may be a digital signal processing (DSP) module. In some embodiments, the circuit 934 may implement a separate image DSP module and a video DSP module.

[0075] Circuit 936 may be a storage interface. Circuit 936 may interface processor / camera circuit 902 with DRAM 916, nonvolatile memory 918, and removable media 920. Circuit 936 may implement the above combination Figure 1-8The described file management layer 100. One or more of the DRAM 916, the non-volatile memory 918, and / or the removable medium 920 may store computer-readable instructions. The computer-readable instructions may be read and executed by the processors 930a-930n. In response to the computer-readable instructions, the processors 930a-930n may be operable to act as a controller for the processors 932a-932n. For example, the resources of the processors 932a-932n may be configured to efficiently perform various specific operations in hardware, and the processors 930a-930n may be configured to make decisions about how to process input / output to / from the various resources of the processor 932.

[0076] Circuit 938 may implement a local memory system. In some embodiments, local memory system 938 may include, but is not limited to, a cache memory (e.g., L2CACHE), a direct memory access (DMA) engine, a graphics direct memory access (GDMA) engine, and a fast random access memory. In an example, DAG memory 98 may be implemented in local memory system 938. Circuit 940 may implement a sensor input (or interface). Circuit 942 may implement one or more control interfaces, including but not limited to an inter-device communication (IDC) interface, an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI), and a pulse width modulation (PWM) interface. Circuit 944 may implement an audio interface (e.g., an I2S interface, etc.). Circuit 946 may implement a clock circuit, including but not limited to a real-time clock (RTC), a watchdog timer (WDT), and / or one or more programmable timers. Circuit 948 may implement an input / output (I / O) interface. Circuit 950 may be a video output module. Circuit 952 may be a communication module. Circuit 954 may be a security module. Circuits 930 - 954 may be connected to each other using one or more buses, interfaces, traces, protocols, or the like.

[0077] Circuit 918 may be implemented as a non-volatile memory (e.g., NAND flash memory, NOR flash memory, etc.). Circuit 920 may include one or more removable media cards (e.g., secure digital media (SD), secure digital extended capacity media (SDXC), etc.). Circuit 922 may include one or more serial interfaces (e.g., RS-485, RS-232, etc.). Circuit 924 may be an interface for connecting to a universal serial bus (USB) host or serving as a USB host. Circuit 926 may be a wireless interface for communicating with a user device (e.g., a smart phone, a computer, a tablet computing device, a cloud resource, etc.). In various embodiments, circuits 904-926 may be implemented as components external to the processor / camera circuit 902. In some embodiments, circuits 904-926 may be on-board components of the processor / camera circuit 902.

[0078] The control interface 942 may be configured to generate signals (e.g., IDC / I2C, STEPPER, IRIS, AF / ZOOM / TILT / PAN, etc.) for controlling the lens and sensor assembly 904. The signal IRIS may be configured to adjust the aperture of the lens assembly 906. The interface 942 may enable the processor / camera circuit 902 to control the lens and sensor assembly 904.

[0079] The storage interface 936 may be configured to manage one or more types of storage and / or data access. In one example, the storage interface 936 may implement a direct memory access (DMA) engine and / or a graphics direct memory access (GDMA). In another example, the storage interface 936 may implement a secure digital (SD) card interface (e.g., to connect to the removable media 920). In various embodiments, programming code (e.g., executable instructions for controlling various processors and encoders of the processor / camera circuit 902) may be stored in one or more of the memories (e.g., DRAM 916, NAND 918, etc.). The programming code, when executed by one or more of the processors 930, typically causes one or more components in the processor / camera circuit 902 to configure video synchronization operations and start video frame processing operations. The resulting compressed video signal may be presented to the storage interface 936, the video output 950, and / or the communication interface 952. The storage interface 936 may transfer program codes and / or data between external media (eg, DRAM 916 , NAND 918 , removable media 920 , etc.) and a local (internal) memory system 938 .

[0080] The sensor input 940 may be configured to send data to / receive data from the image sensor 908. In one example, the sensor input 940 may include an image sensor input interface. The sensor input 940 may be configured to send a captured image (e.g., picture elements, pixels, data) from the image sensor 908 to the DSP module 934, one or more of the processors 930, and / or one or more of the processors 932. The data received by the sensor input 940 may be used by the DSP 934 to determine the brightness (Y) value and the chrominance (U and V) value from the image sensor 908. The sensor input 940 may provide an interface to the lens and sensor assembly 904. The sensor input interface 940 may enable the processor / camera circuit 902 to capture image data from the lens and sensor assembly 904.

[0081] The audio interface 944 may be configured to send / receive audio data. In one example, the audio interface 944 may implement an audio inter-IC sound (I2S) interface. The audio interface 944 may be configured to send / receive data in a format implemented by the audio codec 910.

[0082] The DSP module 934 may be configured to process digital signals. The DSP module 934 may include an image digital signal processor (IDSP), a video digital signal processor DSP (VDSP), and / or an audio digital signal processor (ADSP). The DSP module 934 may be configured to receive information from the sensor input 940 (e.g., pixel data values ​​captured by the image sensor 908). The DSP module 934 may be configured to determine pixel values ​​(e.g., RGB, YUV, brightness, chrominance, etc.) based on the information received from the sensor input 940. The DSP module 934 may be further configured to support or provide a sensor RGB to YUV raw image pipeline to improve image quality, perform bad pixel detection and correction, demosaicing, white balance, color and tone correction, gamma correction, hue adjustment, saturation, brightness and contrast adjustment, chroma and brightness noise filtering.

[0083] The I / O interface 948 may be configured to send / receive data. The data sent / received by the I / O interface 948 may be miscellaneous information and / or control data. In one example, the I / O interface 948 may implement one or more of a general purpose input / output (GPIO) interface, an analog-to-digital converter (ADC) module, a digital-to-analog converter (DAC) module, an infrared (IR) remote interface, a pulse width modulation (PWM) module, a universal asynchronous receiver transmitter (UART), an infrared (IR) remote interface, and / or one or more synchronous data communication interfaces (IDC SPI / SSI).

[0084] The video output module 950 can be configured to send video data. For example, the processor / camera circuit 902 can be connected to an external device (e.g., a television, a monitor, a laptop computer, a tablet computing device, etc.). The video output module 950 can implement a high-definition multimedia interface (HDMI), a PAL / NTSC interface, an LCD / TV / parallel interface, and / or a DisplayPort interface.

[0085] The communication module 952 may be configured to send / receive data. The data sent / received by the communication module 952 may be transmitted / received according to a specific protocol (e.g., USB, Wi-Fi, UART, etc.). In one example, the communication module 952 can implement a secure digital input output (SDIO) interface. The communication module 952 can include a communication interface that receives and sends data over one or more wireless protocols (e.g., The communication module 952 may also include support for wireless communications using one or more universal serial bus protocols (e.g., USB 1.0, 2.0, 3.0, etc.). The processor / camera circuit 902 may also be configured to be powered via a USB connection. However, other communication and / or power interfaces may be implemented accordingly to meet the design criteria of a particular application.

[0086] The security module 954 may include a set of advanced security features to achieve advanced on-device physical security, including OTP, secure boot, As well as I / O visualization and DRAM scrambling. In an example, the security module 958 can include a true random number generator. In an example, the security module 954 can be used for DRAM communication encryption on the processor / camera circuit 902.

[0087] The processor / camera circuit 902 can be configured (e.g., programmed) to control one or more lens assemblies 906 and one or more image sensors 908. The processor / camera circuit 902 can receive raw image data from (multiple) image sensors 908. The processor / camera circuit 902 can simultaneously (in parallel) encode the raw image data into multiple encoded video streams. The multiple video streams can have various resolutions (e.g., VGA, WVGA, QVGA, SD, HD, Ultra HD, 4K, etc.). The processor / camera circuit 902 can receive encoded and / or unencoded (e.g., raw) audio data at the audio interface 944. The processor / camera circuit 902 can also receive encoded audio data from the communication interface 952 (e.g., USB and / or SDIO). The processor / camera circuit 902 can provide the encoded video data to the wireless interface 926 (e.g., using a USB host interface). The wireless interface 926 can include support for one or more wireless and / or cellular protocols (e.g., The processor / camera circuit 902 may include support for wireless communications using Z-Wave, LoRa, Wi-Fi (IEEE 802.11a / b / g / n / ac, IEEE 802.15, IEEE 802.15.1, IEEE 802.15.2, IEEE 802.15.3, IEEE 802.15.4, IEEE 802.15.5, IEEE802.20, GSM, CDMA, GPRS, UMTS, CDMA2000, 3GPP LTE, 4G / HSPA / WiMAX, 5G, SMS, LTE_M, NB-IoT, etc.). The processor / camera circuit 902 may also include support for communications using one or more of the universal serial bus protocols (e.g., USB 1.0, 2.0, 3.0, etc.).

[0088] As will be apparent to those skilled in the relevant art(s), Figures 1 to 11 The functions and structures shown in the figures can be designed, modeled, simulated and / or emulated using one or more of conventional general-purpose processors, digital computers, microprocessors, microcontrollers, distributed computer resources and / or similar computing machines programmed according to the teachings of this specification. As will also be apparent to those skilled in the relevant art(s), a skilled programmer can readily prepare appropriate software, firmware, coding, routines, instructions, opcodes, microcodes and / or program modules based on the teachings of this disclosure. The software is typically embodied in one or more media (e.g., non-transitory storage media) and can be executed sequentially or in parallel by one or more of the processors.

[0089] Embodiments of the present invention may also be implemented in one or more of an ASIC (application specific integrated circuit), an FPGA (field programmable gate array), a PLD (programmable logic device), a CPLD (complex programmable logic device), a sea of ​​gates, an ASSP (application specific standard product), and an integrated circuit. The circuit may be implemented based on one or more hardware description languages. Embodiments of the present invention may be utilized in conjunction with flash memory, non-volatile memory, random access memory, read-only memory, magnetic disk, floppy disk, optical disk (e.g., DVD and DVDRAM), magneto-optical disk, and / or distributed storage systems.

[0090] When the terms "may" and "generally" are used in conjunction with "is" and a verb herein, it is intended to convey the intention that the description is exemplary and is considered broad enough to cover both the specific examples presented in the present disclosure and alternative examples that can be derived based on the present disclosure. The terms "may" and "generally" as used herein should not be interpreted as necessarily implying the desirability or possibility of omitting the corresponding elements.

[0091] While the invention has been particularly shown and described with reference to embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention.

Claims

1. A device comprising: a removable media interface circuit configured to read files and write the files to a non-volatile storage medium; as well as a processor configured to generate encoded data from one or more data streams and manage file operations involving storing the encoded data on the non-volatile storage medium to minimize an amount of file fragmentation by utilizing a file management layer including a plurality of user space application program interfaces, Wherein, the multiple user space application program interfaces include: a first user space application program interface for generating a user space create command and a user space write command, wherein the user space create command is configured to create a new target file and open an existing target file, the target file includes one or more unit files, the one or more unit files have a size based on a bit rate of the one or more data streams, and the user space write command is configured to provide information for writing the encoded data to the one or more target files in the target file; a second user space application program interface for issuing a user space delete command to reclaim the one or more unit files from the target file that is no longer needed; and A third user space application program interface is used to convert the user space creation command, the user space write command, and the user space delete command into one or more system calls to the system kernel, wherein the one or more system calls perform open, close, read, write, file allocation, and file splitting operations at the physical layer of the device, and the third user space application program interface is configured to create the one or more unit files and expand the target file based on the one or more unit files and the information provided by the user space write command.

2. The device according to claim 1, wherein: The non-volatile storage medium is formatted using a virtual file allocation table (vFAT) file system or an extended file allocation table (exFAT) file system.

3. The device according to claim 1, wherein: The non-volatile storage medium includes a Secure Digital (SD) card.

4. The device according to claim 1, wherein: The processor implements an application-level space management scheme to create, remove, overwrite, and resize files in order to avoid fragmentation of files.

5. The device according to claim 4, wherein: The application-level space management scheme provides the plurality of user-space application programming interfaces to allocate and release space in the non-volatile storage medium using file block units.

6. The device according to claim 1, wherein: The processor is configured to encode the data into an MPEG-4 compliant file.

7. The device according to claim 1, wherein: The processor is configured to encode the video data into an MPEG-4 compliant video file.

8. The device according to claim 1, wherein: The removable media interface circuit and the processor are part of a digital recorder product.

9. The device according to claim 1, wherein: The removable media interface circuit and the processor are part of a digital video recorder product.

10. The device according to claim 1, wherein: The removable media interface circuit and the processor are part of a driving recorder product.

11. The device according to claim 1, wherein: The removable media interface circuit and the processor are part of a digital camera system-on-chip (SoC) product.

12. The apparatus of claim 1, further comprising an image sensor configured to generate video data and transmit the video data to the processor.

13. A method for managing a storage medium, comprising: generating encoded data from one or more data streams using a processor; as well as managing file operations involving storing the encoded data on a non-volatile storage medium using the processor to minimize an amount of file fragmentation by utilizing a file management layer including a plurality of user space application program interfaces, Wherein, the multiple user space application program interfaces include: a first user space application program interface for generating a user space create command and a user space write command, wherein the user space create command is configured to create a new target file and open an existing target file, the target file includes one or more unit files, the one or more unit files have a size based on a bit rate of the one or more data streams, and the user space write command is configured to provide information for writing the encoded data to the one or more target files in the target file; a second user space application program interface for issuing a user space delete command to reclaim the one or more unit files from the target file that is no longer needed; and A third user space application program interface is used to convert the user space creation command, the user space write command, and the user space delete command into one or more system calls to the system kernel, wherein the one or more system calls perform opening, closing, reading, writing, file allocation, and file splitting operations at the physical layer of the storage medium, and the third user space application program interface is configured to create the one or more unit files and expand the target file based on the one or more unit files and the information provided by the user space write command.

14. The method according to claim 13, wherein: The non-volatile storage medium is formatted using a virtual file allocation table (vFAT) file system or an extended file allocation table (exFAT) file system.

15. The method according to claim 13, wherein: The non-volatile storage medium includes a Secure Digital (SD) card.

16. The method according to claim 13, wherein: The processor implements an application-level space management scheme to create, remove, overwrite, and resize files in order to avoid fragmentation of files.

17. The method according to claim 16, wherein: The application-level space management scheme provides the plurality of user-space application programming interfaces to allocate and release space in the non-volatile storage medium using file block units.

18. The method according to claim 13, wherein: The encoded data is encoded into a file compliant with MPEG-4.

19. The method according to claim 13, wherein: The encoded data includes video data, and is encoded as a video file compliant with MPEG-4.

20. The method according to claim 19, further comprising: generating the video data using an image sensor; as well as The video data is transmitted to the processor.

Images