How to extract h264 from rtp stream from IP camera or what are my mistakes?

Question

Qt

Greetings.
There is a camera, I establish a connection via RTSP, open a UDP port, the camera sends packets.
There were almost no problems with this,
there were problems how to extract h264 from the UDP stream and simply write it to a file.
The algorithm is as follows:
1. From RTSP I get the SPS and PPS parameters from the DSP for h264, which came in the DSP response to DESCRIBE,
2. I write to the file: 000001 SPS 000001 PPS
3. I start reading RTP packets from the camera
4. I receive the N packet entirely
5.1 I take the frame header buffer from it (the first 12 bytes, with a check that there are no checksums and indents, otherwise I would have to increase it)
5.2. I take the frame data buffer from it (indented from the beginning in proportion to the title and to the end)
5.3 From the headers I find out the Sequence to be sure that the packets are in order
6. I take the first byte from the data buffer - NAL unit
7. I look at its type: (NAL & 0x1f)
7.1.1 If the type is 28, then the frame does not fit into one packet
7.1.2 I take the second byte from the data buffer - fuHeader fragment header
7.1.3. I figure out which fragment it is:
the beginning ( f = fuHeader & 0x80 f!=0 )
the middle ( m = fuHeader & 0xE0 m==0 )
or the end ( e = fuHeader & 0x40 e!=0)
7.1.4. If the fragment starts, then I write to the final buffer
000001 - I
restore the separator NAL (NAL & 0xE0) ^ (fuHeader & & 0x1f) and write to the file
write the frame data buffer with a shift from the beginning by 2 bytes (without NAL and fuHeader)
7.1.5 If the fragment is in the middle, then write to the final buffer
write the frame data buffer with a shift from the beginning by 2 bytes (without NAL and fuHeader
) fragment of the end, then I write to the final buffer
I write the frame data buffer with a shift from the beginning by 2 bytes (without NAL and fuHeader) I write
the final buffer to the file and clear the final buffer artifacts, if you move the camera, you can make out something, but again, solid artifacts and jumps. I looked at the log - packets are received in order (Sequence readings)
- there are practically no losses (Sequence difference from the previous package) (one per 20-30)
- NAL type is always 28 (occasionally skips 6, but I ignore it)
If I record through ffmpeg, then everything is perfect.
I set ffmpeg loglevel trace - my RTSP connection matches in parameters.
What am I doing wrong? Is the algorithm correct?
PS The article was read: https://habrahabr.ru/post/233237/ I checked with it - everything seems to be correct ... I
looked at the source codes of the example - in the example it is done in the same way (part of the half-way and processing),
except perhaps somewhere else - then the processing is worth it, but I understand Java very poorly.

Answer 1

In general, everything was correct in the algorithm.
I did not fully read the udp packet.
It remains to figure out whether its length is stored somewhere in order to check ... because. there are no checksums.