[Live-devel] H264VideoFramer truncating frames

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Mon Mar 23 12:06:18 PDT 2015


On Mon, Mar 23, 2015 at 10:52:46AM +0100, Robert Smith wrote:
> Hi Gilles,
> 
> How were you extracting the NALU's from the frames provided by the encoder?
> Were you using the H264VideoFramer class?

I was using the discrete framer, every NAL was sent separately to
the framer. With my settings: 

- either the image was an IDR and it contained, SPS, PPS, then the
image as a single NAL, it was the case for the first image, and I
also triggered a new IDR for each client connection, in order to
help the decoding (avoids long black period waiting for an I frame);

- or the image was a single NAL.

So, I looked for the 0001 using what could pompously be called an
hardcoded boyer moore search, meaning that it was skipping 4 bytes
at the time most of the time (except if the 4th byte was a 0 or a
1). Something like this:

unsigned h264_next_nal(const unsigned char *data, unsigned size)
{
	unsigned nal_size;

	for (nal_size = 4; nal_size < size;) {
		const unsigned char *tmp = &data[nal_size];
		if (nal_size + 4 > size) {
			nal_size = size;
			break;
		}
		switch(tmp[3]) {
		case 1:
			if (tmp[0] == 0 && tmp[1] == 0 && tmp[2] == 0)
				return nal_size;
			/* Fallback wanted */
		default:
			nal_size += 4;
			break;
		case 0:
			nal_size++;
		}
	}

	return nal_size;
}



Then looked at the first NAL byte to see if it was an SPS or
PPS. When the NAL was not an SPS or a PPS, I knew the remainder of
the buffer was a complete NAL.

In principle, it could also work with slice encoding, except that
you would have to continue calling h264_next_nal until buffer
exhaustion.

-- 
					    Gilles.


More information about the live-devel mailing list