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

Thomas Guillem thomas at gllm.fr
Tue Mar 24 11:34:47 CET 2015



On Tue, Mar 24, 2015, at 10:02, Petri Hintukainen wrote:
> 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

Yes, I was the same figures but I wasn't sure it was the case for every
iso.

> 
> 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.

Ah that seem a good idea, I didn't think about it.
But I did an other trick in dvdread: I put in cache the whole IFO file
when probing it, it avoids a lot of seek/read. And it caches only 128kB
maximum, but some IFO are probed more than one time from libdvd*, so
there is still a little waste or I/O (but much less than before).

> 
> > > 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).

OK.

I'll propose a patch that doesn't probe if the access can't fastseek. If
access can't fastseek, you'll have to force dvd (by using http/dvd://URL
for example) to use the dvdnav demux.

I think it's a good compromise waiting for the libudfread integration in
vlc / libdvd*.

> 
> > With my kindest regards,
> > 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



More information about the vlc-devel mailing list