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.
_______________________________________________
DVDnav-discuss mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
