[MPlayer-users] h.264 packetization and decoding

[Ratin]

Hi, I am dumping an ip camera bitstream (h.264) to a file
https://www.dropbox.com/s/mvk7ouw8int801j/packetfile.h264?dl=0
and decoding via mpv which uses libavcodec to decode. Strangely when I
decode the NALU's using libavcodec, I get a green overlay on=ver 95% of the
video, lot of artifacts, and messages like "[h264 @ 0x7fffe49ded50] illegal
short term buffer state detected". I send complete (non-FU-A) SPS, PPS, SEI
frames in their individual chunks and I combine all Fragmented IDR and P
frames (FU-A) into one chunk after re-constructing them per h.264 spec.

When I play the same bitstream via mpv from the file above, it works.
Surprisingly mpv aggregates a whole bunch of SPS, PPS, IDR NALUs in one
superchunk and sends to libavcodec. My original lengths are in
https://www.dropbox.com/s/uw7k0v8lj7tzpfc/input_packet_lengths.txt?dl=0
but mpv's aggregated packet lengths are in
https://www.dropbox.com/s/i223ja55ynbqjyh/mpv_decode_packet_length.txt?dl=0I


I was wondering why mpv does this (when the FU-A packets has already been
reconstructed in the dumped bitstream file I attached). If I use mpv to
decode the camera stream directly via mpv (rtsp), it does a similar but
slightly different behaviour, it puts all SEI and fragmented P frames in
one chunk and sends to the decoder. The SEI messgaes in this case are just
un-registered user message, so I think SEIs can be safely eliminated.

My question again is why it dumps  first 879322 in one chunk in the
beginning, what logic does it use to determine the boundary? How does
libavcoded handle a huge packet of this size 879322 bytes while I am
getting some kind of buffer overflow (green overlay is an indication of
that)?