[libbluray-devel] Feedback on BD-J support in VLC
Roald Strauss
mr_lou at dewfall.dk
Thu May 19 20:05:28 CEST 2016
On 19-05-2016 13:47, Petri Hintukainen wrote:
>> I don't think you should do any translating mouse button to key
>> events.
>> Xlet developers should implement their own mouse-capture methods
>> using
>> java.awt.event.MouseListener and java.awt.event.MouseMotionListener.
> The problem is I don't know any BD-J Xlet (from BD disc) that would
> support mouse. Still, being able to control BD-J menus with mouse-like
> device would be great (I'm thinking about touch screens / tablets).
> Maybe we could translate mouse events when Xlet does not consume those.
All I know is that textbooks are encouraging Xlet developers to
implement mouse support in their Xlets.
From The HD Cookbook, page 19-1: "BD-J User Input":
"After the remote control, a mouse is the second most likely input
device to be used. Mice are not very common with living room players
today, but they are almost always present in computer players. For this
reason, your title should be capable of accepting mouse input, but the
user interface should be primarily designed for remote control input."
In my humble opinion, if you wish to add some extra mouse support for
discs that hasn't implemented mouse support, you could create a virtual
remote control that you can click with the mouse.
(This approach is also used in the old XleTView
(http://www.interactivetvweb.org/tutorials/getting_started/xletview/running_applications),
and I believe Leawo Blu-ray player also does it that way).
>> Yes, networking works fine in the 3 hardware players I have online
>> (a
>> Sony BDP-S1100, a Samsung something and a Dune HD Smart D1) and also
>> PowerDVD software player.
>>
>> In my Xlets I'm doing a simple HTTP request to check for version of
>> my
>> disc. I can see that this isn't going through in VLC.
> Most likely security manager is missing some checks (URLPermission ?).
> Should be fixed soon (when git is up again).
>
> If there are other problems, maybe you could provide a sample BD image
> for testing ? Even better if it could be used to test mouse events too
> :)
I'll look into creating a sample Xlet for testing purposes. But I have
way too much going on around me at the moment, so it'll take a while.
>> I was under the impression that AACS is related to video only and has
>> nothing to do with signing.
> I think AACS is required to verify the signature chain. BD-J root
> certificate hash is stored in AACS content certificate (which is signed
> by AACS LA public key). So, without AACS BD-J signatures are more or
> less useless.
Hm, well, I don't know anything about AACS.
According to The HD Cookbook, AACS is mandatory for Blu-ray Discs. Yet,
the homebrew discs I'm producing definitely doesn't have AACS - and they
run on all the players I've tested on (22 hardware players and a few
commercial software players).
So it's not true that it's mandatory.
What I think they mean is that any *official* Blu-ray Disc, i.e. one
that has a registered disc number, and has gone through the official
replication process at one of the approved replicators - *they* have to
have AACS. That's my guess.
But any player should (and do apparently) play Blu-ray Discs that
doesn't have AACS.
I have not come across a single player yet that wouldn't play my
self-signed Xlet.
>> It is true that networking requires the Xlet to be signed, according
>> to the specs. This is a bit silly though, because signing an Xlet is
>> no trouble at all and doesn't require any special expensive
>> certificate (as is the case with signing MIDlets).
> Well, that wouldn't make any sense. Signature that can't be verified is
> useless ...
I see your point.
But as I said, all players I've tested on seems to accept anything I
throw at them, with my self-signed Xlet.
Maybe because Xlet developers need to be able to test their Xlets on
real devices?
>> But yes, my Xlets are signed. :-)
>>
>> Since anyone can sign an Xlet without much trouble, I'm not sure it's
>> worth the effort making sure VLC doesn't allow networking if the Xlet
>> isn't signed - unless of course it's the aim that VLC becomes a
>> trustworthy tool for Xlet developers for testing their Xlets.
> Most users see BD disc images as "media files", not applications, and
> play those even if those are from untrusted source. So, I don't think
> BD-J security issues should be taken lightly.
>
> Ideally networking would be an option that user can toggle on/off. I'm
> sure some users would like to disable all BD-J network access.
>
> Maybe we could ask user if networking should be allowed when unsigned Xlet tries to access network. Or issue a warning when Xlet is from "untrusted" source.
That's *probably* what all players *should* have done yes. I can't
explain why they don't.
However, it should also be put in perspective I think. I mean, it made
sense for MIDlets to give these security popups, because sending SMS or
going online or making phone-calls costs money.
But displaying a warning because a Blu-ray disc wants to make an online
call, I don't see the point in that in this age where everything else is
online. JavaME being the sandbox it is, shouldn't really be able to
cause any trouble either.
I see no problem adding a "View offline" option when opening the disc
though. Just like there's a "No blu-ray menu" option.
- Roald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/libbluray-devel/attachments/20160519/8fd51583/attachment.html>
More information about the libbluray-devel
mailing list