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

[Richard]

On 13/02/13 00:30, Richard wrote:
> 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?

No takers?

Richard.