[Libav-user] h.264 packetization and decoding

Ratin ratin3 at gmail.com
Sun Feb 7 18:15:54 CET 2016

Hi, I am dumping an ip camera bitstream (h.264) to a file
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
but mpv's aggregated packet lengths are in

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20160207/ec7ce23b/attachment-0001.html>

More information about the Libav-user mailing list