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)?
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
