[libbluray-devel] Issue With HDVM Suspend / Resume Handling

[tourette s]

On Mon, Mar 28, 2011 at 11:01 PM, tourettes <tourettesmp at gmail.com> wrote:
> Hi,
>
> I think I have found an issue with the way how HDVM suspend and resume
> are handled. We will end up in lost events on the library user side at least
> in
> the following use case:
>
> 1) BD is started in navigation mode
> 2) Main movie is selected in the main menu
> 3) User goes back into the main menu (with bd_menu_call())
> 4) User starts again the main movie from main menu
>
> Here's what happens in the bluray.c & register.c
>
> * Menu is entered for the 2nd time (with bd_menu_call() from the main movie)
>  - registers gets saved
>  - bd->title_idx will point to the menu related index
>
> * Start main movie 2nd time -> restore state -> register restoring sets
> correct playlist ID
>  - bd->title_idx will point to the menu related title
>  - an event about playlist change is generated (at this point application
> queries the
>    bd->title_idx, which results wrong title index)
>
> * run_hdvm() triggers bd_select_playlist()
>  - bd->title_idx will get correct title index (main movie)
>  - an event about the playlist change won't get triggered since registers
> are already up to date
>
> How to fix that?
>
>  - Restore bd->title_idx (and other content as well?) when registers are
> restored
>  - Remove  "if (p->psr[reg] == val)" check in bd_psr_setting_write() and
> leave it up to libbrary
>    user to filter out the possible duplicate events
>  - Poll on client side for possible bd->title_idx changes
>
> None of the fixes seem good ones (at least the polling one is really bad).


In addition to that there is quite similar issue with the
BD_EVENT_PLAYITEM events.
They are missing on event bigger scale. On menu / navigation based
playback mode
when a title or playlist is changing the BD_EVENT_PLAYITEM is missing since most
of the playlist / title changes are changing the clip to the 1st clip
in the playlist (which is
quite logical) but the clip identifier / index is generated on the fly
and stays as zero.

Use case:

1) playback is started - 1st playlist starts (contains only one clip)
-> BD_EVENT_PLAYITEM
is generated with clip index 0

2) next playlist is started (could be the menu- 1st clip is started ->
BD_EVENT_PLAYITEM
is not generated since registers already contain clip zero

3) user selects something from BD menu - new playlist is started - 1st
clip is started
 -> BD_EVENT_PLAYITEM is not generated since registers already contain clip zero

Effectively the player cannot see the actual m2ts file changes that
happen underneat, this
would be quite important for to be able to track the clip / timestamp
boundaries. Currently
it is just possible to remove the register event filtering for
duplicate events but I don't think
it is the best solution. Also the player side workarounds aren't that
good to solve the issue
(you could use other events to query if the clip has changed). It
would be logical if every single
m2ts clip change would trigger the BD_EVENT_PLAYITEM that is visible
to the application.