From: Michael R. <mr...@us...> - 2002-10-18 19:19:10
|
Hi James, > There have been reports for some time about problems with the read > cache code in libdvdnav. > From the point of view of libdvdnav, it was never actually supposed > to have a "get_next_block()" api call. > The application using libdvdnav was supposed to do all the reading of > sectors, and thus do their own caching. > I propose that we therefore move the get_next_block() code from > libdvdnav into "xine-lib/src/input/input_dvd.c" I don't like this approach because the dvdnav_get_next_block() function is quite a big piece of code and contains logic I think belongs to libdvdnav and not to the player app. If you just don't like the point of libdvdnav doing all the reading itself, I can agree with you: If the reading was the duty of the player, all caching would be a lot easier. So let me propose another way: We make the whole libdvdnav caching API public (This basically means the functions in src/read_cache.h) and provide a way of replacing these functions with a new cache. This way, lightweight applications can still use the built in read cache of libdvdnav and more sophisticated apps with own buffer management can provide own caching functions. The way of getting the data from libdvdnav will stay the same (IMHO quite clean) way it is now. Michael -- printk("MASQUERADE: No route: Rusty's brain broke!\n"); 2.4.3 linux/net/ipv4/netfilter/ipt_MASQUERADE.c |