[FFmpeg-devel] pts/dts generation and index for mpegts (vob)
Erik Van Grunderbeeck
Mon Apr 27 15:01:52 CEST 2009
> mpeg-ps not mpeg-ts
> Vobs aren't really meant to be read without parsing and understanding
> the NAV
> (pci/dsi) packtes within. It's quite common that the timestamps are
> discontinuous in the vob files (and there could be multiple angles
> It's however quite simple to make the vobs timestamps continuous if you
> read the nav packets. You just adjust timestamps based on the diff
> between two
> consecutive packet's start/end times.
> However it does mean that in order to allow seeks in the files, one
> would have
> to parse all NAV packets prior to the time you want too seek too. They
> contain a pointer to the next nav packets within, so one could do that
> finding the first one and jumping forward step by step. Still they are
> many and it would probably be quit uggly.
Yes, but the seek code skips them right now just looking for specific
packets id's based on either the stream selected, or the generic index
(which is usually the first video stream). I tried seeking on the first
audio stream btw; and lost audio there. Not sure why yet.
Reading the nav packets would be faster though as it would allow skipping in
the file since the stream offsets would be known (and in a "real" stream the
parser could instruct the sender to really seek forward and restart sending
from a specific offset, instead of sending all the packets over the wire).
I think Michael's suggestion was build the index from start before the
stream's are used (correct me if wrong Michael).
One thing I haven't seen or tested the behavior on is a DVD/vob with
multiple angles (since I don't have one here). Not sure if that works in
ffmpeg/ffplay, or the whole stream just gets pushed seq.
I am starting to think that the best way to solve this is send the input
file information on the chapter (or cell) layout. That would allow the
de-muxer to skip, offset pts and possibly also take into account chapter
info. Not sure if an extension like this would be excepted (I would be
willing to code it). A parser could extract them (ege from the ifo file, or
whatever would have them for any other formats), and feed them back to the
demuxer. Then again, I don't know what other container formats have this
kind of information available.
More information about the ffmpeg-devel