<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="im" style="font-size:12.8px">Hi, I am dumping an ip camera bitstream (h.264) to a file</span><div style="font-size:12.8px"><a href="https://www.dropbox.com/s/mvk7ouw8int801j/packetfile.h264?dl=0" target="_blank">https://www.dropbox.com/s/mvk7ouw8int801j/packetfile.h264?dl=0</a></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"> <br></div><div style="font-size:12.8px">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 </div><div style="font-size:12.8px"><a href="https://www.dropbox.com/s/uw7k0v8lj7tzpfc/input_packet_lengths.txt?dl=0" target="_blank">https://www.dropbox.com/s/uw7k0v8lj7tzpfc/input_packet_lengths.txt?dl=0</a> <br></div><span class="im" style="font-size:12.8px">but mpv's aggregated packet lengths are in </span><div style="font-size:12.8px"><a href="https://www.dropbox.com/s/i223ja55ynbqjyh/mpv_decode_packet_length.txt?dl=0I" target="_blank">https://www.dropbox.com/s/i223ja55ynbqjyh/mpv_decode_packet_length.txt?dl=0I</a> </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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)?</div></div></div></div>