使用recvfrom接收H264视频流出现0xFF字节：来源及安全移除方法

Hey there, let's walk through your problem step by step.

Short answer: VLC doesn't intentionally inject large chunks of 0xFF into H264 streams by default, but there are a few edge cases where you might see this:

• UDP packet padding: UDP has a minimum packet size requirement on some network devices. If VLC sends a packet smaller than this minimum, intermediate routers/switches might pad the packet with 0xFF to meet the size requirement.
• Encoding edge cases: While H264's RBSP (Raw Byte Sequence Payload) can include padding bytes for alignment, these are rarely continuous large blocks of 0xFF. It's more likely a transport issue than a VLC encoding choice.
• Misconfigured VLC settings: Double-check your VLC push stream configuration—some obscure options (like forced packet padding) might inadvertently add these bytes, though this is uncommon.

To confirm, use a packet sniffer (like Wireshark) to inspect the packets VLC sends directly. If the 0xFF blocks are present in the outgoing packets, then VLC is the source; otherwise, it's a network/transport layer issue.

Since you've confirmed they aren't packet delimiters, the key is to tie the removal logic to H264's structure (specifically NALU start codes) to avoid corrupting valid stream data. Here's a practical approach:

1. Locate NALU boundaries first #

H264 streams are made up of NALUs (Network Abstraction Layer Units), each prefixed with a start code: either 0x000001 (3-byte) or 0x00000001 (4-byte). Use these start codes to segment the stream into valid NALUs—this helps you distinguish between extraneous 0xFF blocks and valid data.

2. Handle 0xFF blocks based on their location #

• Between NALUs: If the 0xFF blocks sit between two NALU start codes, they're irrelevant padding and can be safely removed. H264 decoders only care about the start codes and NALU payloads; intermediate junk bytes are ignored.
• Inside a NALU: Continuous large 0xFF blocks inside a NALU are almost always a sign of corrupted data (either from transmission errors or bad padding). In this case, it's safer to discard the entire corrupted NALU rather than trying to salvage it—keeping corrupted data can break decoder sync.

3. Example code snippet (C/C++) #

Here's a simplified example of how to filter out the extraneous 0xFF blocks while preserving valid H264 data:

#include <stdint.h>
#include <string.h>

// Helper to find the next NALU start code in a buffer
uint8_t* find_nalu_start(uint8_t* buf, int len) {
    if (len < 3) return NULL;
    for (int i = 0; i < len - 3; i++) {
        if (buf[i] == 0x00 && buf[i+1] == 0x00) {
            if (buf[i+2] == 0x01) return &buf[i];
            if (i+3 < len && buf[i+3] == 0x01) return &buf[i];
        }
    }
    return NULL;
}

void filter_ff_blocks(uint8_t* input_buf, int input_len, uint8_t* output_buf, int* output_len) {
    uint8_t* ptr = input_buf;
    uint8_t* end = input_buf + input_len;
    uint8_t* out_ptr = output_buf;

    while (ptr < end) {
        uint8_t* nalu_start = find_nalu_start(ptr, end - ptr);
        if (!nalu_start) {
            // Cache incomplete data for next iteration
            memcpy(out_ptr, ptr, end - ptr);
            out_ptr += end - ptr;
            break;
        }

        // Skip all 0xFF blocks between current pointer and NALU start
        while (ptr < nalu_start) {
            if (*ptr == 0xFF) {
                // Skip consecutive 0xFF
                while (ptr < nalu_start && *ptr == 0xFF) ptr++;
            } else {
                // Preserve non-FF bytes (rare, but just in case)
                *out_ptr++ = *ptr++;
            }
        }

        // Copy the NALU start code
        int start_code_len = (nalu_start[2] == 0x01) ? 3 : 4;
        memcpy(out_ptr, nalu_start, start_code_len);
        out_ptr += start_code_len;
        ptr = nalu_start + start_code_len;

        // Find next NALU to get current NALU length
        uint8_t* next_nalu = find_nalu_start(ptr, end - ptr);
        int nalu_data_len = next_nalu ? (next_nalu - ptr) : (end - ptr);

        // Check if NALU has excessive FF bytes (corrupted)
        bool is_corrupted = false;
        int consecutive_ff = 0;
        for (int i = 0; i < nalu_data_len; i++) {
            if (ptr[i] == 0xFF) {
                consecutive_ff++;
                if (consecutive_ff > 10) { // Arbitrary threshold for "large block"
                    is_corrupted = true;
                    break;
                }
            } else {
                consecutive_ff = 0;
            }
        }

        // Copy valid NALU data, skip corrupted ones
        if (!is_corrupted) {
            memcpy(out_ptr, ptr, nalu_data_len);
            out_ptr += nalu_data_len;
        }

        ptr = next_nalu ? next_nalu : end;
    }

    *output_len = out_ptr - output_buf;
}

4. Additional tips #

• Test with another streaming tool: Try pushing the same H264 stream with FFmpeg. If the 0xFF blocks disappear, the issue is specific to your VLC configuration.
• Adjust UDP MTU: VLC's UDP streaming MTU setting might be too small, triggering padding. Try setting it to 1400 (a safe default for most networks) to reduce the chance of packet padding.
• Validate with a decoder: After filtering, feed the processed stream to a lightweight H264 decoder (like FFmpeg's ffplay) to ensure you haven't corrupted valid data.

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