Re: [libbluray-devel] JRE for Android part 3
well.. as usual you solved it! Thank you Petri! Release in the same thread. Now more people can enjoy full disc blurays and that's awesome! https://forum.kodi.tv/showthread.php?tid=360250 On Wed, Feb 24, 2021 at 2:49 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > ke, 2021-02-24 kello 13:24 -0300, Vitor Dall'Acqua kirjoitti: > > Hey just wanted to bring this back up again to check if you guys have > > any advice on this.I have compiled the aarch32 version of that > > OpenJDK but I'm facing 2 problems: > > > > One is that I can't build a server version of libjvm.so, so I'm using > > the client one. > > I have reported it here: > > https://github.com/PojavLauncherTeam/PojavLauncher/issues/949 > > but so far no solution was found. > > Those build scripts seem to select client JVM for aarch32. > Client JVM should be OK for BD-J. > > > The other problem is that while using it libbluray always ends with > > this error: > > ERROR: loadN() failed: java.lang.UnsatisfiedLinkError: > > java.awt.Component.initIDs()V > > java.awt.Component.initIDs(Native Method) > > java.awt.Component.(Component.java:596) > > org.videolan.BDJLoader.loadN(BDJLoader.java:228) > > org.videolan.BDJLoader.access$200(BDJLoader.java:46) > > org.videolan.BDJLoader$BDJLoaderAction.doAction(BDJLoader.java:363) > > org.videolan.BDJAction.process(BDJAction.java:59) > > org.videolan.BDJActionQueue.run(BDJActionQueue.java:86) > > java.lang.Thread.run(Thread.java:748) > > > > I have compiled the lib as debug and I'm using 0x22804 as debug mask > > for libbluray but no other information is available. > > Any idea what this might be? > > I had the same issue while testing it in Ubuntu. AWT libraries are > missing native functions. Maybe preloading could fix this. I fixed it > by adding those functions to few more places... > > You could try if the attached patch helps. Probably all changes are not > needed and some are "duplicate". I didn't test those much, as my only > intent was to see if it can run BD-J Xlets. > > Ex. change in jdk/make/lib/Awt2dLibraries.gmk is basically wrong, and > may cause build issues. You probably should try first without it. > > Also note that it is against aarch64 tree (I don't know if it applies > to aarch32 tree as-is). > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
ke, 2021-02-24 kello 13:24 -0300, Vitor Dall'Acqua kirjoitti:
> Hey just wanted to bring this back up again to check if you guys have
> any advice on this.I have compiled the aarch32 version of that
> OpenJDK but I'm facing 2 problems:
>
> One is that I can't build a server version of libjvm.so, so I'm using
> the client one.
> I have reported it here:
> https://github.com/PojavLauncherTeam/PojavLauncher/issues/949
> but so far no solution was found.
Those build scripts seem to select client JVM for aarch32.
Client JVM should be OK for BD-J.
> The other problem is that while using it libbluray always ends with
> this error:
> ERROR: loadN() failed: java.lang.UnsatisfiedLinkError:
> java.awt.Component.initIDs()V
> java.awt.Component.initIDs(Native Method)
> java.awt.Component.(Component.java:596)
> org.videolan.BDJLoader.loadN(BDJLoader.java:228)
> org.videolan.BDJLoader.access$200(BDJLoader.java:46)
> org.videolan.BDJLoader$BDJLoaderAction.doAction(BDJLoader.java:363)
> org.videolan.BDJAction.process(BDJAction.java:59)
> org.videolan.BDJActionQueue.run(BDJActionQueue.java:86)
> java.lang.Thread.run(Thread.java:748)
>
> I have compiled the lib as debug and I'm using 0x22804 as debug mask
> for libbluray but no other information is available.
> Any idea what this might be?
I had the same issue while testing it in Ubuntu. AWT libraries are
missing native functions. Maybe preloading could fix this. I fixed it
by adding those functions to few more places...
You could try if the attached patch helps. Probably all changes are not
needed and some are "duplicate". I didn't test those much, as my only
intent was to see if it can run BD-J Xlets.
Ex. change in jdk/make/lib/Awt2dLibraries.gmk is basically wrong, and
may cause build issues. You probably should try first without it.
Also note that it is against aarch64 tree (I don't know if it applies
to aarch32 tree as-is).
diff --git a/hotspot/src/os/linux/vm/os_linux.cpp b/hotspot/src/os/linux/vm/os_linux.cpp
index eff6253e..6379e315 100644
--- a/hotspot/src/os/linux/vm/os_linux.cpp
+++ b/hotspot/src/os/linux/vm/os_linux.cpp
@@ -2452,8 +2452,8 @@ void os::jvm_path(char *buf, jint buflen) {
dli_fname, sizeof(dli_fname), NULL);
assert(ret, "cannot locate libjvm");
#ifdef __ANDROID__
- char* java_home_var = ::getenv("JAVA_HOME");
- if (java_home_var == NULL || dli_fname[0] == '\0') {
+ //char* java_home_var = ::getenv("JAVA_HOME");
+ if (/*java_home_var == NULL ||*/ dli_fname[0] == '\0') {
return;
}
snprintf(buf, buflen, /* "%s/lib/%s/server/%s", java_home_var, cpu_arch, */ dli_fname);
diff --git a/hotspot/src/share/vm/runtime/os.cpp b/hotspot/src/share/vm/runtime/os.cpp
index 22c94cf3..ce64caa2 100644
--- a/hotspot/src/share/vm/runtime/os.cpp
+++ b/hotspot/src/share/vm/runtime/os.cpp
@@ -443,7 +443,7 @@ void* os::native_java_library() {
vm_exit_during_initialization("Unable to load native library", ebuf);
}
-#if defined(__OpenBSD__)
+#if defined(__OpenBSD__) || defined(__ANDROID__)
// Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so
// ignore errors
if (dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(),
diff --git a/jdk/make/lib/Awt2dLibraries.gmk b/jdk/make/lib/Awt2dLibraries.gmk
index 347f30e6..f0384054 100644
--- a/jdk/make/lib/Awt2dLibraries.gmk
+++ b/jdk/make/lib/Awt2dLibraries.gmk
@@ -808,6 +808,7 @@ ifeq ($(BUILD_HEADLESS), true)
#awt_UNIXToolkit.c
LIBAWT_HEADLESS_FILES := \
+XToolkit.c \
awt_AWTEvent.c \
awt_Event.c \
awt_Font.c \
diff --git a/jdk/src/share/native/common/xlocale.h b/jdk/src/share/native/common/xlocale.h
index 5a489751..022dbf4a 100644
--- a/jdk/src/share/native/common/xlocale.h
+++ b/jdk/src/share/native/common/xlocale.h
@@ -29,6 +29,8 @@
#define _XLOCALE_H_
#include
/* If we just use void* here, GCC exposes that in error messages. */
+#ifndef _BITS_TYPES_LOCALE_T_H
struct __locale_t;
typedef struct __locale_t* locale_t;
+#endif
#endif /* _XLOCALE_H_ */
diff --git a/jdk/src/solaris/native/sun/awt/HeadlessToolkit.c b/jdk/src/solaris/native/sun/awt/HeadlessToolkit.c
index fd17f3b8..c621e865 100644
--- a/jdk/src/solaris/native/sun/awt/HeadlessToolkit.c
+++ b/jdk/src/solaris/native/sun/awt/HeadlessToolkit.c
@@ -41,4 +41,34 @@ JNIEXPORT jboolean JNICALL AWTIsHeadless() {
return JNI_TRUE;
}
+JNIEXPORT void JNICALL
+Java_java_awt_Component_initIDs
+ (JNIEnv *env, jclass cls)
+{
+
+}
+
+
+JNIEXPORT void JNICALL
+Java_java_awt_Container_initIDs
+ (JNIEnv *env, jclass cls)
+{
+
+}
+
+
+JNIEXPORT void JNICALL
+Java_java_awt_Window_initIDs
+ (JNIEnv *env, jclass cls)
+{
+
+}
+
+JNIEXPORT void JNICALL
+Java_java_awt_Frame_initIDs
+ (JNIEnv *env, jclass cls)
+{
+
+}
+
#endif
diff --git a/jdk/src/solaris/native/sun/awt/VDrawingArea.c b/jdk/src/solaris/native/sun/awt/VDrawingArea.c
index 712d0840..b5bbb26e 100644
--- a/jdk/src/solaris/native/sun/awt/VDrawingArea.c
+++
Re: [libbluray-devel] JRE for Android part 3
Hey just wanted to bring this back up again to check if you guys have any advice on this. I have compiled the aarch32 version of that OpenJDK but I'm facing 2 problems: One is that I can't build a server version of libjvm.so, so I'm using the client one. I have reported it here: https://github.com/PojavLauncherTeam/PojavLauncher/issues/949 but so far no solution was found. The other problem is that while using it libbluray always ends with this error: ERROR: loadN() failed: java.lang.UnsatisfiedLinkError: java.awt.Component.initIDs()V java.awt.Component.initIDs(Native Method) java.awt.Component.(Component.java:596) org.videolan.BDJLoader.loadN(BDJLoader.java:228) org.videolan.BDJLoader.access$200(BDJLoader.java:46) org.videolan.BDJLoader$BDJLoaderAction.doAction(BDJLoader.java:363) org.videolan.BDJAction.process(BDJAction.java:59) org.videolan.BDJActionQueue.run(BDJActionQueue.java:86) java.lang.Thread.run(Thread.java:748) I have compiled the lib as debug and I'm using 0x22804 as debug mask for libbluray but no other information is available. Any idea what this might be? On Tue, Feb 2, 2021 at 11:53 AM Vitor Dall'Acqua wrote: > So the renderer in the application must expand the colors to HDR, right? > > BD-J uses argb. > I see coordinates, x, y. > Width, height. > > I see planes. > > But I don't see anything related to color space. > > I guess there's none in how the overlay is rendered. > It might be something up with Kodi's demuxer that sends it to media codec > decoder. > > On Tue, Feb 2, 2021, 11:40 AM Petri Hintukainen < > phint...@users.sourceforge.net> wrote: > >> ma, 2021-02-01 kello 22:11 -0300, Vitor Dall'Acqua kirjoitti: >> > Petri, quick question, >> > Is it possible to disable the resume feature without breaking the >> > cache and persistent storage? >> >> Disabling persistent storage efficiently disables this feature. Of >> course also all other features that use persistent storage stop working >> (ex. bookmarks, ...). >> Resume is implemented in each disc BD-J Xlets, so there's no generic >> way to disable just it. You could try deleting the resume file, but it >> is not easy as each disc/toolkit use different names for the file. >> >> ma, 2021-02-01 kello 22:20 -0300, Vitor Dall'Acqua kirjoitti: >> > and, it might be possible that the 2D elements are being >> > rendered because no HDR information is sent to the disc? >> >> No. BD-J menus are always SDR, and max resolution is FHD. >> >> It is up to the application to render overlays over the video, >> libbluray can't know how it is best done. >> >> >> ___ >> libbluray-devel mailing list >> libbluray-devel@videolan.org >> https://mailman.videolan.org/listinfo/libbluray-devel >> > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
So the renderer in the application must expand the colors to HDR, right? BD-J uses argb. I see coordinates, x, y. Width, height. I see planes. But I don't see anything related to color space. I guess there's none in how the overlay is rendered. It might be something up with Kodi's demuxer that sends it to media codec decoder. On Tue, Feb 2, 2021, 11:40 AM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > ma, 2021-02-01 kello 22:11 -0300, Vitor Dall'Acqua kirjoitti: > > Petri, quick question, > > Is it possible to disable the resume feature without breaking the > > cache and persistent storage? > > Disabling persistent storage efficiently disables this feature. Of > course also all other features that use persistent storage stop working > (ex. bookmarks, ...). > Resume is implemented in each disc BD-J Xlets, so there's no generic > way to disable just it. You could try deleting the resume file, but it > is not easy as each disc/toolkit use different names for the file. > > ma, 2021-02-01 kello 22:20 -0300, Vitor Dall'Acqua kirjoitti: > > and, it might be possible that the 2D elements are being > > rendered because no HDR information is sent to the disc? > > No. BD-J menus are always SDR, and max resolution is FHD. > > It is up to the application to render overlays over the video, > libbluray can't know how it is best done. > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
ma, 2021-02-01 kello 22:11 -0300, Vitor Dall'Acqua kirjoitti: > Petri, quick question, > Is it possible to disable the resume feature without breaking the > cache and persistent storage? Disabling persistent storage efficiently disables this feature. Of course also all other features that use persistent storage stop working (ex. bookmarks, ...). Resume is implemented in each disc BD-J Xlets, so there's no generic way to disable just it. You could try deleting the resume file, but it is not easy as each disc/toolkit use different names for the file. ma, 2021-02-01 kello 22:20 -0300, Vitor Dall'Acqua kirjoitti: > and, it might be possible that the 2D elements are being > rendered because no HDR information is sent to the disc? No. BD-J menus are always SDR, and max resolution is FHD. It is up to the application to render overlays over the video, libbluray can't know how it is best done. ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
and, it might be possible that the 2D elements are being rendered because no HDR information is sent to the disc? Just noticed this: bd_psr_setting_write(p, PSR_UHD_CAP, /* TODO */ 0x ); bd_psr_setting_write(p, PSR_UHD_DISPLAY_CAP, /* TODO */ 0x ); bd_psr_setting_write(p, PSR_UHD_HDR_PREFER, /* TODO */ 0x ); bd_psr_setting_write(p, PSR_UHD_SDR_CONV_PREFER, /* TODO */ 0 ) On Mon, Feb 1, 2021 at 10:11 PM Vitor Dall'Acqua wrote: > Petri, quick question, > > Is it possible to disable the resume feature without breaking the cache > and persistent storage? > > On Mon, Feb 1, 2021 at 3:00 PM Vitor Dall'Acqua wrote: > >> My ideas to fix hdr didn't work out as expected. >> >> So, I'm releasing everything: >> https://forum.kodi.tv/showthread.php?tid=360250 >> >> Thanked you, Petri and Shaya in the release thread. If you guys don't >> want your name there, please, let me know and I remove it. >> But I'm trully grateful by the help you two gave to this. >> >> So, changes made to Kodi: >> >> https://github.com/fandangos/Kodi-HDR-Edition/commit/c2320a06c727eac77a0d8f7ecc498537d1c5bf0a >> >> Changes made to libbluray: >> https://github.com/Fandangos/libbluray/ >> >> Changes made to OpenJDK: >> https://github.com/fandangos/openjdk-multiarch-jdk8u >> >> The addon for Kodi to work and pre compiled libs: >> https://github.com/fandangos/JRE-Kodi-Android/ >> >> >> >> On Mon, Feb 1, 2021 at 8:10 AM Vitor Dall'Acqua wrote: >> >>> Only the m2ts demuxer that might be missing a few bytes and causing the >>> decoder to fail. >>> >>> I have an idea to fix HDR menu itens that I'll test today. >>> >>> On Mon, Feb 1, 2021, 7:56 AM Petri Hintukainen < >>> phint...@users.sourceforge.net> wrote: >>> su, 2021-01-31 kello 14:52 -0300, Vitor Dall'Acqua kirjoitti: > Ok, while I work on why it's not rendering the menu in HDR.. > Petri, libnet.so that needs to be loaded before libjvm.so I have to > pack it with Kodi (while it is already inside JAVA_HOME) > > I'm loading it like this: > > static const char libnet[] = "libnet"; > dl_dlopen(libnet, NULL); > > how do I write in C to load it but load from inside > JAVA_HOME/lib/aarch64/ ? You need full absolute path. Something like static const char libnet[] = JAVA_HOME "/lib/aarch64/libnet"; I've updated JRE image (with OpenBSD libnet fix), it shouldn't need any libs preloaded anymore. What other changes there are left in libbluray ? ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel >>> ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Petri, quick question, Is it possible to disable the resume feature without breaking the cache and persistent storage? On Mon, Feb 1, 2021 at 3:00 PM Vitor Dall'Acqua wrote: > My ideas to fix hdr didn't work out as expected. > > So, I'm releasing everything: > https://forum.kodi.tv/showthread.php?tid=360250 > > Thanked you, Petri and Shaya in the release thread. If you guys don't want > your name there, please, let me know and I remove it. > But I'm trully grateful by the help you two gave to this. > > So, changes made to Kodi: > > https://github.com/fandangos/Kodi-HDR-Edition/commit/c2320a06c727eac77a0d8f7ecc498537d1c5bf0a > > Changes made to libbluray: > https://github.com/Fandangos/libbluray/ > > Changes made to OpenJDK: > https://github.com/fandangos/openjdk-multiarch-jdk8u > > The addon for Kodi to work and pre compiled libs: > https://github.com/fandangos/JRE-Kodi-Android/ > > > > On Mon, Feb 1, 2021 at 8:10 AM Vitor Dall'Acqua wrote: > >> Only the m2ts demuxer that might be missing a few bytes and causing the >> decoder to fail. >> >> I have an idea to fix HDR menu itens that I'll test today. >> >> On Mon, Feb 1, 2021, 7:56 AM Petri Hintukainen < >> phint...@users.sourceforge.net> wrote: >> >>> su, 2021-01-31 kello 14:52 -0300, Vitor Dall'Acqua kirjoitti: >>> > Ok, while I work on why it's not rendering the menu in HDR.. >>> > Petri, libnet.so that needs to be loaded before libjvm.so I have to >>> > pack it with Kodi (while it is already inside JAVA_HOME) >>> > >>> > I'm loading it like this: >>> > >>> > static const char libnet[] = "libnet"; >>> > dl_dlopen(libnet, NULL); >>> > >>> > how do I write in C to load it but load from inside >>> > JAVA_HOME/lib/aarch64/ ? >>> >>> You need full absolute path. Something like >>> static const char libnet[] = JAVA_HOME "/lib/aarch64/libnet"; >>> >>> >>> I've updated JRE image (with OpenBSD libnet fix), it shouldn't need any >>> libs preloaded anymore. >>> >>> What other changes there are left in libbluray ? >>> >>> ___ >>> libbluray-devel mailing list >>> libbluray-devel@videolan.org >>> https://mailman.videolan.org/listinfo/libbluray-devel >>> >> ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
My ideas to fix hdr didn't work out as expected. So, I'm releasing everything: https://forum.kodi.tv/showthread.php?tid=360250 Thanked you, Petri and Shaya in the release thread. If you guys don't want your name there, please, let me know and I remove it. But I'm trully grateful by the help you two gave to this. So, changes made to Kodi: https://github.com/fandangos/Kodi-HDR-Edition/commit/c2320a06c727eac77a0d8f7ecc498537d1c5bf0a Changes made to libbluray: https://github.com/Fandangos/libbluray/ Changes made to OpenJDK: https://github.com/fandangos/openjdk-multiarch-jdk8u The addon for Kodi to work and pre compiled libs: https://github.com/fandangos/JRE-Kodi-Android/ On Mon, Feb 1, 2021 at 8:10 AM Vitor Dall'Acqua wrote: > Only the m2ts demuxer that might be missing a few bytes and causing the > decoder to fail. > > I have an idea to fix HDR menu itens that I'll test today. > > On Mon, Feb 1, 2021, 7:56 AM Petri Hintukainen < > phint...@users.sourceforge.net> wrote: > >> su, 2021-01-31 kello 14:52 -0300, Vitor Dall'Acqua kirjoitti: >> > Ok, while I work on why it's not rendering the menu in HDR.. >> > Petri, libnet.so that needs to be loaded before libjvm.so I have to >> > pack it with Kodi (while it is already inside JAVA_HOME) >> > >> > I'm loading it like this: >> > >> > static const char libnet[] = "libnet"; >> > dl_dlopen(libnet, NULL); >> > >> > how do I write in C to load it but load from inside >> > JAVA_HOME/lib/aarch64/ ? >> >> You need full absolute path. Something like >> static const char libnet[] = JAVA_HOME "/lib/aarch64/libnet"; >> >> >> I've updated JRE image (with OpenBSD libnet fix), it shouldn't need any >> libs preloaded anymore. >> >> What other changes there are left in libbluray ? >> >> ___ >> libbluray-devel mailing list >> libbluray-devel@videolan.org >> https://mailman.videolan.org/listinfo/libbluray-devel >> > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Only the m2ts demuxer that might be missing a few bytes and causing the decoder to fail. I have an idea to fix HDR menu itens that I'll test today. On Mon, Feb 1, 2021, 7:56 AM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > su, 2021-01-31 kello 14:52 -0300, Vitor Dall'Acqua kirjoitti: > > Ok, while I work on why it's not rendering the menu in HDR.. > > Petri, libnet.so that needs to be loaded before libjvm.so I have to > > pack it with Kodi (while it is already inside JAVA_HOME) > > > > I'm loading it like this: > > > > static const char libnet[] = "libnet"; > > dl_dlopen(libnet, NULL); > > > > how do I write in C to load it but load from inside > > JAVA_HOME/lib/aarch64/ ? > > You need full absolute path. Something like > static const char libnet[] = JAVA_HOME "/lib/aarch64/libnet"; > > > I've updated JRE image (with OpenBSD libnet fix), it shouldn't need any > libs preloaded anymore. > > What other changes there are left in libbluray ? > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
su, 2021-01-31 kello 14:52 -0300, Vitor Dall'Acqua kirjoitti: > Ok, while I work on why it's not rendering the menu in HDR.. > Petri, libnet.so that needs to be loaded before libjvm.so I have to > pack it with Kodi (while it is already inside JAVA_HOME) > > I'm loading it like this: > > static const char libnet[] = "libnet"; > dl_dlopen(libnet, NULL); > > how do I write in C to load it but load from inside > JAVA_HOME/lib/aarch64/ ? You need full absolute path. Something like static const char libnet[] = JAVA_HOME "/lib/aarch64/libnet"; I've updated JRE image (with OpenBSD libnet fix), it shouldn't need any libs preloaded anymore. What other changes there are left in libbluray ? ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
su, 2021-01-31 kello 12:58 -0300, Vitor Dall'Acqua kirjoitti:
> the only library I'm preloading is libnet.so that is used by
> libnio.so, or else it says it's not possible to find it.
This seems to issue with OpenBSD too. There's workaround in Hotspot
code. Enabling it for Android could fix this.
diff --git a/hotspot/src/share/vm/runtime/os.cpp b/hotspot/src/share/vm/runtime/os.cpp
index 22c94cf3..ce64caa2 100644
--- a/hotspot/src/share/vm/runtime/os.cpp
+++ b/hotspot/src/share/vm/runtime/os.cpp
@@ -443,7 +443,7 @@ void* os::native_java_library() {
vm_exit_during_initialization("Unable to load native library", ebuf);
}
-#if defined(__OpenBSD__)
+#if defined(__OpenBSD__) || defined(__ANDROID__)
// Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so
// ignore errors
if (dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(),
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Ok, spoke to some people. No chance to remove that GetDecoderFilterManager
from Kodi.
So I looked into the m2ts file that plays during the menu:
playing the menu file m2ts alone
INFO : ffmpeg[0x3042539040X]: Duration: 00:00:45.04, bitrate: N/A
INFO : ffmpeg[0x3042539040X]: Program 1
INFO : ffmpeg[0x3042539040X]: Stream #0:0[0x1011]: Video: hevc
(HDMV / 0x564D4448), none, 3840x2160, 90k tbn
INFO : ffmpeg[0x3042539040X]: Stream #0:1[0x1100]: Audio: ac3
(AC-3 / 0x332D4341), 0 channels
DEBUG : CDVDDemuxFFmpeg::AddStream ID: 0
DEBUG : CDVDDemuxFFmpeg::AddStream ID: 1
INFO : Opening stream: 0 source: 256
INFO : Creating video codec with codec id: 173
DEBUG : CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x
Height 2160, Fpsrate 0 / Fpsscale 0, CodecID 173, Level -99, Profile -99,
PTS_invalid 0, Tag 1447904328, *Extradata-Size: 121*
CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.decode),
colorFormat(21)
CDVDVideoCodecAndroidMediaCodec::InjectExtraData
CDVDVideoCodecAndroidMediaCodec:: width(3840), height(2160), stride(0),
slice-height(0), color-format(0)
CDVDVideoCodecAndroidMediaCodec:: crop-left(0), crop-top(0),
crop-right(3839), crop-bottom(2159)
CDVDVideoCodecAndroidMediaCodec:: Multi-Surface Rendering
CDVDVideoCodecAndroidMediaCodec:: Open Android MediaCodec
OMX.Nvidia.h265.decode
Playing the disc with menu:
INFO : ffmpeg[0x30248dc040X]: Duration: N/A, start: 600.00,
bitrate: N/A
INFO : ffmpeg[0x30248dc040X]: Program 1
INFO : ffmpeg[0x30248dc040X]: Stream #0:0[0x1011]: Video: hevc
(Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084),
3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
DEBUG : CDVDDemuxFFmpeg::AddStream ID: 0
INFO : Opening stream: 0 source: 256
INFO : Display resolution ADJUST : 3840x2160 @ 23.976025 - Full
Screen (27) (weight: 0.000)
INFO : Creating video codec with codec id: 173
DEBUG : CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x
Height 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile
2, PTS_invalid 0, Tag 1447904328, *Extradata-Size: 114*
INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing
codec:OMX.Nvidia.h265.decode
DEBUG : CDVDVideoCodecAndroidMediaCodec::Open
m_codecname(OMX.Nvidia.h265.decode), colorFormat(2135033992)
DEBUG : CDVDVideoCodecAndroidMediaCodec::Open
m_codecname(OMX.Nvidia.h265.decode), colorFormat(21)
DEBUG : CDVDVideoCodecAndroidMediaCodec::InjectExtraData
DEBUG : CDVDVideoCodecAndroidMediaCodec:: width(3840),
height(2160), stride(0), slice-height(0), color-format(0)
DEBUG : CDVDVideoCodecAndroidMediaCodec:: crop-left(0),
crop-top(0), crop-right(3839), crop-bottom(2159)
DEBUG : CDVDVideoCodecAndroidMediaCodec:: Multi-Surface Rendering
INFO : CDVDVideoCodecAndroidMediaCodec:: Open Android MediaCodec
OMX.Nvidia.h265.decode
DEBUG : CDVDVideoCodecAndroidMediaCodec::UpdateFpsDuration
fpsRate:24000 fpsscale:1001, fpsDur:41708
DEBUG : CVideoPlayerVideo::OpenStream - open stream with codec id:
173
there's a 7 bytes or bits, I don't know what extradata is.. missing.
Is this something that you know what is about, Petri?
On Sun, Jan 31, 2021 at 3:26 PM Vitor Dall'Acqua wrote:
> Well.. at least now I know exactly what caused the problems:
>
> This line has to go from inside BD_EVENT_STILL_TIME on videoplayer.cpp
> m_dvd.state = DVDSTATE_STILL;
>
> and this check has to go:
> if (!CServiceBroker::GetDecoderFilterManager()->isValid(m_codecname,
> m_hints))
> continue;
>
> So we can use hardware acceleration.
> The background video will play just fine in HDR but all the 2d assets like
> the interactive menu is rendered in HDR.
>
> I don't know if you would like to tackle this, Petri, but
>
> https://github.com/xbmc/xbmc/commit/892df0b3d04e2cc4808bd34199f6fb3034cbb47f
>
> There is the math needed to get SDR content into HDR.
> This actually solves another problem in Kodi that is, when it goes in HDR
> all the menu is over saturated.
> Here what is going on is that when you start the menu of a uhd bluray, the
> 2d content is dessaturated.
>
> I would be really nice to have this but not the most needed feature on
> libbluray.
>
> On Sun, Jan 31, 2021 at 2:52 PM Vitor Dall'Acqua wrote:
>
>> Ok, while I work on why it's not rendering the menu in HDR..
>>
>> Petri, libnet.so that needs to be loaded before libjvm.so I have to pack
>> it with Kodi (while it is already inside JAVA_HOME)
>>
>> I'm loading it like this:
>>
>> static const char libnet[] = "libnet";
>> dl_dlopen(libnet, NULL);
>>
>> how do I write in C to load it but load from inside
>> JAVA_HOME/lib/aarch64/ ?
>>
>> On Sun, Jan 31, 2021 at 1:53 PM Vitor Dall'Acqua
>> wrote:
>>
>>> FIXED IT:
>>>
>>> case BD_EVENT_STILL_TIME:
>>> /* {
>>> if (m_dvd.state != DVDSTATE_STILL)
>>> {
>>> // else notify the player we have received a still frame
>>>
>>> m_dvd.iDVDStillTime = *static_cast(pData);
>>> m_dvd.iDVDStillStartTime =
Re: [libbluray-devel] JRE for Android part 3
Well.. at least now I know exactly what caused the problems:
This line has to go from inside BD_EVENT_STILL_TIME on videoplayer.cpp
m_dvd.state = DVDSTATE_STILL;
and this check has to go:
if (!CServiceBroker::GetDecoderFilterManager()->isValid(m_codecname,
m_hints))
continue;
So we can use hardware acceleration.
The background video will play just fine in HDR but all the 2d assets like
the interactive menu is rendered in HDR.
I don't know if you would like to tackle this, Petri, but
https://github.com/xbmc/xbmc/commit/892df0b3d04e2cc4808bd34199f6fb3034cbb47f
There is the math needed to get SDR content into HDR.
This actually solves another problem in Kodi that is, when it goes in HDR
all the menu is over saturated.
Here what is going on is that when you start the menu of a uhd bluray, the
2d content is dessaturated.
I would be really nice to have this but not the most needed feature on
libbluray.
On Sun, Jan 31, 2021 at 2:52 PM Vitor Dall'Acqua wrote:
> Ok, while I work on why it's not rendering the menu in HDR..
>
> Petri, libnet.so that needs to be loaded before libjvm.so I have to pack
> it with Kodi (while it is already inside JAVA_HOME)
>
> I'm loading it like this:
>
> static const char libnet[] = "libnet";
> dl_dlopen(libnet, NULL);
>
> how do I write in C to load it but load from inside JAVA_HOME/lib/aarch64/
> ?
>
> On Sun, Jan 31, 2021 at 1:53 PM Vitor Dall'Acqua wrote:
>
>> FIXED IT:
>>
>> case BD_EVENT_STILL_TIME:
>> /* {
>> if (m_dvd.state != DVDSTATE_STILL)
>> {
>> // else notify the player we have received a still frame
>>
>> m_dvd.iDVDStillTime = *static_cast(pData);
>> m_dvd.iDVDStillStartTime = XbmcThreads::SystemClockMillis();
>>
>> if (m_dvd.iDVDStillTime != 0)
>> m_dvd.iDVDStillTime *= 1000;
>>
>> /* adjust for the output delay in the video queue
>> unsigned int time = 0;
>> if (m_CurrentVideo.stream && m_dvd.iDVDStillTime > 0)
>> {
>> time = (unsigned int)(m_VideoPlayerVideo->GetOutputDelay() /
>> (DVD_TIME_BASE / 1000));
>> if (time < 1 && time > 0)
>> m_dvd.iDVDStillTime += time;
>> }
>> m_dvd.state = DVDSTATE_STILL;
>> CLog::Log(LOGDEBUG, "BD_EVENT_STILL_TIME - waiting %i sec, with
>> delay of %d sec",
>> m_dvd.iDVDStillTime, time / 1000);
>> }
>> }*/
>>
>> I had to comment this and now video plays fine.
>> But... for some reason.. the menu isn't rendered in HDR.
>>
>>
>> On Sun, Jan 31, 2021 at 12:58 PM Vitor Dall'Acqua
>> wrote:
>>
>>> I think the other changes I did are not needed if you preload the
>>> libraries (those were required to get it loaded in Ubuntu / x86_64).
>>>
>>> the only library I'm preloading is libnet.so that is used by libnio.so,
>>> or else it says it's not possible to find it.
>>> I'm not using that snip you made to preload every lib and it's working.
>>>
>>> Just to let you know.
>>>
>>> On Sun, Jan 31, 2021 at 12:50 PM Petri Hintukainen <
>>> phint...@users.sourceforge.net> wrote:
>>>
la, 2021-01-30 kello 14:27 -0300, Vitor Dall'Acqua kirjoitti:
> Also, Petri, do you think you could share the changes you made
> on JRE to allow it to run without JAVA_HOME?
Attached.
Source tree was from:
git clone --depth 1
https://github.com/PojavLauncherTeam/openjdk-aarch64-jdk8u openjdk
I think the other changes I did are not needed if you preload the
libraries (those were required to get it loaded in Ubuntu / x86_64).
Preloading is weird and quite hacky. And those libraries are never
closed. I don't know if it belongs to libbluray. Maybe if it was just
one, consistent library. But definetely not blindly all libraries in
lib/ folder.
If JVM doesn't find the libraries, it cold be fixable with -
Djava.library.path (or simliar) or LD_LIBRARY_PATH. If JVM doesn't try
loading those, it is bug in java files.
If we can't get it loading properly, preloading could be done in Kodi
or in libjvm.so wrapper library. It is specific to this one JVM and/or
configuration.
> And did you create a make file to compile it? Or did it by hand?
There are build scripts in
https://github.com/PojavLauncherTeam/android-openjdk-build-multiarch.git
> And finally, the changes needed on libbluray are just a few lines of
> code on bdj.c.
> Do you think a #ifdef android would be a good idea?
For generic, android specific parts, yes.
If there are some App / Kodi specific things (like paths), we need to
add some way to configure those build-time and/or runtime.
> I believe that even VLC could play full disks on Android too.
Depends on the device. This requires some kind of keyboard or remote
controller (BD-J can't be used with touch screen). In
Re: [libbluray-devel] JRE for Android part 3
Ok, while I work on why it's not rendering the menu in HDR..
Petri, libnet.so that needs to be loaded before libjvm.so I have to pack it
with Kodi (while it is already inside JAVA_HOME)
I'm loading it like this:
static const char libnet[] = "libnet";
dl_dlopen(libnet, NULL);
how do I write in C to load it but load from inside JAVA_HOME/lib/aarch64/ ?
On Sun, Jan 31, 2021 at 1:53 PM Vitor Dall'Acqua wrote:
> FIXED IT:
>
> case BD_EVENT_STILL_TIME:
> /* {
> if (m_dvd.state != DVDSTATE_STILL)
> {
> // else notify the player we have received a still frame
>
> m_dvd.iDVDStillTime = *static_cast(pData);
> m_dvd.iDVDStillStartTime = XbmcThreads::SystemClockMillis();
>
> if (m_dvd.iDVDStillTime != 0)
> m_dvd.iDVDStillTime *= 1000;
>
> /* adjust for the output delay in the video queue
> unsigned int time = 0;
> if (m_CurrentVideo.stream && m_dvd.iDVDStillTime > 0)
> {
> time = (unsigned int)(m_VideoPlayerVideo->GetOutputDelay() /
> (DVD_TIME_BASE / 1000));
> if (time < 1 && time > 0)
> m_dvd.iDVDStillTime += time;
> }
> m_dvd.state = DVDSTATE_STILL;
> CLog::Log(LOGDEBUG, "BD_EVENT_STILL_TIME - waiting %i sec, with
> delay of %d sec",
> m_dvd.iDVDStillTime, time / 1000);
> }
> }*/
>
> I had to comment this and now video plays fine.
> But... for some reason.. the menu isn't rendered in HDR.
>
>
> On Sun, Jan 31, 2021 at 12:58 PM Vitor Dall'Acqua
> wrote:
>
>> I think the other changes I did are not needed if you preload the
>> libraries (those were required to get it loaded in Ubuntu / x86_64).
>>
>> the only library I'm preloading is libnet.so that is used by libnio.so,
>> or else it says it's not possible to find it.
>> I'm not using that snip you made to preload every lib and it's working.
>>
>> Just to let you know.
>>
>> On Sun, Jan 31, 2021 at 12:50 PM Petri Hintukainen <
>> phint...@users.sourceforge.net> wrote:
>>
>>> la, 2021-01-30 kello 14:27 -0300, Vitor Dall'Acqua kirjoitti:
>>> > Also, Petri, do you think you could share the changes you made
>>> > on JRE to allow it to run without JAVA_HOME?
>>>
>>> Attached.
>>>
>>> Source tree was from:
>>> git clone --depth 1
>>> https://github.com/PojavLauncherTeam/openjdk-aarch64-jdk8u openjdk
>>>
>>> I think the other changes I did are not needed if you preload the
>>> libraries (those were required to get it loaded in Ubuntu / x86_64).
>>>
>>> Preloading is weird and quite hacky. And those libraries are never
>>> closed. I don't know if it belongs to libbluray. Maybe if it was just
>>> one, consistent library. But definetely not blindly all libraries in
>>> lib/ folder.
>>>
>>> If JVM doesn't find the libraries, it cold be fixable with -
>>> Djava.library.path (or simliar) or LD_LIBRARY_PATH. If JVM doesn't try
>>> loading those, it is bug in java files.
>>>
>>> If we can't get it loading properly, preloading could be done in Kodi
>>> or in libjvm.so wrapper library. It is specific to this one JVM and/or
>>> configuration.
>>>
>>> > And did you create a make file to compile it? Or did it by hand?
>>>
>>> There are build scripts in
>>> https://github.com/PojavLauncherTeam/android-openjdk-build-multiarch.git
>>>
>>> > And finally, the changes needed on libbluray are just a few lines of
>>> > code on bdj.c.
>>> > Do you think a #ifdef android would be a good idea?
>>>
>>> For generic, android specific parts, yes.
>>> If there are some App / Kodi specific things (like paths), we need to
>>> add some way to configure those build-time and/or runtime.
>>>
>>> > I believe that even VLC could play full disks on Android too.
>>>
>>> Depends on the device. This requires some kind of keyboard or remote
>>> controller (BD-J can't be used with touch screen). In "normal" phone or
>>> tablet the user would be stuck in the first BD-J menu.
>>> So we need some kind of virtual remote controller for those devices.
>>> Either on-screen "keypad", or translating gestures to key events.
>>>
>>> (almost all HDMV menus should be usable with touch screen / mouse).
>>>
>>>
>>> ___
>>> libbluray-devel mailing list
>>> libbluray-devel@videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
FIXED IT:
case BD_EVENT_STILL_TIME:
/* {
if (m_dvd.state != DVDSTATE_STILL)
{
// else notify the player we have received a still frame
m_dvd.iDVDStillTime = *static_cast(pData);
m_dvd.iDVDStillStartTime = XbmcThreads::SystemClockMillis();
if (m_dvd.iDVDStillTime != 0)
m_dvd.iDVDStillTime *= 1000;
/* adjust for the output delay in the video queue
unsigned int time = 0;
if (m_CurrentVideo.stream && m_dvd.iDVDStillTime > 0)
{
time = (unsigned int)(m_VideoPlayerVideo->GetOutputDelay() /
(DVD_TIME_BASE / 1000));
if (time < 1 && time > 0)
m_dvd.iDVDStillTime += time;
}
m_dvd.state = DVDSTATE_STILL;
CLog::Log(LOGDEBUG, "BD_EVENT_STILL_TIME - waiting %i sec, with
delay of %d sec",
m_dvd.iDVDStillTime, time / 1000);
}
}*/
I had to comment this and now video plays fine.
But... for some reason.. the menu isn't rendered in HDR.
On Sun, Jan 31, 2021 at 12:58 PM Vitor Dall'Acqua wrote:
> I think the other changes I did are not needed if you preload the
> libraries (those were required to get it loaded in Ubuntu / x86_64).
>
> the only library I'm preloading is libnet.so that is used by libnio.so, or
> else it says it's not possible to find it.
> I'm not using that snip you made to preload every lib and it's working.
>
> Just to let you know.
>
> On Sun, Jan 31, 2021 at 12:50 PM Petri Hintukainen <
> phint...@users.sourceforge.net> wrote:
>
>> la, 2021-01-30 kello 14:27 -0300, Vitor Dall'Acqua kirjoitti:
>> > Also, Petri, do you think you could share the changes you made
>> > on JRE to allow it to run without JAVA_HOME?
>>
>> Attached.
>>
>> Source tree was from:
>> git clone --depth 1
>> https://github.com/PojavLauncherTeam/openjdk-aarch64-jdk8u openjdk
>>
>> I think the other changes I did are not needed if you preload the
>> libraries (those were required to get it loaded in Ubuntu / x86_64).
>>
>> Preloading is weird and quite hacky. And those libraries are never
>> closed. I don't know if it belongs to libbluray. Maybe if it was just
>> one, consistent library. But definetely not blindly all libraries in
>> lib/ folder.
>>
>> If JVM doesn't find the libraries, it cold be fixable with -
>> Djava.library.path (or simliar) or LD_LIBRARY_PATH. If JVM doesn't try
>> loading those, it is bug in java files.
>>
>> If we can't get it loading properly, preloading could be done in Kodi
>> or in libjvm.so wrapper library. It is specific to this one JVM and/or
>> configuration.
>>
>> > And did you create a make file to compile it? Or did it by hand?
>>
>> There are build scripts in
>> https://github.com/PojavLauncherTeam/android-openjdk-build-multiarch.git
>>
>> > And finally, the changes needed on libbluray are just a few lines of
>> > code on bdj.c.
>> > Do you think a #ifdef android would be a good idea?
>>
>> For generic, android specific parts, yes.
>> If there are some App / Kodi specific things (like paths), we need to
>> add some way to configure those build-time and/or runtime.
>>
>> > I believe that even VLC could play full disks on Android too.
>>
>> Depends on the device. This requires some kind of keyboard or remote
>> controller (BD-J can't be used with touch screen). In "normal" phone or
>> tablet the user would be stuck in the first BD-J menu.
>> So we need some kind of virtual remote controller for those devices.
>> Either on-screen "keypad", or translating gestures to key events.
>>
>> (almost all HDMV menus should be usable with touch screen / mouse).
>>
>>
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
I think the other changes I did are not needed if you preload the libraries (those were required to get it loaded in Ubuntu / x86_64). the only library I'm preloading is libnet.so that is used by libnio.so, or else it says it's not possible to find it. I'm not using that snip you made to preload every lib and it's working. Just to let you know. On Sun, Jan 31, 2021 at 12:50 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > la, 2021-01-30 kello 14:27 -0300, Vitor Dall'Acqua kirjoitti: > > Also, Petri, do you think you could share the changes you made > > on JRE to allow it to run without JAVA_HOME? > > Attached. > > Source tree was from: > git clone --depth 1 > https://github.com/PojavLauncherTeam/openjdk-aarch64-jdk8u openjdk > > I think the other changes I did are not needed if you preload the > libraries (those were required to get it loaded in Ubuntu / x86_64). > > Preloading is weird and quite hacky. And those libraries are never > closed. I don't know if it belongs to libbluray. Maybe if it was just > one, consistent library. But definetely not blindly all libraries in > lib/ folder. > > If JVM doesn't find the libraries, it cold be fixable with - > Djava.library.path (or simliar) or LD_LIBRARY_PATH. If JVM doesn't try > loading those, it is bug in java files. > > If we can't get it loading properly, preloading could be done in Kodi > or in libjvm.so wrapper library. It is specific to this one JVM and/or > configuration. > > > And did you create a make file to compile it? Or did it by hand? > > There are build scripts in > https://github.com/PojavLauncherTeam/android-openjdk-build-multiarch.git > > > And finally, the changes needed on libbluray are just a few lines of > > code on bdj.c. > > Do you think a #ifdef android would be a good idea? > > For generic, android specific parts, yes. > If there are some App / Kodi specific things (like paths), we need to > add some way to configure those build-time and/or runtime. > > > I believe that even VLC could play full disks on Android too. > > Depends on the device. This requires some kind of keyboard or remote > controller (BD-J can't be used with touch screen). In "normal" phone or > tablet the user would be stuck in the first BD-J menu. > So we need some kind of virtual remote controller for those devices. > Either on-screen "keypad", or translating gestures to key events. > > (almost all HDMV menus should be usable with touch screen / mouse). > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
la, 2021-01-30 kello 14:27 -0300, Vitor Dall'Acqua kirjoitti:
> Also, Petri, do you think you could share the changes you made
> on JRE to allow it to run without JAVA_HOME?
Attached.
Source tree was from:
git clone --depth 1
https://github.com/PojavLauncherTeam/openjdk-aarch64-jdk8u openjdk
I think the other changes I did are not needed if you preload the
libraries (those were required to get it loaded in Ubuntu / x86_64).
Preloading is weird and quite hacky. And those libraries are never
closed. I don't know if it belongs to libbluray. Maybe if it was just
one, consistent library. But definetely not blindly all libraries in
lib/ folder.
If JVM doesn't find the libraries, it cold be fixable with -
Djava.library.path (or simliar) or LD_LIBRARY_PATH. If JVM doesn't try
loading those, it is bug in java files.
If we can't get it loading properly, preloading could be done in Kodi
or in libjvm.so wrapper library. It is specific to this one JVM and/or
configuration.
> And did you create a make file to compile it? Or did it by hand?
There are build scripts in
https://github.com/PojavLauncherTeam/android-openjdk-build-multiarch.git
> And finally, the changes needed on libbluray are just a few lines of
> code on bdj.c.
> Do you think a #ifdef android would be a good idea?
For generic, android specific parts, yes.
If there are some App / Kodi specific things (like paths), we need to
add some way to configure those build-time and/or runtime.
> I believe that even VLC could play full disks on Android too.
Depends on the device. This requires some kind of keyboard or remote
controller (BD-J can't be used with touch screen). In "normal" phone or
tablet the user would be stuck in the first BD-J menu.
So we need some kind of virtual remote controller for those devices.
Either on-screen "keypad", or translating gestures to key events.
(almost all HDMV menus should be usable with touch screen / mouse).
diff --git a/hotspot/src/os/linux/vm/os_linux.cpp b/hotspot/src/os/linux/vm/os_linux.cpp
index eff6253e..6379e315 100644
--- a/hotspot/src/os/linux/vm/os_linux.cpp
+++ b/hotspot/src/os/linux/vm/os_linux.cpp
@@ -2452,8 +2452,8 @@ void os::jvm_path(char *buf, jint buflen) {
dli_fname, sizeof(dli_fname), NULL);
assert(ret, "cannot locate libjvm");
#ifdef __ANDROID__
- char* java_home_var = ::getenv("JAVA_HOME");
- if (java_home_var == NULL || dli_fname[0] == '\0') {
+ //char* java_home_var = ::getenv("JAVA_HOME");
+ if (/*java_home_var == NULL ||*/ dli_fname[0] == '\0') {
return;
}
snprintf(buf, buflen, /* "%s/lib/%s/server/%s", java_home_var, cpu_arch, */ dli_fname);
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
And... what exactly is the extradata? I can log it if I understand what it is. I mean, should I log it with %s? I'm waiting for a stream? a number? On Sun, Jan 31, 2021 at 12:22 PM Vitor Dall'Acqua wrote: > I notice the extradata byte missing but that's not the case, I believe, > because > 1. it's a different file (couldn't get Kodi to load the playlist for the > background menu video) > 2. I see that this value changes from video to video. > > Now that I got it to actually request the configure method to the decoder > this is the output from the logcat: > > 01-31 12:52:05.099 2467 2814 I OMXClient: IOmx service obtained > 01-31 12:52:05.099 19053 19062 I OMXMaster: > makeComponentInstance(OMX.Nvidia.h265.encoder) in omx@1.0-service process > 01-31 12:52:05.133 3365 3365 D SurfaceFlinger: duplicate layer name: > changing SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main to > SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main#1 > 01-31 12:52:05.134 3365 3365 D SurfaceFlinger: duplicate layer name: > changing Background for -SurfaceView - > org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main to Background for -SurfaceView - > org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main#1 > 01-31 12:52:05.167 2467 2467 D XBMCVideoPlayView: Created > 01-31 12:52:05.167 2467 2467 D XBMCVideoPlayView: Changed, format:-2, > width:1920, height:1080 > 01-31 12:52:05.168 2467 2654 D Kodi: 2021-01-31 12:52:05.168 T:2654 >DEBUG : CDVDVideoCodecAndroidMediaCodec::InjectExtraData > 01-31 12:52:05.168 2467 2654 D XBMCVideoPlayView: getSurface() = > Surface(name=null)/@0x2c84213 > 01-31 12:52:05.171 2467 2813 D SurfaceUtils: connecting to surface > 0x294e2f9010, reason connectToSurface > 01-31 12:52:05.171 2467 2813 I MediaCodec: [OMX.Nvidia.h265.encoder] > setting surface generation to 2526213 > 01-31 12:52:05.171 2467 2813 D SurfaceUtils: disconnecting from surface > 0x294e2f9010, reason connectToSurface(reconnect) > 01-31 12:52:05.172 2467 2813 D SurfaceUtils: connecting to surface > 0x294e2f9010, reason connectToSurface(reconnect) > 01-31 12:52:05.172 19053 19062 E OMXNodeInstance: > setParameter(0x46927a80:Nvidia.h265.encoder, > ParamStandardComponentRole(0x117)) ERROR: UnsupportedSetting(0x80001019) > 01-31 12:52:05.173 2467 2814 W ACodec : [OMX.Nvidia.h265.encoder] > Failed to set standard component role 'video_decoder.hevc'. > 01-31 12:52:05.173 2467 2814 E ACodec : [OMX.Nvidia.h265.encoder] > configureCodec returning error -1010 > 01-31 12:52:05.173 2467 2814 E ACodec : signalError(omxError > 0x80001001, internalError -1010) > 01-31 12:52:05.173 2467 2813 E MediaCodec: Codec reported err > 0xfc0e, actionCode 0, while in state 3 > 01-31 12:52:05.173 2467 2813 D SurfaceUtils: disconnecting from surface > 0x294e2f9010, reason disconnectFromSurface > 01-31 12:52:05.173 2467 2654 E MediaCodec: configure failed with err > 0xfc0e, resetting... > 01-31 12:52:05.176 2467 2814 I OMXClient: IOmx service obtained > 01-31 12:52:05.176 19053 19062 I OMXMaster: > makeComponentInstance(OMX.Nvidia.h265.encoder) in omx@1.0-service process > 01-31 12:52:05.178 2467 2654 E Kodi: 2021-01-31 12:52:05.178 T:2654 >ERROR : CDVDVideoCodecAndroidMediaCodec::ConfigureMediaCodec: > configure failed > > android works as a blackbox so send to the decoder, and the decoder will > play. > > On Sun, Jan 31, 2021 at 12:14 PM Petri Hintukainen < > phint...@users.sourceforge.net> wrote: > >> su, 2021-01-31 kello 11:06 -0300, Vitor Dall'Acqua kirjoitti: >> > Already tested your latest commits, Petri. Much faster and the logs >> > are much cleaner. Thank you. >> >> I wrote those changes long time ago, but I didn't notice any measurable >> speedup (not even when playing .iso over SMB). I guess the difference >> is you're not using mounted filesystem, so you don't have any OS level >> caching. >> >> > I'm still working my way with the hardware rendering. >> > Sadly I can't debug this on windows with visual studio, >> > bitstreamconverter isn't used neither androidmediacodec obviously. >> > So, I'm back at changing things with a notepad, compiling and >> > testing. >> > >> > >> > Here is a log of how the m2ts stream played from a playlist should >> > work: >> > 2021-01-31 10:45:20.913 T:19521 DEBUG : >> > CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x Height >> > 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile >> > 2, PTS_invalid 0, Tag 1447904328, Extradata-Size: 115 >> > 2021-01-31 10:45:20.913 T:19521INFO : >> > CBitstreamConverter::Open Invalid hvcC >> > 2021-01-31 10:45:20.913 T:19521INFO : >> > CDVDVideoCodecAndroidMediaCodec::Open Testing >> > codec:OMX.Nvidia.mp2.decoder >> > 2021-01-31 10:45:20.917 T:13323INFO : [WHITELIST] >> > Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, >> > 3D: false >> > 2021-01-31 10:45:20.917 T:13323 DEBUG : [WHITELIST] Using >> > the default whitelist because the user whitelist is empty >> >
Re: [libbluray-devel] JRE for Android part 3
I notice the extradata byte missing but that's not the case, I believe, because 1. it's a different file (couldn't get Kodi to load the playlist for the background menu video) 2. I see that this value changes from video to video. Now that I got it to actually request the configure method to the decoder this is the output from the logcat: 01-31 12:52:05.099 2467 2814 I OMXClient: IOmx service obtained 01-31 12:52:05.099 19053 19062 I OMXMaster: makeComponentInstance(OMX.Nvidia.h265.encoder) in omx@1.0-service process 01-31 12:52:05.133 3365 3365 D SurfaceFlinger: duplicate layer name: changing SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main to SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main#1 01-31 12:52:05.134 3365 3365 D SurfaceFlinger: duplicate layer name: changing Background for -SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main to Background for -SurfaceView - org.xbmc.kodi19DV/org.xbmc.kodi19DV.Main#1 01-31 12:52:05.167 2467 2467 D XBMCVideoPlayView: Created 01-31 12:52:05.167 2467 2467 D XBMCVideoPlayView: Changed, format:-2, width:1920, height:1080 01-31 12:52:05.168 2467 2654 D Kodi: 2021-01-31 12:52:05.168 T:2654 DEBUG : CDVDVideoCodecAndroidMediaCodec::InjectExtraData 01-31 12:52:05.168 2467 2654 D XBMCVideoPlayView: getSurface() = Surface(name=null)/@0x2c84213 01-31 12:52:05.171 2467 2813 D SurfaceUtils: connecting to surface 0x294e2f9010, reason connectToSurface 01-31 12:52:05.171 2467 2813 I MediaCodec: [OMX.Nvidia.h265.encoder] setting surface generation to 2526213 01-31 12:52:05.171 2467 2813 D SurfaceUtils: disconnecting from surface 0x294e2f9010, reason connectToSurface(reconnect) 01-31 12:52:05.172 2467 2813 D SurfaceUtils: connecting to surface 0x294e2f9010, reason connectToSurface(reconnect) 01-31 12:52:05.172 19053 19062 E OMXNodeInstance: setParameter(0x46927a80:Nvidia.h265.encoder, ParamStandardComponentRole(0x117)) ERROR: UnsupportedSetting(0x80001019) 01-31 12:52:05.173 2467 2814 W ACodec : [OMX.Nvidia.h265.encoder] Failed to set standard component role 'video_decoder.hevc'. 01-31 12:52:05.173 2467 2814 E ACodec : [OMX.Nvidia.h265.encoder] configureCodec returning error -1010 01-31 12:52:05.173 2467 2814 E ACodec : signalError(omxError 0x80001001, internalError -1010) 01-31 12:52:05.173 2467 2813 E MediaCodec: Codec reported err 0xfc0e, actionCode 0, while in state 3 01-31 12:52:05.173 2467 2813 D SurfaceUtils: disconnecting from surface 0x294e2f9010, reason disconnectFromSurface 01-31 12:52:05.173 2467 2654 E MediaCodec: configure failed with err 0xfc0e, resetting... 01-31 12:52:05.176 2467 2814 I OMXClient: IOmx service obtained 01-31 12:52:05.176 19053 19062 I OMXMaster: makeComponentInstance(OMX.Nvidia.h265.encoder) in omx@1.0-service process 01-31 12:52:05.178 2467 2654 E Kodi: 2021-01-31 12:52:05.178 T:2654 ERROR : CDVDVideoCodecAndroidMediaCodec::ConfigureMediaCodec: configure failed android works as a blackbox so send to the decoder, and the decoder will play. On Sun, Jan 31, 2021 at 12:14 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > su, 2021-01-31 kello 11:06 -0300, Vitor Dall'Acqua kirjoitti: > > Already tested your latest commits, Petri. Much faster and the logs > > are much cleaner. Thank you. > > I wrote those changes long time ago, but I didn't notice any measurable > speedup (not even when playing .iso over SMB). I guess the difference > is you're not using mounted filesystem, so you don't have any OS level > caching. > > > I'm still working my way with the hardware rendering. > > Sadly I can't debug this on windows with visual studio, > > bitstreamconverter isn't used neither androidmediacodec obviously. > > So, I'm back at changing things with a notepad, compiling and > > testing. > > > > > > Here is a log of how the m2ts stream played from a playlist should > > work: > > 2021-01-31 10:45:20.913 T:19521 DEBUG : > > CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x Height > > 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile > > 2, PTS_invalid 0, Tag 1447904328, Extradata-Size: 115 > > 2021-01-31 10:45:20.913 T:19521INFO : > > CBitstreamConverter::Open Invalid hvcC > > 2021-01-31 10:45:20.913 T:19521INFO : > > CDVDVideoCodecAndroidMediaCodec::Open Testing > > codec:OMX.Nvidia.mp2.decoder > > 2021-01-31 10:45:20.917 T:13323INFO : [WHITELIST] > > Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, > > 3D: false > > 2021-01-31 10:45:20.917 T:13323 DEBUG : [WHITELIST] Using > > the default whitelist because the user whitelist is empty > > 2021-01-31 10:45:20.919 T:13323 DEBUG : [WHITELIST] > > Searching for an exact resolution with an exact refresh rate > > 2021-01-31 10:45:20.920 T:13323 DEBUG : [WHITELIST] > > Matched an exact resolution with an exact refresh rate 3840x2160 @ > > 23.976025 - Full Screen (27) > > 2021-01-31 10:45:20.920 T:13323INFO : Display resolution > > ADJUST : 3840x2160 @
Re: [libbluray-devel] JRE for Android part 3
su, 2021-01-31 kello 11:06 -0300, Vitor Dall'Acqua kirjoitti: > Already tested your latest commits, Petri. Much faster and the logs > are much cleaner. Thank you. I wrote those changes long time ago, but I didn't notice any measurable speedup (not even when playing .iso over SMB). I guess the difference is you're not using mounted filesystem, so you don't have any OS level caching. > I'm still working my way with the hardware rendering. > Sadly I can't debug this on windows with visual studio, > bitstreamconverter isn't used neither androidmediacodec obviously. > So, I'm back at changing things with a notepad, compiling and > testing. > > > Here is a log of how the m2ts stream played from a playlist should > work: > 2021-01-31 10:45:20.913 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x Height > 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile > 2, PTS_invalid 0, Tag 1447904328, Extradata-Size: 115 > 2021-01-31 10:45:20.913 T:19521 INFO : > CBitstreamConverter::Open Invalid hvcC > 2021-01-31 10:45:20.913 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.mp2.decoder > 2021-01-31 10:45:20.917 T:13323 INFO : [WHITELIST] > Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, > 3D: false > 2021-01-31 10:45:20.917 T:13323 DEBUG : [WHITELIST] Using > the default whitelist because the user whitelist is empty > 2021-01-31 10:45:20.919 T:13323 DEBUG : [WHITELIST] > Searching for an exact resolution with an exact refresh rate > 2021-01-31 10:45:20.920 T:13323 DEBUG : [WHITELIST] > Matched an exact resolution with an exact refresh rate 3840x2160 @ > 23.976025 - Full Screen (27) > 2021-01-31 10:45:20.920 T:13323 INFO : Display resolution > ADJUST : 3840x2160 @ 23.976025 - Full Screen (27) (weight: 0.000) > 2021-01-31 10:45:20.924 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.wma.decoder > 2021-01-31 10:45:20.924 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.h264.decode > 2021-01-31 10:45:20.925 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.DOVI.decode > 2021-01-31 10:45:20.925 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.h263.decode > 2021-01-31 10:45:20.926 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec::Open Testing > codec:OMX.Nvidia.h265.decode > 2021-01-31 10:45:20.927 T:13332 DEBUG : Could not acquire > timestamp > 2021-01-31 10:45:21.073 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec::Open > m_codecname(OMX.Nvidia.h265.decode), colorFormat(2135033992) > 2021-01-31 10:45:21.073 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec::Open > m_codecname(OMX.Nvidia.h265.decode), colorFormat(21) > 2021-01-31 10:45:21.163 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec::InjectExtraData > 2021-01-31 10:45:21.220 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec:: width(3840), height(2160), > stride(0), slice-height(0), color-format(0) > 2021-01-31 10:45:21.220 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec:: crop-left(0), crop-top(0), crop- > right(3839), crop-bottom(2159) > 2021-01-31 10:45:21.220 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec:: Multi-Surface Rendering > 2021-01-31 10:45:21.220 T:19521 INFO : > CDVDVideoCodecAndroidMediaCodec:: Open Android MediaCodec > OMX.Nvidia.h265.decode > 2021-01-31 10:45:21.220 T:19521 DEBUG : > CDVDVideoCodecAndroidMediaCodec::UpdateFpsDuration fpsRate:24000 > fpsscale:1001, fpsDur:41708 > 2021-01-31 10:45:21.221 T:19521 DEBUG : > CVideoPlayerVideo::OpenStream - open stream with codec id: 173 > > and this is how it works during a menu: > > > 2021-01-31 10:33:58.032 T:13409 INFO : > ffmpeg[0x2965bbd040X]: Duration: N/A, start: 600.00, bitrate: > N/A > 2021-01-31 10:33:58.032 T:13409 INFO : > ffmpeg[0x2965bbd040X]: Program 1 > 2021-01-31 10:33:58.033 T:13409 INFO : > ffmpeg[0x2965bbd040X]: Stream #0:0[0x1011]: Video: hevc (Main 10) > (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), > 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 > tbc > 2021-01-31 10:33:58.033 T:13409 DEBUG : > CDVDDemuxFFmpeg::AddStream ID: 0 > 2021-01-31 10:33:58.033 T:13409 INFO : Opening stream: 0 > source: 256 > 2021-01-31 10:33:58.033 T:13409 INFO : [WHITELIST] > Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, > 3D: false > 2021-01-31 10:33:58.033 T:13409 DEBUG : [WHITELIST] Using > the default whitelist because the user whitelist is empty > 2021-01-31 10:33:58.034 T:13409 DEBUG : [WHITELIST] > Searching for an exact resolution with an exact refresh rate > 2021-01-31 10:33:58.034 T:13409 DEBUG : [WHITELIST] > Matched an exact resolution with an exact refresh rate 3840x2160 @ > 23.976025 - Full Screen (27) > 2021-01-31 10:33:58.034 T:13409 INFO : Display resolution > ADJUST : 3840x2160 @ 23.976025 -
Re: [libbluray-devel] JRE for Android part 3
Ok, a little bit more or progress: commenting this: //if (codec_info.isEncoder()) // continue; and this // if (!CServiceBroker::GetDecoderFilterManager()->isValid(m_codecname, m_hints)) // continue; now I'm at: 2021-01-31 12:09:44.920 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.aac.decoder 2021-01-31 12:09:44.920 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.amrnb.decoder 2021-01-31 12:09:44.921 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.amrwb.decoder 2021-01-31 12:09:44.921 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.flac.decoder 2021-01-31 12:09:44.921 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.g711.alaw.decoder 2021-01-31 12:09:44.922 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.g711.mlaw.decoder 2021-01-31 12:09:44.922 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.mp2.decoder 2021-01-31 12:09:44.922 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.mp3.decoder 2021-01-31 12:09:44.923 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.opus.decoder 2021-01-31 12:09:44.923 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.raw.decoder 2021-01-31 12:09:44.923 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.vorbis.decoder 2021-01-31 12:09:44.923 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.wma.decoder 2021-01-31 12:09:44.924 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.aac.encoder 2021-01-31 12:09:44.924 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.amrnb.encoder 2021-01-31 12:09:44.924 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.amrwb.encoder 2021-01-31 12:09:44.924 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.google.flac.encoder 2021-01-31 12:09:44.924 T:31447INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.h265.encoder 2021-01-31 12:09:44.925 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::TRUE IS 1 <--- this is a marker I made. 2021-01-31 12:09:44.923 T:31323INFO : [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, 3D: false 2021-01-31 12:09:44.927 T:31323 DEBUG : [WHITELIST] Using the default whitelist because the user whitelist is empty 2021-01-31 12:09:44.928 T:31323 DEBUG : [WHITELIST] Searching for an exact resolution with an exact refresh rate 2021-01-31 12:09:44.928 T:31323 DEBUG : [WHITELIST] Matched an exact resolution with an exact refresh rate 3840x2160 @ 23.976025 - Full Screen (27) 2021-01-31 12:09:44.928 T:31323INFO : Display resolution ADJUST : 3840x2160 @ 23.976025 - Full Screen (27) (weight: 0.000) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2135033992) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(19) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(21) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2130708361) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435328) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435329) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435330) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435331) 2021-01-31 12:09:44.952 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435332) 2021-01-31 12:09:44.953 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.encoder), colorFormat(2146435333) 2021-01-31 12:09:45.043 T:31447 DEBUG : CDVDVideoCodecAndroidMediaCodec::InjectExtraData 2021-01-31 12:09:45.055 T:31447 ERROR : CDVDVideoCodecAndroidMediaCodec::ConfigureMediaCodec: configure failed 2021-01-31 12:09:45.056 T:31447INFO : CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency Video Coding) On Sun, Jan 31, 2021 at 11:06 AM Vitor Dall'Acqua wrote: > Already tested your latest commits, Petri. > Much faster and the logs are much cleaner. Thank you. > > I'm still working my way with the hardware rendering. > Sadly I can't debug this on windows with
Re: [libbluray-devel] JRE for Android part 3
Already tested your latest commits, Petri. Much faster and the logs are much cleaner. Thank you. I'm still working my way with the hardware rendering. Sadly I can't debug this on windows with visual studio, bitstreamconverter isn't used neither androidmediacodec obviously. So, I'm back at changing things with a notepad, compiling and testing. Here is a log of how the m2ts stream played from a playlist should work: 2021-01-31 10:45:20.913 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x Height 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile 2, PTS_invalid 0, Tag 1447904328, Extradata-Size: 115 2021-01-31 10:45:20.913 T:19521INFO : CBitstreamConverter::Open Invalid hvcC 2021-01-31 10:45:20.913 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.mp2.decoder 2021-01-31 10:45:20.917 T:13323INFO : [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, 3D: false 2021-01-31 10:45:20.917 T:13323 DEBUG : [WHITELIST] Using the default whitelist because the user whitelist is empty 2021-01-31 10:45:20.919 T:13323 DEBUG : [WHITELIST] Searching for an exact resolution with an exact refresh rate 2021-01-31 10:45:20.920 T:13323 DEBUG : [WHITELIST] Matched an exact resolution with an exact refresh rate 3840x2160 @ 23.976025 - Full Screen (27) 2021-01-31 10:45:20.920 T:13323INFO : Display resolution ADJUST : 3840x2160 @ 23.976025 - Full Screen (27) (weight: 0.000) 2021-01-31 10:45:20.924 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.wma.decoder 2021-01-31 10:45:20.924 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.h264.decode 2021-01-31 10:45:20.925 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.DOVI.decode 2021-01-31 10:45:20.925 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.h263.decode 2021-01-31 10:45:20.926 T:19521INFO : CDVDVideoCodecAndroidMediaCodec::Open Testing codec:OMX.Nvidia.h265.decode 2021-01-31 10:45:20.927 T:13332 DEBUG : Could not acquire timestamp 2021-01-31 10:45:21.073 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.decode), colorFormat(2135033992) 2021-01-31 10:45:21.073 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open m_codecname(OMX.Nvidia.h265.decode), colorFormat(21) 2021-01-31 10:45:21.163 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec::InjectExtraData 2021-01-31 10:45:21.220 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec:: width(3840), height(2160), stride(0), slice-height(0), color-format(0) 2021-01-31 10:45:21.220 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec:: crop-left(0), crop-top(0), crop-right(3839), crop-bottom(2159) 2021-01-31 10:45:21.220 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec:: Multi-Surface Rendering 2021-01-31 10:45:21.220 T:19521INFO : CDVDVideoCodecAndroidMediaCodec:: Open Android MediaCodec OMX.Nvidia.h265.decode 2021-01-31 10:45:21.220 T:19521 DEBUG : CDVDVideoCodecAndroidMediaCodec::UpdateFpsDuration fpsRate:24000 fpsscale:1001, fpsDur:41708 2021-01-31 10:45:21.221 T:19521 DEBUG : CVideoPlayerVideo::OpenStream - open stream with codec id: 173 and this is how it works during a menu: 2021-01-31 10:33:58.032 T:13409INFO : ffmpeg[0x2965bbd040X]: Duration: N/A, start: 600.00, bitrate: N/A 2021-01-31 10:33:58.032 T:13409INFO : ffmpeg[0x2965bbd040X]: Program 1 2021-01-31 10:33:58.033 T:13409INFO : ffmpeg[0x2965bbd040X]: Stream #0:0[0x1011]: Video: hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc 2021-01-31 10:33:58.033 T:13409 DEBUG : CDVDDemuxFFmpeg::AddStream ID: 0 2021-01-31 10:33:58.033 T:13409INFO : Opening stream: 0 source: 256 2021-01-31 10:33:58.033 T:13409INFO : [WHITELIST] Searching the whitelist for: width: 3840, height: 2160, fps: 23.976, 3D: false 2021-01-31 10:33:58.033 T:13409 DEBUG : [WHITELIST] Using the default whitelist because the user whitelist is empty 2021-01-31 10:33:58.034 T:13409 DEBUG : [WHITELIST] Searching for an exact resolution with an exact refresh rate 2021-01-31 10:33:58.034 T:13409 DEBUG : [WHITELIST] Matched an exact resolution with an exact refresh rate 3840x2160 @ 23.976025 - Full Screen (27) 2021-01-31 10:33:58.034 T:13409INFO : Display resolution ADJUST : 3840x2160 @ 23.976025 - Full Screen (27) (weight: 0.000) 2021-01-31 10:33:58.069 T:13409INFO : Creating video codec with codec id: 173 2021-01-31 10:33:58.071 T:13409 DEBUG : CDVDVideoCodecAndroidMediaCodec::Open hints: Width 3840 x Height 2160, Fpsrate 24000 / Fpsscale 1001, CodecID 173, Level 153, Profile 2, PTS_invalid 0, Tag 1447904328, Extradata-Size: 114 2021-01-31 10:33:58.071 T:13409INFO : CBitstreamConverter::Open Invalid hvcC 2021-01-31 10:33:58.073 T:13409 ERROR : CDVDVideoCodecAndroidMediaCodec::
Re: [libbluray-devel] JRE for Android part 3
You are right. That's why I asked for the source with Petri's changes. But they probably would want me to create the build process. And this is out of my league. I will try to convince somebody to take this showing as this works as expected. As you mentioned as a proof of concept. But for the moment, the JRE library can be installed as an addon, not support by Kodi. The only thing is that environment variables need to be set for it to work and libbluray needs 3 or 4 lines of code to work too. I once worked with my Kodi build, called Kodi HDR Edition. Since windows had no public api to turn hdr on and off and pass the metadata I had to use nvidia and amd private apis. This could not be part of Kodi. So i maintained it for more than a year and an unofficial build. The same is happening with Dolby Vision on android right now, until ffmpeg team decides to add support for mkv dolby vision we are doing it our way but it won't get merged into Kodi. And the same will happen to bluray menu playback. It will be a standalone build with standalone addon for people to use until it gets merged with Kodi as a binary addon. (I'll just use the same build that supports dolby vision) Not much different to the way vpeter does for CoreElec. You have to use his image of the OS for bluray menu support. On Sat, Jan 30, 2021, 2:45 PM Shaya Potter wrote: > On Sat, Jan 30, 2021 at 7:27 PM Vitor Dall'Acqua wrote: > >> This problem is true for every disc, regular or uhd. >> Since the shield is doing all the hard work with software rendering the >> entire menu becomes slow. >> But this isn't perceptible with the shield on 1080p because it has the >> power to render it and display the menu. >> >> Both cases you present might be the reason for that. >> >> But I would say that the missing ts packets have a higher chance of being >> the one. >> >> The good news is that I tried several regular blurays and everything >> plays just fine. >> >> This is probably the last step we have to work with, after that is just >> preparing for release. >> >> Also, Petri, do you think you could share the changes you made on JRE to >> allow it to run without JAVA_HOME? >> >> And did you create a make file to compile it? Or did it by hand? >> >> And finally, the changes needed on libbluray are just a few lines of code >> on bdj.c. >> Do you think a #ifdef android would be a good idea? >> >> I believe that even VLC could play full disks on Android too. >> > > if I had to guess, I think kodi would want more. They wouldn't want to > drop a prebuilt jvm into their tree, they would want their build process to > use jvm sources, perhaps apply a set of patches to it, and build the jvm as > part of the normal android build. Of course, I could be wrong. I think > the work that's been done in these threads is proof of concept to > demonstrate that it can work and its something kodi should support by > default as part of their "store" builds.. I'd think that it would be > constructive for you to loop in kodi's android developers to this > discussion. i.e. they might know intricacies of android that the rest of > us are missing. thoughts? > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Sat, Jan 30, 2021 at 7:27 PM Vitor Dall'Acqua wrote: > This problem is true for every disc, regular or uhd. > Since the shield is doing all the hard work with software rendering the > entire menu becomes slow. > But this isn't perceptible with the shield on 1080p because it has the > power to render it and display the menu. > > Both cases you present might be the reason for that. > > But I would say that the missing ts packets have a higher chance of being > the one. > > The good news is that I tried several regular blurays and everything plays > just fine. > > This is probably the last step we have to work with, after that is just > preparing for release. > > Also, Petri, do you think you could share the changes you made on JRE to > allow it to run without JAVA_HOME? > > And did you create a make file to compile it? Or did it by hand? > > And finally, the changes needed on libbluray are just a few lines of code > on bdj.c. > Do you think a #ifdef android would be a good idea? > > I believe that even VLC could play full disks on Android too. > if I had to guess, I think kodi would want more. They wouldn't want to drop a prebuilt jvm into their tree, they would want their build process to use jvm sources, perhaps apply a set of patches to it, and build the jvm as part of the normal android build. Of course, I could be wrong. I think the work that's been done in these threads is proof of concept to demonstrate that it can work and its something kodi should support by default as part of their "store" builds.. I'd think that it would be constructive for you to loop in kodi's android developers to this discussion. i.e. they might know intricacies of android that the rest of us are missing. thoughts? ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
This problem is true for every disc, regular or uhd. Since the shield is doing all the hard work with software rendering the entire menu becomes slow. But this isn't perceptible with the shield on 1080p because it has the power to render it and display the menu. Both cases you present might be the reason for that. But I would say that the missing ts packets have a higher chance of being the one. The good news is that I tried several regular blurays and everything plays just fine. This is probably the last step we have to work with, after that is just preparing for release. Also, Petri, do you think you could share the changes you made on JRE to allow it to run without JAVA_HOME? And did you create a make file to compile it? Or did it by hand? And finally, the changes needed on libbluray are just a few lines of code on bdj.c. Do you think a #ifdef android would be a good idea? I believe that even VLC could play full disks on Android too. On Sat, Jan 30, 2021, 1:58 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > la, 2021-01-30 kello 18:27 +0200, Shaya Potter kirjoitti: > > On Sat, Jan 30, 2021 at 12:14 AM Vitor Dall'Acqua > > wrote: > > > Nailed it > > > 2021-01-29 20:07:07.860 T:13984INFO : > > > CBitstreamConverter::Open Invalid hvcC > > > 2021-01-29 20:07:07.862 T:13984 ERROR : > > > CDVDVideoCodecAndroidMediaCodec:: Failed to create Android > > > MediaCodec > > > 2021-01-29 20:07:07.863 T:13984INFO : > > > CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency > > > Video Coding) > > > > > > > have you tried it without the jvm and does it initiate the hardware > > cosdec correctly? and therefore play the uhd fine? (i.e. by using > > kodi just to select a title/playlist) > > Yes, could check that too (or even playing directly the problematic > .m2ts file). I remember there was an issue where few first ts packets > were skipped. That could cause issues while initializing HW codec ? > > > the fact that it works well with regular blurays, but not UHD, makes > > me wonder if kodi is initiating the hevc hardware codec incorrectly > > for the UHD bluray or if the hevc codec doesn't support a mode it > > needs if its going to have to "draw over" the screen, while the AVC > > codec does. Dont know anything about android and built in codecs and > > their capabilities, so just thinking out loud about what could be the > > differences. > > Maybe HW codec is disabled intentionally ? Vitor, you mentioned > something about DVD menus earlier. Could it be HW decoding in menus is > disabled because of DVD/MPEG2 still images ? > BluRay menus usually use background video, so this is not needed. Those > few that use still images should be easy to detect from playlist > metadata. > ___ > > libbluray-devel mailing list > > libbluray-devel@videolan.org > > https://mailman.videolan.org/listinfo/libbluray-devel > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
la, 2021-01-30 kello 18:27 +0200, Shaya Potter kirjoitti: > On Sat, Jan 30, 2021 at 12:14 AM Vitor Dall'Acqua > wrote: > > Nailed it > > 2021-01-29 20:07:07.860 T:13984 INFO : > > CBitstreamConverter::Open Invalid hvcC > > 2021-01-29 20:07:07.862 T:13984 ERROR : > > CDVDVideoCodecAndroidMediaCodec:: Failed to create Android > > MediaCodec > > 2021-01-29 20:07:07.863 T:13984 INFO : > > CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency > > Video Coding) > > > > have you tried it without the jvm and does it initiate the hardware > cosdec correctly? and therefore play the uhd fine? (i.e. by using > kodi just to select a title/playlist) Yes, could check that too (or even playing directly the problematic .m2ts file). I remember there was an issue where few first ts packets were skipped. That could cause issues while initializing HW codec ? > the fact that it works well with regular blurays, but not UHD, makes > me wonder if kodi is initiating the hevc hardware codec incorrectly > for the UHD bluray or if the hevc codec doesn't support a mode it > needs if its going to have to "draw over" the screen, while the AVC > codec does. Dont know anything about android and built in codecs and > their capabilities, so just thinking out loud about what could be the > differences. Maybe HW codec is disabled intentionally ? Vitor, you mentioned something about DVD menus earlier. Could it be HW decoding in menus is disabled because of DVD/MPEG2 still images ? BluRay menus usually use background video, so this is not needed. Those few that use still images should be easy to detect from playlist metadata. ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
If you play the m2ts (the one from the background video) alone it will play fine. It fails for 1080p and 4k streams if inside a menu. Fails because of extradata. I have compiled Kodi on windows with libbluray and I'll have to debug this with breakpoints to figure out what is the value of the extradata that is being sent. The fail is here: https://github.com/xbmc/xbmc/blob/5230b683323ca58c62459a371c1306a6cb4d4644/xbmc/utils/BitstreamConverter.cpp For 4k it fails at line 444 (invalid hvcc). For 1080p it fails with the log on line 357 (invalid avcc) On Sat, Jan 30, 2021, 1:27 PM Shaya Potter wrote: > On Sat, Jan 30, 2021 at 12:14 AM Vitor Dall'Acqua > wrote: > >> Nailed it >> >> 2021-01-29 20:07:07.860 T:13984INFO : >> CBitstreamConverter::Open Invalid hvcC >> 2021-01-29 20:07:07.862 T:13984 ERROR : >> CDVDVideoCodecAndroidMediaCodec:: Failed to create Android MediaCodec >> 2021-01-29 20:07:07.863 T:13984INFO : >> CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency Video >> Coding) >> > > have you tried it without the jvm and does it initiate the hardware cosdec > correctly? and therefore play the uhd fine? (i.e. by using kodi just to > select a title/playlist) > > the fact that it works well with regular blurays, but not UHD, makes me > wonder if kodi is initiating the hevc hardware codec incorrectly for the > UHD bluray or if the hevc codec doesn't support a mode it needs if its > going to have to "draw over" the screen, while the AVC codec does. Dont > know anything about android and built in codecs and their capabilities, so > just thinking out loud about what could be the differences. > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Sat, Jan 30, 2021 at 12:14 AM Vitor Dall'Acqua wrote: > Nailed it > > 2021-01-29 20:07:07.860 T:13984INFO : > CBitstreamConverter::Open Invalid hvcC > 2021-01-29 20:07:07.862 T:13984 ERROR : > CDVDVideoCodecAndroidMediaCodec:: Failed to create Android MediaCodec > 2021-01-29 20:07:07.863 T:13984INFO : > CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency Video > Coding) > have you tried it without the jvm and does it initiate the hardware cosdec correctly? and therefore play the uhd fine? (i.e. by using kodi just to select a title/playlist) the fact that it works well with regular blurays, but not UHD, makes me wonder if kodi is initiating the hevc hardware codec incorrectly for the UHD bluray or if the hevc codec doesn't support a mode it needs if its going to have to "draw over" the screen, while the AVC codec does. Dont know anything about android and built in codecs and their capabilities, so just thinking out loud about what could be the differences. ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Nailed it 2021-01-29 20:07:07.860 T:13984INFO : CBitstreamConverter::Open Invalid hvcC 2021-01-29 20:07:07.862 T:13984 ERROR : CDVDVideoCodecAndroidMediaCodec:: Failed to create Android MediaCodec 2021-01-29 20:07:07.863 T:13984INFO : CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency Video Coding) On Fri, Jan 29, 2021 at 7:03 PM Vitor Dall'Acqua wrote: > Extracted or not makes no difference. > > The problem is that the shield is powerful enough to play a 1080p stream > as software but it is not to play a 4k hdr stream without hardware > acceleration. > > Disabled hardware acceleration in Kodi and the result during the movie is > the same as the menu. > > On Fri, Jan 29, 2021, 6:56 PM Vitor Dall'Acqua wrote: > >> Regular bluray is fine. Extracted or ISO. >> >> 4k bluray seems to be the problem. >> Tested iso only for far. >> >> >> >> On Fri, Jan 29, 2021, 6:29 PM Vitor Dall'Acqua wrote: >> >>> I'm doing some extensive testing so I need some more time. >>> >>> I want to test the same movie as iso and extracted to check if the >>> archive support addon on Kodi might be the problem. >>> >>> The popup, when the movie is already running makes no difference, I can >>> say that. >>> >>> But there are some movies that when open the top menu and start the >>> movie doesn't change the state (top menu - movie playing) and this caused >>> the main movie to run really slow. >>> >>> Another test HDMV disc extracted plays just fine. >>> >>> Now I'm waiting for 3:10 to Yuma to extract. >>> >>> And I have an event to attend to, so I'll do my best today but probably >>> I'll have more info tomorrow. >>> >>> >>> On Fri, Jan 29, 2021, 6:02 PM Petri Hintukainen < >>> phint...@users.sourceforge.net> wrote: >>> pe, 2021-01-29 kello 16:33 -0300, Vitor Dall'Acqua kirjoitti: > Now that you mention it, a few days ago I tested a HDMV disc and the > background video played just fine. I'll test again and check. While testing, you could also check if keeping pop-up menu open during plaback makes any difference. ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel >>> ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Extracted or not makes no difference. The problem is that the shield is powerful enough to play a 1080p stream as software but it is not to play a 4k hdr stream without hardware acceleration. Disabled hardware acceleration in Kodi and the result during the movie is the same as the menu. On Fri, Jan 29, 2021, 6:56 PM Vitor Dall'Acqua wrote: > Regular bluray is fine. Extracted or ISO. > > 4k bluray seems to be the problem. > Tested iso only for far. > > > > On Fri, Jan 29, 2021, 6:29 PM Vitor Dall'Acqua wrote: > >> I'm doing some extensive testing so I need some more time. >> >> I want to test the same movie as iso and extracted to check if the >> archive support addon on Kodi might be the problem. >> >> The popup, when the movie is already running makes no difference, I can >> say that. >> >> But there are some movies that when open the top menu and start the movie >> doesn't change the state (top menu - movie playing) and this caused the >> main movie to run really slow. >> >> Another test HDMV disc extracted plays just fine. >> >> Now I'm waiting for 3:10 to Yuma to extract. >> >> And I have an event to attend to, so I'll do my best today but probably >> I'll have more info tomorrow. >> >> >> On Fri, Jan 29, 2021, 6:02 PM Petri Hintukainen < >> phint...@users.sourceforge.net> wrote: >> >>> pe, 2021-01-29 kello 16:33 -0300, Vitor Dall'Acqua kirjoitti: >>> > Now that you mention it, a few days ago I tested a HDMV disc and the >>> > background video played just fine. I'll test again and check. >>> >>> While testing, you could also check if keeping pop-up menu open during >>> plaback makes any difference. >>> >>> >>> >>> ___ >>> libbluray-devel mailing list >>> libbluray-devel@videolan.org >>> https://mailman.videolan.org/listinfo/libbluray-devel >>> >> ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Regular bluray is fine. Extracted or ISO. 4k bluray seems to be the problem. Tested iso only for far. On Fri, Jan 29, 2021, 6:29 PM Vitor Dall'Acqua wrote: > I'm doing some extensive testing so I need some more time. > > I want to test the same movie as iso and extracted to check if the archive > support addon on Kodi might be the problem. > > The popup, when the movie is already running makes no difference, I can > say that. > > But there are some movies that when open the top menu and start the movie > doesn't change the state (top menu - movie playing) and this caused the > main movie to run really slow. > > Another test HDMV disc extracted plays just fine. > > Now I'm waiting for 3:10 to Yuma to extract. > > And I have an event to attend to, so I'll do my best today but probably > I'll have more info tomorrow. > > > On Fri, Jan 29, 2021, 6:02 PM Petri Hintukainen < > phint...@users.sourceforge.net> wrote: > >> pe, 2021-01-29 kello 16:33 -0300, Vitor Dall'Acqua kirjoitti: >> > Now that you mention it, a few days ago I tested a HDMV disc and the >> > background video played just fine. I'll test again and check. >> >> While testing, you could also check if keeping pop-up menu open during >> plaback makes any difference. >> >> >> >> ___ >> libbluray-devel mailing list >> libbluray-devel@videolan.org >> https://mailman.videolan.org/listinfo/libbluray-devel >> > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
I'm doing some extensive testing so I need some more time. I want to test the same movie as iso and extracted to check if the archive support addon on Kodi might be the problem. The popup, when the movie is already running makes no difference, I can say that. But there are some movies that when open the top menu and start the movie doesn't change the state (top menu - movie playing) and this caused the main movie to run really slow. Another test HDMV disc extracted plays just fine. Now I'm waiting for 3:10 to Yuma to extract. And I have an event to attend to, so I'll do my best today but probably I'll have more info tomorrow. On Fri, Jan 29, 2021, 6:02 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > pe, 2021-01-29 kello 16:33 -0300, Vitor Dall'Acqua kirjoitti: > > Now that you mention it, a few days ago I tested a HDMV disc and the > > background video played just fine. I'll test again and check. > > While testing, you could also check if keeping pop-up menu open during > plaback makes any difference. > > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
pe, 2021-01-29 kello 16:33 -0300, Vitor Dall'Acqua kirjoitti: > Now that you mention it, a few days ago I tested a HDMV disc and the > background video played just fine. I'll test again and check. While testing, you could also check if keeping pop-up menu open during plaback makes any difference. ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Now that you mention it, a few days ago I tested a HDMV disc and the background video played just fine. I'll test again and check. What I was referring to is this: DEBUG : CBlurayCallback::Logger - udf_fs.c:79: Opening UDF file BDMV/CLIPINF/0.clpi... (0x2923e3c240) DEBUG : CFileCache::Process - Cache completely reset for seek to position 737280 DEBUG : CFileCache::Process - Cache completely reset for seek to position 11974656 DEBUG : CBlurayCallback::Logger - udf_fs.c:52: Closed UDF file (0x2923e3c240) DEBUG : CBlurayCallback::Logger - udf_fs.c:79: Opening UDF file BDMV/CLIPINF/0.clpi... (0x2923e3c240) DEBUG : CFileCache::Process - Cache completely reset for seek to position 737280 DEBUG : CFileCache::Process - Cache completely reset for seek to position 11974656 DEBUG : CBlurayCallback::Logger - udf_fs.c:52: Closed UDF file (0x2923e3c240) DEBUG : CBlurayCallback::Logger - udf_fs.c:79: Opening UDF file BDMV/CLIPINF/0.clpi... (0x2923e3c240) DEBUG : CFileCache::Process - Cache completely reset for seek to position 737280 DEBUG : CFileCache::Process - Cache completely reset for seek to position 11974656 DEBUG : CBlurayCallback::Logger - udf_fs.c:52: Closed UDF file (0x2923e3c240) DEBUG : CBlurayCallback::Logger - udf_fs.c:79: Opening UDF file BDMV/CLIPINF/0.clpi... (0x2923e3c240) DEBUG : CFileCache::Process - Cache completely reset for seek to position 737280 DEBUG : CFileCache::Process - Cache completely reset for seek to position 11974656 DEBUG : CBlurayCallback::Logger - udf_fs.c:52: Closed UDF file (0x2923e3c240) Don't know if this is a UDF thing but for sure this isn't good for SMB On Fri, Jan 29, 2021 at 4:23 PM Petri Hintukainen < phint...@users.sourceforge.net> wrote: > pe, 2021-01-29 kello 10:43 -0300, Vitor Dall'Acqua kirjoitti: > > JIT isn't disabled here. > > I believe this has something to do with how Kodi works while is > > inside a menu because if I start a scene and it still thinks it's > > inside a menu, the playback is sluggish. > > If I just start the main menu and the menu statement is off the movie > > plays fine. > > If I understand this right, it is related to BD-J menus ? And it is > slow even if menu is "empty" (= nothing visible on the display) ? > > Have you tried if HDMV discs (= discs without BD-J) play any better ? > That would be easy way to check if it has something to do with BD-J. > > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
pe, 2021-01-29 kello 10:43 -0300, Vitor Dall'Acqua kirjoitti: > JIT isn't disabled here. > I believe this has something to do with how Kodi works while is > inside a menu because if I start a scene and it still thinks it's > inside a menu, the playback is sluggish. > If I just start the main menu and the menu statement is off the movie > plays fine. If I understand this right, it is related to BD-J menus ? And it is slow even if menu is "empty" (= nothing visible on the display) ? Have you tried if HDMV discs (= discs without BD-J) play any better ? That would be easy way to check if it has something to do with BD-J. ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
ok, it now uses java_home for the java tmp dir...
It doesn't improve.. but one thing that might be the problem, is the same
thing I reported here, quite some time ago...
https://forum.rclone.org/t/constant-access-to-the-same-file-over-and-over-again/9849
I use rclone to serve the files from google drive and Jriver uses libbluray
to display the menus on Windows.
Without the cache backend of rclone it's impossible to use libbluray
because it hammers the files, instead of grabbing it all, it keeps
accessing it over and over again.
Right now, I'm testing with isos on my NAS, on my LAN, nothing like rclone
but looking at the logs this seems to be the case.
The best thing would be that libbluray actually copies all the bdjo,
*.mpls, *.clpi and all data files.. and access m2ts that play in the
background with bigger chunks of data.
that's just my guess but looking at the logs and taking 2 to 3 minutes to
actually start a disc and looking at logcat and see it access mpls over and
over, this seems to be the case.
Hopefully this is something easy to change and not something that requires
rewrite of libbluray entirely.
On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua wrote:
> no it does not
>
> On Fri, Jan 29, 2021 at 2:26 PM Vitor Dall'Acqua wrote:
>
>> setenv("LIBBLURAY_CACHE_ROOT",
>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache/").c_str(),
>> 1);
>>
>> solves option[n++].optionString = str_dup ("-Djava.io.tmpdir=/storage/
>> emulated/0/Android/");
>>
>> it seems.
>>
>> On Fri, Jan 29, 2021 at 1:33 PM Vitor Dall'Acqua
>> wrote:
>>
>>> I have a guess why it's sluggish now..
>>>
>>> This is how kodi sets the temp dir:
>>> #ifdef HAVE_LIBBLURAY_BDJ
>>> std::string cacheDir =
>>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache");
>>> std::string persistentDir =
>>>
>>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/persistent");
>>> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_PERSISTENT_ROOT,
>>> persistentDir.c_str());
>>> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_CACHE_ROOT,
>>> cacheDir.c_str());
>>> #endif
>>>
>>> but.. java doesn't honor it and tries to use /tmp/bdj-cache-dir
>>> and that's why I had to use
>>>
>>> option[n++].optionString = str_dup
>>> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>>>
>>> Petri, you know libbluray better than anyone.
>>>
>>> What is going on with this?
>>>
>>>
>>> On Fri, Jan 29, 2021 at 11:18 AM Vitor Dall'Acqua
>>> wrote:
>>>
Playing on nvidia shield tv pro (2019)
same for 2k movies.
The problem is somewhere here:
https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693
On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter
wrote:
> On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua
> wrote:
>
>> Java isn't installed system wide. It's just a library being loaded.
>> if I use adb shell to do this there's nothing to be returned.
>>
>> I'll test it now while I test JIT disabled.. but I'm pretty sure it's
>> how Kodi treats menu playback.
>> I have fixed the chapter skipping and seeking in titles with popup
>> menus so I know that is do some really weird things during menu playback,
>> like stopping time and such.
>>
>
> but I'm not sure why kodi should behave performantly on x86 and not on
> android (unless the android device is severly underpowered relative to the
> x86, which can be true).
>
> what device are you playing it on? nvidia shield (generation?) or
> something else?
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
no it does not
On Fri, Jan 29, 2021 at 2:26 PM Vitor Dall'Acqua wrote:
> setenv("LIBBLURAY_CACHE_ROOT",
> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache/").c_str(),
> 1);
>
> solves option[n++].optionString = str_dup ("-Djava.io.tmpdir=/storage/
> emulated/0/Android/");
>
> it seems.
>
> On Fri, Jan 29, 2021 at 1:33 PM Vitor Dall'Acqua wrote:
>
>> I have a guess why it's sluggish now..
>>
>> This is how kodi sets the temp dir:
>> #ifdef HAVE_LIBBLURAY_BDJ
>> std::string cacheDir =
>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache");
>> std::string persistentDir =
>>
>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/persistent");
>> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_PERSISTENT_ROOT,
>> persistentDir.c_str());
>> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_CACHE_ROOT,
>> cacheDir.c_str());
>> #endif
>>
>> but.. java doesn't honor it and tries to use /tmp/bdj-cache-dir
>> and that's why I had to use
>>
>> option[n++].optionString = str_dup
>> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>>
>> Petri, you know libbluray better than anyone.
>>
>> What is going on with this?
>>
>>
>> On Fri, Jan 29, 2021 at 11:18 AM Vitor Dall'Acqua
>> wrote:
>>
>>> Playing on nvidia shield tv pro (2019)
>>>
>>> same for 2k movies.
>>> The problem is somewhere here:
>>>
>>> https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693
>>>
>>> On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter wrote:
>>>
On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua
wrote:
> Java isn't installed system wide. It's just a library being loaded.
> if I use adb shell to do this there's nothing to be returned.
>
> I'll test it now while I test JIT disabled.. but I'm pretty sure it's
> how Kodi treats menu playback.
> I have fixed the chapter skipping and seeking in titles with popup
> menus so I know that is do some really weird things during menu playback,
> like stopping time and such.
>
but I'm not sure why kodi should behave performantly on x86 and not on
android (unless the android device is severly underpowered relative to the
x86, which can be true).
what device are you playing it on? nvidia shield (generation?) or
something else?
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
>>>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
setenv("LIBBLURAY_CACHE_ROOT",
CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache/").c_str(),
1);
solves option[n++].optionString = str_dup ("-Djava.io.tmpdir=/storage/
emulated/0/Android/");
it seems.
On Fri, Jan 29, 2021 at 1:33 PM Vitor Dall'Acqua wrote:
> I have a guess why it's sluggish now..
>
> This is how kodi sets the temp dir:
> #ifdef HAVE_LIBBLURAY_BDJ
> std::string cacheDir =
> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache");
> std::string persistentDir =
>
> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/persistent");
> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_PERSISTENT_ROOT,
> persistentDir.c_str());
> bd_set_player_setting_str(m_bd, BLURAY_PLAYER_CACHE_ROOT,
> cacheDir.c_str());
> #endif
>
> but.. java doesn't honor it and tries to use /tmp/bdj-cache-dir
> and that's why I had to use
>
> option[n++].optionString = str_dup
> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>
> Petri, you know libbluray better than anyone.
>
> What is going on with this?
>
>
> On Fri, Jan 29, 2021 at 11:18 AM Vitor Dall'Acqua
> wrote:
>
>> Playing on nvidia shield tv pro (2019)
>>
>> same for 2k movies.
>> The problem is somewhere here:
>>
>> https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693
>>
>> On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter wrote:
>>
>>> On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua
>>> wrote:
>>>
Java isn't installed system wide. It's just a library being loaded.
if I use adb shell to do this there's nothing to be returned.
I'll test it now while I test JIT disabled.. but I'm pretty sure it's
how Kodi treats menu playback.
I have fixed the chapter skipping and seeking in titles with popup
menus so I know that is do some really weird things during menu playback,
like stopping time and such.
>>>
>>> but I'm not sure why kodi should behave performantly on x86 and not on
>>> android (unless the android device is severly underpowered relative to the
>>> x86, which can be true).
>>>
>>> what device are you playing it on? nvidia shield (generation?) or
>>> something else?
>>> ___
>>> libbluray-devel mailing list
>>> libbluray-devel@videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
I have a guess why it's sluggish now..
This is how kodi sets the temp dir:
#ifdef HAVE_LIBBLURAY_BDJ
std::string cacheDir =
CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache");
std::string persistentDir =
CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/persistent");
bd_set_player_setting_str(m_bd, BLURAY_PLAYER_PERSISTENT_ROOT,
persistentDir.c_str());
bd_set_player_setting_str(m_bd, BLURAY_PLAYER_CACHE_ROOT,
cacheDir.c_str());
#endif
but.. java doesn't honor it and tries to use /tmp/bdj-cache-dir
and that's why I had to use
option[n++].optionString = str_dup
("-Djava.io.tmpdir=/storage/emulated/0/Android/");
Petri, you know libbluray better than anyone.
What is going on with this?
On Fri, Jan 29, 2021 at 11:18 AM Vitor Dall'Acqua wrote:
> Playing on nvidia shield tv pro (2019)
>
> same for 2k movies.
> The problem is somewhere here:
>
> https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693
>
> On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter wrote:
>
>> On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua
>> wrote:
>>
>>> Java isn't installed system wide. It's just a library being loaded.
>>> if I use adb shell to do this there's nothing to be returned.
>>>
>>> I'll test it now while I test JIT disabled.. but I'm pretty sure it's
>>> how Kodi treats menu playback.
>>> I have fixed the chapter skipping and seeking in titles with popup menus
>>> so I know that is do some really weird things during menu playback, like
>>> stopping time and such.
>>>
>>
>> but I'm not sure why kodi should behave performantly on x86 and not on
>> android (unless the android device is severly underpowered relative to the
>> x86, which can be true).
>>
>> what device are you playing it on? nvidia shield (generation?) or
>> something else?
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Playing on nvidia shield tv pro (2019) same for 2k movies. The problem is somewhere here: https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693 On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter wrote: > On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua wrote: > >> Java isn't installed system wide. It's just a library being loaded. >> if I use adb shell to do this there's nothing to be returned. >> >> I'll test it now while I test JIT disabled.. but I'm pretty sure it's how >> Kodi treats menu playback. >> I have fixed the chapter skipping and seeking in titles with popup menus >> so I know that is do some really weird things during menu playback, like >> stopping time and such. >> > > but I'm not sure why kodi should behave performantly on x86 and not on > android (unless the android device is severly underpowered relative to the > x86, which can be true). > > what device are you playing it on? nvidia shield (generation?) or > something else? > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua wrote: > Java isn't installed system wide. It's just a library being loaded. > if I use adb shell to do this there's nothing to be returned. > > I'll test it now while I test JIT disabled.. but I'm pretty sure it's how > Kodi treats menu playback. > I have fixed the chapter skipping and seeking in titles with popup menus > so I know that is do some really weird things during menu playback, like > stopping time and such. > but I'm not sure why kodi should behave performantly on x86 and not on android (unless the android device is severly underpowered relative to the x86, which can be true). what device are you playing it on? nvidia shield (generation?) or something else? ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Java isn't installed system wide. It's just a library being loaded. if I use adb shell to do this there's nothing to be returned. I'll test it now while I test JIT disabled.. but I'm pretty sure it's how Kodi treats menu playback. I have fixed the chapter skipping and seeking in titles with popup menus so I know that is do some really weird things during menu playback, like stopping time and such. On Fri, Jan 29, 2021 at 10:59 AM Shaya Potter wrote: > > On Fri, Jan 29, 2021 at 3:55 PM Vitor Dall'Acqua wrote: > >> ahm how do I check that? >> >> I'm disabling JIT now to test. >> But I still think the problem is that Kodi isn't using hardware >> accelaration during menus and this is why it's slow. >> > > run the java vm by hand. see example > > http://openjdk.java.net/projects/mobile/android.html > > as it shows Zero VM. as opposed to when I run on my laptop, it shows > Server VM (i.e. hotspot in Server configuration_ > > $ java -version > openjdk version "11.0.9.1" 2020-11-04 > OpenJDK Runtime Environment (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04) > OpenJDK 64-Bit Server VM (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, mixed > mode, sharing) > > > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
try a regular 2k bluray :) 4k could also be causing issues. On Fri, Jan 29, 2021 at 3:57 PM Vitor Dall'Acqua wrote: > 3:10 to Yuma > > UHD Bluray outputing 4k hdr. > > On Fri, Jan 29, 2021, 10:55 AM Shaya Potter wrote: > >> >> On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua >> wrote: >> >>> IT'S WORKING!!! >>> >>> https://ibb.co/2Zf5DTD >>> >>> really really slow.. but it's working >>> >> >> just for edification, which movie is this? >> ___ >> libbluray-devel mailing list >> libbluray-devel@videolan.org >> https://mailman.videolan.org/listinfo/libbluray-devel >> > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Fri, Jan 29, 2021 at 3:55 PM Vitor Dall'Acqua wrote: > ahm how do I check that? > > I'm disabling JIT now to test. > But I still think the problem is that Kodi isn't using hardware > accelaration during menus and this is why it's slow. > run the java vm by hand. see example http://openjdk.java.net/projects/mobile/android.html as it shows Zero VM. as opposed to when I run on my laptop, it shows Server VM (i.e. hotspot in Server configuration_ $ java -version openjdk version "11.0.9.1" 2020-11-04 OpenJDK Runtime Environment (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04) OpenJDK 64-Bit Server VM (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, mixed mode, sharing) ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
3:10 to Yuma UHD Bluray outputing 4k hdr. On Fri, Jan 29, 2021, 10:55 AM Shaya Potter wrote: > > On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua wrote: > >> IT'S WORKING!!! >> >> https://ibb.co/2Zf5DTD >> >> really really slow.. but it's working >> > > just for edification, which movie is this? > ___ > libbluray-devel mailing list > libbluray-devel@videolan.org > https://mailman.videolan.org/listinfo/libbluray-devel > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua wrote: > IT'S WORKING!!! > > https://ibb.co/2Zf5DTD > > really really slow.. but it's working > just for edification, which movie is this? ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
ahm how do I check that?
I'm disabling JIT now to test.
But I still think the problem is that Kodi isn't using hardware
accelaration during menus and this is why it's slow.
On Fri, Jan 29, 2021 at 10:51 AM Shaya Potter wrote:
> it is using the hotspot vm? not the zerovm?
>
> On Fri, Jan 29, 2021 at 3:44 PM Vitor Dall'Acqua wrote:
>
>> JIT isn't disabled here.
>>
>> I believe this has something to do with how Kodi works while is inside a
>> menu because if I start a scene and it still thinks it's inside a menu, the
>> playback is sluggish.
>> If I just start the main menu and the menu statement is off the movie
>> plays fine.
>>
>> On Fri, Jan 29, 2021 at 10:40 AM Shaya Potter wrote:
>>
>>> great job. so petri was right about the no jit (to be expected that he
>>> would be). but this provides a good starting point, I think, especially as
>>> this seems to be a supported configuration of the jvm.
>>>
>>> On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua
>>> wrote:
>>>
IT'S WORKING!!!
https://ibb.co/2Zf5DTD
really really slow.. but it's working
On Fri, Jan 29, 2021, 10:16 AM Petri Hintukainen <
phint...@users.sourceforge.net> wrote:
> pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
> > it probably doesn't make a difference, but meant setting DISPLAY env
> > variable to :0.0 (much like JAVA_HOME you were dealing with before).
> >
> > On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
> > wrote:
> > > Made no difference
> > > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
> > >
> > > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
> > >
> > > maybe I'm not writing it properly.
>
> It should be without X11_ prefix:
>
> setenv("DISPLAY", ":0.0", 1);
>
> This seems to be enough. Or skip autodetection with
>
>option[n++].optionString = str_dup("-Djava.awt.headless=false");
>
> (it seems to assume Linux == X11 ...).
>
> > > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
> > > wrote:
> > > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
> > > > veg...@gmail.com> wrote:
> > > > > Ok solved the write protected with
> > > > > option[n++].optionString = str_dup ("-
> > > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
> > > > >
> > > > > Petri, now this is beyond me:
> > > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
> > > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
> > > > > loadN() failed: java.awt.HeadlessException:
> > > > >No X11
> > > > > DISPLAY variable was set, but this program performed an
> > > > > operation which requires it.
> > > > >
> > > > > Do you have any idea?
> > > > >
> > > >
> > > > this is the headless awt thing i mentioned before. This is very
> > > > good progress I'd think.
> > > >
> > > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
> > > > if it's just checking for the env var but doesn't actually draw
> > > > to it, it might get it past it. If it actually has to draw, it
> > > > will fail somewhere else later. The question is what libbluray
> > > > would need for java9's headless awt mode.
> > > > ___
> > > > libbluray-devel mailing list
> > > > libbluray-devel@videolan.org
> > > > https://mailman.videolan.org/listinfo/libbluray-devel
> > > ___
> > > libbluray-devel mailing list
> > > libbluray-devel@videolan.org
> > > https://mailman.videolan.org/listinfo/libbluray-devel
> > ___
> > libbluray-devel mailing list
> > libbluray-devel@videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
>
>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
>>> ___
>>> libbluray-devel mailing list
>>> libbluray-devel@videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
Re: [libbluray-devel] JRE for Android part 3
it is using the hotspot vm? not the zerovm?
On Fri, Jan 29, 2021 at 3:44 PM Vitor Dall'Acqua wrote:
> JIT isn't disabled here.
>
> I believe this has something to do with how Kodi works while is inside a
> menu because if I start a scene and it still thinks it's inside a menu, the
> playback is sluggish.
> If I just start the main menu and the menu statement is off the movie
> plays fine.
>
> On Fri, Jan 29, 2021 at 10:40 AM Shaya Potter wrote:
>
>> great job. so petri was right about the no jit (to be expected that he
>> would be). but this provides a good starting point, I think, especially as
>> this seems to be a supported configuration of the jvm.
>>
>> On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua
>> wrote:
>>
>>> IT'S WORKING!!!
>>>
>>> https://ibb.co/2Zf5DTD
>>>
>>> really really slow.. but it's working
>>>
>>> On Fri, Jan 29, 2021, 10:16 AM Petri Hintukainen <
>>> phint...@users.sourceforge.net> wrote:
>>>
pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
> it probably doesn't make a difference, but meant setting DISPLAY env
> variable to :0.0 (much like JAVA_HOME you were dealing with before).
>
> On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
> wrote:
> > Made no difference
> > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
> >
> > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
> >
> > maybe I'm not writing it properly.
It should be without X11_ prefix:
setenv("DISPLAY", ":0.0", 1);
This seems to be enough. Or skip autodetection with
option[n++].optionString = str_dup("-Djava.awt.headless=false");
(it seems to assume Linux == X11 ...).
> > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
> > wrote:
> > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
> > > veg...@gmail.com> wrote:
> > > > Ok solved the write protected with
> > > > option[n++].optionString = str_dup ("-
> > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
> > > >
> > > > Petri, now this is beyond me:
> > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
> > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
> > > > loadN() failed: java.awt.HeadlessException:
> > > >No X11
> > > > DISPLAY variable was set, but this program performed an
> > > > operation which requires it.
> > > >
> > > > Do you have any idea?
> > > >
> > >
> > > this is the headless awt thing i mentioned before. This is very
> > > good progress I'd think.
> > >
> > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
> > > if it's just checking for the env var but doesn't actually draw
> > > to it, it might get it past it. If it actually has to draw, it
> > > will fail somewhere else later. The question is what libbluray
> > > would need for java9's headless awt mode.
> > > ___
> > > libbluray-devel mailing list
> > > libbluray-devel@videolan.org
> > > https://mailman.videolan.org/listinfo/libbluray-devel
> > ___
> > libbluray-devel mailing list
> > libbluray-devel@videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
>>> ___
>>> libbluray-devel mailing list
>>> libbluray-devel@videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
JIT isn't disabled here.
I believe this has something to do with how Kodi works while is inside a
menu because if I start a scene and it still thinks it's inside a menu, the
playback is sluggish.
If I just start the main menu and the menu statement is off the movie plays
fine.
On Fri, Jan 29, 2021 at 10:40 AM Shaya Potter wrote:
> great job. so petri was right about the no jit (to be expected that he
> would be). but this provides a good starting point, I think, especially as
> this seems to be a supported configuration of the jvm.
>
> On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua wrote:
>
>> IT'S WORKING!!!
>>
>> https://ibb.co/2Zf5DTD
>>
>> really really slow.. but it's working
>>
>> On Fri, Jan 29, 2021, 10:16 AM Petri Hintukainen <
>> phint...@users.sourceforge.net> wrote:
>>
>>> pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
>>> > it probably doesn't make a difference, but meant setting DISPLAY env
>>> > variable to :0.0 (much like JAVA_HOME you were dealing with before).
>>> >
>>> > On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
>>> > wrote:
>>> > > Made no difference
>>> > > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
>>> > >
>>> > > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
>>> > >
>>> > > maybe I'm not writing it properly.
>>>
>>> It should be without X11_ prefix:
>>>
>>> setenv("DISPLAY", ":0.0", 1);
>>>
>>> This seems to be enough. Or skip autodetection with
>>>
>>>option[n++].optionString = str_dup("-Djava.awt.headless=false");
>>>
>>> (it seems to assume Linux == X11 ...).
>>>
>>> > > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
>>> > > wrote:
>>> > > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
>>> > > > veg...@gmail.com> wrote:
>>> > > > > Ok solved the write protected with
>>> > > > > option[n++].optionString = str_dup ("-
>>> > > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
>>> > > > >
>>> > > > > Petri, now this is beyond me:
>>> > > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
>>> > > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
>>> > > > > loadN() failed: java.awt.HeadlessException:
>>> > > > >No X11
>>> > > > > DISPLAY variable was set, but this program performed an
>>> > > > > operation which requires it.
>>> > > > >
>>> > > > > Do you have any idea?
>>> > > > >
>>> > > >
>>> > > > this is the headless awt thing i mentioned before. This is very
>>> > > > good progress I'd think.
>>> > > >
>>> > > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
>>> > > > if it's just checking for the env var but doesn't actually draw
>>> > > > to it, it might get it past it. If it actually has to draw, it
>>> > > > will fail somewhere else later. The question is what libbluray
>>> > > > would need for java9's headless awt mode.
>>> > > > ___
>>> > > > libbluray-devel mailing list
>>> > > > libbluray-devel@videolan.org
>>> > > > https://mailman.videolan.org/listinfo/libbluray-devel
>>> > > ___
>>> > > libbluray-devel mailing list
>>> > > libbluray-devel@videolan.org
>>> > > https://mailman.videolan.org/listinfo/libbluray-devel
>>> > ___
>>> > libbluray-devel mailing list
>>> > libbluray-devel@videolan.org
>>> > https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>>>
>>> ___
>>> libbluray-devel mailing list
>>> libbluray-devel@videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
great job. so petri was right about the no jit (to be expected that he
would be). but this provides a good starting point, I think, especially as
this seems to be a supported configuration of the jvm.
On Fri, Jan 29, 2021 at 3:36 PM Vitor Dall'Acqua wrote:
> IT'S WORKING!!!
>
> https://ibb.co/2Zf5DTD
>
> really really slow.. but it's working
>
> On Fri, Jan 29, 2021, 10:16 AM Petri Hintukainen <
> phint...@users.sourceforge.net> wrote:
>
>> pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
>> > it probably doesn't make a difference, but meant setting DISPLAY env
>> > variable to :0.0 (much like JAVA_HOME you were dealing with before).
>> >
>> > On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
>> > wrote:
>> > > Made no difference
>> > > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
>> > >
>> > > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
>> > >
>> > > maybe I'm not writing it properly.
>>
>> It should be without X11_ prefix:
>>
>> setenv("DISPLAY", ":0.0", 1);
>>
>> This seems to be enough. Or skip autodetection with
>>
>>option[n++].optionString = str_dup("-Djava.awt.headless=false");
>>
>> (it seems to assume Linux == X11 ...).
>>
>> > > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
>> > > wrote:
>> > > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
>> > > > veg...@gmail.com> wrote:
>> > > > > Ok solved the write protected with
>> > > > > option[n++].optionString = str_dup ("-
>> > > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
>> > > > >
>> > > > > Petri, now this is beyond me:
>> > > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
>> > > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
>> > > > > loadN() failed: java.awt.HeadlessException:
>> > > > >No X11
>> > > > > DISPLAY variable was set, but this program performed an
>> > > > > operation which requires it.
>> > > > >
>> > > > > Do you have any idea?
>> > > > >
>> > > >
>> > > > this is the headless awt thing i mentioned before. This is very
>> > > > good progress I'd think.
>> > > >
>> > > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
>> > > > if it's just checking for the env var but doesn't actually draw
>> > > > to it, it might get it past it. If it actually has to draw, it
>> > > > will fail somewhere else later. The question is what libbluray
>> > > > would need for java9's headless awt mode.
>> > > > ___
>> > > > libbluray-devel mailing list
>> > > > libbluray-devel@videolan.org
>> > > > https://mailman.videolan.org/listinfo/libbluray-devel
>> > > ___
>> > > libbluray-devel mailing list
>> > > libbluray-devel@videolan.org
>> > > https://mailman.videolan.org/listinfo/libbluray-devel
>> > ___
>> > libbluray-devel mailing list
>> > libbluray-devel@videolan.org
>> > https://mailman.videolan.org/listinfo/libbluray-devel
>>
>>
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
IT'S WORKING!!!
https://ibb.co/2Zf5DTD
really really slow.. but it's working
On Fri, Jan 29, 2021, 10:16 AM Petri Hintukainen <
phint...@users.sourceforge.net> wrote:
> pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
> > it probably doesn't make a difference, but meant setting DISPLAY env
> > variable to :0.0 (much like JAVA_HOME you were dealing with before).
> >
> > On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
> > wrote:
> > > Made no difference
> > > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
> > >
> > > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
> > >
> > > maybe I'm not writing it properly.
>
> It should be without X11_ prefix:
>
> setenv("DISPLAY", ":0.0", 1);
>
> This seems to be enough. Or skip autodetection with
>
>option[n++].optionString = str_dup("-Djava.awt.headless=false");
>
> (it seems to assume Linux == X11 ...).
>
> > > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
> > > wrote:
> > > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
> > > > veg...@gmail.com> wrote:
> > > > > Ok solved the write protected with
> > > > > option[n++].optionString = str_dup ("-
> > > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
> > > > >
> > > > > Petri, now this is beyond me:
> > > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
> > > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
> > > > > loadN() failed: java.awt.HeadlessException:
> > > > >No X11
> > > > > DISPLAY variable was set, but this program performed an
> > > > > operation which requires it.
> > > > >
> > > > > Do you have any idea?
> > > > >
> > > >
> > > > this is the headless awt thing i mentioned before. This is very
> > > > good progress I'd think.
> > > >
> > > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
> > > > if it's just checking for the env var but doesn't actually draw
> > > > to it, it might get it past it. If it actually has to draw, it
> > > > will fail somewhere else later. The question is what libbluray
> > > > would need for java9's headless awt mode.
> > > > ___
> > > > libbluray-devel mailing list
> > > > libbluray-devel@videolan.org
> > > > https://mailman.videolan.org/listinfo/libbluray-devel
> > > ___
> > > libbluray-devel mailing list
> > > libbluray-devel@videolan.org
> > > https://mailman.videolan.org/listinfo/libbluray-devel
> > ___
> > libbluray-devel mailing list
> > libbluray-devel@videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
>
>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
pe, 2021-01-29 kello 14:58 +0200, Shaya Potter kirjoitti:
> it probably doesn't make a difference, but meant setting DISPLAY env
> variable to :0.0 (much like JAVA_HOME you were dealing with before).
>
> On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua
> wrote:
> > Made no difference
> > setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
> >
> > setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
> >
> > maybe I'm not writing it properly.
It should be without X11_ prefix:
setenv("DISPLAY", ":0.0", 1);
This seems to be enough. Or skip autodetection with
option[n++].optionString = str_dup("-Djava.awt.headless=false");
(it seems to assume Linux == X11 ...).
> > On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter
> > wrote:
> > > On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua <
> > > veg...@gmail.com> wrote:
> > > > Ok solved the write protected with
> > > > option[n++].optionString = str_dup ("-
> > > > Djava.io.tmpdir=/storage/emulated/0/Android/");
> > > >
> > > > Petri, now this is beyond me:
> > > > 2021-01-28 21:58:59.346 T:18499 DEBUG :
> > > > CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR:
> > > > loadN() failed: java.awt.HeadlessException:
> > > > No X11
> > > > DISPLAY variable was set, but this program performed an
> > > > operation which requires it.
> > > >
> > > > Do you have any idea?
> > > >
> > >
> > > this is the headless awt thing i mentioned before. This is very
> > > good progress I'd think.
> > >
> > > A simple thing to try to do is set env variable X11_DISPLAY=:0,
> > > if it's just checking for the env var but doesn't actually draw
> > > to it, it might get it past it. If it actually has to draw, it
> > > will fail somewhere else later. The question is what libbluray
> > > would need for java9's headless awt mode.
> > > ___
> > > libbluray-devel mailing list
> > > libbluray-devel@videolan.org
> > > https://mailman.videolan.org/listinfo/libbluray-devel
> > ___
> > libbluray-devel mailing list
> > libbluray-devel@videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
it probably doesn't make a difference, but meant setting DISPLAY env
variable to :0.0 (much like JAVA_HOME you were dealing with before).
On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua wrote:
> Made no difference
>
> setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
>
> setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
>
> maybe I'm not writing it properly.
>
> On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter wrote:
>
>> On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua
>> wrote:
>>
>>> Ok solved the write protected with
>>>
>>> option[n++].optionString = str_dup
>>> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>>>
>>> Petri, now this is beyond me:
>>> 2021-01-28 21:58:59.346 T:18499 DEBUG :
>>> CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR: loadN() failed:
>>> java.awt.HeadlessException:
>>>No X11 DISPLAY
>>> variable was set, but this program performed an operation which requires it.
>>>
>>> Do you have any idea?
>>>
>>
>> this is the headless awt thing i mentioned before. This is very good
>> progress I'd think.
>>
>> A simple thing to try to do is set env variable X11_DISPLAY=:0, if it's
>> just checking for the env var but doesn't actually draw to it, it might get
>> it past it. If it actually has to draw, it will fail somewhere else
>> later. The question is what libbluray would need for java9's headless awt
>> mode.
>> ___
>> libbluray-devel mailing list
>> libbluray-devel@videolan.org
>> https://mailman.videolan.org/listinfo/libbluray-devel
>>
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Made no difference
setenv("X11_DISPLAY", "DISPLAY=:0.0", 1);
setenv("X11_DISPLAY", "X11_DISPLAY=:0.0", 1);
maybe I'm not writing it properly.
On Fri, Jan 29, 2021 at 5:49 AM Shaya Potter wrote:
> On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua wrote:
>
>> Ok solved the write protected with
>>
>> option[n++].optionString = str_dup
>> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>>
>> Petri, now this is beyond me:
>> 2021-01-28 21:58:59.346 T:18499 DEBUG :
>> CBlurayCallback::Logger - org.videolan.BDJLoader:0: ERROR: loadN() failed:
>> java.awt.HeadlessException:
>>No X11 DISPLAY
>> variable was set, but this program performed an operation which requires it.
>>
>> Do you have any idea?
>>
>
> this is the headless awt thing i mentioned before. This is very good
> progress I'd think.
>
> A simple thing to try to do is set env variable X11_DISPLAY=:0, if it's
> just checking for the env var but doesn't actually draw to it, it might get
> it past it. If it actually has to draw, it will fail somewhere else
> later. The question is what libbluray would need for java9's headless awt
> mode.
> ___
> libbluray-devel mailing list
> libbluray-devel@videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
On Fri, Jan 29, 2021 at 2:02 AM Vitor Dall'Acqua wrote:
> Ok solved the write protected with
>
> option[n++].optionString = str_dup
> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>
> Petri, now this is beyond me:
> 2021-01-28 21:58:59.346 T:18499 DEBUG : CBlurayCallback::Logger
> - org.videolan.BDJLoader:0: ERROR: loadN() failed:
> java.awt.HeadlessException:
>No X11 DISPLAY variable
> was set, but this program performed an operation which requires it.
>
> Do you have any idea?
>
this is the headless awt thing i mentioned before. This is very good
progress I'd think.
A simple thing to try to do is set env variable X11_DISPLAY=:0, if it's
just checking for the env var but doesn't actually draw to it, it might get
it past it. If it actually has to draw, it will fail somewhere else
later. The question is what libbluray would need for java9's headless awt
mode.
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Ok solved the write protected with
option[n++].optionString = str_dup
("-Djava.io.tmpdir=/storage/emulated/0/Android/");
Petri, now this is beyond me:
2021-01-28 21:58:59.346 T:18499 DEBUG : CBlurayCallback::Logger
- org.videolan.BDJLoader:0: ERROR: loadN() failed:
java.awt.HeadlessException:
No X11 DISPLAY variable
was set, but this program performed an operation which requires it.
Do you have any idea?
On Thu, Jan 28, 2021 at 7:41 PM Vitor Dall'Acqua wrote:
> Ok preloading libnet.so works!
>
> Ok.. we now have to manipulate this path...
>
> 2021-01-28 20:30:15.431 T:14892 DEBUG : CBlurayCallback::Logger
> - org.videolan.CacheDir:0: ERROR: Error creating directory
> /tmp/libbluray-bdj-cache
>
> I was looking at the source..
> Can this be JAVA_HOME/temp or something?
>
> I know nothing of Java =/
>
> On Thu, Jan 28, 2021 at 7:01 PM Vitor Dall'Acqua wrote:
>
>> email got too big..
>>
>> Path is correct now we are a few inches from this starting to work...
>>
>> My python addon extracts the files and list everything, all is good.
>> Now check this out:
>> This is from my listing:
>> DEBUG :
>> /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnet.so
>> DEBUG :
>> /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnio.so
>>
>> and this is the result:
>> 2021-01-28 19:51:08.734 T:12529 DEBUG :
>> CBlurayCallback::Logger -
>> BDJActionQueue.java:org.videolan.BDJActionQueue.run:93: action failed:
>> java.lang.UnsatisfiedLinkError:
>> /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnio.so:
>> dlopen failed: library "libnet.so" not found
>>
>> if I would have to guess it is looking for libnet.so at the root of the
>> library directories.
>> Those are now moved and should respect the correct path.
>>
>
___
libbluray-devel mailing list
libbluray-devel@videolan.org
https://mailman.videolan.org/listinfo/libbluray-devel
Re: [libbluray-devel] JRE for Android part 3
Ok preloading libnet.so works! Ok.. we now have to manipulate this path... 2021-01-28 20:30:15.431 T:14892 DEBUG : CBlurayCallback::Logger - org.videolan.CacheDir:0: ERROR: Error creating directory /tmp/libbluray-bdj-cache I was looking at the source.. Can this be JAVA_HOME/temp or something? I know nothing of Java =/ On Thu, Jan 28, 2021 at 7:01 PM Vitor Dall'Acqua wrote: > email got too big.. > > Path is correct now we are a few inches from this starting to work... > > My python addon extracts the files and list everything, all is good. > Now check this out: > This is from my listing: > DEBUG : > /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnet.so > DEBUG : > /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnio.so > > and this is the result: > 2021-01-28 19:51:08.734 T:12529 DEBUG : CBlurayCallback::Logger > - BDJActionQueue.java:org.videolan.BDJActionQueue.run:93: action failed: > java.lang.UnsatisfiedLinkError: > /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/user/0/org.xbmc.kodi19DV/cache/apk/assets/j2re-image/lib/aarch64/libnio.so: > dlopen failed: library "libnet.so" not found > > if I would have to guess it is looking for libnet.so at the root of the > library directories. > Those are now moved and should respect the correct path. > ___ libbluray-devel mailing list libbluray-devel@videolan.org https://mailman.videolan.org/listinfo/libbluray-devel
