revid: Unnecessary warning(s) at startup

[Alan Noble]

In MTS mode, revid often (always?) issues at least one of the following warnings:

{"level":"warn","time":"2019-11-07T07:12:48.984+1030","caller":"revid/senders.go:252","message":"revid: mtsSender: ringBuffer write error","error":"ring: write too long for buffer element"}

If this is just due to revid starting and not actually cause for concern, then it should be suppressed. Better yet, the root cause should be identified and remedied.

[Alan Noble]

@Saxon Milton do you understand the cause of this message at startup?

[Saxon Milton]

I haven’t seen this problem before - it might be scene specific. I’m guessing the i-frame is extra big at startup for that particular scene. I think the ring buffer should technically allow for this. I don’t like the thought of revid ignoring extra big H264 data that only happens sometimes, we should instead look at the vring idea imo to fix this.

[Alan Noble]

I raised this because it happens very frequently at startup (although not always) and I would like to understand the cause. The ring buffer is clearly not allowing for it

[Saxon Milton]

I don’t mean to say our current ring buffer implementation will handle it (because it definitely won’t), but it should, and i think that calls for the vring. It’s unrealistic and also poorly optimised to have fixed size rb elements when dealing with H264 VBR, which will produce a seriously wide range of access unit sizes.

I will have a look if there’s something I’m doing in the code, but I’m fairly convinced it’s because of the weird completely white to normal contrast effect that happens when the camera first starts (there would be alot of change in this picture transition, hence the large amounts of data).

[Saxon Milton]

Also if it is because of this weird colour transition, then it’s probably wise to expect that any other large amounts of movement (could be something passing really close by the camera) would also result in such large amounts of data, in which case we should be able to handle it.

[Alan Noble]

Ah, yes, the vring would handle it. In the meantime though, it means we’re most likely dropping i-frames, which of course means the first part of the clip is corrupt. While it is not so much an issue for continuous recording, it could be an issue in burst mode, esp. if the clip is triggered by motion.

[Saxon Milton]

No longer an issue now that we use v-ring.