We should not update the parser state when peeking a SPS

[dwlsalmeida]

We should not update the parser state when peeking a SPS

[Gnurou]

Ah indeed this doesn't look right. Is there anything that prevents us from processing all the NALUs sequentially instead of looking for a SPS first?

Or would it help if we made decode return the number of bytes processed in the input, so the caller knows they need to call it again in case it returned without processing all the stream (which would happen if we e.g. have a SPS in the middle like your example)?

[dwlsalmeida]

Ah indeed this doesn't look right. Is there anything that prevents us from processing all the NALUs sequentially instead of looking for a SPS first?

I don't think so, in fact this is what Chromium and GStreamer do. That is, they parse the NALUs in order, and if they see a SPS, they will renegotiate.

If, for whatever reason, someone sends <slice>, <sps>, <pps> this will return an error though.

I think it is more sane if we just let it error out though, as I do not think it is sane for any stream to contain slice data before its respective SPS and PPS are parsed anyways, in which case we can get rid of peek_sps altogether.

Or would it help if we made decode return the number of bytes processed in the input, so the caller knows they need to call it again in case it returned without processing all the stream (which would happen if we e.g. have a SPS in the middle like your example)?

Even if we remove peek_sps() altogether, we still need to implement the above somehow, see #35.

My original idea was to return the current offset in DecodingState::AwaitingFormat, but returning it from decode() does make more sense indeed.

[dwlsalmeida]

This is fixed by #37

We now process each NAL by itself and if a SPS is not available when one is needed we reject the stream.