interpret Annex B sequences

Servers are not supposed to use Annex B sequences in RTP payloads, but
V380 cameras do. Retina promises that it "works around brokenness in
cheap closed-source cameras", so let's try to make this work.

As noted by @Curid in #108, there's prior art: gortsp does Annex B
decoding. ffmpeg also appears to support this, perhaps by accident: the
output from its RTP layer is in Annex B format, and it doesn't error on
Annex B sequences in RTP, so callers implicitly get the same result with
proper or improper framing.

Along the way, notice NALs that illegally contain the sequences
`00 00 00` or `00 00 02` and ones that illegally end with `00`. We'll
see if this happens in practice, but I'd prefer to explicitly consider
how to work around it if so, rather than passing along bad data
unknowingly.

Throughput on my laptop falls from 3.4 GiB/s to 2.9 GiB/s on the
`depacketize/h264_aac_discard` test, which uses realistic data.
I think that's acceptable. The code avoids unnecessary copies (or
refcounts even) and uses `memchr::memchr` to optimize the case of
looking for the next zero byte. From skimming a profile, most of the
added time is in `memchr`, so I don't think we're going to do much
better than that.

Fixes #68
Fixes #108

Author: scottlamb

CHANGELOG.md

@@ -1,6 +1,10 @@
 ## unreleased
 
 *   improve some error messages on bad H.264 `sprop-parameter-sets`
+*   interoperate with V380 cameras by interpreting Annex B sequences in contexts
+    where single NALs are otherwise expected.
+    (Fixes [#68](https://github.com/scottlamb/retina/issues/68),
+    [[#108](https://github.com/scottlamb/retina/issues/108)]).
 
 ## `v0.4.10` (2024-08-19)
 

Cargo.lock

@@ -30,6 +30,7 @@ h264-reader = "0.7.0"
 hex = "0.4.3"
 http-auth = "0.1.2"
 log = "0.4.8"
+memchr = "2.7.4"
 once_cell = "1.7.2"
 pin-project = "1.0.7"
 pretty-hex = "0.4.0"

Cargo.toml

@@ -77,7 +77,7 @@ fn make_test_data(max_payload_size: u16) -> Bytes {
         3575, 3144, 3431, 3317, 3154, 3387, 3630, 3232, 3574, 3254, 4198, 4235, 4898, 4890, 4854,
         4854, 4863, 4652, 4227, 4101, 3867, 3870, 3716, 3074, 3253, 3267, 3192, 3995, 3904, 3781,
     ];
-    let mut dummy_frame = vec![0; 1048576];
+    let mut dummy_frame = vec![1; 1048576];
     dummy_frame[4] = h264_reader::nal::UnitType::SliceLayerWithoutPartitioningIdr.id();
     let mut p =
         retina::codec::h264::Packetizer::new(max_payload_size, 0, 24104, 96, 0x4cacc3d1).unwrap();

benches/client.rs

@@ -0,0 +1 @@
+allow-print-in-tests = true

clippy.toml

@@ -12,6 +12,7 @@ cargo-fuzz = true
 [dependencies]
 bytes = "1"
 libfuzzer-sys = "0.4"
+memchr = "2.7.4"
 
 [dependencies.retina]
 path = ".."

fuzz/Cargo.lock

@@ -12,7 +12,7 @@ use libfuzzer_sys::fuzz_target;
 use std::num::NonZeroU32;
 
 fuzz_target!(|data: &[u8]| {
-    if data.len() < 2 {
+    if data.len() < 3 {
         return;
     }
     let conn_ctx = retina::ConnectionContext::dummy();
@@ -31,6 +31,15 @@ fuzz_target!(|data: &[u8]| {
     )
     .unwrap();
     let timestamp = retina::Timestamp::new(0, NonZeroU32::new(90_000).unwrap(), 0).unwrap();
+
+    // data[2] is the NAL header.
+    // data[3..] should not contain Annex B separators; the depacketizer will split them, and the
+    // result won't be the same as expected below.
+    let finder = memchr::memmem::Finder::new(&[0, 0, 1]);
+    if finder.find(&data[3..]).is_some() {
+        return;
+    }
+
     if p.push(timestamp, Bytes::copy_from_slice(&data[2..]))
         .is_err()
     {