Re: [VCDImager Bugs/Devel] Burning from .cif

[Andrew Stevens]

> yes, indeed! :-)
> 
> most important thing is, to detect if a given 2324 byte mpeg2 block is of
> type video, audio or else; then it would be usefull, to detect about the
> videostream, if it is NTSC or PAL, and furthermore about the audio stream
> if it is one or two mpeg1/2 streams, or if it is one mpeg2 multichannel...
Type of content in a sector is pretty easy (stream ids in the packet
headers). However...
> as it concerns search.dat/scandata.dat, we need some means to detect if a
> mpeg block represents an I-picture; and to which time index a mpeg2 block
> in a stream corresponds.. (while reading the complete stream if necessary)

The rest would be a royal pain in the A*** as the start/end of
audio/video access units (frame data chunks) is *not* aligned with the
start of packets.  You'd have no alternative but to parse the whole
video stream.   It'd be pretty easy to generate the required information
during multiplexing though.   I could build this into "mplex" quite
easily.


> it was great, if there was a quick way, to detect the length of a
> (fseek()able) mpeg2 stream without having to read it from beginning to
> end...

Why would the length of the stream differ from its file-length?  Or do
you mean find out the number of access units or sectors?

Andrew