[mythtv] [mythtv-commits] Ticket #9410: Positioning problems with BBC HD and BBC ONE HD recordings

[Paul Gardiner]

On 01/01/2011 17:54, John P Poet wrote:
> We use ffmpeg's ff_find_start_code routine to fine the beginning of
> the next NAL UNIT.  Is it miss-identifying the start of the NAL UNIT?

In an attempt to help out, I started looking at the parser and the h264
spec. I've checked ff_find_start_code very carefully, and I believe it
to be correct. There are, however, some slight oddities in how it's
used in H264Parser::addBytes.

The method is a while loop, but it looks to me that the body can
only ever be run once: it is only in the case that the test
(sync_accumulator & 0xfffffff00) == 0x100 fails, that execution
doesn't run into a return statement, and if that test does fail
then ff_find_start_code will have walked the whole buffer looking
for a start code, so byteP will equal endP.

Of course that is harmless, but seeing the loop, gives the impression
that ff_find_start_code might be called multiple times, which in turn
implies that sync_accumulator should be kept up to date with any
movement of the pointer, and that isn't the case because the line
byteP += (get_bits_count(&gb) / 8) changes just byteP.

Even if I'm right that the loop body executes at most once, the
fact that addBytes is called multiple times from H264PreProcessPkt,
to consume a buffer
would mean that ff_find_start_code could get called with byteP
out of sync with sync_accumulator.

I very much doubt if any of this can cause any real parsing error,
but having looked into it, I thought it worth posting this just
in case it is of any help.

Cheers,
	Paul.