[libdvdcss-devel] [PATCH] Read 50 sectors in advance during CSS key computation

[Diego Biurrun]

From: David Dielsky <***@gmail.com>

This reduces the number of read accesses.

Signed-off-by: Diego Biurrun <***@biurrun.de>
---

This is still a horrible hack. I fail to see the purpose of reading
data from the DVD into a dummy buffer, only to then reset the offset
pointer and read the data that actually gets processed from the DVD
again ...

src/css.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

diff --git a/src/css.c b/src/css.c
index b70759a..ee94548 100644
--- a/src/css.c
+++ b/src/css.c
@@ -1493,6 +1493,15 @@ static int CrackTitleKey( dvdcss_t dvdcss, int i_pos, int i_len,
int b_read_error = 0;
int i_ret;

+ /* Read 50 sectors in advance into a dummy buffer, in order to keep the
+ * data in the OS buffers and reduce the number of read accesses. */
+ const int nb_sectors = 50;
+ void *null_buffer = malloc( nb_sectors * DVDCSS_BLOCK_SIZE );
+ if( !null_buffer )
+ {
+ return -1;
+ }
+
print_debug( dvdcss, "cracking title key at block %i", i_pos );

i_tries = 0;
@@ -1507,6 +1516,13 @@ static int CrackTitleKey( dvdcss_t dvdcss, int i_pos, int i_len,
print_error( dvdcss, "seek failed" );
}

+ // every 50 sectors, read 50 sectors
+ if ( i_reads % nb_sectors == 0 )
+ {
+ dvdcss_read(dvdcss, null_buffer, nb_sectors, DVDCSS_NOFLAGS);
+ dvdcss->pf_seek( dvdcss, i_pos );
+ }
+
i_ret = dvdcss_read( dvdcss, p_buf, 1, DVDCSS_NOFLAGS );

/* Either we are at the end of the physical device or the auth
@@ -1585,6 +1601,8 @@ static int CrackTitleKey( dvdcss_t dvdcss, int i_pos, int i_len,
print_debug( dvdcss, "end of title reached" );
}

+ free( null_buffer );
+
/* Print some statistics. */
print_debug( dvdcss, "successful attempts %d/%d, scrambled blocks %d/%d",
i_success, i_tries, i_encrypted, i_reads );

[Jean-Baptiste Kempf]

Post by Diego Biurrun
This reduces the number of read accesses.
This is still a horrible hack. I fail to see the purpose of reading
data from the DVD into a dummy buffer, only to then reset the offset
pointer and read the data that actually gets processed from the DVD
again ...

It works when we read over HTTP. We're doing more testing about that,
before pushing it.

With my kindest regards,

[Diego Biurrun]

Post by Jean-Baptiste Kempf

Post by Diego Biurrun
This reduces the number of read accesses.
This is still a horrible hack. I fail to see the purpose of reading
data from the DVD into a dummy buffer, only to then reset the offset
pointer and read the data that actually gets processed from the DVD
again ...

It works when we read over HTTP. We're doing more testing about that,
before pushing it.

I'm toying with the idea of rewriting it to just use the data from the
buffer instead of reading into and then ignoring the buffer contents.
But I wonder if you haven't had the (seemingly obvious) idea yourselves
before and run into some problems that I am naively overlooking ...

Diego

[Jean-Baptiste Kempf]

Post by Diego Biurrun

Post by Jean-Baptiste Kempf

Post by Diego Biurrun
This reduces the number of read accesses.
This is still a horrible hack. I fail to see the purpose of reading
data from the DVD into a dummy buffer, only to then reset the offset
pointer and read the data that actually gets processed from the DVD
again ...

It works when we read over HTTP. We're doing more testing about that,
before pushing it.

I'm toying with the idea of rewriting it to just use the data from the
buffer instead of reading into and then ignoring the buffer contents.
But I wonder if you haven't had the (seemingly obvious) idea yourselves
before and run into some problems that I am naively overlooking ...

We're looking on how to do that in the client app, tbh.

But, no, we did not do this (obvious) idea.

With my kindest regards,