[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