[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)?

[Reimar Döffinger]

I kind of don't think discussing mpv and libavcodec belongs on this
list, so I think you'll have to look for help elsewhere beyond
a few hints.

Post by Ratin
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.

Not sure how you mean that, but if you put the SPS/PPS/SEI in packets
separately from the frames that won't work.

Post by Ratin
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)?

The packetization rules are in libavcodec/h264_parser.c.
And it has nothing to do with overflow, you're just confusing
the decoder (particularly the reference frame tracking) with the
input it gets, probably triggering error concealment (which
normally should result in grey, not green though, unless you
overwrite some buffers with 0s when you shouldn't).