[MPlayer-dev-eng] Patch to fix seeking in H264 TS

Loren Merritt lorenm at u.washington.edu
Sun Feb 17 12:54:07 CET 2008


On Sat, 16 Feb 2008, Nico Sabbi wrote:
>> Il Saturday 16 February 2008 00:07:25 Ian Rickards ha scritto:
>>>
>>> Here's a log of the verbose output from the current mplayer code which hangs
>>> forever.  I put a debugging printf in the while loop waiting for NAL unit
>>> 05 - as you can see it gets 09 + 06 + 01 types, but never 05, interleaved
>>> with PARSE_PAT, FILL_PMT, PARSE_PMT.  I could upload a sample ts somewhere?
>
> the sample in question is seektest.ts.
> I fixed it stopping the search of the startcode at an IDR slice || SPS,
> but I'm not completely sure that my fix is correct: that H264 pdf
> I have is one of the most confusing thing I ever read

Afaict the correct detection of seek points is:
Look for the first slice of an IDR frame, or a recovery point SEI (NAL 
type 6, payload type 6). Then seek back and include any preceding 
SPS, PPS, and/or SEI.

Recovery point is usually indicated by 00 00 01 06 06. But not always, 
because there can be multiple SEI messages in a SEI NAL, and recovery 
point need not be the first one.

IDR || SPS is a pretty good heuristic for seek point, but not guaranteed. 
While I can't think of any reason to put an SPS in the middle of a GOP, 
and I don't know of an encoder that does so, it is allowed.

--Loren Merritt



More information about the MPlayer-dev-eng mailing list