H26x 00 01 00 detected as start code at certain alignments

[festlv]

Potentially related to #212: at certain alignments, 00 01 00 is detected as start code.

The following test case can be used to reproduce the issue:

TEST(FormatTests, h264_scl_00_01_00) {
    uvgrtp::context ctx;
    uvgrtp::session* local_session = ctx.create_session("127.0.0.1");
    std::shared_ptr<uvgrtp::rtp>    rtp_;
    auto socket_ = std::shared_ptr<uvgrtp::socket>(new uvgrtp::socket(0));
    auto format_26x = uvgrtp::formats::h264(socket_, rtp_, 0);
    int scl_start_offset = 32;

    for (int offset = 0; offset < 16; offset++) {
        uint8_t data[DATA_SIZE];
        memset(data, DATA_VALUE, DATA_SIZE);

        //00 01 00 somewhere before the real start code
        data[offset] = 0;
        data[offset + 1] = 0x1;
        data[offset + 2] = 0;
        //real scl
        data[scl_start_offset + offset] = 0;
        data[scl_start_offset + offset + 1] = 0;
        data[scl_start_offset + offset + 2] = 1;

        std::cout << "Testing h264 SCL offset " << scl_start_offset + offset << std::endl;
        uint8_t start_len;
        size_t out = format_26x.find_h26x_start_code(data, 128 - offset, 0, start_len);

        EXPECT_EQ(3 + scl_start_offset + offset, (int)out);
        EXPECT_EQ(3, start_len);
    }
}

[jrsnen]

Hi, thanks for reporting this. It does indeed seem like 010 is recognized as start code, which shouldn't happen. The bug is probably somewhere in this function.

[jrsnen]

The issue is caused by how scl rotates the current and previous value for h264. I'll fix this soon.

[jrsnen]

Fixed by 73018e2bdfed2b753c8dbeea48dba8c5962785b0