[libbluray-devel] first patch-set

[hpi]

>> Register:
>>
>>> Set some different initial register values. This prevents sending startup
>>> messages for initial states (that are not valid) on a register restore.
>
>>That might have some unwanted side-effects if HDMV application expects
>>certain initial values. Maybe this should be fixed somewhere else ;
>>what kind of problems do the initial values cause ?
> 2 fold:
>
> 1) My reasoning is that apps dont want the initial values of whatever the
> registers are initialized at.

Some kind of notification is still needed, as the previous value is
also invalid.

> Could be any value, and doesnt make sense to them?

HDMV and BD-J applications use the registers too. Initial values are
fixed and all players use the same initial values. Changing those may
cause problems in HDMV / BD-J applications, so filtering should be
based on some flag instead of changing initial values.

I also think filtering the events should be done at higher layer (in
the callback function ?).
Restore events may still be needed internally. I don't know if java
side can set callbacks to be called when PSR value changes. If I
remember right, some PSRs are used for communications between
different parts of player (BD+ ?) so it is likely registers can be
trapped at java side too ?


Following applies only to navigation mode started with bd_play() -
that's also the only scenario where restore is currently used:

When title is 0xffff other values (playlist, clip, chapter, angle,
current time, ...) have no meaning and should not be used at all. But
application should still cache the values for later use: when title
playback starts, only changed values are signaled to application.

Maybe we could drop all status events in _process_psr_event() when
title is 0xffff ? Well, then, some care should be taken to ensure
events are always sent before playback starts.

One possible solution is to block all status events while HDMV VM is
running and generate events when HDMV VM enters suspended state
(playlist playback starts and register values are valid).
bd_read_ext() won't return any data before that as playback is
suspended while HDMV VM is running,
Here it might be good idea to run the whole HDMV application once
without returning to application for every event. HDMV execution is
supposed to be instant i.e. take no time. Not returning from
bd_read_ext() should prevent application from doing anything stupid
like seeking or changing title :)

> 2) I saw some issues where on playback on object gets restored (ege play
> title, then go back if I remember correctly). The restore object thus
> resends the init values of the registers again, and then whatever the
> statemachine is giving. Ill try to repro the restore scenario if you want.

No need, I can see it too and agree it may cause problems and is
misleading (BD_EVENT_PLAYLIST 0 when playlist 0 is not playing -->
application does something, maybe tries to fetch title info for
possibly unexisting playlist 0).

>> Mpls parse
>>
>>> Added a reference comment. I have a couple of blurays where there is
>>> certainly a selection possible (a menu is drawn) but the value for the
> pgs
>>> graphics read is 0. Not sure what is happening there.
>
>>Do you mean menus are visible with some other player ?
> Yep. Cyberlink PowerDVD 10
>
>>Playlist sub_count is the number of sub paths. Typically
>>non-synchronous menu is stored in separate sub-path (m2ts file) so
>>that it can be pre-loaded. But menus can be muxed to the main path too
>> (that's not yet supported). That should be possible to check with
>>mpls_dump application (mpls_dump -v -i -l -p /path/to/?????.mpls).
>
> Ill check with the BR I have that shows the problem. If you want, and let me
> know how I can check for the muxing I can probably give you a patch (I know
> and have experience on mpegts muxing)

Demuxing is already implemented, you just need to hook it to bd_read()
when there is active/selected IG stream in the main path. I don't have
such samples so I didn't add it yet. _find_ig_stream() should always
find current IG stream. If it is muxed to main path, sub_path_idx is
not set. In that case we need some flag to tell when embedded IG
stream should be demuxed, and call gc_decode_ts(,...,ig_pid,...) for
every block. Maybe just add IG stream pid field to BD_STREAM and call
gc_decode_ts() in _read_block if PID is set ?

_find_ig_stream() needs to be called at least when opening playlist
and when when PSR for active IG stream changes. Currently it is not
called if there are no sub-paths. Current code also doesn't support
changing IG stream in middle of playlist, so that could be added too
:).

Maybe we need to reset graphics controller after some operations (seek ?).

Synchronous menus can be valid only during certain perioid of clip, so
some logic should be implemented in graphics controller too. Maybe we
need to run it periodically so that possibly visible menu is
invalidated when it is not anymore valid (based on current player SCR
and composition_timeout_pts). Also selection_timeout_pts handling is
not implemented yet...

> Further remarks ;)
>
> 1) Theres a subtle bug if you use the FILTER values (ege
> TITLES_FILTER_DUP_TITLE/TITLES_FILTER_DUP_CLIP). If that is used then some
> valid mpls's will be filtered that are valid when the BR is played in
> navigation mode. The list that navigation mode uses should be the full list
> available on the disc, while the filter values should return a filter lists
> based on that. I am also not really sure why that filtering is there anyway?

Yes, bd_get_titles() and bd_select_title() are quite useless in
navigation mode (using bd_select_title() may even cause some problems
...). Maybe bd_play() should always populate complete title list and
even disable further calls to bd_get_titles().
Filtering is intended for direct playlist playback when menus are not
used at all. The idea is to filter menu backgrounds etc. from title
list.

> 2) I have some BR's with dynamic PG's (ege animations). Right now, thats not
> supported since the object state gets suspened after the VM runs. Any idea
> on that?  It also fills in with an issue I see/have on pre-buffering of the
> streams: in my player, I am running about 5 seconds ahead of the BR mainly
> because of audio buffering. When I know a new playlist/clip is going to be
> loaded, I let my buffers run clear. However, then I can't get PG's results
> anymore, since I can't do a read() (and the pg's VM animation is running in
> read()). All of that could be solved if theres some seperate VM run call, on
> a callback or so from the library, that would check if a VM run would run a
> new clip or just animate a menu.

I assume you're referring to animations in buttons (controlled by
start_object_id_ref, end_object_id_ref and repeat_flag) and in menu
pages (in/out effects) ?

HDMV VM can run only when playlist is not playing. It is suspended
until playback stops. Animations should be implemented in graphics
controller.

You can use bd_user_input(..., BD_VK_NONE) to trigger page rendering.
Maybe BD_VK_NONE should be mapped to GC_CTRL_NOP to always force page
rendering (currently it does nothing if menu is already visible). This
code path already supports setting PSR_TIME; it should be used for
animation timing. Adding button animations should be quite simple
using this method, I already have some code for that but it is far
from complete :)