[vlc-devel] [PATCH] dvdnav: add Demux submodule

[Petri Hintukainen]

On ma, 2015-03-23 at 23:41 +0100, Jean-Baptiste Kempf wrote:
> On 23 Mar, Rémi Denis-Courmont wrote :
> > Le lundi 23 mars 2015, 19:48:35 Thomas Guillem a écrit :
> > > Ah yes, we can't play dvd without seek.
> > > dvdread has now an internal cache when probing IFO, therefore there is
> > > much less seeks than before. So, can we use CAN_SEEK instead ?
> > 
> > I don´t know how much it seeks. Presumably it does not seek much if at all 
> > during playback, but what about menus?
> 
> Seeks are mostly happening in decryption part, but that is cached now,
> in dvdread.

Amount of seeks can be reduced by caching all filesystem metadata (and
even small files). Clever implementation could also read sectors
sequentially, even if this requires reading too much and caching sectors
while parsing the data.

I did a simple test with libudfread. Test program (udfls) lists files in
UDF filesystem (so, it reads all metadata in alphabetic order). With one
random DVD it ended up reading following sectors:
  16-18, 256, 32-35, 262, 264-284

All metadata was laid so that it is at the beginning of the partition
and read sequentially. This is probably common practice, as seeking is
expensive.

There's one seek backwards after reading sector 256 (anchor volume
descriptor pointer). Volume descriptor sequence is stored before it in
sectors 32-35. Now, I don't know if it would be faster to read sectors
0-256 and cache those, or seek several times (-> 16 -> 256 -> 32 ->
262) ?
Also, in second step it could be faster to avoid seeks and just read +
cache all intermediate sectors at the beginning of partition ?

Caching 500 first blocks would require 1 MB. Not too much in a system
that can play DVDs. And this cache can be freed after the directory
structure has been parsed. Read would take less than a second with
slowest possible DVD drive (or network link that would be fast enough
for DVD).

Maybe the read/seek callbacks in the module could ignore seeks and use
stream_Peek() until a block from lba > 512 is requested ? That should
avoid seeks while parsing disc structure and directories.

> > But in any case, you need FASTSEEK because the probe function needs to seek 
> > forward and back to zero - unless you find a way to probe based on the first few 
> > hundreds of bytes like other demuxers.
>
> That means if forced, it is not necessary.
> And yes, I think it can be probed way better, in the way you described.

Probably not "based on the first few hundred of bytes". We need more
than 32 kb. Sectors 0-15 are reserved and typically used for booting. I
have DVD .iso images where first 32 kb are filled with zeros.

Maybe we could check if all "real" DVDs have first sectors filled with
zeros. I don't know if there are any other formats that start with 32kb
of 0's ... ?

Also, seeking back shouldn't be necessary if dvd is detected. dvdread
will seek before read (and, it will first read the same sectors that
were probed, not sector 0).

> With my kindest regards,
>