Systems and programs, etc.

Abstract

To provide a system and a program which can make fragmentation of a file hard to occur and read the file in a general operating system.SOLUTION: A system generates a cluster chain by preliminarily allocating a predetermined number of unused clusters with consecutive numbers in the case of recording a container file for recording generation information including image information in an SD card, and continuously writes the image information in an area with size (10MB in the present embodiment) obtained by multiplying cluster size (32KB in the present embodiment) by the predetermined number (10MB / 32KB pieces in the present embodiment) to generate a file.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present invention relates to, for example, systems, programs and the like.

Background Art

[0002] For example, drive recorders that record vehicle status information (such as forward video, speed, acceleration, etc.), which is information acquired in a vehicle, on a recording medium, are widely installed in transport vehicles such as trucks, and commercial vehicles such as taxis and buses, and are also increasingly being installed in ordinary vehicles.

[0003] Some drive recorders constantly record vehicle status information, for example while the vehicle is traveling, and others record vehicle status information as needed for a certain period before and after the occurrence of an accident or sudden braking.

[0004] The recording of vehicle status information by such drive recorders is performed on a removable recording medium such as a memory card including an SD card that is detachable from the drive recorder. In general, analysis of vehicle status information is often performed by processing of viewer application software (hereinafter referred to as a viewer app) that operates on a personal computer.

[0005] At the time of analysis, this recording medium is removed from the vehicle's drive recorder, and inserted into a memory card reader connected to an analysis personal computer in an office or the like. On the personal computer, the viewer app process reads the vehicle status information from the recording medium inserted into the memory card reader, and visualizes and displays the information on the screen (for example, Patent Document 1). This makes it possible to check and analyze the vehicle status information based on the information visualized on the screen.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Summary of the Invention

[0007] However, the conventional system had various problems. Therefore, the present invention aims to provide a system and program, etc., that have superior characteristics compared to conventional systems.

[0008] The object of the present invention is not limited thereto, and the applicant intends to obtain rights through divisional applications, amendments, etc., for configurations that aim to obtain the effects derived from the components of the configuration disclosed in this specification and the drawings, etc. For example, problems that can be described in this specification as "~is possible" or "~is feasible" are disclosed in this specification. Each problem is described independently, and the applicant intends to obtain rights to each configuration for solving each problem independently through divisional applications, amendments, etc. Even if a problem is implicitly understood from the description in the specification, the applicant intends to include a part of the configuration described in this specification in the claims through amendment or divisional application. Furthermore, configurations that solve problems by combining these independent problems are also disclosed, and the applicant intends to obtain rights to them. [Means for solving the problem]

[0009] (1) A system that records the generated information on a recording medium accessible by this system, wherein at least a portion of the information can be read by a general operating system of a personal computer when the recording medium is accessible from a personal computer, but the system records the generated information in a manner different from the writing method of the general operating system.

[0010] In this way, information recorded by the system can be read by a general operating system, and recording can be done in a system-friendly manner that differs from the writing method of the general operating system. Thus, both can be achieved simultaneously. For example, in a system that differs from the writing method of the general operating system, it becomes possible to suppress issues such as fragmentation of the contents of the recording medium, and destruction of the management area due to inaccessibility caused by unexpected power outages or unexpected removal of the recording medium. This reduces the frequency of formatting the recording medium, or even eliminates the need for periodic formatting altogether.

[0011] The recording medium accessible by the system may be a recording medium connected to the system (for example, an SSD, HDD, etc. connected via a USB cable), and in particular, the system may be configured to allow the recording medium to be detachably attached (for example, a configuration with a built-in SD card reader / writer, etc.), and the recording medium may be one attached to the system (for example, an SD card, etc.).

[0012] For a personal computer, a so-called IBM PC / AT compatible machine would be a good choice. For a general operating system, Microsoft Windows would be a good option.

[0013] When the aforementioned recording medium is accessible from a personal computer, for example, the system may be equipped with a wireless communication function (such as a Wi-Fi network connection function), and the personal computer may also be equipped with a wireless communication function that can connect to it, and the personal computer may be able to access the recording medium of the system. In particular, it is preferable when a removable recording medium is removed from the system and connected to the personal computer.

[0014] To configure the aforementioned recording medium so that at least a portion of it can be read by a typical operating system of a personal computer when it is accessible from the personal computer, it is preferable to use a format that is compatible with the standard format of a typical operating system. For example, it is preferable to use a format that is displayed in the GUI when you right-click the drive letter icon in Microsoft Windows Explorer and select "Format". In terms of formatting, it is best to use at least one of the following: FAT16, FAT32, or exFAT.

[0015] When the recording medium is installed in a personal computer, at least a portion of it can be read by the personal computer's general operating system. However, as a recording configuration that differs from the writing method of the general operating system, the recording medium may be configured to have partitions in the same format as the general operating system of the personal computer, as well as partitions in a different format (particularly as in (10) below), or the recording medium may have partitions in the same format as the general operating system of the personal computer, but the procedure for recording to those partitions may differ from the procedure performed by the general operating system (particularly as at least one of (2) to (8) below). These may also be combined.

[0016] (2) The generated information includes video data based on imaging data captured by the imaging means, The writing method in the aforementioned general operating system is such that when data is written to a file and the file size changes from 0 to 1 or more, one unused cluster is allocated at that time, that cluster number is set in the directory entry of the file, and thereafter, as the file size increases and the cluster being written to overflows, a new cluster is allocated to form a cluster chain. A method different from the writing method in the aforementioned general operating system is to form a cluster chain by pre-allocating a predetermined number of consecutive unused clusters when generating a file containing video data, and then generate the file by continuously writing the data containing the video data to an area of ​​size obtained by multiplying the cluster size by the predetermined number.

[0017] In this way, even if the system repeatedly writes and erases video data based on the image data captured by the imaging means to the recording medium, file fragmentation can be made less likely to occur than before, and the files containing the recorded video data can be read using a common operating system of a personal computer.

[0018] For a configuration that allows at least a portion of the data to be read by a common operating system, it is best to format the data using a cluster size selectable during formatting with the standard formatting software of a common operating system. For example, it is good to have a function to format the storage medium using a cluster size (called the allocation unit size by Microsoft) selectable in Microsoft Windows. These cluster sizes are 4KB, 8KB, 16KB, 32KB, and 64KB when formatted as FAT16 or FAT32. When formatted as exFAT, the cluster sizes are 4KB, 32KB, and 128KB. The aforementioned predetermined number should preferably be 100 or more, and even better if it is 1000 or more.

[0019] Furthermore, the "size obtained by multiplying the cluster size by the predetermined number" should preferably be in megabytes, particularly in units of tens of megabytes.

[0020] For example, the "size obtained by multiplying the cluster size by the predetermined number" should be at least an order of magnitude larger than the cluster size selectable when formatting with the standard formatting software of a typical operating system. For example, if the cluster size selectable when formatting with the standard formatting software of a typical operating system is in kilobytes, then the "size obtained by multiplying the cluster size by the predetermined number" should be in megabytes.

[0021] Furthermore, in this configuration, the size of a single file containing this video data should be set to be larger than "the cluster size multiplied by the predetermined number." For example, the settings for the video file's recording time, bitrate, etc., should be set so that a file larger than "the cluster size multiplied by the predetermined number" is generated. Preferably, the size of a single file containing this video data should be set to several times to about 10 times "the cluster size multiplied by the predetermined number."

[0022] In a general operating system, the writing method is such that when data is written to a file and the file size changes from 0 to 1 or more, one unused cluster at that point is allocated, the cluster number is set in the directory entry of the file, and thereafter, each time the file size increases and the currently written cluster overflows, a new cluster is allocated to form a cluster chain. Therefore, when creation and deletion of files of different sizes are repeated, the usage efficiency of the recording medium can be increased. For example, when small-sized files and large-sized files coexist, although areas with consecutive cluster numbers are not always secured, they can be used without waste, so it can be said that this is a good method as a file writing method for personal computers. However, in the system, video data results in large file sizes. Therefore, if the cluster size is set in megabyte units for recording video data, fragmentation is less likely to occur, and efficiency degradation can be minimized. For example, in FAT, the cluster size selectable at the time of formatting is in kilobyte units, so when a 50-megabyte file is recorded, it is distributed across approximately 5000 clusters, and repeated writing and erasing gradually causes the cluster writing locations to become fragmented, which is a drawback. According to the present method, since a predetermined number of consecutive clusters are secured and video data is written to the consecutive clusters, fragmentation can be suppressed.

[0023] The present system may be configured by creating and incorporating a device driver that implements this method on a personal computer, but it is preferable to configure and include a program that implements this method on an embedded device that is not a personal computer. The system is particularly preferably a drive recorder that records video and the like in a vehicle.

[0024] It should be noted that the system is preferably configured such that in particular video data is continuously generated and recorded based on imaging data captured by an imaging unit while power is supplied to the system (referred to as continuous recording).

[0025] (3) When the recording medium is mounted on a personal computer, at least a part of the recording medium is readable by a general operating system of the personal computer, and the method different from the writing method in the general operating system is configured such that, in the initialization processing of the recording medium by the system, clusters at predetermined positions are reserved for files readable by the file system adopted by the general operating system of the personal computer, and the video data is recorded by overwriting within a file using the pre-reserved clusters within a range not exceeding the size of the file to sequentially record the video, so that a file containing the video data can be recorded without changing the cluster positions of the file.

[0026] With this arrangement, file fragmentation caused by writing of video data recorded by the system in the recording medium can be suppressed. In addition, access to the file management area can be reduced or made unnecessary, and for example, the possibility of problems such as the video file recorded on the recording medium becoming unreadable by the personal computer due to unexpected power-off of the system or unexpected removal of the recording medium during updating of the file management area, which has occurred in conventional systems, can be significantly reduced. It should be noted that, for example, both the function of (3) and the function of (2) may be provided, and a function may be provided for setting which recording is to be performed and performing the set recording.

[0027] (4) In the initialization processing of the recording medium, a plurality of files using the pre-reserved clusters are created in advance as fixed-length files, the video data has a variable bit rate, and the fixed length size is set to be larger than the size of data including video data when recording for the predetermined unit time at the maximum bit rate of the variable bit rate, so that the video data of a predetermined unit time is recorded in one of the fixed-length files. It is preferable to provide a function of performing recording set as described above.

[0028] In this way, the video data per unit time will be recorded in a pre-created fixed-length file. Therefore, file fragmentation can be prevented with almost certainty, and the possibility of corruption of the management area can be reduced. Furthermore, it is advisable to repeat the process of recording the next unit time's video data into the next pre-created fixed-length file, and once all pre-created fixed-length files have been recorded with video data, the first fixed-length file recorded will be overwritten with the new video data.

[0029] The specified unit time should preferably be in the range of 1 to 10 minutes. Ideally, it should be 1 or 5 minutes. This is because, even if an unexpected power outage or removal of the storage medium occurs during video data recording, the data that could be lost will be limited to within these timeframes.

[0030] (5) In the initialization process of the recording medium, multiple files using the pre-allocated cluster are created in advance as fixed-length files, and the video data is of a variable bitrate. The recording medium has a function to monitor the capacity recorded in one fixed-length file and change the fixed-length file to record, so that the video data of the variable bitrate fills one fixed-length file as much as possible.

[0031] In this way, although the duration of video recorded in a fixed-length file will not be constant, it solves the problem that occurs with method (4) above, where the entire fixed-length file is not recorded, reducing the amount of video that can be recorded on the recording medium. In a method where a file is created in advance (a cluster in a fixed location is reserved) and then overwritten without changing that cluster location, pre-determining means that a file exceeding that file size can never be created. Therefore, method (4) has its biggest drawback: an enormous amount of unused capacity is left on the recording medium. For example, to record the same amount of time as in (2) or (10) described later, the bitrate that defines the video quality must be reduced to, for example, 2 / 3. As a result, the video quality becomes poor. However, this problem can be solved by using method (5).

[0032] To ensure that the fixed-length file in 1 is filled as completely as possible, for example, the system should buffer at least the video between keyframes (the frame before the next keyframe) so that the next fixed-length file starts from a keyframe. If there is still room for the video between keyframes in the currently being written file, it should be written to the currently being written file; otherwise, it should be recorded to the next fixed-length file. The keyframe interval can be, for example, between I-frames, and the system should be configured so that the contents of the next fixed-length file do not start from P-frames or B-frames, but rather from I-frames. For example, the system could be equipped with both function (5) and function (4), allowing the user to set which type of recording to perform, and then perform the recording of the selected type.

[0033] (6) The system may have a function to continuously record the video data to the recording medium while the power is on, and in the initialization process of the recording medium, the file that uses the pre-allocated cluster may be created in advance as a very large single file, and the video data to be continuously recorded may be recorded in this very large file. This approach simplifies the process and reduces the likelihood of fragmentation compared to conventional methods.

[0034] For example, the system may be equipped with at least two of the functions from (4) to (6), and may also be equipped with a function that allows the user to set which type of recording to be performed and then records the selected type.

[0035] A very large single file could be, for example, a file whose size is less than or equal to the capacity of the storage medium and equal to the maximum capacity of the file system storing the file. Alternatively, a very large single file could be, for example, a file with a capacity of more than half the capacity of the storage medium, and in particular, a file whose size is more than half the capacity of the storage medium (and, for example, less than or equal to the capacity of the storage medium). It would also be good to have a function to set this range.

[0036] (7) The file that uses the pre-allocated cluster is generated as an invisible file in the personal computer's operating system during the initialization process of the recording medium, and the file to be written is made visible when the video data is written.

[0037] In this way, when the recording medium is read by a personal computer immediately after the initialization process of the recording medium has been completed, it will not be possible to see files that use the pre-allocated cluster and do not contain any video data.

[0038] (8) The file that uses the pre-allocated cluster may have a function in the initialization process of the recording medium that generates it as a file that can be played back by the operating system of the personal computer.

[0039] In this way, when the recording medium is read by a personal computer immediately after the initialization process of the recording medium has been completed, the files that are visible can be played back and the video can be viewed. The video data of the playable file should be a video that continuously displays a predetermined screen during playback. For example, it could be a video where the entire screen is covered with a predetermined color (for example, a video of a completely black screen), or a video that continuously displays a string of text such as "This is an unrecorded file," or it could be generated by copying a file containing a predetermined video that has been previously recorded inside the system. For example, the system could be equipped with both function (8) and function (7), allowing the user to set which type of recording to perform, and then perform the recording of the selected type.

[0040] (9) The file containing the video data should preferably have a function to generate a file in a format that can be played back by a common operating system of the personal computer.

[0041] In this way, video files recorded on the recording medium can be played back on a common operating system of a personal computer. It is particularly good to have configuration (8). In particular, in configurations (4) to (6), it is good to generate the files created during the initialization process in a file format that can be played back on the common operating system of the personal computer.

[0042] The format types described in (2) to (9) above may be the format types adopted by the operating system of the personal computer, and in the initialization process, it is preferable to format using the said format before performing the initialization process described in each of the items (2) to (9).

[0043] (10) The generated information includes video data based on imaging data captured by the imaging means, and the recording medium is configured to be readable by a general operating system of a personal computer when it is installed in a personal computer, and the recording medium is provided with a partition in the same format as the general operating system of the personal computer, and a function to write to the partition, and a partition in a different format than the general operating system of the personal computer is provided as a method different from the writing method of the general operating system, and for the partition of the different format, the video data index is not written to the management area, and the video data is written sequentially to the recording medium.

[0044] In this way, the concept of fragmentation disappears. Furthermore, video data cannot be viewed using only the standard functions of a typical personal computer's operating system. Therefore, it can be said that the security level is high.

[0045] Furthermore, for example, with functions (2) through (9), if the recording medium is removed from the system while the management area is being written, depending on the timing, the contents of the recording medium may be completely lost. This does not happen with method (10). In addition, with functions (2) through (9), it is best to configure the system so that the management area is not touched when recording video data, but it may not always be possible to configure everything this way. In such cases, method (10) should be used.

[0046] Furthermore, in the configuration of (10), the recording medium may also be provided with a function to record at least one of the video data from (2) to (9) in addition to the video data from (10) on a partition using the same format as the format used by the general operating system of the personal computer. In this way, even if one of the partitions is destroyed, the video data can be read and played back from the undamaged partition.

[0047] In method (10), since the video data is of variable length, it becomes very difficult to find the beginning of a video frame. Therefore, it is advisable to attach chain data to each frame so that it can be searched between frames. It is advisable to have a mechanism where each frame has a directory entry, similar to FAT. The drawback is that it is not visible in general personal computer operating systems, such as in file search applications like Explorer, so a dedicated application is required. For example, if the recording medium is an SD card, writing to a continuous area of ​​the SD card is faster, but writing to non-contiguous areas causes a sharp decrease in writing speed. However, with a configuration like (10), this can be prevented, and for example, simultaneous writing of a total of 4 streams can be achieved, such as 2 cameras / continuous recording and events separately. In addition, in a communication-type system, it becomes relatively easy to write 8 streams by adding low-resolution video (video with low capacity) compared to other recording methods.

[0048] (11) The video data may be provided with a function that allows the video to be cueed based on the first information and the second information, which allows the video to be cueed based on the first information and the second information, by assigning a first information to the video data to go back a predetermined time in the past without using the management area and a second information to the video data. (12) The program should be one that enables a computer to implement the functions of any of the systems described in (1) through (12).

[0049] (13) It is preferable to provide a driver program for the personal computer's general operating system that enables the personal computer's general operating system to access video data on a partition in a format different from the format used by the personal computer's general operating system, which has been recorded by the system described in (10) above.

[0050] The above configurations may be modified by replacing "personal computer" with "smartphone" in (1) through (13). Alternatively, the above configurations may be modified by replacing "personal computer" with "tablet." In these cases, Android is a suitable operating system.

[0051] The inventions described in (1) to (11) above can be combined in any way. For example, one may combine all or part of the configuration of the invention described in (1) with at least part of the configuration of at least one of the inventions described in (2) and onward. In particular, it is preferable to combine the invention described in (1) with at least part of the configuration of at least one of the inventions described in (2) and onward. Alternatively, one may extract any configuration from the inventions described in (1) to (11) and combine the extracted configurations. The applicant of this application intends to obtain rights to inventions that include these configurations. Furthermore, even if there are descriptions such as "in the case of..." or "when...", these are not meant to be descriptions that limit the configuration to that case or time. These are merely examples of better configurations, and the applicant intends to obtain rights to configurations that do not fall under these cases or times. Also, even if there is a sequence of descriptions, it is not limited to that order. Configurations with some parts deleted or the order rearranged are also disclosed, and the applicant intends to obtain rights to them as well. [Effects of the Invention]

[0052] According to the present invention, it is possible to provide a system that is superior to conventional systems. For example, it becomes possible to suppress fragmentation of the contents of the recording medium, and damage to the management area due to inaccessibility caused by unexpected power outages or unexpected removal of the recording medium, thereby reducing the frequency of periodic formatting of the recording medium, or even providing a system that does not require periodic formatting of the recording medium.

[0053] Furthermore, the effects of the present invention are not limited to those described herein. Effects derived from the components disclosed in this specification and the drawings are also disclosed, and the applicant intends to obtain rights to such components through divisional applications, amendments, etc. For example, phrases such as "can do" or "is possible" in this specification are descriptions that clearly indicate the effects to be achieved, and there are components that demonstrate effects even without such descriptions. Moreover, there are effects that can be grasped by the component even without such descriptions. [Brief explanation of the drawing]

[0054] [Figure 1] This is an explanatory diagram illustrating the transfer of an SD card between a dashcam and a computer. [Figure 2] This is an explanatory diagram illustrating an example of how to install a dashcam in a vehicle. [Figure 3] This is a block diagram illustrating an example of the basic electrical configuration of a dashcam. [Figure 4] This is a block diagram illustrating a schematic electrical configuration example of a personal computer and devices connected to it. [Figure 5] This figure shows an example of how a viewer software running on a personal computer will appear on the screen. [Figure 6] This figure shows an example of the format selection screen displayed on a dashcam. [Modes for carrying out the invention]

[0055] Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. Note that the embodiments described below are just one example of the present invention, and the content of the present invention should not be interpreted as being limited based on the following description. The following description will explain an embodiment of the present invention based on an example in which the system is implemented by processing a program executed on a drive recorder installed in a vehicle.

[0056] As shown in Figure 1, the drive recorder 1 of this embodiment has a function to record video data generated by compressing the image data captured by the drive recorder 1 onto an SD card, which is an example of a recording medium. Furthermore, when the vehicle engine is turned off and the power to the drive recorder is turned off, and the SD card is removed from the drive recorder 1 and inserted into an SD card reader / writer 36 connected to a PC 35 installed in an office or the like, the drive recorder has a function to play back and display the recorded video data on the screen of the viewer software shown in Figure 5, which is executed on the PC 35. The SD card is a 32GB card. Also, Microsoft's Windows 10 is running as the operating system on the PC 35.

[0057] As shown in Figure 2, the drive recorder 1 is fixed to the upper part of the vehicle's windshield 3, near the center in the left-right direction, on the passenger side, by attaching one side of a mounting material such as double-sided tape to the windshield and the other side to the windshield. The drive recorder 1 is fixed with its camera lens pointed in a direction that captures the view in front of the vehicle. The drive recorder 1 is connected to the cigarette lighter socket 5 and power cable 6, and receives power from the vehicle when the vehicle's accessory power is on.

[0058] Figure 3 shows the schematic electrical configuration of the drive recorder 1. As shown in Figure 3, the drive recorder 1 includes a controller MC, a CCD camera 13, an interface 33, a GPS receiver 24, a display unit with a touch panel 25, an SD card reader 31, an acceleration sensor 15, a database 32, and the like. The controller MC is connected to the interface 33, which is connected to the CCD camera 13 and converts the video signal from the CCD camera 13 into a digital signal that can be input to the controller MC, as well as the acceleration sensor 15, GPS receiver 24, display unit 25, SD card reader 31, and database 32.

[0059] The controller MC is composed of a microcontroller with a well-known CPU, memory such as ROM and RAM, timers, and other peripheral circuits. The ROM of the controller MC stores various programs, including a card initialization program for initializing the SD card to a state where video data can be written, a recording program for saving generated information, including GPS information including location information received by the GPS receiver 24, acceleration information detected by the acceleration sensor 15, and video information captured by the CCD camera 13, to the SD card, programs for performing various processes described later, and a real-time OS (Operation System). The controller MC realizes various functions by executing these programs. The controller MC executes a recording processing program and performs recording processing to record the generated information in one of the eight formats described below.

[0060] The GPS receiver 24 detects the vehicle's current position information based on instructions from the controller MC. In this embodiment, the detection timing is set to every second. The controller MC acquires GPS information, including position information, every second during the recording process. The position information includes the time, vehicle's position, speed, latitude, longitude, and altitude, all determined based on signals from GPS satellites.

[0061] The acceleration sensor 15 is a three-axis type sensor that detects acceleration and tilt in each of the three axes (X, Y, Z), and continuously outputs the detected values ​​to the controller MC. In the recording process, the controller MC generates acceleration information by associating this three-axis acceleration information with time information every 10ms.

[0062] The SD card reader 31 reads or updates data on the SD card inserted through the slot 18 based on the control of the controller MC. The database 32 is a non-volatile memory (e.g., EEPROM) externally connected to the controller MC.

[0063] The CCD camera 13 continuously outputs captured image information to the controller MC via the interface unit 33, which performs digital conversion of the captured image. In the recording process, the controller MC compresses the image information input via the interface unit 33, associating it with the time, and generates video information.

[0064] The controller MC performs an SD card insertion check process immediately after power-on and when it detects that the SD card has been removed during recording. The SD card insertion check process checks whether an SD card is inserted in the SD card reader / writer 31. If an SD card is detected to be inserted, the process proceeds to the SD card format confirmation process. If an SD card is not detected to be inserted, the display unit 25 displays the message "Please insert an SD card" and waits for the SD card to be inserted. Once an SD card is detected to be inserted, this display is turned off and the process proceeds to the SD card format confirmation process.

[0065] The SD card format verification process reads each sector of the SD card, checks the logical structure of the partitions and format, determines which of the eight formats described below the card belongs to, and passes the determined format type to the recording process to start the recording process. In the recording process, the data is recorded to the SD card according to the structure of the format type passed to it. If the card does not match any of the eight formats, the process proceeds to the card initialization process.

[0066] The card initialization process displays the video data recording format screen shown in Figure 6 on the display unit 25. The video data recording format screen allows the user to input an initialization command for the card by selecting one of eight formats. This video data recording format screen has eight rows of text indicating format methods arranged vertically, radio buttons to the left of each row of text, and a "Cancel" button and an "Initialize" button at the bottom. When the "Initialize" button is touched, the initialization process is performed using the format method indicated by the text in the row selected by the radio button, the selected format type is stored in the RAM of the controller MC, and the process proceeds to recording. When the "Cancel" button is touched, the process proceeds back to the SD card format confirmation process.

[0067] The eight formatting methods, as shown in Figure 6, are, from top to bottom: "Pre-allocate a predetermined number of consecutive unused clusters," "Record video data of a predetermined unit time into a fixed-length file (visible at initialization)," "Record video data of a predetermined unit time into a fixed-length file (invisible at initialization)," "Record variable-bitrate video data into a fixed-length file, filling it as much as possible (visible at initialization)," "Record variable-bitrate video data into a fixed-length file, filling it as much as possible (invisible at initialization)," "Record continuously recorded video data into a very large file (visible at initialization)," "Record continuously recorded video data into a very large file (invisible at initialization)," and "Record in a proprietary format." The processing for each case is explained in (1) to (8) below. (1) In the case of "pre-allocating a predetermined number of consecutive unused clusters within the cluster chain"

[0068] When the controller MC detects that the "Initialize" button has been touched while "Pre-allocate a predetermined number of consecutive unused clusters in the cluster chain" is selected, it treats the entire SD card as one partition and performs a standard FAT32 format, before proceeding to the recording process. The cluster size used during this formatting is the same as that of Windows 10: 4KB if the detected capacity of the SD card is between 512MB and 8,191MB, 8KB if it is between 8,192MB and 16,383MB, 16KB if it is between 16,384MB and 32,767MB, and 32KB if it is 32,768MB or more. Then, in this recording process, when it is determined that the format type stored in RAM is "to pre-allocate a predetermined number of consecutive unused clusters in the cluster chain," frame information is generated by compressing the image information acquired from the CCD camera 13 with a predetermined codec (e.g., H.254) for each frame, and adding GPS information and acceleration information as subtitle data in text format. 60 seconds of frame information is then written as a single container file (e.g., an AVI container). The size of this container file is generally less than 70MB. When writing this file, the writing method of Windows 10 on the PC 35 is to allocate one unused cluster at the time data is written to the file and the file size changes from 0 to 1 or more, set that cluster number in the directory entry of the file, and thereafter, whenever the file size increases and the cluster being written overflows, a new cluster is allocated to form a cluster chain. However, the drive recorder 35 writes using a different method than the writing method of Windows 10 running on the PC 35.This different method generates a cluster chain by pre-allocating a predetermined number of consecutive unused clusters when recording a container file containing generated information including video information onto an SD card. The process involves writing the video information continuously to an area of ​​size (10MB in this embodiment) obtained by multiplying the cluster size (32KB in this embodiment) by this predetermined number (10MB / 32KB in this embodiment). This process is repeated, allocating and writing the next 10MB, until the container file is written to the FAT32 file system.

[0069] Specifically, when a new container file is created on the SD card, the system searches for a range on the FAT32-formatted FAT (File Allocation Table) where a predetermined number of consecutively numbered clusters can be secured, and creates a cluster chain within this range (the first cluster stores the next cluster number, the next cluster stores the cluster number after that, and so on, in succession). The first cluster number is then recorded in the directory entry that records the file name of the container file. After writing 10MB, which is the capacity of the cluster group corresponding to this cluster chain, a new 10MB cluster chain is similarly created, and the last cluster is added to the beginning of that chain, repeating this process until a container file equivalent to one minute (approximately less than 70MB in this embodiment) is written, and the file is closed. Each 10MB unit is treated as a single large virtual cluster, and a container file of slightly less than 70MB containing one minute of video information can be stored using seven virtual clusters.

[0070] According to this method, even if the drive recorder 1 repeatedly writes and erases generated information, including video information based on imaging information captured by the CCD camera 13, to the SD card, file fragmentation is less likely to occur than before, and the file can be read on a PC 35 running Windows 10.

[0071] The writing method in Windows 10 is such that when data is written to a file and the file size changes from 0 to 1 or more, one unused cluster is allocated at that time, and that cluster number is set in the directory entry of the file. Subsequently, whenever the file size increases and the cluster being written to overflows, a new cluster is allocated, forming a cluster chain. Therefore, the efficiency of the storage medium can be high when files of different sizes are repeatedly created and deleted. For example, if small and large files are mixed, a contiguous area of ​​cluster numbers may not be allocated, but it can be used without waste, making it a good method for writing files on a PC. However, in the case of drive recorder 1, the container file that records generated information including video information will have a large file size. Therefore, to record video information, setting the cluster size in megabytes will reduce fragmentation and minimize the decrease in efficiency. For example, with FAT, the selectable cluster size during formatting is in kilobytes, so when recording a 70MB file, it is distributed across approximately 7000 cluster locations. A drawback is that repeated writing and erasing gradually fragments the cluster writing locations. However, with this method, contiguous clusters of 10MB each are secured, and the container file is written to these contiguous clusters, thus suppressing fragmentation. (2) In the case of "recording video data of a predetermined unit time into a fixed-length file (visible at initialization)"

[0072] When the controller MC detects that the "Initialize" button has been touched while "Record video data of a predetermined unit time into a fixed-length file (visible at initialization)" is selected, it performs a standard FAT32 format, treating the entire SD card as one partition. After formatting that partition in FAT32 format, it creates 400 fixed-length AVI files of 70MB each on the 32GB SD card (filenames from 0001.avi to 0400.avi) and proceeds to the recording process. These AVI files record a completely black screen as internal video information. During the recording process, a cluster is reserved in a specific location for files readable by the FAT32 file system used in Windows 10. When recording AVI files containing video information, the video is recorded by overwriting the existing AVI files within the pre-reserved cluster, within the limits of the AVI file's size. In other words, for each frame, frame information is generated by compressing the image information acquired from the CCD camera 13 using a predetermined codec (e.g., H.254), adding GPS information and acceleration information as subtitle data in text format, and 60 seconds' worth of frame information is overwritten into a single container file (e.g., an AVI container) created during the initialization process. In this way, a file containing video data is recorded without changing the cluster location of that file. The video information is of variable bitrate, and the fixed length size (70MB) is set to be larger than the size of the container file containing the generated information including video information when recording one minute at the maximum bitrate of the variable bitrate (8Mbps in this embodiment) (8Mbps * 60 seconds / 8 bytes = 60MB in this embodiment). The generated information for one minute is overwritten into the first AVI file, the generated information for the next minute is overwritten into the second AVI file, and so on, until the overwriting of the 400th AVI file is complete, at which point the process returns to overwriting the first AVI file. By repeating this process, data can be continuously recorded into clusters that have been pre-allocated as files.

[0073] In this way, the video data per unit of time is overwritten and recorded within a pre-created fixed-length file. Therefore, file fragmentation can be prevented with almost certainty, and the possibility of corruption of management areas such as FAT can be reduced.

[0074] In this embodiment, the unit time is set to 1 minute. This way, even if an unexpected power outage or removal of the storage medium occurs while the drive recorder 1 is recording video information, the amount of data that may be lost will be limited to less than 1 minute.

[0075] Furthermore, in this embodiment, only the content is overwritten and updated without writing to the file management area. Therefore, the possibility of problems such as the management area of ​​video files recorded on the recording medium becoming unreadable by a personal computer due to an unexpected power outage of the system or the unexpected removal of the recording medium during the update of the file management area, which occurred in conventional systems, can be greatly reduced. Consequently, it is no longer necessary to perform periodic formatting of the recording medium, which was previously required, and a drive recorder superior to conventional models can be provided.

[0076] In this embodiment, the AVI file using a pre-allocated cluster has a function to generate a video-playable file on the Windows 10 operating system of the personal computer 35 during the SD card initialization process. Therefore, when the SD card is read by a personal computer immediately after the SD card initialization process is completed, the AVI file visible can be played and the video can be viewed. The video data of this playable AVI file is set to continuously display a black screen during playback, but it may also be set to a video where the entire screen is covered with another color (for example, a blue screen), or a video that continuously displays text such as "This is an unrecorded file." Alternatively, an AVI file with the above structure containing a predetermined video may be stored in the database 32 of the drive recorder 1 in advance, and this file may be copied from the database 32 to the SD card when generating a file during the initialization process. (3) In the case of "recording video data of a predetermined unit time into a fixed-length file (invisible during initialization)"

[0077] In the process described in (2) above, the process of "creating 400 fixed-length AVI files of 70MB each on a 32GB SD card and proceeding to the recording process" is changed to "creating 400 fixed-length AVI files of 70MB each on a 32GB SD card, replacing the first byte of the filename in the directory entry of all files with byte data indicating deletion (0xE5 in this embodiment), and then restoring the first byte of the filename of the file to its original byte data when data writing to the AVI file begins."

[0078] AVI files that use these pre-allocated clusters are created as invisible files deleted in the Windows 10 operating system of the PC during the SD card initialization process, and have a function to make the files being written to become visible files when the generated information, including video information, is written to the AVI file.

[0079] This prevents the appearance of files with no video data recorded on them when reading the recording medium with the BASOCON35 immediately after the SD card initialization process is complete, as these files utilize pre-allocated clusters. (4) In the case of "recording variable bitrate video data into a fixed-length file of 1 as much as possible (visible at initialization)"

[0080] In (3) above, the generated information, including one minute of video information, is recorded by overwriting a fixed-length file that was previously generated during the initialization process. The first minute of generated information is recorded by overwriting the first AVI file, the next minute of generated information is recorded by overwriting the second AVI file, and so on. ...When the overwriting of the 400th AVI file is complete, the process returns to overwriting the first AVI file. However, instead of recording one minute of video information, the system records in a way that fills the contents of the AVI file as much as possible. That is, the system records while monitoring the capacity of the fixed-length AVI file containing the generated information, so that the variable-bitrate video information is recorded as much as possible into one fixed-length AVI file. Before the capacity is exceeded, the system changes the fixed-length AVI file being recorded to the next AVI file.

[0081] In this way, although the duration of the video recorded in a fixed-length AVI file will not be constant, it solves the problem that occurs with method (3) above, where the entire fixed-length AVI file is not recorded, reducing the amount of video that can be recorded on the SD card. In the method of creating an AVI file in advance (securing a cluster in a fixed location) and overwriting it without changing that cluster location, pre-determining means that the process will never create an AVI file that exceeds that file size. Therefore, method (3) has the biggest drawback, which is that an enormous amount of space is left unused on the SD card, especially when shooting video with a low bitrate and little variation. However, this problem can be solved by doing as in (4).

[0082] To ensure that the data is recorded as fully as possible into a fixed-length AVI file, the following configuration is implemented: at least the video between keyframes (the frame before the next keyframe) is buffered in the RAM of the drive recorder 1's controller MC so that the next fixed-length file starts from a keyframe. If there is still room for the video between keyframes in the AVI file currently being written to, it is written to the AVI file currently being written to; otherwise, it is recorded to the next fixed-length AVI file. The keyframe interval is defined as the interval between I-frames, ensuring that the content of the next fixed-length file does not start from a P-frame or B-frame, and is always configured to start from an I-frame. (5) In the case of "recording variable bitrate video data into a fixed-length file of 1 as much as possible (invisible during initialization)" Similar to the modification of the process in (3) for (2) above, the process for which the modification of the process in (4) is performed is carried out. (6) In the case where "video data to be continuously recorded is recorded in a single, very large file (visible at initialization)"

[0083] When the controller MC detects that the "Initialize" button is touched while "Record continuously recorded video data in a single very large file (visible during initialization)" is selected, it performs a standard FAT32 format, treating the entire SD card as one partition. After formatting that partition in FAT32 format, it creates seven fixed-length 4GB AVI files on the 32GB SD card (filenames from 0001.avi to 0007.avi) and proceeds to the recording process. These AVI files record a completely black screen as internal video information. During the recording process, a cluster is reserved in a specific location for files readable by the FAT32 file system used in Windows 10. When recording AVI files containing video information, the video is recorded by overwriting the existing AVI files within the pre-reserved cluster, within the limits of the AVI file's size. For each frame, the image information acquired from the CCD camera 13 is compressed using a predetermined codec (e.g., H.254), and GPS information and acceleration information are added as subtitle data in text format to generate frame information. This frame information is then overwritten into a single container file (e.g., an AVI container) created during the initialization process until it is full. At this time, the recording is done in such a way that the contents of the AVI file are filled as much as possible. That is, the variable bitrate video information is recorded into a fixed-length AVI file while monitoring the capacity of the generated information recorded into that fixed-length AVI file, and before the capacity is exceeded, the fixed-length AVI file being recorded is changed to the next AVI file. In this way, a file containing video data is recorded without changing the location of the file's cluster. Thus, the drive recorder 1 has a function to continuously record generated information, including video information, to the SD card while the power is on. During the SD card initialization process, multiple files are created in advance as very large 4GB files using pre-allocated clusters, and the continuously recorded video information is recorded within these very large 4GB files.This approach simplifies the process and reduces the likelihood of fragmentation compared to conventional methods.

[0084] In this embodiment, the very large 1 file is defined as, for example, 4GB, which is less than or equal to the capacity of the SD card (32GB) and the maximum file size of the file system that stores the file. However, by changing the format to exFAT, this very large 1 file may be made, for example, a file with a capacity of more than half the capacity of the SD card. In particular, it is preferable that the size of this 1 file be more than half the capacity of the SD card (and, for example, less than or equal to the capacity of the SD card). Within this range, a slider may also be displayed on the screen shown in Figure 6 on the display unit 25, and a function may be provided to set the capacity by user operation (dragging) of the slider. (7) In the case where "video data to be continuously recorded is stored in a single, very large file (invisible during initialization)" Similar to the modification of the process in (3) for (2) above, the process for which the modification of the process in (6) is performed is carried out.

[0085] In the formatting and recording methods described in (1) through (7) above, the format is FAT32, so the files can be accessed using applications such as Windows Explorer on a PC 35. Furthermore, in the formatting and recording methods described in (1) through (7) above, files containing video information are generated in a file format playable on Windows 10 on a PC 35, so AVI files recorded on the SD card can be played on Windows 10 on a PC 35. (8) In the case of "recording in a proprietary format"

[0086] When the controller MC detects that the "Initialize" button is touched while "Record in proprietary format" is selected, it creates two partitions, each half the size of the entire SD card. One is the first partition, which is formatted in FAT32 format. The other partition, which is left unformatted, generates frame information by compressing the image information acquired from the CCD camera 13 with a predetermined codec (e.g., H.254) for each frame, and adding GPS information and acceleration information as subtitle data in text format. This frame information is then recorded directly and sequentially. In other words, the latter partition does not have a management area like FAT, and as a result, it does not write the index of the video information to the management area. Instead, it sequentially packs the generated information, including the video information, into the SD card and writes it.

[0087] This eliminates the concept of fragmentation. Furthermore, video information cannot be viewed using only the standard functions of Windows 10 on a PC. Therefore, it can be said that the security level is also high. Consequently, it eliminates the need for periodic formatting of storage media, which was previously required, and provides a superior system compared to the past.

[0088] Furthermore, in functions (1) through (7), if the recording medium is removed from the system while a management area such as FAT is being written, depending on the timing, the contents of the recording medium may be completely lost. This does not happen with method (8). In functions (1) through (7), it is best to configure the system so that management areas such as FAT are not written as much as possible when recording video information, but it is not always possible to configure everything in this way. In such cases, it is best to choose method (8).

[0089] Furthermore, in the configuration of (8), the SD card may also be provided with a function to perform at least one of the recording processes (1) to (7) in parallel with the recording process of (8) for partitions that use the same format as the format used by the PC 35's Windows 10. In this way, even if one of the partitions is destroyed, the video data can be read and played back from the undamaged partitions.

[0090] In method (8), since the video information is of variable length, it becomes very difficult to find the beginning of a video frame. Therefore, it is advisable to attach chain data to each frame so that it can be searched between frames. It is advisable to have a mechanism where each frame has a directory entry, similar to FAT. The drawback is that it is not visible in general personal computer operating systems, such as in file search applications like Explorer, so a dedicated application is required. For example, if the recording medium is an SD card, writing to a continuous area of ​​the SD card is faster, but writing to non-contiguous areas causes a sharp decrease in writing speed. However, by configuring it as in (10), this can be prevented, and for example, simultaneous writing of a total of 4 streams, such as 2 cameras / continuous recording and events separately, can be achieved. In addition, in communication-type systems, it becomes relatively easy to write 8 streams by adding low-resolution video (video with low capacity) compared to other recording methods.

[0091] Furthermore, in the recording processes (1) to (7), the video information may be recorded with the addition of first information for going back a predetermined time without using the management area, and second information for going back a predetermined frame without using the management area. The drive recorder 1 may be equipped with SD card playback, rewind, and fast-forward buttons, and playback may start when the playback button is detected by the controller MC, and when the rewind or fast-forward button is detected to be pressed, the video may be cueed based on the first and second information. Alternatively, the video cueing process based on the first and second information may be performed on viewer software running on the personal computer 35 in Figure 5.

[0092] According to the functions (1) to (8) described above, a drive recorder 1 can record generated information to an SD card accessible by the drive recorder 1, and when the SD card is accessible from the PC 35, at least a portion of it can be read by the PC 35's Windows 10, but the drive recorder records the generated information using a method different from the writing method in Windows 10.

[0093] This allows information recorded by drive recorder 1 to be read by Windows 10, and also allows recording in a format convenient for drive recorder 1, which is different from the writing method used by Windows 10. In this way, both can be achieved simultaneously.

[0094] In this embodiment, an SD card is used as the recording medium accessible by the drive recorder 1, but it may also be a recording medium connected to the drive recorder 1, such as an SSD or HDD connected via a USB cable.

[0095] In this embodiment, the SD card is considered accessible from the PC 35 when it is inserted into an SD card reader / writer connected to the PC 35. However, for example, the drive recorder 1 may be equipped with a wireless communication function (e.g., a network connection function via Wi-Fi), and the PC 35 may also be equipped with a wireless communication function that can connect to it, allowing the PC 35 to access the SD card of the drive recorder 1. In this embodiment, the part designated as FAT32 may be changed to at least one of FAT16, FAT32, exFAT, etc., depending on the capacity of the SD card.

[0096] Furthermore, it would be beneficial to equip the Windows 10 PC 35 with viewer software, as shown in Figure 5, which has the function of acquiring, expanding, and displaying video information from the generated information in the rear partition recorded by the process described in (10) above.

[0097] Alternatively, the viewer software may be configured as a Windows 10 device driver (a driver that processes the file system) that provides the generated information in the subsequent partition recorded in the process of (10) above as a file for reference, without performing any special reading operations to read the partition after (10).

[0098] In this embodiment, the example of a personal computer 35 was used, but the configuration may be changed by replacing the personal computer with a "smartphone" or "tablet." In these cases, Android is a suitable operating system.

[0099] Furthermore, the scope of the present invention is not limited to the configurations explicitly described in the specification, but also includes combinations of various aspects of the present invention disclosed herein. While the configurations for which patent protection is sought are specified in the appended claims, we intend to include configurations disclosed herein that are not currently specified in the claims in the future.

[0100] The present invention is not limited to the configuration described in the embodiments above. The components of each embodiment and modification described above can be arbitrarily selected and combined. Furthermore, any component of each embodiment and modification can be arbitrarily combined with any component described in the means for solving the invention, or any component that embodies any component described in the means for solving the invention. The present application intends to obtain rights to these as well through amendments or divisional applications. Even if there is a description such as "in the case of..." or "when...", it is not meant to be a configuration that is limited to that case or time. Configurations that do not fall under these cases or times are also disclosed, and the present application intends to obtain rights to them. Also, even if there is a sequence of descriptions, it is not limited to that order. Configurations with some parts deleted or the order rearranged are also disclosed, and the present application intends to obtain rights to them.

[0101] Furthermore, by converting to a design registration application, we intend to acquire rights to the overall design or a partial design. The drawing depicts the entire device with solid lines, but it is a drawing that includes not only the overall design but also partial designs claimed for parts of the device. For example, it is a drawing that includes not only a partial design for a part of the device's components, but also a partial design for a part of the device regardless of its components. A part of the device may be a component of the device, or a part of a component. We intend to acquire rights not only to the overall design, but also to a partial design where any part of the solid lines in the drawing is represented by dashed lines. In addition, all modules, components, and parts inside the device's casing that are shown in the drawing are independently tradable, and similarly, we intend to acquire rights to them by converting to a design registration application. [Explanation of symbols]

[0102] 1...Dashcam, 2...Main unit case, 15...Accelerometer, 24...GPS receiver, 31...SD card reader / writer, 32...Database, 35...PC, 36...SD card reader / writer, 45...Monitor, MC...Controller.

Claims

1. A system that has a function to record generated information on a recording medium, The recording medium is accessible from a personal computer and is readable by the operating system of that personal computer, but it has a function to record the generated information using a method different from the writing method of the operating system. When the recording medium is installed in the personal computer, at least a portion of the recording medium can be read by the operating system of the personal computer, but the method is different from the writing method of the operating system, and in the initialization process of the recording medium of the system, a cluster at a fixed location is reserved for a file that can be read by the file system adopted by the operating system of the personal computer, and the recording of the generated information is done by overwriting the file that uses the cluster reserved in the initialization process, within a limit that does not exceed the size of the file, thereby recording a file containing video data without changing the location of the cluster of the file. The system includes a function to generate a file using the clusters allocated in the initialization process in the initialization process of the recording medium as a fixed-length file that can play video on the operating system of the personal computer, and which contains video data that continuously displays a predetermined screen during playback. A system characterized by the following:

2. A program for a computer to implement the functions of the system described in claim 1.

Images