bug-vcdimager
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Herbert Valerio Riedel
Subject: Re: [VCDImager Bugs/Devel] Burning from .cif
Date: Tue, 14 Nov 2000 13:30:20 +0100 (CET)

hey!

On Tue, 14 Nov 2000, Andrew Stevens wrote:
> > 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...

:-) then just put it in vcd_mpeg.[ch]

(btw, mpeg2 still has that 2324byte blocksize property for VCDs?)

some function/way for detecting what version the mpeg stream is, would
be usefull too...

> > 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.
mmmh... I could imagine, to have that access point files empty, if
the information is not available and fill it, if the user supplies some
index file together with the mpeg stream, or maybe doint some other
smart thing... but I'll have to think about that first :)

I'll implement an empty (that is, just the header) of search.dat in the
mean time, and see if DVD players can cope with it... and then at a later
point of time/development make it conform to the specs... :)

> > 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?
well, I mean to find out the playing time, to be more exact :)

-- 
Herbert Valerio Riedel      /     Finger address@hidden for GnuPG Public Key
GnuPG Key Fingerprint: AC2A CD57 A5C8 A1CB 0A18  DA95 CB0B DB23 60B6 16F5




reply via email to

[Prev in Thread] Current Thread [Next in Thread]