[MPlayer-dev-eng] About mplayer dvd seek, I've checked DVDx source code

[Arpi]

Hi,

> >I guess the idea is: Find the nearest cell,and the cell time
> >length(e.g. 5 seconds),cell size(e.g. 10MB),cell seeking time(e.g. 2
> >seconds). Then the cell seeking location is 2/5*10=4MB.
> >
> >I mean DVDx firstly locate a cell by .ifo information and then assume
> >it is CBR in the cell to locate the seek location. But ffmpeg just
> >assume the total DVD is CBR and locate it.
> >---------------------------------

> 1) you can't adapt a solution that nearly works for dvd but not for 
> other mpeg streams

the main problem with dvd, is that mplayer isn't a dvd playing
application, i mena it wasn't designed to be. so its main structure
isn't about ifo parsing and so on, it's separated to a stream and a
demuxer layer. the stream layer has a driver for dvd, but the seeking
is done in teh demuxer layer, which knows nothing about the stream
format or the dvd details (it doesnt even know if it's an file or
a dvd device or a network streaming).

(more) hacks could be added to export such metadata from stream
layer to demuxer, and make code even more ugly, but afaik it isn't
planned...  but it's kept in mind for g2 design from the first day.

> 2) in mpeg timers can jump (so e.g. you pass from 03:20:00 to 01:00:00 
> without continuity),
> so after having (hopefully :) ) built a map of type 
> timestamp=>seek_position the time
> specified with -ss might be different from the real time ( = mpeg 
> timestamp) present in
> the bitstream

yes. but it could be solved (and should be, maybe i'll even do it),
by building a time->sector map in dvd stream driver.
the ifo contains the start and length time of each cell
(anyway, an avg. cell isn't 5 sec, but 5-10 minutes (usually a chapter)
long), so it can be calculated. the problem begins with angles,
and multiple-path (both theatre/derectorscut edition on same disk
sharing some of the video, or the same for multiple language texts
like the big scrolling in the beginning of starwars ep1), where
each cell may belong to different time positions depending on
the selected path (title) / angle.

but in mplayer, you cannot change angle/title while playing, so
such map could be built when startup playback, and angle+title
are already known.

it could fix osd time display on dvds (no jumping and reset
at chapter boundaries on some discs) and so using external
subtitles for dvd too.

but it wont help much on seeking, which is done based on the
bitrate field from mpeg-es headers (so _VERY_ inaccurate,
it doesnt even know about audio streams and their bitrates).


A'rpi / MPlayer, Astral & ESP-team

--
Girls are like internet domain names, the ones I like are already taken.