Panicing after Timestamp changed error

[anti-social]

I got following error when streaming with one of my cameras:

Timestamp changed from 1574224004 (mod-2^32: 1574224004), npt 524.633 to 1574227704 (mod-2^32: 1574227704), npt 524.674 in the middle of a fragmented NAL
    
    conn: 10.248.0.91:37514(me)->10.248.0.101:554@2025-11-03T06:38:40.994083243Z
    stream: 10.248.0.91:61828-61829(me) -> 10.248.0.101:32769-32770
    ssrc: 0000a046
    seq: 4310
    pkt: 2025-11-03T06:47:26.128406364Z

thread 'tokio-runtime-worker' panicked at /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/retina-0.4.15/src/codec/h265.rs:471:42:
range end index 4294967295 out of range for slice of length 2

[scottlamb]

Ouch!

When starting a fragmentation unit, h265::Depacketizer::push puts in a placeholder next_piece_idx. (Really, I should change it to be explicit about this via Option<NonZeroU32> instead; 0 isn't a valid value anyway.) The panic is from erroneously trying to use this placeholder value.

When it returns Timestamp changed ... in the middle of a fragmented NAL error, it's resetting self.input_state to DepacketizerState::New. The invariants for Depacketizer are that self.pieces and self.nals are supposed to be empty in this state, but this Err path doesn't maintain them correctly.

The H.264 depacketizer probably has the exact same problem.

More generally, I hadn't put any thought into what happens if you try to continue reading from Depacketizer (or Demuxed) after an Err return. I think all of my code (including retina's unit tests, retina's fuzz tests, retina's examples, or Moonfire NVR) abandons the session. The documentation doesn't say either.

This is with your own calling code, I assume? Are you trying to recover the stream after an error? I suppose that's a pretty reasonable thing to try; ffmpeg for example probably just persists through anything.

[anti-social]

I cannot recover because of the panic. Possibly I could try to launch a new task but I'm not sure it is a good idea.

[anti-social]

Oh, I see the panic happens when I'm fetching the next frame. I'll try to reinitialize a session.

[anti-social]

I had a counter of consequent errors before returning an error. Removed it. Will try it tomorrow.

[scottlamb]

You called Demuxed::poll_next and got Some(Err(_)). So far, this is by design.

Then you called it again. What were you hoping would happen? Obviously not a panic, and that's a Retina bug I intend to fix. It could return None (never returning more data on this Demuxed, you have to reconnect). Or it could try to recover, maybe returning a few more errors along the way. I'm trying to decide which.

The reconnect behavior you can already get by just reconnecting at the first Err. But even so I never intend for it to be possible to cause a panic like this.

[anti-social]

What were you hoping would happen?

I thought maybe it is one time error. As I said before I had a counter and after some threshold is reached I restarted a session.

[anti-social]

I'm pretty new in video streaming. So I don't know if there are cases when an error is temporal and a session could be restored or any error leads to a session becomes unrestorable.

It could return None (never returning more data on this Demuxed, you have to reconnect). Or it could try to recover, maybe returning a few more errors along the way. I'm trying to decide which.

Yeah, returning None could mean the stream is over and we should reconnect.

[scottlamb]

Care to give the fix-122 branch a spin?

[anti-social]

Sorry for a delay but I already do not have access to those cameras.

I do not have an expertise in RTSP but I tried the patch with an another camera and it works fine