[Live-devel] MPEG2TransportStreamIndexer & h264 (cont)

[Nikos Antonopoulos]

Hi all, 

i've finally had the time to have a closer look at the indexer and some 
x264 specifics and i'm starting to feel lucky on getting the 1st cope with
the 2nd... However it'd be great if anyone could give me some more info:

Firstly, can u please verify i've got this straight and please excuse 
if i'm running long. i'd like to get this right :

For each TS packet the indexer retrieves some relevant timing info and stores an index record.
The indexer then copies the mpeg payload of the TS packet to a parse buffer,
and scans for bitstream codes (Video sequence start, GOPs and a default case
for all the rest - pictures, slices, the lot.). When an entire section has been found 
(000001XX - 000001YY) the indexer marks all corresponding index records with the appropriate
type (RECORD_VSH, RECORD_GOP, RECORD_PIC_NON_IFRAME, RECORD_PIC_IFRAME) 
and writes them (all index records available) to the index file before parsing again. 
I must admit i can't really see why the first indices of each section/frame are marked by 
( | 0x80 )... but anyhow! I also have a small gap of understanding as to why the indexer sometimes 
splits an index record in two...

Now, i believe i've understood how to parse the x264 stream. The code prefix is the same (00 00 01)
and i've found the stream (btw, i make my testfiles either w/ VLC or mencoder) to consist of:

1: Coded slice of a non-IDR picture
5: Coded slice of an IDR picture
7: Sequence parameter set
8: Picture parameter set

the stream is structured as: 7-8-5-1-1-...-1-7-8-5-1-1...

I understand that only the '5' elements (Coded slices of an IDR pic) hold indexing info. 
They are the equivalent of 'RECORD_PIC_IFRAME' type records for an mpeg1-2 file.

Ok, so would all this be adequate to make an index file? If so, i suppose that most
changes would go in function parseFrame(). But something i can't really see is what would
go in the type member of each index record. I suppose that a new enumeration of possible types
is needed but then would the user of the index file know what to do with the records?
Anything u think i'm missing here?

I'll try to stay on this and hopefully i will have a more complete picture (& hopefully some code to share) 
soon but any suggestions would be greatly appreciated...

sorry for the lengthy text...

many thanks
Nik


>>I've been trying to use trick play by creating an index file (using
>>MPEG2TransportStreamIndexer) for an MPEG-TS (h264/mp3) file.
>>I've has no luck with it - been getting an empty index file.
>>
>>I understand that the indexer is designed to work with mpeg1-2 files.
>>Question is whether I should spend some time into making this handle
>>h264 files as well. Would that be too difficult?


>It's on our "to do" list.  What makes it non-trivial is that the 
>index file generation code works by analyzing each of the video 
>frames in the Video Elementary Stream embedded within the Transport 
>Stream - in order to figure out which frames are 'key frames' (i.e., 
>I-frames), and where they are.  I.e., the indexing code would need to 
>know the structure of MPEG-4 video frames (just as it currently knows 
>about MPEG-2 video frames).