Alright, let's figure out how to fix this so your encrypted video files can be recognized and played (in their scrambled state) just like those header-preserved PNGs you mentioned.

The trick here is identical to the PNG example: leave the video file's format header completely intact, and only encrypt the actual media content (the frames, audio samples, etc.). Media players rely on the header to identify the file type and parse its structure—so keeping that unencrypted lets the player load the file, even if the actual content is scrambled.

1. Map your video format's structure
   Different video containers (MP4, MKV, AVI, etc.) have distinct header layouts. For example:

   • MP4 uses "boxes" (moov for metadata, mdat for media data)
   • MKV has a header segment followed by clusters of media data
   • AVI has a RIFF header upfront, then the data chunk
     You need to pinpoint exactly where the header ends and the raw media data begins. Don't guess—use format-specific parsers or libraries to get this boundary right.

2. Write the unencrypted header to your output file
   When processing the input video, first read the entire header section and write it directly to the encrypted output file. No encryption here—this is what tells players "hey, this is a valid MP4/MKV/AVI file".

3. Encrypt only the media data
   For the bytes after the header, apply your encryption. But pick an encryption mode that works with streaming/arbitrary-length data:

   • Use AES-CTR or AES-OFB (stream ciphers) instead of CBC/ECB. These modes don't require padding, so the encrypted data length matches the original—critical for media players that expect precise data sizes from the header.

4. Store encryption metadata (if needed)
   If your algorithm requires an initialization vector (IV) or nonce, save it somewhere in the file that won't break the header structure. For example, you can append it right after the header (players will ignore extra bytes at the start if they don't fit the format's header spec) or embed it in an unused field in the header itself.

Here's a simplified example for MP4 files (note: you'll need to replace the hardcoded header size with actual parsing logic):

import os
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

def encrypt_video(input_path, output_path, encryption_key):
    # WARNING: Replace this with actual MP4 header parsing (use libraries like pymp4)
    # This is just a placeholder—don't use fixed sizes in production
    HEADER_END_OFFSET = 1024

    with open(input_path, "rb") as in_file, open(output_path, "wb") as out_file:
        # Write the unmodified header
        header = in_file.read(HEADER_END_OFFSET)
        out_file.write(header)

        # Generate and write IV (needed for AES-CTR)
        iv = os.urandom(16)
        out_file.write(iv)

        # Initialize stream cipher
        cipher = Cipher(algorithms.AES(encryption_key), modes.CTR(iv))
        encryptor = cipher.encryptor()

        # Encrypt and write media data in chunks
        chunk_size = 4096
        while chunk := in_file.read(chunk_size):
            encrypted_chunk = encryptor.update(chunk)
            out_file.write(encrypted_chunk)
        out_file.write(encryptor.finalize())

• Don't skip proper format parsing: A fixed header size will break on different videos. Use libraries like pymp4 (for MP4), mkvparse (for MKV), or even ffmpeg commands to extract the exact header boundary.
• Test with a small video first: Encrypt a short clip, then try opening it with VLC or another flexible player. If it loads and plays scrambled content (visual noise, garbled audio), you're on the right track.
• Decryption needs to reverse this process: When decrypting, read the header, read the IV, then decrypt the rest of the data and combine it with the header to get the original file.

内容的提问来源于stack exchange，提问作者Rf11