Android pie-x86 hw accel video codecs

[Michael Goffioul]

Hi,

I'm in the process of porting the hw accelerated video codec layer
from oreo-x86 to pie-x86. This is still work in progress, but in case
someone wants to give it a spin, I've attached the current status. The
codec layer works for me, including VA-API decoding, in an ExoPlayer
based app. I'm still working on the extractor layer (I don't really
need it, so I left it aside at the moment). There's been some
significant code reorganization between oreo and pie in the extractor
layer, so it takes some time.

Michael.

[Jon West]

If you could post it as a patch with your commit authorship attached, I could run off a pie build with it included to test with pretty quickly.

[Michael Goffioul]

I will, once I've finalized the whole thing. At the moment it's just
for experimenting, and some part of the patch might not apply 100%
cleanly, as I've other customizations in the queue (although I don't
expect any conflict, just line offsets).

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.
> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/90d53df5-98a7-49aa-95c6-8a77e4bdc02f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jon West]

All good, I can likely try and apply it and test over the weekend anyways. Just let us know when you're comfortable with them then ;)

On Friday, May 31, 2019 at 8:23:15 PM UTC-4, Michael Goffioul wrote:

I will, once I've finalized the whole thing. At the moment it's just
for experimenting, and some part of the patch might not apply 100%
cleanly, as I've other customizations in the queue (although I don't
expect any conflict, just line offsets).

On Fri, May 31, 2019 at 8:14 PM Jon West <electr...@gmail.com> wrote:
>
> If you could post it as a patch with your commit authorship attached, I could run off a pie build with it included to test with pretty quickly.
>
> On Friday, May 31, 2019 at 7:06:22 PM UTC-4, Michael Goffioul wrote:
>>
>> Hi,
>>
>> I'm in the process of porting the hw accelerated video codec layer
>> from oreo-x86 to pie-x86. This is still work in progress, but in case
>> someone wants to give it a spin, I've attached the current status. The
>> codec layer works for me, including VA-API decoding, in an ExoPlayer
>> based app. I'm still working on the extractor layer (I don't really
>> need it, so I left it aside at the moment). There's been some
>> significant code reorganization between oreo and pie in the extractor
>> layer, so it takes some time.
>>
>> Michael.
>
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

[Michael Goffioul]

If you have a good test case for the extractor layer, I'm all ears. I
never use it, as my core app is using ExoPlayer, which only needs the
codec layer.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/e84d7cfe-909f-4407-aa5d-a8df94cab6f0%40googlegroups.com.

[Jon West]

I was able to test using ExoPlayer and things seem to be running without issue. Not sure if I have the right player app to test with though. Feel free to trecommend what you use to test with, and I'd be happy to report back.

[Michael Goffioul]

Here's a full patch series. I didn't do exhaustive testing of the
extractor layer, but I was able to play MPEG/TS or WMV content from
HTTP, which is good enough to know that layer is working. I also
verified that MPEG2 and H264 decoding was using VA-API on my Intel
platform.

The archive contains 2 series of patches, to be applied on
frameworks/av/ and on external/stagefright-plugins/.

Michael.

On Sun, Jun 2, 2019 at 4:37 PM Jon West <electr...@gmail.com> wrote:
>
> I was able to test using ExoPlayer and things seem to be running without issue. Not sure if I have the right player app to test with though. Feel free to trecommend what you use to test with, and I'd be happy to report back.
>

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/575e464b-fa0e-4534-91a1-dfb1b8ce4682%40googlegroups.com.

[lambdadroid]

FWIW, Intel also finally managed to open-source their hardware
accelerated video codec implementation based on MediaSDK at the end of
last year.

Relevant repositories:
- MediaSDK: https://github.com/Intel-Media-SDK/MediaSDK
- MediaSDK_OMX_IL: https://github.com/Intel-Media-SDK/MediaSDK_OMX_IL
(This is the Android OMX implementation that used to be proprietary)
- libstagefrighthw: https://android.googlesource.com/platform/hardware/intel/common/libstagefrighthw/

The version they have open-sourced is intended for use with their new
media stack, which supports only BDW or newer.
The VAAPI driver for that is at https://github.com/intel/media-driver
plus some additional repositories...

However, I managed to get it working for the old VAAPI driver on my
Bay Trail tablet. A couple of patches are required for this:
- https://github.com/me176c-dev/android_hardware_mediasdk/commit/af809f95a21b0a6008533711336a4270b2a92873
- https://github.com/me176c-dev/android_hardware_mediasdk/commit/5b14956479700abe5dd964600261eb24500249a3
- https://github.com/me176c-dev/android_hardware_mediasdk-omx/commit/68c4e95642e4ef8a2c07321e195f7bc560a54409
- https://github.com/me176c-dev/android_hardware_mediasdk-omx/commit/fb76a822024dcf281b176573f73a4eaad60c0ccf
- https://github.com/me176c-dev/android_hardware_intel-vaapi-driver/commit/705d69b4e57a5a50e27c03b455792c85fdde81c9

On my tablet, this brings it back to a similar state it had with
proprietary files they released for Nougat for Android-IA.

I think someone reported an issue with those proprietary files back
then on the Android-IA repository, where the hardware accelerated codecs
would freeze with certain videos and produce a greenish screen. This
issue is still present. Otherwise it works quite well for most videos.

Intel's stack has a couple of obvious advantages:

- It does not require any changes in the Android framework, since it
runs external as regular libstagefrighthw OMX plugin.

- It may be a bit more efficient(?)
I believe the current FFmpeg based OMX implementation still does
quite a bit on CPU (e.g. scaling) and therefore transfers data
more often between the CPU and GPU.
But I haven't done actual performance tests.

However, it's probably mainly optimized for their new media stack...
Not sure when my patches are going to break, the old VAAPI driver is not
maintained very well...

Note: Their OMX implementation strictly requires their fork of minigbm
as gralloc HAL at the moment, i.e. https://github.com/intel/minigbm

Since it doesn't have a FB HAL, you need a Graphics Composer
(hwcomposer) HAL. drmfb-composer [1] works well for older hardware;
for newer hardware, something more sophisticated like drm_hwcomposer or
IA-Hardware-Composer may also do the job.

Just wanted to mention this since I've been using this for a few months
now without major problems. Your mail reminded me to post this here :)

[1]: https://github.com/me176c-dev/drmfb-composer

[Mauro Rossi]

Very nice reports from both Micheal and lambdadroid

I have conducted some tests with ChromeOS minigbm (gralloc0 API) with drm_framebuffer support added in minigbm,

Intel was working, but amdgpu not working out-of-the-box and radeon, nouveau not working (for unknown reasons).

I have not tried yet drm_hwcomposer (master branch with hwc2 API), neither with ChromeOS minigbm (gralloc0 API) nor with intel minigbm (gralloc1)

For people wanting to try IA-HardareComposer with intel minigbm (gralloc1) i.e. the Android graphic stack of Celadon suitable for Intel GPUs,

here are the branches fixed for build and experimentally tested with oreo-x86 (they boot ok).

[1] https://github.com/maurossi/minigbm/commits/minigbm_intel (hint: git clone to external/ as minigbm_intel and checkout minigbm_intel)

[2] https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24 (hint: git clone to external/ and checkout 2019-Apr-24)

intel minigbm (gralloc1 API) module has been named 'gralloc.intel'

IA-Hardware-Composer (hwc2 API) module has been named 'hwcomposer.intel'

Here follow the necessary git diff changes in device/generic/common to build with gralloc1 support with IA-Hardware-Composer hwc two:

NOTE: remember that these changes will most probably break other drivers, which are not patched for gralloc1 compliance, 

I tried if amdgpu, radeon, nouveau were by any chance working, but they are not booting.

I don't know if BOARD_USES_GRALLOC1 allows for SurfaceFlinger runtime fallback to gralloc0,

does someone know that?

Mauro 

utente@utente-MS-7576:~/pie-x86/device/generic/common$ git diff
diff --git a/BoardConfig.mk b/BoardConfig.mk
index bd23daf..a73d8a4 100644
--- a/BoardConfig.mk
+++ b/BoardConfig.mk
@@ -60,15 +60,15 @@ USE_INTEL_OMX_COMPONENTS := true
 
 USE_OPENGL_RENDERER := true
 NUM_FRAMEBUFFER_SURFACE_BUFFERS ?= 3
-BOARD_USES_DRM_GRALLOC := true
+BOARD_USES_MINIGBM := true
 BOARD_USES_DRM_HWCOMPOSER ?= true
 SF_START_GRAPHICS_ALLOCATOR_SERVICE := true
-
+BOARD_USES_GRALLOC1 := true
 USE_CAMERA_STUB ?= false
-
+BOARD_USES_IA_HWCOMPOSER := true
 SUPERUSER_EMBEDDED := true
 SUPERUSER_PACKAGE_PREFIX := com.android.settings.cyanogenmod.superuser
-
+TARGET_USES_HWC2 := true
 # This enables the wpa wireless driver
 BOARD_WPA_SUPPLICANT_DRIVER ?= NL80211
 WPA_SUPPLICANT_VERSION ?= VER_2_1_DEVEL
diff --git a/gpu/gpu_mesa.mk b/gpu/gpu_mesa.mk
index 26abe35..afb66e3 100644
--- a/gpu/gpu_mesa.mk
+++ b/gpu/gpu_mesa.mk
@@ -9,9 +9,9 @@
 #
 
 PRODUCT_PACKAGES := \
-    hwcomposer.drm  \
+    hwcomposer.drm hwcomposer.intel \
     gralloc.drm     \
-    gralloc.gbm     \
+    gralloc.gbm gralloc.intel \
     libGLES_mesa    \
     libtxc_dxtn     \
 
diff --git a/init.sh b/init.sh
index 3cbfe79..fa0c458 100644
--- a/init.sh
+++ b/init.sh
@@ -157,7 +157,14 @@ function init_hal_gralloc()
                                set_property debug.drm.mode.force ${video:-1280x800}
                        fi
                        ;;
-               0*inteldrmfb|0*radeondrmfb|0*nouveaufb|0*svgadrmfb|0*amdgpudrmfb)
+               0*inteldrmfb)
+                       if [ "$HWACCEL" != "0" ]; then
+                               set_property ro.hardware.hwcomposer ${HWC:-intel}
+                               set_property ro.hardware.gralloc ${GRALLOC:-intel}
+                               set_drm_mode
+                       fi
+                       ;;
+               0*radeondrmfb|0*nouveaufb|0*svgadrmfb|0*amdgpudrmfb)
                        if [ "$HWACCEL" != "0" ]; then
                                set_property ro.hardware.gralloc ${GRALLOC:-drm}
                                set_drm_mode

[lambdadroid]

On Tue, Jun 04, 2019 at 10:40:24AM -0700, Mauro Rossi wrote:
> Very nice reports from both Micheal and lambdadroid
>
> I have conducted some tests with ChromeOS minigbm (gralloc0 API) with
> drm_framebuffer support added in minigbm,
> Intel was working, but amdgpu not working out-of-the-box and radeon,
> nouveau not working (for unknown reasons).
>
> I have not tried yet drm_hwcomposer (master branch with hwc2 API), neither
> with ChromeOS minigbm (gralloc0 API) nor with intel minigbm (gralloc1)
>
> For people wanting to try IA-HardareComposer with intel minigbm (gralloc1)
> i.e. the Android graphic stack of Celadon suitable for Intel GPUs,
> here are the branches fixed for build and experimentally tested with
> oreo-x86 (they boot ok).
>
> [1] https://github.com/maurossi/minigbm/commits/minigbm_intel (hint: git
> clone to external/ as minigbm_intel and checkout minigbm_intel

> <https://github.com/maurossi/minigbm/commits/minigbm_intel>)

> [2] https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24 (hint:
> git clone to external/ and checkout 2019-Apr-24

> <https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24>)

>
> intel minigbm (gralloc1 API) module has been named 'gralloc.intel'
> IA-Hardware-Composer (hwc2 API) module has been named 'hwcomposer.intel'
>
> Here follow the necessary git diff changes in device/generic/common to
> build with gralloc1 support with IA-Hardware-Composer hwc two:
>
> NOTE: remember that these changes will most probably break other drivers,
> which are not patched for gralloc1 compliance,
> I tried if amdgpu, radeon, nouveau were by any chance working, but they are
> not booting.
>
> I don't know if BOARD_USES_GRALLOC1 allows for SurfaceFlinger runtime
> fallback to gralloc0,
> does someone know that?

As far as I know, this is an Intel specific variable.
It does not have any relevance for AOSP.

I think it is only used for some Intel specific things like their
Gralloc1 patch for Mesa [1] or in MediaSDK_OMX_IL.

And that reminds me: The Gralloc1 patch for Mesa [1] is also needed for
Intel's hardware accelerated video codec implementation.
I forgot to mention that.

[1]: https://github.com/me176c-dev/android_hardware_mesa/commit/50df97d88a4820f38d143b990d97baa0554a7b38

>
> Mauro
>

[Povilas Staniulis]

Ideally, you should use XML manifests and the repo tool, not manual git
clones.

On 2019-06-04 20:40, Mauro Rossi wrote:
> Very nice reports from both Micheal and lambdadroid
>
> I have conducted some tests with ChromeOS minigbm (gralloc0 API) with
> drm_framebuffer support added in minigbm,
> Intel was working, but amdgpu not working out-of-the-box and radeon,
> nouveau not working (for unknown reasons).
>
> I have not tried yet drm_hwcomposer (master branch with hwc2 API),
> neither with ChromeOS minigbm (gralloc0 API) nor with intel minigbm
> (gralloc1)
>
> For people wanting to try IA-HardareComposer with intel minigbm
> (gralloc1) i.e. the Android graphic stack of Celadon suitable for
> Intel GPUs,
> here are the branches fixed for build and experimentally tested with
> oreo-x86 (they boot ok).
>
> [1] https://github.com/maurossi/minigbm/commits/minigbm_intel
> <https://github.com/maurossi/minigbm/commits/minigbm_intel> (hint: git

> clone to external/ as minigbm_intel and checkout minigbm_intel
> <https://github.com/maurossi/minigbm/commits/minigbm_intel>)
> [2] https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24

> <https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24> (hint:
> git clone to external/ and checkout 2019-Apr-24

> <https://github.com/maurossi/IA-Hardware-Composer/tree/2019-Apr-24>)

> +if["$HWACCEL"!="0"];then

> +                            set_property ro.hardware.hwcomposer
> ${HWC:-intel}
> +                            set_property ro.hardware.gralloc
> ${GRALLOC:-intel}
> +                            set_drm_mode
> +fi
> +;;

> +0*radeondrmfb|0*nouveaufb|0*svgadrmfb|0*amdgpudrmfb)

> https://github.com/intel/minigbm <https://github.com/intel/minigbm>

> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to android-x86...@googlegroups.com

> <mailto:android-x86...@googlegroups.com>.

> To post to this group, send email to andro...@googlegroups.com

> <mailto:andro...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/android-x86.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/android-x86/332aab14-e186-47ef-bfb9-9df4052dadf4%40googlegroups.com
> <https://groups.google.com/d/msgid/android-x86/332aab14-e186-47ef-bfb9-9df4052dadf4%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Michael Goffioul]

On Tue, Jun 4, 2019 at 12:32 PM lambdadroid <lambd...@gmail.com> wrote:
> I think someone reported an issue with those proprietary files back
> then on the Android-IA repository, where the hardware accelerated codecs
> would freeze with certain videos and produce a greenish screen. This
> issue is still present. Otherwise it works quite well for most videos.

That was me. I'm glad you confirmed the problem still exists, that
avoids me wasting me time with android-ia/celadon again. One of the
limitations with the intel codecs is that there was no mpeg2
hw-accelerated decoding. Is it still the case?

Michael.

[lambdadroid]

On Tue, Jun 04, 2019 at 02:55:02PM -0400, Michael Goffioul wrote:
> On Tue, Jun 4, 2019 at 12:32 PM lambdadroid <lambd...@gmail.com> wrote:
> > I think someone reported an issue with those proprietary files back
> > then on the Android-IA repository, where the hardware accelerated codecs
> > would freeze with certain videos and produce a greenish screen. This
> > issue is still present. Otherwise it works quite well for most videos.
>
> That was me.

Ah, I thought it was you but I wasn't entirely sure :)

> I'm glad you confirmed the problem still exists, that
> avoids me wasting me time with android-ia/celadon again.

I do wonder if there is a way to investigate/fix this issue now that the
code is open-source. I haven't had time to check it myself...
Unfortunately the code goes through so many layers
(Android -> OMX -> MediaSDK -> VAAPI)
that it's really annoying to debug anything.

Anyway, if you still have that test video from the issue I
could try playing it on my tablet.

I had a similar issue on Nougat when playing the splash screen video
from the "YouTube Kids" app. This is the one that still happens on Pie,
but I'm not 100% sure if it's the same issue as the one you reported.

> One of the
> limitations with the intel codecs is that there was no mpeg2
> hw-accelerated decoding. Is it still the case?

There is definitely code for MPEG-2 in their implementation,
but I haven't tested it yet.
Seems like they enabled it in Celadon last year [1].

Do you have a particular test video you would like me to test?
Should be simple to enable it on my device for testing.

[1]: https://github.com/projectceladon/device-androidia/commit/b209872633c1b7bd4f6ab301977d26541bc44363

>
> Michael.
>
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.

> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAB-99LuyYhZ2fMHR5pN2sPV%2BdGb_Yzkfn9YGfTA04ZHdcGoWJQ%40mail.gmail.com.

[Michael Goffioul]

On Tue, Jun 4, 2019 at 3:22 PM lambdadroid <lambd...@gmail.com> wrote:
> > I'm glad you confirmed the problem still exists, that
> > avoids me wasting me time with android-ia/celadon again.
>
> I do wonder if there is a way to investigate/fix this issue now that the
> code is open-source. I haven't had time to check it myself...
> Unfortunately the code goes through so many layers
> (Android -> OMX -> MediaSDK -> VAAPI)
> that it's really annoying to debug anything.
>
> Anyway, if you still have that test video from the issue I
> could try playing it on my tablet.
>
> I had a similar issue on Nougat when playing the splash screen video
> from the "YouTube Kids" app. This is the one that still happens on Pie,
> but I'm not 100% sure if it's the same issue as the one you reported.
>
> > One of the
> > limitations with the intel codecs is that there was no mpeg2
> > hw-accelerated decoding. Is it still the case?
>
> There is definitely code for MPEG-2 in their implementation,
> but I haven't tested it yet.
> Seems like they enabled it in Celadon last year [1].
>
> Do you have a particular test video you would like me to test?
> Should be simple to enable it on my device for testing.

This was documented in this PR:
https://github.com/android-ia/device-androidia/pull/65
but unfortunately, this has been deleted from github. From what I
remember, it was a HLS stream, the bip-bop test clip, but I don't
remember the URL.

Michael.

[Michael Goffioul]

I agree. Everybody's time is limited. There are nice experiences (with
good results) being conducted around android-x86 code base, but the
amount of manual steps required in order to just get the right source
tree is such that the average person will just look away for something
easier. But a good part of those manual steps could be avoided by
publishing a custom manifest. That being said, creating and
maintaining such custom manifest also takes time.

> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.

> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/abd23ff1-40f6-2451-50dc-b1a192ef65bf%40gmail.com.

[Povilas Staniulis]

Yes, but writing a manifest is usually easier than writing a custom
build script to get the right sources.
Sorry for being off-topic.

[Chih-Wei Huang]

lambdadroid <lambd...@gmail.com> 於 2019年6月5日 週三 上午12:32寫道：

I have no doubt about that.
The big issue of our current implementation is
we don't have hwcomposer and the graphic stack
doesn't support YV12. As a result it needs the CPU
to convert the hardware decoded format to RGB565.
The bigger the video resolution is, the worse performance it has.

> However, it's probably mainly optimized for their new media stack...
> Not sure when my patches are going to break, the old VAAPI driver is not
> maintained very well...
>
> Note: Their OMX implementation strictly requires their fork of minigbm
> as gralloc HAL at the moment, i.e. https://github.com/intel/minigbm
>
> Since it doesn't have a FB HAL, you need a Graphics Composer
> (hwcomposer) HAL. drmfb-composer [1] works well for older hardware;
> for newer hardware, something more sophisticated like drm_hwcomposer or
> IA-Hardware-Composer may also do the job.

> Just wanted to mention this since I've been using this for a few months
> now without major problems. Your mail reminded me to post this here :)

Glad to see you made it work.
However, it requires Intel's graphic stack as you said.
How to integrate them into our codebase without
breaking the support of other GPUs is a big challenge...


> [1]: https://github.com/me176c-dev/drmfb-composer

[lambdadroid]

> However, it requires Intel's graphic stack as you said.
> How to integrate them into our codebase without
> breaking the support of other GPUs is a big challenge...
>

Selecting Intel's minigbm is mainly a matter of setting a system
property (i.e. ro.hardware.gralloc). For all other modules/required
patches it should be simply to make them conditional to Intel at
runtime.

I believe that, at least for Intel, drm_framebuffer or preferably
drmfb-composer should provide quite a stable solution, even for older
hardware. For newer hardware, a proper hwcomposer like drm_hwcomposer or
IA-Hardware-Composer would be obviously preferred, but those will tend
to break more likely due to the additional complexity.

I was wondering: Is the VAAPI hardware video acceleration only usable if
you use Intel graphics? Or can it also be used indirectly like with a
Intel CPU but a AMD GPU?
This would definitely not work with Intel's stack.

>
> > [1]: https://github.com/me176c-dev/drmfb-composer

>
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAKc24n2633diUQHsgAXFNxfBePOxiQ0R_BFsaEvrV1icZUz-cQ%40mail.gmail.com.

[lambdadroid]

On Tue, Jun 04, 2019 at 02:55:02PM -0400, Michael Goffioul wrote:

I have just tested it. MPEG2 decoding seems to work without any problems
for all my test files. Seems like they fixed it.
Thanks for suggesting it, I have added it to the builds for my device :)

The YouTube Kids splash screen video still leads to GPU freezes.

The ExoPlayer demo videos I have tested (bip bop, etc) seem to be
working fine. I think you had some custom media file back then.
Downloaded from Google Drive or so, I don't remember exactly.

>
> Michael.

>
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAB-99LuyYhZ2fMHR5pN2sPV%2BdGb_Yzkfn9YGfTA04ZHdcGoWJQ%40mail.gmail.com.

[Michael Goffioul]

On Wed, Jun 5, 2019 at 2:44 PM lambdadroid <lambd...@gmail.com> wrote:
>
> On Tue, Jun 04, 2019 at 02:55:02PM -0400, Michael Goffioul wrote:
> > On Tue, Jun 4, 2019 at 12:32 PM lambdadroid <lambd...@gmail.com> wrote:
> > > I think someone reported an issue with those proprietary files back
> > > then on the Android-IA repository, where the hardware accelerated codecs
> > > would freeze with certain videos and produce a greenish screen. This
> > > issue is still present. Otherwise it works quite well for most videos.
> >
> > That was me. I'm glad you confirmed the problem still exists, that
> > avoids me wasting me time with android-ia/celadon again. One of the
> > limitations with the intel codecs is that there was no mpeg2
> > hw-accelerated decoding. Is it still the case?
>
> I have just tested it. MPEG2 decoding seems to work without any problems
> for all my test files. Seems like they fixed it.
> Thanks for suggesting it, I have added it to the builds for my device :)
>
> The YouTube Kids splash screen video still leads to GPU freezes.
>
> The ExoPlayer demo videos I have tested (bip bop, etc) seem to be
> working fine. I think you had some custom media file back then.
> Downloaded from Google Drive or so, I don't remember exactly.

Neither do I... I have a series of test videos (some of them on my
Google Drive, indeed), but I don't remember which one caused the
freeze. I thought it was a public HLS stream with bip-bop content.
However the freeze was really bad, making the whole device
unresponsive, and eventually reboot. Do you have a public manifest to
share for your build, I might just give it a spin on my device?

Michael.

[lambdadroid]

For the YouTube Kids splash screen video, the screen freezes for a
while. Eventually, the kernel manages to reset the GPU so it's just
unresponsive while the video is playing. No reboots for me.

I'm afraid I cannot you with a build or manifest that will work as-is,
since my builds are not based on Android-x86. :/
However, most of my repositories will probably work if added to
Android-x86. But setting up configuration files etc will require some
additional work...

I have plans to try it on Android-x86 myself,
but I haven't really found the time for it (yet)..

If you want to make those changes, here is rougly how to do it:

0. Sync some additional repositories.
https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/lineage_me176c.xml#L33-L37
Make sure Mesa has https://github.com/me176c-dev/android_hardware_mesa/commit/08be6944d1855f83e3ac0920f8ed53e2320fa6b6

1. You need to use Intel minigbm with some hwcomposer.
(https://github.com/intel/minigbm)
For older hardware, https://github.com/me176c-dev/drmfb-composer
is most likely to work stable out of the box.

2. Set several variables in BoardConfig.mk:
https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/BoardConfig.mk#L87-L90
https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/BoardConfig.mk#L98-L103

3. Build libmfxhw64/libmfxhw32, libmfx_omx_core, libmfx_omx_components_hw

4. Add some config files:
https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/media/media_codecs.xml
https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/media/mfx_omxil_core.conf

So yeah, unfortunately this is quite a bit of work :/

> Michael.
>
> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAB-99Lv0agx-EU5LHruJnY8uaqyxgcE2DX2_LH38WGZaiNnFbw%40mail.gmail.com.

[Michael Goffioul]

Chih-Wei, do you have any plan in integrating those patches in pie-x86?

[Chih-Wei Huang]

Michael Goffioul <michael....@gmail.com> 於 2019年6月14日 週五 上午3:30寫道：

>
> Chih-Wei, do you have any plan in integrating those patches in pie-x86?

Yes, definitely.
Will resume pie-x86 after 8.1-r2 release.
Thank you very much for the patches!


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Michael Goffioul]

On Wed, Jun 5, 2019 at 3:51 PM lambdadroid <lambd...@gmail.com> wrote:
> If you want to make those changes, here is rougly how to do it:
>
> 0. Sync some additional repositories.
> https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/lineage_me176c.xml#L33-L37
> Make sure Mesa has https://github.com/me176c-dev/android_hardware_mesa/commit/08be6944d1855f83e3ac0920f8ed53e2320fa6b6
>
> 1. You need to use Intel minigbm with some hwcomposer.
> (https://github.com/intel/minigbm)
> For older hardware, https://github.com/me176c-dev/drmfb-composer
> is most likely to work stable out of the box.
>
> 2. Set several variables in BoardConfig.mk:
> https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/BoardConfig.mk#L87-L90
> https://github.com/me176c-dev/android_device_asus_K013/blob/fad3237563dd6a923b025859077c95dd0221ad91/BoardConfig.mk#L98-L103
>
> 3. Build libmfxhw64/libmfxhw32, libmfx_omx_core, libmfx_omx_components_hw
>
> 4. Add some config files:
> https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/media/media_codecs.xml
> https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/media/mfx_omxil_core.conf

Using the instructions above, I was able to compile and include
Intel's codecs into my Androie pie build (Intel's minigbm +
drmfb-composer). But the problems that existed in Android-IA are still
present on my Baytrail platform:
- this stream freezes the entire display:
https://drive.google.com/open?id=1yTnESs23lfe6nR4oj7BNCnHQ4DfiiyM6
- no de-interlacing

[Michael Goffioul]

If anybody is interested, I've posted ANR and logcat when the freeze occur:
- https://drive.google.com/open?id=1eI6PwCvIlbRj7fU69nMTs1d1Z0-XFM_1
- https://drive.google.com/open?id=1yTO40cZrcMdBQyayXuFzE5pD9u6b4FJu

[lambdadroid]

Confirmed. Same problem on my tablet.

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAB-99Lv9mrQPOEieLk9Y%3D2EodL61Mxkeu-3cgJBxtr%2B851%3D_zw%40mail.gmail.com.

[endrich...@googlemail.com]

hei guys,

i followed the steps above and built eversthing needed into an android x86 pie image.

however i can't figure out how to use the new omx codecs.

how do i switch from ffmpeg omx to intel omx? media_codecs.xml has only intel omx entries and all libmfx*.so objects are in the image.

thanks

[endrich...@googlemail.com]

Sorry, nervermind.

Forgot to build libstagefrighthw, mfx_omxil_core.conf was in the wrong folder and i didn't set the kernel params to all intel.

Also the patches mentioned in vaapi and mediasdk where missing.

it now works now and i've fluid 4k on my N3350.

thanks for all hints in this thread!

[Daniel Cheung]

Can you post a more complete & newbie friendly instruction? I'm on Z8300 and would love to improve the HW video acceleration on my tablet.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/7ee59cb2-3da0-4914-a5be-af959143cbabn%40googlegroups.com.

[endrich...@googlemail.com]

Sure,

but be aware that i am no expert aswell, so i pretty sure have some missunderstandings.

the first thing you should try is to boot your device with kernel params HWC=intel and GRALLOC=intel (to use intels minigbm fork) - i dont know which hwcomposer "intel" is pointing at here.

a simple way to do this is to use the default android 9 (pie) source and select hwcomposer.intel gralloc.intel boot option (Debug mode).  hit enter and type exit+enter 2 times to boot android.

no other boot option worked for me in the end so this seems required to go on?!

as others mentioned minigbm should work with other hwcomposers, but didnt for me... at least not with the following solution.

if this boots fine on your device you need to go on and get the needed repos.

i cloned

https://github.com/projectceladon/MediaSDK.git -b celadon/p/mr0/master

https://github.com/projectceladon/mediasdk-omx.git 

https://android.googlesource.com/platform/hardware/intel/common/libstagefrighthw

i placed them all in hardware/intel/common

the mesa patches and intel minigbm should already be in current pie sources.

in the mediasdk repo i changed the CFLAGS in mfx_defs.mk to not get build errors.

i also applied the patches mentioned above to vaapi, libstagefrighthw, mediasdk and mediasdk-omx. those are all attached.

the changes needed in the device/generic/common boardconfig.mk are also attached.

after you applied the patches build each repo with entering it and type mma (after you setup your build env like shown here https://www.android-x86.org/source.html)

you can now either push the *.so files to the folders on your device or build a new iso.

last thing needed was to add OMX.inte.hw* MediaCodecs to /etc/media_codecs.xml (this is also shown above)

and place the (also attached) mfx_omxil_core.conf in /vendor/etc/ (as shown by MFX_OMX_CONFIG_FILE_PATH in mediasdk-omx/omx_utils/include/mfx_omx_defs.h)

i hope i didnt forget anything.

greets.

[endrich...@googlemail.com]

Is anyone here following this approch? I currently have an issue playing Videos in portrait mode as they are not displayed rotated.

Any ideas are very welcome.

[endrich...@googlemail.com]

So it turns out this is probably not possible using the "old" vaapi drivers with i965_drv_video.

It seems IA-Hardware-Composer is using vaRenderPicture (see IA-Hardware-Composer/common/compositor/va/varenderer.cpp) with set pipe_param.rotation_state, which is not supported by the old vaapi drivers.

The newer media-driver seem to evaluate this flag and rotates the video accordingly.

Does anyone know another way to rotate the frames?

Another issue is, that screencap (screenshot utility) can not record the frame and returning black images.

[Alexander Kuznetsov]

I have missunderstandings in this line "in the mediasdk repo i changed the CFLAGS in mfx_defs.mk to not get build errors."

What exactly need change in this file mfx_defs.mk ?

Or maybe someone will attach OMX.inte.hw *,  *.so   files and I can just place them in folders without building from repositories.

Thank you for your attention, I will be glad to receive your answers.

вторник, 19 января 2021 г. в 14:39:39 UTC+3, endrich...@googlemail.com:

[endrich...@googlemail.com]

I just set the following:

MFX_CFLAGS := -DANDROID \

              -Wno-error=unused-parameter \

              -Wno-error=missing-field-initializers \

              -Wno-error=sign-compare \

              -Wno-error=absolute-value \

              -Wno-error=unused-function \

              -Wno-error=unknown-pragmas \

              -Wno-error=unused-variable \

              -Wno-error=unused-value \

              -Wno-error=overloaded-virtual

to get it build. 

Btw. i managed to get it running ..... finally, i just needed to not use the GVT in IA-Hardware-Composer

bool GpuDevice::IsGvtActive() const {

-  return gvt_active_;

+  ITRACE("Running on bare-metal mode");

+  return false;

 }

which is used to switch between virtual and bare metal machine. i guess intel is trying to focus on virtualization.

[BrokenE39]

Hi endrich,

May I ask which version of Android and which kernel are you using in your successful built? I couldn't get it to build previously with instructions on this thread (before yours) but failed. And then I tried to see if Kernel 5.10+ would fix the problem but couldn't get it to build at all.

Thanks

[endrich...@googlemail.com]

Hei,

sure thing, kernel version is 4.19.122 and im on the Android 9 PI branch.

all changes i made should be mentioned above.

[BrokenE39]

Awesome. I'll give it another try this weekend. Also, did you device ever crash after waking up from sleep? From what I can tell it has something to do with the GPU driver. Just wondering if you had the same problem and it went away after you compiled the new driver.

[Scripter Provider]

Hey bro this is the Android-x86 forum. Please do not be off topic here. Or we will report you to Google.

I use old gmail (for android 2.3) just for fun

On Aug 18, 2021 9:42 PM, "victoria...@gmail.com" <victoria...@gmail.com> wrote:

ADD us on App Wickr me... Bowe420 ,Our shipping and delivery is 100% safe and convenient. Steep out All 420 

strains,all body pain killers pills,Pharmaceutical,research chemicals.

You needed. Quality Smoke 💨 And Meds 💊

Remember we Can go anywhere at anytime as long as you request

We have the following drugs 💉 in stock.and  ship 📦 as well.

- Cannabis Temazepam - Xanax Shrooms ( Pfizer LongBars, Upjohn), Oxycodone/Oxycontin Cocaine -

- Heroine

Roxicodone, Diazepam, Valium, Subutex/Suboxone, Ritalin, Adderall, Tramadol,Vicodin, Ecstasy, Ketamine, MDMA, LSD, 

Fentalyn patches, Nembutal, Klonopin, Ativan, Dilaudid, AMBIEN,Norcos, Hydrocodone, Methadone, Crystal Meth Crack, 

Mexican blues 30'S, Black Tar H, Viagra many more.

Hit us: merviel...@gmail.com

Wickr me... Bowe420

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/f4c44aca-02cf-4ca3-a16d-34e639e14dd9n%40googlegroups.com.

[endrich...@googlemail.com]

I disabled all sleep functionallity, so i actually dont know if there is a problem.