[DVDnav-discuss] Still timeout workaround in vm.c

[Richard]

Hi,

In vm_position_get there is a workaround for discs that indicate a still 
by "a cell playback time higher than the time the frames in this cell 
actually take to play (like 1 frame with 1 minute playback time)", and 
that these discs are considered to be broken.

I don't think they *are* broken.  It's unusual but I don't think there's 
any reason why a VOBU needs to be more than one sector (i.e. the NAV 
packet) long.

Take audio DVDs, for example (and here I don't mean "proper" audio DVDs, 
with data in the AUDIO_TS directory, I mean DVDs that are basically 
audio-only with data in the VIDEO_TS directory and playable on a normal 
DVD player).  These DVDs often show a single frame over several minutes 
worth of music.

The first VOBU of a cell on such a disc will typically contain a single 
video frame along with audio frames.  Subsequent VOBUs will only contain 
audio packets (ignoring the NAV packets).  As I understand it, the 
initial video frame should be shown either until the next video frame is 
found or until the end of the cell.  Through a combination of the 
'pci_gi_t.vobu_se_e_ptm', 'dsi_gi_t.vobu_1stref_ea' and 
'vobu_sri_t.next_video' fields in the NAV packets, it can be determined 
when the last frame will come, and when the next should be expected.

So, having determined that, if you remove the audio stream, you have the 
exact scenario that the workaround was implemented for, except that it 
doesn't appear to be a broken or invalid scenario to me.  Unusual, 
certainly, but not invalid.  It would also allow timeouts of greater 
than 254 seconds (although that could probably also be achieved via 
other means, but would still be a valid alternative).

In this scenario, it would be up to the player to ensure the correct 
timing is maintained by syncing itself to the start and end PTMs in each 
NAV packet rather than video or audio data.

The problem with the workaround (apart from the duration issue) is that 
a player following the above behaviour will likely get into trouble as 
dvdnav_get_next_cache_block will return DVDNAV_STILL_FRAME at the end of 
the cell, and cause it to show the frame for too long (at best twice as 
long, at worst, indefinitely).

Does that explanation make sense?  Comments?

Richard.