Blockchain Fintech Example Patent for Blockchain digest augmentation of group-of-pictures video streams

Invented by Tyson York Winarski, Individual

The market for Blockchain digest augmentation of group-of-pictures video streams is an emerging and promising sector within the blockchain and video streaming industries. This innovative technology combines the benefits of blockchain with the efficiency of group-of-pictures (GOP) video streaming, creating a secure and seamless experience for users. Blockchain technology, known for its decentralized and transparent nature, has already disrupted various industries, including finance, supply chain, and healthcare. Its potential in the video streaming market is no exception. By leveraging blockchain, video streaming platforms can enhance security, reduce costs, and improve the overall user experience. One of the key challenges in video streaming is ensuring the integrity and authenticity of the content. With the rise of deepfake technology and the ease of manipulating videos, trust has become a significant concern for both content creators and consumers. Blockchain digest augmentation addresses this issue by creating a unique cryptographic hash for each video frame or GOP. These hashes are then stored on the blockchain, ensuring that any tampering or alteration of the video can be easily detected. By using blockchain digest augmentation, video streaming platforms can provide users with an added layer of security. Content creators can have peace of mind knowing that their videos are protected from unauthorized modifications, while consumers can trust that the content they are watching is genuine and unaltered. Furthermore, this technology can also improve the efficiency of video streaming platforms. GOP video streaming, which only transmits the differences between frames rather than the entire video, is already a more efficient method compared to traditional streaming. However, by integrating blockchain digest augmentation, the process becomes even more streamlined. The blockchain hashes can be used to verify the integrity of each frame or GOP, eliminating the need for redundant data transmission. This results in faster streaming speeds, reduced bandwidth requirements, and ultimately, cost savings for both content providers and consumers. The market for blockchain digest augmentation of GOP video streams is still in its early stages, but the potential is immense. As more video streaming platforms adopt this technology, users will benefit from enhanced security and improved streaming experiences. Additionally, content creators will have a reliable way to protect their intellectual property and ensure that their work is not tampered with. Investors and entrepreneurs are also recognizing the opportunities in this market. Startups focusing on blockchain-based video streaming solutions are emerging, attracting funding and partnerships from industry leaders. As the demand for secure and efficient video streaming continues to grow, the market for blockchain digest augmentation is expected to expand rapidly. In conclusion, the market for blockchain digest augmentation of GOP video streams holds great promise for the future of video streaming. By combining the benefits of blockchain technology with the efficiency of GOP streaming, this technology offers enhanced security, improved streaming experiences, and cost savings for both content providers and consumers. As this market continues to evolve, we can expect to see more innovative solutions and increased adoption, revolutionizing the way we consume and create video content.

The Individual invention works as follows

Background for Blockchain digest augmentation of group-of-pictures video streams

Blockchain technologies are increasingly used to ensure the safe transfer of information. Hash algorithms take input and convert it into a unique sequence of digits, called a digest, with a high degree of probability. The more digits there are in the hash digest the less likely it is that two inputs with the same hash will collide. The hash function shows the avalanche, which is when a small change in input can have a big impact on the output digest. This specification combines the MFX format with Blockchain hash technology to create a standards compatible implementation. The Material eXchange format (MXF) is a container for digital audio/sound and video media that is defined by a series of SMPTE Standards. SMPTE was originally founded as the Society of Motion Picture Engineers in 1916.

MXF” is a ‘container’ “MXF is a?container? The MXF format supports multiple streams of coded “essence” encoded in a variety video and audio/sound formats. It also includes a metadata wrapper that describes the content of the MXF files. MXF is a stable platform-independent standard that supports full metadata and timecode. MXF is a subset version of the Advanced Authoring Format data model. This was done under the Zero Divergence Directive. Theoretically, this allows MXF/AAF work flows between Non-Linear Editing systems (NLEs) using AAF, and cameras, servers and other devices that use MXF. MXF clips can be divided into two basic types: the first is those in which the media (essence) and metadata are stored together. These files are said have internal essence. These files are called external essence. The second type involves files that store the essence in a separate file from the metadata. The decoder reads first the metadata file and then the files that contain the essence.

XDCAMMXF from SONY”? ADOBE supports XDCAM MXF? What about After Effects and ADOBE? Premiere Pro, APPLE? Final Cut Pro X, AUTODESK? Smoke, AVID, CAPELLA SYSTEMS, DALET, EVS, IMAGINE COMMUNICATIONS COMPANY? Vegas Pro, SORENSON? Squeeze, TELESTREAM? FlipFactory, GRASSVALLEY? EDIUS, GRASSVALLEY? K2, and MERGING technologies? VCube. P2 MXF from PANASONIC? Does ADOBE support P2 MXF? What about After Effects and ADOBE? Premiere Pro, APPLE? Final Cut Pro X, AUTODESK? Smoke, AVID?, DALET?, EVS?, GRASSVALLEY? GRASSVALLEY, EDIUS and AVID? K2. IKEGAMI? IKEGAMI? DN.x.HD at 145 Mbit/second as well as MPEG-2 at 50 Mbit/second long-GOP at 4:2:2 and 100 Mbit/second for I-frame. The GOP is a group of pictures, which includes I (independently coding), P (predictively coding using one picture), B (bipredictively coding using two images) frames. In 2010, Canon? In 2010, CANON? These camcorders record in MPEG-2 video at bitrates of up to 50 Mbit/s and 16-bit linear PCM sound in what format? XF codec. CANON? CANON? Premiere, APPLE? Final Cut Pro X, AVID? Media Composer and GRASSVALLEY. EDIUS. MXF is the audio and video package format used for Digital Cinema Packages (DCP). The STANAG specification documents also use MXF. MXF files are named?.mxf?. The MACINTOSH file type code is?.mxf?. The MACINTOSH? MXF files are referred to as?mxf’, with a trailing space. Internet has?application/mxf’. ADOBE’s CinemaDNG, which is intended to be an open file format for digital cinema files (and others), uses MXF as one of its options. CinemaDNG (intended by ADOBE?

The present specification is aimed at the use of blockchain technology and hash digests to ensure the integrity of media files that contain Group-of-Picture video streams, audio streaming streams, and data streams. Hash digests can be used to secure GOP video streams by using an H-Frame appended to a GOP consisting of I, B, and P frames. Hash digests can be used with blockchain technology to create audio streams. An AH-Frame is created that adds audio information. Hash digests can be used to append a data block in data streams. Media files containing GOPs, data blocks, audio blocks and H-Frames can be packaged into MXF files for transmission. In one embodiment, blockchain hash digests for GOPs in the H-Frames are based on hashing the I, P, and B frames. In a second embodiment, the hashing of I-Frames from a series of GOPs is used to create the blockchain digests of GOPs for H-Frames.

The present specification discloses a digital Group Of Pictures (GOP), blockchain, stored in electronic memory. The digital Group of Pictures comprises a first Group Of Pictures with I, B and P frames, as well as a first H Frame containing hash information derived from the first Group Of Pictures, along with a previous Group Of Pictures. This data structure creates a first block of blockchain data with the first Group Of Pictures and the first hash information. The digital Group of Pictures includes a Second Group Of Pictures with I, B and P frames, as well as a Second H-Frame that contains second hash digestion information formed from the Second Group Of Pictures, and a First hash digest from the First Group Of Pictures. This data structure creates a second block of blockchain data with the second Group Of Pictures and the second hash information. The digital Group of Pictures can also include an initial Group Of Pictures with I, B and P frames, as well as a genesis-H-Frame that contains genesis hash digestion information formed from the original Group Of Pictures. This data structure creates a genesis block that contains the data of the Group Of Pictures and the blockchain hash information. The first hash digestion information can be either a first digest or a link to an online first digest. The second hash digestion information can be a cloud-based, second hashdig or a link. The genesis digest information can be either a genesis digest or a link to cloud-based genesis digest. Links to cloud-based digests can be accessed without security credentials on a public blockchain system. The links to cloud-based digests can be accessed only by security credentials for a blockchain system with private access. The first hash-digest can be created from the I Frames from the first Group Of Pictures, and the hash-digest from the I Frames from the previous Group Of Pictures. The second hash-digest can be created from the I Frames of the second Group Of Pictures, and the first hash-digest. First, the hash digest can be created from the I-, B-, and Pframes from the first Group Of Pictures, along with a previous hash digest that was made from the I-, B-, and Pframes from the prior Group Of Pictures. The second hash is created from the I,B,and P-Frames in the second Group Of Pictures, as well as the first hash. A link to a cloud-based key can be stored in the first H Frame. This allows the first Group Of Pictures to be encrypted. A link to a second cloud based encryption key can be stored in the second H Frame. The initial Group Of Pictures can be encrypted using an initial cloud based encryption key. A link to the first cloud based encryption key will be stored in the genesis H Frame. The first H Frame may also include an algorithm identification specifying which hashing algorithm was used to create the first hash-digest. The second H Frame can contain an algorithm identification specifying what hashing algorithm was used to create the second hash-digest. The digital Group of Pictures can also include a Material eXchange format (MXF), a digital file with a system item, and a generic container. The system item includes metadata for the genesis Group Of Pictures and first Group Of Pictures. The generic container includes the genesis Group Of Pictures and first Group Of Pictures as well as the genesis H Frame, first H Frame, and second H Frame. The generic container can store the genesis H Frame, first H Frame, and second H Frame together as a H Frame set. The genesis H Frame, first H Frame, and second H Frame can be sequentially stored before their respective Group Of Pictures in the generic container. The genesis H Frame, first H Frame, and second H Frame can also be stored in a generic container sequentially, after the respective Group Of Pictures. The Material eXchange format (MXF), digital file can be sent electronically by a sender over a communication link like a satellite transmission, a wireless terrestrial transmission, or a distributed communications network. The MXF File System Manager on the receiver performs an error check of the Material eXchange Format digital file. It extracts the genesis Group Of Pictures from the generic container, creates new hash digests for the genesis Group Of Pictures and first Group Of Pictures and then compares these to the blockchain hash digest information stored within the genesis H-Frame, first H-Frame, and second MXF digital file. The MXF File System Manager compares the new hash digestions with the blockchain hash information contained within the genesis H Frame, first H Frame, and second H Frame transmitted in the Material eXchange Format digital file. When the new hash-digests do not match with the blockchain hash-digest information stored in the genesis Hframe, first Hframe, and second Hframe transmitted in the Material eXchange Format digital file, the receiver asks the sender for a retransmission.

The present specification discloses a digital media file chain stored in an electronic memory. The digital media file chain includes a group of Group Of Picture files (GOP), a set audio files and a collection of data files. The group of Group of Pictures files include a Group Of Pictures, a GOP Hash File containing GOP hash digestion information formed from both the Group Of Pictures as well as a previous GOP hash from another Group of Pictures. This data structure creates a GOP block with the Group Of Pictures data and GOP hash digestion information as GOP Blockchain hash digest data. The set of audio data includes an audio file, an audio hash information file that contains audio hash digestion information generated from the audio and prior audio hash from an earlier audio file. This data structure creates an audio block with the audio file and audio hash digestion information. The set of files includes both a data file as well as a data-hash file that contains data-hash digest information derived from the data file, and an older data-hash digest derived from an earlier data hash. This data structure creates a data block with the data file and data hash digestion information. The GOP hash digestion information can be either a hash of the GOP or a link to an online GOP hash. Audio hash digestion information can be audio hash, or audio file hash information can be a hyperlink to a cloud based audio hash. Data hash digestion information can be a data hash, or a link to cloud-based data digest. When the Group of Picture files are encrypted, the GOP hash file can include an algorithm identification specifying the hashing algorithm used to create the GOP hash digest as well as a link to the cloud-based encryption key. When the audio files have been encrypted, the audio hash file can include an algorithm identification specifying the hashing algorithm used to create the audio hash digest as well as a link to the cloud-based encryption key. Data hash files may also include an algorithm ID specifying the hash algorithms used to create the data hash and a link that leads to a cloud-based key for encryption. The blockchain for digital media files may also include a Material eXchange Format digital file (MXF), which has a system item, and a generic file container. The system item includes metadata for the Group Of Picture Files, audio files and data files. The generic container holds the group of picture files, audio files and data files. Material eXchange format (MXF), a digital file, is sent electronically by a sender over a communication link. This could be a satellite link, a wireless terrestrial link or a network-wide communications link. The MXF File System Manager, located at the receiver, checks for errors in the Material eXchange Format digital file. It extracts the group of picture files, audio files and data files from the generic container, then creates a hash digest for the Group Of Picture files and audio files and data files. The MXF file system manager compares new hash digestions with GOP blockchain hash information, audio Blockchain hash information, and data Blockchain hash information received along with the Material eXchange Format digital file. When the new hash-digests do not match with the GOP blockchain hash-digest information, audio blockchain digest information and data blockchain digest information that was received along with the Material eXchange format (MXF), digital file, the receiver asks the sender for a retransmission.

The present specification discloses a method for digitally transmitting a Group Of Pictures in a Material Exchange Format (MXF). This method will access an stored Group Of Pictures from a digital storage device, and generate a digest from both the stored Group Of Pictures and a previous digest of a Group Of Pictures. The method stores the hash-digest information in an H Frame file that is appended to the Group Of Pictures and creates metadata for the Group Of Pictures. The method wraps Group Of Pictures in a Material Exchange Format (MXF), by placing both the Group Of Pictures and H-Frame files within a generic container, and storing metadata as a system item. The method then transmits the Material eXchange format (MXF), either via a satellite transmission, a wireless terrestrial transmission, or a network communication link. This method allows the Group Of Pictures to be encrypted using a cloud-based key. The H-Frame may store a link to the cloud based encryption key. Hash digest information can also be linked to a cloud hash digest. It may be possible to access the link to a cloud-based digest without any security credentials in a blockchain system with public access. Only security credentials can be used to access the link to a cloud-based digest for a blockchain system with private access. The H-Frame may also contain an identifier specifying which hash algorithm was used to create the cloud-based digest. The method includes also accessing the Material eXchange format (MXF), File at the recipient node, after it is transmitted from the sender. It then parses the link from the Material eXchange format (MXF), File. The method accesses cloud-based hash digestion with the link, and parses the Group Of Pictures File in the generic Container from the Material eXchange Format(MXF). The method then creates a new hash of the Group Of Pictures File at the receiver node, and compares it to the cloud hash. When the cloud-based hash digest is matched by the new hash, the method will allow access to Group Of Pictures. When the new hash does not match with the cloud-based, the method denies access to the Group Of Pictures File and contacts the sender node for a retransmission of the Material eXchange format (MXF). This method can also access the Material eXchange format (MXF), after it is transmitted by the sender. In this case, the hash-digestion information in the H Frame is a digest. The method parses the hash from the Material eXchange Format File (MXF). The method parses also the Group Of Pictures File in the generic Container from the Material eXchange Format(MXF). The method creates a new hash of the Group Of Pictures File at the receiver node, and compares it to the hash accessed from Material eXchange Format(MXF) file. The method allows access to Group Of Pictures when the new digest matches that accessed from Material eXchange format (MXF). The method will, however, deny access to Group Of Pictures if the new hash does not match that accessed through the Material eXchange Format File (MXF). When the new hash value does not match that of the Material eXchange Format File (MXF), the method will contact the sender to retransmit it to the receiver. The method can also decrypt the Group Of Pictures File using the cloud-based encryption keys with the link that is stored in the H Frame.

The following description will reveal further aspects of the invention. In addition, the novelty features that characterize the invention are highlighted in detail by the claims attached to this specification.

The invention is described and illustrated with reference to one embodiment. However, those of skill in the art will understand that the form and detail can be changed without departing from its spirit or scope. FIG. FIG. In this example, the media file is a video 2. Video file 2 may be structured as a video chain 4. The video file 2 has a description that shows a video chapter 6, and a video chapter 8, respectively. Video chapters 6 and 8 can represent different parts of a movie. The first video chapter 6 contains a video scene 10 Video scenes 12 and 14 are included in the second video chapter 8. Video Scene 10 contains a Group Of Pictures GOP1 18 and an audio file AUDIO1 30 as well as a data file. Group of Pictures GOP1 18, is composed of I-Frames and B-Frames. GOP1 18 can also be paired with H-Frame 16 H-Frame is a frame that contains hash digest information. H-Frame 16, which contains hash digest data on GOP1 18, is a frame of the present invention. In the present invention, Video 2 is organized into a video chain 4. H-Frame 16 contains hash digestion information for GOP1 18 and hash information from an earlier Group Of Pictures. This information could include a hash digest. The hash-digest information in H-Frame 16 could also include a hyperlink to a cloud-based digest.

AUDIO130 is paired similarly with AH Frame 28. AUDIO1 is a digital audio file that contains sound information such as sound effects, the soundtrack and human speech. It also includes GOP1 18. Audio-Hash Frame 28 contains audio hash data about AUDIO1 File 30 and audio hash digests from previous AUDIO files. This hash information can include a hash. Alternatively, hash-digest information in AH-Frame 28 could include a hyperlink to a cloud hash-digest. DATA138 is paired with DH Frame 36. DATA1 is a digital data file that includes audio and video information AUDIO1 30, as well as the GOP1 18 video information. DATA138 may contain digital information, such as closed captioning information for video scene 10, digital data about GOP1 and AUDIO1, links to cloud-based information. DH-Frame is a Data Hash frame which contains hash digests for DATA138 and a previous DATA, forming a chain. The H-Frames 16, AH Frame 28, and DH Frame 36 allow the error checking of their associated files GOP1 18 AUDIO1 30 and DATA138. For illustrative purposes, the first video chapter 6 has a single video sequence 10. The first video chapter may contain any number of scenes 10. For illustrative purposes, video scene 10 has one GOP1 18 and one AUDIO1 30. Video scene 10 can have any number Groups Of Pictures (GOPs), any number AUDIO blocks (AUDIO blocks) and any number DATA blocks.

Second Video Chapter 8 includes two videos scenes, 12 & 14, to illustrate the concept. Second video chapter 8 can include any number video scenes. The GOP2 22nd and GOP3 26th follow the GOP1 18th in sequence. GOP2 22 pairs with H-Frame. H-Frame 20 includes hash digest information about GOP2 22. This hash-digest information can be an actual hash-digest or a hyperlink to a cloud based hash-digest. The present invention organizes Video 2 into a video chain 4. In this way, H-Frames 20, 24 and 30 include interlinking information on their respective GOPs and a previous GOP in order to form a series of interlinking digests. H-Frames 20 and 24 include hash digest data based on GOP1 18 & GOP2 22. H-Frame 20 includes hash digestion information based on GOP1 18 and GOP2 22. This hash-digest information can be either an actual hash-digest or a cloud hash-digest. Scene 12 of the video includes GOP2 22 as well as H-Frame. Video scene 14 contains GOP3 26 as well as H-Frame 25. Note that AUDIO234 spans video scenes 12 and 14. A musical score is often repeated across several video scenes. AUDIO234 is paired with AH Frame 32. AH Frame 32 contains audio digest information based upon AUDIO234 and AUDIO130, forming a link between AH Frame 28 and AH Frame 32. DATA2 is paired with DH Frame 40. DATA3 48 is paired with DH Frame 44. DH-Frame 44 includes hash digest data based on DATA1 36. DH-Frame 40 includes hash digest data based upon DATA3 42 and DATA2 46. The DH Frame 40 and DH Frame 44 are interlinked hash digests that form a series with DH Frame 36.

The video content 2 can be described as video blockchain 4.” Video blockchain 4 contains a series Group Of Pictures blocks: GOP-1 48; GOP-2 50; and GOP-3 52. This is only an example of video blockchain 4, which has three blocks of Groups of Pictures. Video blockchain 4 can have any number Groups Of Pictures block. GOP-1 block 48 contains GOP1 18 in data, and hash digest from H-Frame 16, as blockchain hash digestion information. GOP-2 block 48 includes GOP2 22 and hash-digest information from H Frame 20 as blockchain digest information. GOP-3 block 50 includes GOP3 26 and hash-digest information from H Frame 24 as blockchain digest information. Video blockchain 4 can include any number audio blocks of blockchain data. In this example, video blockchain 4 contains two audio blocks of blockchain information, AUD-1 block 54 and AUD-2 block 56. AUD-1 block 56 includes AUDIO1 34 as data, and the audio hash-digest information from AH Frame 28 as blockchain digest information. AUD-2 block 54 includes AUDIO2 36 as data and the audio hash digestion information from AH-Frame 31 as blockchain hash information. Video blockchain 4 can include a chain of any number DATA blocks. FIG. FIG. DAT-1 block 58 contains DATA138 as data, and also the hash-digest information from DH Frame 36 as blockchain digest information. DAT-2 Block 60 contains DATA2 42 and the hash-digest information from DH Frame 40 as blockchain digest information. DAT-3 Block 62 contains DATA338 as data, and also the hash-digest information from DH Frame 36 as blockchain digest information.

FIG. The diagram in Figure 2 shows a video stream consisting of Group Of Pictures (GOP), I, B and P Frames, shown in a stored order of 64. Each GOP is preceded with an H-Frame such as H Frame 66. GOP 64 includes I Frame 68 and B Frames 70,72,76,78,82,84,88,90. GOP 64 includes P-Frames 80, 86 and 74. I-Frame 68 is a frame which is coded separately from all other frames. This type of frame is the first one in each GOP 64 (in order). The P-Frames (predictive codes frames) contain motion-compensated differences relative to previous decoded frames. The Groups of Pictures shown in FIG. are represented by GOP 64. 1. This includes GOP1 18, GOP2 22 and GOP3 26, as well as GOP1. In older designs, such as MPEG-1, H.262/MPEG-2, and H.263, a single P-Frame may only refer to one frame. This frame must appear before the P Frame in both display and decoding order, and it must be either an I-Frame, or a P Frame. The newer standards H.264/MPEG-4 AVC, and HEVC do not have these constraints. The motion-compensated differences information in B-Frames 72, 76, 78, 80, 84, 90, and 92 (bi-predictive codes frames) is relative to the previously decoded frames. In older designs, such as MPEG-1 or H.262/MPEG-2 each B-Frame may only refer to two frames: the frame that precedes it in the display order, and the following frame. All referenced frames are I-Frames and P-Frames. The constraints of older standards such as MPEG-1 and H.262/MPEG-2 do not apply to the newer H.264/MPEG-4 AVC or HEVC. HEVC is High Efficiency Video Coding. It’s also known as H.265 or MPEG-H part 2. HVEC is a standard for video compression, and one of the potential successors to AVC (H.264) or MPEG-4 Part 10. HEVC is about twice as data-efficient at the level of video quality or video quality that AVC provides. It supports resolutions of up to 8192.times.4320 including 8K UHD. AVC is Advanced Video Coding. It is a block-oriented motion-compensation-based video compression standard. I-Frames, P-Frames, and B Frames of Group of Pictures 64 are often denoted by two numbers. For example, M=3,N=12. The first number indicates the distance between anchor frames (I and P). The second number tells the distance of two full images, or I-frames. This is the size for the GOP. In FIG. In FIG. In the repeated sequence IBBPBBPBBPBB IBBPBBPBBPBB IBBPBBPBBPBB IBBPBBPBBPBB, there is an I frame or a P frame every 3 frames. . . .

FIG. The diagram in Figure 3 shows a process of creating a hash digest on the blockchain of a group of pictures (GOP), based on an existing GOP 64 and previous GOP. The process shown in FIG. The process of FIG. 1 (including GOP1 18, GOP2 22 and GOP3 26) is converted into a digest hash for use with the Group Of Pictures hashed. The cryptographic hash module 386 shown in FIG. The process in FIG. To generate a Blockchain hash digest for a Group Of Pictures, use step 3. The cryptographic hash module 386 receives input data in step 92. The blockchain hash information for a block is created based on data from the current block and the previous block’s hash information. In this case the input data used to calculate the hash of a specific blockchain block is the data from GOPn as well as the hash of GOPn?1. In this case, GOPn is the GOP 64 in FIG. The 2 is made up of I-Frames, B-Frames, 70, 72 and 76. P-Frames, 80, and 86. The cryptographic hash module 386 uses the data from step 92 to run one of several algorithms such as SHA 224, SHA 256, SHA 512, SHA 512/224, SHA 512/256 or MD5. The hash digest of GOPn, which is based on GOPn and GOPn’s 1, is output in step 96. The hash digest created in step 96 will be placed into H-Frame 65. The hash-digest produced in step 96 can also be stored in a cloud location, and a link is placed in H-Frame 66. The hash digest created in step 96 can be used to form the GOP chain as shown in FIG. 5 .

FIG. Table 104 defines the format of an H-Frame, for example the Groups of Pictures shown in FIG. The table 104 in Figure 1 shows the format of the H-Frame for a Group of Pictures, such as the Groups of Pictures shown in Figure 1. 3 . The H-Frame is shown in column 108, which shows the bytes of interest. If byte-0 is 110 and not FEh or FFh then byte 110 contains the hash algorithm as described in Section 112, e.g. SHA224 (00h), SHA256 (01h), SHA-384 (0h), SHA512 (03h), SHA512/224 (4h), SHA512/256 (5h), MD5 (06h), etc., where?h? Hexadecimal is denoted by?h? Two hexadecimal numbers are contained in a single byte. H-Frame does not limit itself to the SHA algorithm shown in FIG. Other algorithms may be added to 4 as well. If byte-0 is 110, FEh then an identifier will be provided to indicate that there is a hyperlink to a cloud based encryption key, and to a hash digest cloud based of the GOP 64 as associated with the H Frame, as shown in 112. In some embodiments GOP 64 can be encrypted using a key. The key that is used to encrypt GOP 64 can be stored on the cloud. If byte-0 is 110 (1111 1111 binary), you can download the hash algorithm identifier and the resultant hash digest from the cloud or website. If byte-0, 110, is anything but FEh, or FFh, starting with byte-1, 114, the blockchain digest, in hexadecimal, is added, such as example digest 1ef801f01d5231845f1c5c92aae9511d282b44b8 . . . As shown in section 116. The SHA algorithm in byte-0 of 110 determines the length of the digest. The SHA-2 hash functions have digests that are 224 bit (28 bytes), 256 bit (32 bytes), or 384 bit (48 bytes). Once one of these hash algorithm is selected in byte 0 110, the length of the blockchain digest in bytes is known. The following is an example of how to access an H-Frame that uses the SHA-256 algorithms. (With spaces added for easier reading) 01 1ef801f01d5231845f1c (5c92aae9511d282b44b8 a3b7c6d1e5f21234267a (2f3a(h)). In section 116, if byte-0 is 110 and is FEh then byte-1 is 114. This is the link to the cloud-based encryption key, as well as the cloud-based hash-digest of the GOP 64 that is associated with the H Frame. If byte-0 is FFh then section 116 will provide a link for the cloud or website that contains both the hash algorithm and digest. This link can be used to restrict access to hash algorithms and digests to those with access credentials. Links to cloud-based digests can be accessed without security credentials in a public blockchain system. The links to cloud-based digests can be accessed only by security credentials of a private blockchain system.

FIG. “FIG. 1. GOP-1 block 48. GOP-2 block. 50. GOP-3 block. 52. As information, GOP-1 block 48 contains a hash of GOP-1 48 and a previous blockchain block’s hash (not shown). The data in GOP-1 block 48 includes all of the Group Of Pictures, GOP1 18. As information, GOP-2 block fifty includes a hash of GOP-2 50 as well as the hash of GOP-1 48. As data, GOP-2 block includes all Group Of Pictures GOP2 22, as well as a hash digest of GOP-2 50. GOP-3 block 50 includes a digest of GOP-3 52 and the previous blockchain block GOP-2. Group Of Pictures GDP3 26 is also included in GOP-3 block 52.

FIG. The diagram in Figure 6 shows a group of I-Frames formed by I-Frames 124, 126, 128, 130, 132, 134, 136, 138, 140, 142, 144, and 146 that were extracted from a Group-Of-Pictures. GOIF 120 can be a subset or the whole video stream. It is preceded by H-Frame 122. Ikegami can provide a series of I Frames in its 100 Mb/second Mode. In a different embodiment, a series I-Frames can be a series JPEG, JPEG-2000 (Joint Photographic Experts Group), TIFF (Tagged Image File Format), GIF, PNG, or bitmap formats. H-Frame 120 contains the blockchain digest for this series of I Frames, whether or not there are any P or B frames between. H-Frame 120 also contains the hash algorithm used. The B-Frames, P-Frames, and C-Frames all contain information about the motion-compensated differences. I-Frames have a code that is independent of other frames. They are therefore the most important to protect. It may be more efficient to create a video blockchain and blockchain hash digest from just the I Frames of a Group Of Pictures, rather than including the P Frames and B Frames.

FIG. The diagram in Figure 7 shows a process of forming a hash digest on a blockchain of a group of I-Frames based on a previous GOIF. The GOIF can be formed by combining all the I-Frames from a video stream. Input data 148 of the cryptographic hash functions 150 include Group Of I Frames 120 which includes I Frames 124,126,128,130,132,134,136,138,140,142,144 and146. The cryptographic hash module 386 uses input data 146 to apply the cryptographic hash 150. Cryptographic hash functions 150 include SHA 224, SHA 256, SHA-384, SHA 512, SHA 512/224, SHA 512/256, and MD5. These hash algorithms are used as examples. Any hash algorithm can be used with this process. The output of the cryptographic ish function is a hash of Group Of I-Frames 152. This is used to convert a number of GOIFs in a GOIF chain as shown in FIG. 9 .

FIG. “FIG. 7 . The H-Frame is shown in column 156, which shows the bytes of interest. Column 162 gives the description for those bytes. If byte-0 is 158 and not FEh or FFh then byte 158 contains the hash algorithm as described on 164. For example, SHA224 (00h), SHA256 (01h), SHA-384 (0h), SHA512 (03h), SHA512/224 (4h), SHA512/256 (5h), MD5 (06h), etc., where?h? Hexadecimal is denoted by?h? Two hexadecimal numbers are contained in one byte. H-Frame does not limit itself to the SHA algorithm shown in FIG. Other algorithms may also be added. If byte-0 is FEh then an identifier will be provided to link to a Cloud-based encryption key, and a Link to a Cloud-based hash-digest of the GOIF 120 that is associated with the H Frame as described in section 164. In some embodiments, GOIF 120 can be encrypted using a key. The key that is used to encrypt GOIF 120 can be stored on the cloud. If byte-0 is not FEh or FFh, then the cloud will store the key used to encrypt GOIF 120. If byte-0, 158, is anything but FEh, or FFh, starting with byte-1, 160, the blockchain digest, in hexadecimal, is added, such as example digest 1ef801f01d5231845f1c5c92aae9511d282b44b8 . . . As noted in section 162. The SHA algorithm is listed at byte-0 in 158. The SHA-2 hash functions have digests that are 224 bit (28 bytes), 256 bit (32 bytes), or 384 bit (48 bytes). Once one of these algorithms is selected in bytes 158 and 158a, it is possible to determine the size of the blockchain digest. The following is an example of how to access an H-Frame that uses the SHA-256 algorithms. (With spaces added for easier reading) 01 1ef801f01d5231845f1c (5c92aae9511d282b44b8 a3b7c6d1e5f21234267a (2f3a(h)). In section 166, if byte-0 is FEh then starting at byte-1 is 160 a link is provided to a cloud based encryption key as well as a link for a cloud based hash digest associated with the GOP 64. If byte-0 is FFh then section 166 provides a link for the hash algorithm and digest. This link can be used to restrict access to hash algorithms and digests to only those with access credentials. Links to cloud-based digests can be accessed without security credentials on a public blockchain system. The links to cloud-based digests can be accessed only by security credentials of a private blockchain system.

FIG. The figure 9 shows an example of a blockchain 168 formed by multiple Group Of I-Frames 120, which are created from a group of Group Of Pictures. FIG. In FIG. 9, there is a non-limiting, but exemplary blockchain consisting of three GOIF block 170,172, and174. The blockchain 168 can contain any number or blocks of blockchain, even a single block when a GOIF includes all the I-Frames of an entire video stream. The GOIF-1 blockchain block 170 contains a hash of the block itself, as well as GOIF-1 170- and an earlier GOIF block (not shown). GOIF-1 Block 170 includes all Group Of I Frames GOIF1 as well (based on GOIF120). As information, GOIF-2 Block 172 contains a hash of its own, GOIF-2 172, as well as the hash of GOIF-1 Block 170. GOIF-2 Block 172 includes all data from Group Of I Frames GOIF2 based on GOIF120. The GOIF-3 blockchain block 174 contains a hash of itself (GOIF-3 174) and the previous block of the blockchain GOIF-2172. GOIF-3 Block 174 includes Group Of I Frames GOIF3 as well (based on GOIF120).

Click here to view the patent on Google Patents.