November 2011 - DVDnav-discuss - lists.mplayerhq.hu

no VTS_TMAPT ??
by Roger Pack 24 Nov '11

24 Nov '11

As a side note, in VLC starting basically any "Disney DVD's" causes this message to be output, about 5 times: "Please send bug report - no VTS_TMAPT ??" Full output: https://gist.github.com/1390408 Reporting as requested :) -Roger-

1 1

[PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (Overview: Source to follow)
by gnosygnu 24 Nov '11

24 Nov '11

Hi all. I've written a patch for jumping to a time in searching.c. I emailed something similar to this group a year ago, but there didn't seem to be much interest then. I am emailing again because there is some revived interest in the VLC community. (See http://forum.videolan.org/viewtopic.php?f=32&t=76308&start=20#p315221) Currently, dvdnav_time_search is marked "FIXME: right now, this function does not use the time tables but interpolates only the cell times". This method is usually inaccurate: it interpolates using sectors, but one sector does not equal one fixed unit of time. For example, if there is a 10:00 cell and the cell is 1000 sectors long, it assumes that 5:00 is at sector 500. Jumping to sector 500 may actually jump instead to 5:12. My patch jumps to a time using the time map and the vobu address map. I placed it in a new function called "dvdnav_jump_to_sector" because I wanted to keep backward compatibility with the existing "dvdnav_time_search" -- in case anyone wanted to keep using this method. I provide more details on my approach below. I will include the patch itself in the next email. Please note that most of my work is based on reverse-engineering the IFO files. I am not a DVD application developer, so my approach may be flawed or may not follow DVD specification. Also, please note that Java/C# is my primary language. I learned C for this task, and have not used it for anything else since then. My apologies in advance if I do something terribly stupid. Finally, please note that my patch does not change or delete any existing code. However, it does add a lot of code: 650+ lines. I realize that such length makes it harder and less desirable to review. I do think the approach needs to have this complexity, especially to handle some outlier DVDs I've encountered. I appreciate any feedback or review. At the very least, I hope others will find this useful. Thanks. ------- Details ------- My patch introduces a new function called "dvdnav_jump_to_sector". It finds a sector for a given time and jumps to it. In libdvdnav/src/dvdnav/dvdnav.h, it adds 1 line. (see dvdnav.h.patch) In libdvdnav/src/searching.c, it adds 650+ lines. (see searching.c.patch.zip) No other lines are modified or deleted. >From a broad perspective, it works like this: (1) Find the two time map entries around a given time (2) Get the vobus of these two time map entries (3) Get the sector of the jump_time through interpolation of the vobus For clarity's sake, I will repeat the above with fabricated data (1) Find the two time map entries around a given time Given time 56... Time map index 10 is identified as 55 seconds 56 seconds must be between entries 10 and 11 (2) Get the vobus of these two time map entries Time entry 10 is at sector 193 which is vobu 405 Time entry 11 is at sector 303 which is vobu 455 (3) Get the sector of the jump_time through interpolation of the vobus 56 is 20% of the way between 55 and 60 415 is 20% of the way between 405 and 455 320 is the corresponding sector of vobu 415 Note that step (1) actually requires more sub-steps (1a) Find the cell for a given time (1b) Find the tmap entries around the cell's start sector (1c) Find the vobus for these tmap entries and cell start (1d) Interpolate the time of earlier tmap entry (1e) Find the tmap entries around jump_time (2) Get the vobus of these two time map entries (3) Get the sector of the jump_time through interpolation of the vobus Again, here is the above with some fabricated data. I try to represent the tables visually below. It was written with a fixed-width font. My apologies if it does not show up formatted in the email. (1a) Find the cell for a given time Given time 56... ---- -------- -------- ---------- ---------- cell bgn_time end_time bgn_sector end_sector ---- -------- -------- ---------- ---------- 1 0 28 0 99 ---> 2 29 600 100 1000 3 601 900 1001 1400 ... **** Cell 2 encloses 56. (1b) Find the tmap entries around the cell's start sector ---- ------ tmap sector ---- ------ ... 3 71 ---> 4 88 ---> 5 108 6 121 ... **** tmap entries 4 and 5 enclose cell start sector of 100. (1c) Find the vobus for these tmap entries and cell start ---- ------ vobu sector ---- ------ ... ---> 200 88 ... ---> 208 100 209 102 ---> 210 108 ... **** 200, 208 and 210 are the relevant vobus (1d) Interpolate the time of earlier tmap entry 208 is 80% of the way between 200 and 210 4 secs is 80% of 5 secs 25 is the time-point when subtracting 4 from 29 (cell_bgn) vobu 200 is at 25 seconds **** 25 secs is the calculated time of tmap idx 4 (1e) Find the tmap entries around jump_time ---- ---- ------ tmap time sector ---- ---- ------ 4 25 5 30 6 35 7 40 8 45 9 50 ---> 10 55 193 ---> 11 60 303 ... **** 56 must be between tmap entries 10 and 11 (2) Get the vobus of these two time map entries ---- ------ vobu sector ---- ------ ... ---> 405 193 ... 415 320 ... ---> 455 503 ... **** 405 and 445 are the relevant vobus (3) Get the sector of the jump_time through interpolation of the vobus 56 is 20% of the way between 55 and 60 415 is 20% of the way between 405 and 455 320 is the corresponding sector of vobu 415 **** 320 is the closest vobu sector for 56 secs ----------- Other notes ----------- (1b) has a hack to handle cells that start at discontinuity entries - Basically if a cell starts in a discontinuity entry, then the sector/vobu data may not be good for interpolation For example, using the same data above ---- ---- ------ ---- tmap time sector vobu ---- ---- ------ ---- 4 25 88 200 <- flagged with discontinuity bit 5 30 108 210 6 35 140 218 Since there is a discontinuity occurring at tmap entry 4, the sectors between 88 and 108 may not represent 5 seconds of data (It usually does, but not always) To handle this, the proc looks forward to the next tmap entry and uses the vobu difference there to infer the vobu of the lo tmap With data, this means Look at tmap entry 6. It has a vobu of 218 There are 8 vobus between 218 and 210 Assume that tmap entry 10 starts at 202 (not 200) This works in practice on a handful of DVDs I've encountered, but the logic will probably not hold for all. There is a small percentage of DVDs that have issues - Time map was missing (no entries) For these DVDs, I wrote dvdnav_find_vobu_by_cell_boundaries. This function uses the same logic as tmap, but uses the cell_boundaries only. It is not as accurate as a tmap, but it is close. It is more accurate than raw sector interpolation. Roughly speaking, it is accurate 50% of the time, and the other other 50% of the time, it is off by 1 to 3 seconds. - Time map has non-consecutive entries. For example, a DVD with a time interval of 5 seconds had entries at tmap index 99 that was not 500 seconds in playback, but 521 seconds (or some other non-intuitive number). For these DVDs, steps (1a) - (1d) were written. If we could assume that tmap index 99 was always at time 500 seconds, then we could skip directly to (1e). ---------------- Function summary ---------------- Entry function: - dvdnav_jump_to_sector_by_time Find the nearest vobu and jump to it Core function: - dvdnav_find_vobu_by_tmap Find the nearest vobu by using the tmap Fallback function: - dvdnav_find_vobu_by_cell_boundaries Find the nearest vobu by using the cell boundaries Utility functions: - dvdnav_tmap_get_entries_for_sector Find the tmap entries on either side of a given sector - dvdnav_tmap_calc_time_for_tmap_entry Given two tmap entries and a known time, calc the time for the lo tmap entry - dvdnav_admap_interpolate_vobu Given two sectors and a fraction, calc the corresponding vobu - dvdnav_cell_find Given a sector/time/idx find the cell that encloses it - dvdnav_tmap_search Do binary search for the earlier tmap entry near find_sector - dvdnav_admap_search Do a binary search for earlier admap index near find_sector - dvdnav_tmap_get_entry Get a sector from a tmap Misc functions (separated for readability): - dvdnav_tmap_get Get a tmap, tmap_len and tmap_interval - dvdnav_admap_get Get an admap and admap_len Log/Debug functions - is_null Check if pointer is null, and log it if it is

2 4

failure with sudo make install
by Roger Pack 23 Nov '11

23 Nov '11

Ran into this oddity today, trying to install libdvdnav from src. $ ./configure2 Done, type 'make install' to build and install $ sudo make install ... install -s -m 755 obj/libdvdnav.so \ /usr/local/lib/libdvdnav.so.4.2.0 install -s -m 755 obj/libdvdnavmini.so \ /usr/local/lib/libdvdnavmini.so.4.2.0 install: cannot stat `obj/libdvdnavmini.so': No such file or directory make: *** [install-shared] Error 1 however, it works fine if I do $ ./configure2 $ make then $ sudo install Just thought I'd mention it, since it seemed a bit odd. Thanks. -roger

1 0

[PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (REV 4: fix hack for reloading entire IFO)
by gnosygnu 21 Nov '11

21 Nov '11

Revision 4 fixes a HACK wherein the entire .IFO was reloaded, just to load the time map. This patch also reduces the error messages that were generated in the log output. Per recent request, I'm sending this patch uncompressed.

3 2

Fwd: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing?
by Roger Pack 21 Nov '11

21 Nov '11

Anybody have any recollection as to why, once upon a time, mplayer had to disable libdvdnav caching, and adds the message "you should use -nocache" to this day? Just wondering if maybe it's a bug that's been fixed since. Cheers! -roger- ---------- Forwarded message ---------- From: Nico Sabbi <nicola.sabbi(a)poste.it> Date: Thu, Nov 17, 2011 at 8:36 AM Subject: Re: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing? To: mplayer-dev-eng(a)mplayerhq.hu Alexander Roalter ha scritto: > > As far as I can remember, Nico once said the -nocache is no more explicitly needed with dvdnav, but I could be wrong. > Also, the text is displayed irregardless of the option taken, so it shows with or without -nocache (which is a bit annoying) I simply commented that line out... > Long time ago Reimar patched mplayer to permit the caching of dvdnav streams, but mplayer's caching is a totally different thing from dvdnav's caching. IIRC setting the readahead flag in dvdnav caused all sorts of problems at the time. Maybe the two are no more incompatible, but too many years (and tears) have passed, I don't know. _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng(a)mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

1 0

[PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (REV 1: handle delay when reading directly off disc)
by gnosygnu 19 Nov '11

19 Nov '11

Revision to handle delay when reading directly off disc. See related email for more info

3 15

[PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (REV 3: fix: jumping in cell 1 would use admap, not tmap)
by gnosygnu 18 Nov '11

18 Nov '11

Two changes: 1) fix for jumping in first cell Roger found an embarrassing bug wherein jumping in the first cell would only use the admap, not the tmap. It raised the "cell not found" errors in his earlier trace. Specifically, I changed the following line in dvdnav_cell_find old: else if (find_mode == CELL_FIND_INDEX) { if (find_val == CELL_FIND_INDEX) { new: else if (find_mode == CELL_FIND_INDEX) { if (find_val == cur_cell_idx) { 2) CELL_FIND_ prefixes Erik suggested adding CELL_FIND_ prefixes to the cell_find_mode_t enum I've attached revision 3 above. Thanks

2 1

Re: [DVDnav-discuss] [PATCH] "dvdnav_jump_to_sector" as an alternative to "dvdnav_time_search" (REV 1: handle delay when reading directly off disc)
by Roger Pack 17 Nov '11

17 Nov '11

> Thanks. The error message is the same as before. It should be fixed > with rev3. I downloaded your Sintel and ran through it now and a jump > to 0:30; 1:00 and 1:30 (all in chapter 1/cell 1). Works now Sweet. With v3It does appear that the "cell not found" message is gone now. >> jumping to 5490000cell not found; find=1 cells_len=7could not retrieve >> cell 1libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2 >> libdvdnav: chapter NOT FOUND! >> I would note that having these extra messages scares people a little :) > > Okay. Don't want to do that. > > Can you recommend less ominous wording? Note that in the above, my > patch only introduces "cell not found; find=1 cells_len=7could not > retrieve cell 1" It still says libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2 libdvdnav: chapter NOT FOUND! This is expected, is that right? (with the "old" search method it didn't output any error messages...but the new one is smarter, so perhaps this is normal, if scary because of the caps :) ) Thanks! -r

1 0

[PATCH] Fix a package error
by KO Myung-Hun 17 Nov '11

17 Nov '11

Hi/2. I attach 3 patches to fix a package error. ----- dvdnav-remove-mkinstalldirs.diff This removes mkinstalldirs from Makefile.am. mkinstalldirs is really required ? ----- dvdread-remove-mkinstalldirs.diff Ditto. ----- dvdread-remove-absent-sources.diff dvd_udf.h and bitreader.h are not in src. Due to this, 'make distdir' fails. -- KO Myung-Hun Using Mozilla SeaMonkey 2.0.14 Under OS/2 Warp 4 for Korean with FixPak #15 On AMD ThunderBird 1GHz with 512 MB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr

3 4

"priming" still necessary?
by Roger Pack 16 Nov '11

16 Nov '11

Hello. I noticed this snippet recently, in mplayer's stream_dvdnav.c ... dvdnav_open(&(priv->dvdnav),priv->filename) ... if(1) //from vlc: if not used dvdnav from cvs will fail { int len, event; char buf[2048]; dvdnav_get_next_block(priv->dvdnav,buf,&event,&len); dvdnav_sector_search(priv->dvdnav, 0, SEEK_SET); } ... Anybody know if this is still needed? I'm guessing it's not anymore? (seems to work fine without it, but wanted to double check if anybody had any insights there). Thanks. -roger-

1 0