[Live-devel] H264VideoFramer truncating frames

[Robert Smith]

Thanks,

I'm not sure what sort of constraints I can put on the number of slices 
so I probably can't get away with short circuiting the parsing as nicely 
as you do, but from memory our code for finding the start codes steps 
byte by byte so your example here would definitely be a significant 
improvement.

I would need to search for three byte start codes though, I haven't 
analysed the output of the TI encoder but I have had other encoders 
outputting three start byte start codes.

On 03/23/2015 08:06 PM, Gilles Chanteperdrix wrote:
> 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.
>