UHD Video decoding/playback performance

[Florian E]

Hi guys,

im struggeling with the current video decoding/playback performance and im currently stuck.

my test hardware is a J1900 and N4100 intel which should be able to playback 3840x2160 videos but are not with android x86.

as comparison i installed OpenELEC and all sample videos ran flawless so the hardware and the drivers should not be the problem i guess?!

i build android x86 7.1.2 and android 8 to try to get the best out of it but both have poor video performance.

i also tried various kernel versions and updated libva and vaapi from intel git repositories without any improvements.

logcat states hwaccel is enabled so all should be good.

i attached a 1080p (flawless) and a 4k logcat but they seem not to differ

so my guess its somewhat android related, but i have no clue how to get further into this. 

i tried: vlc, kodi, exoplayer and the pre-installed gallery media player - all have the same stuttering issue.

if you want to re-produce, you can get the exoplayer demo and run any UHD sample.

so can you guys help me out a little bit?

which layer is next? where can i start?

thanks

[Michael Goffioul]

The problem is that the video decoding layer in android-x86 is not fully hw-accelerated. Only the decoding part is, but the rendering (scaling to screen size and dumping to video card) is still software based. This is the bottleneck, and I'm afraid your hardware is not beefy enough. This is a known limitation of the ffmpeg based codecs in android-x86.

If you look into this: https://osdn.net/projects/android-x86/scm/git/external-stagefright-plugins/blobs/pie-x86/omx/SoftFFmpegVideo.cpp

decoding is handle in SoftFFmpegVideo::decodeVideo, then the decoded frame is rescaled in SoftFFmpegVideo::drainOneOutputBuffer.

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 view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/855926e0-7ecc-43cc-8ac2-36119488030bo%40googlegroups.com.

[endrich...@googlemail.com]

Hey,

thanks for your answer and the hint to the correct sources.

Im now a few days into this and build things my own to do some testings.

i started with this old ffmpeg player git repo:

https://github.com/HausnerR/ffmpeg-android-example 

which requiers a few changes to build.

also i cloned and built ffmpeg 3.4 to got it running.

I now can decode the video and even if its completely software decoding i got better performance than using android x86 default. every frame takes about 90-100ms. 

as in the default player the image freezes completely, runs a few frames very smooth and freezes again :( (2160p!)

however to find the issue, i need to add hw accel - but i cannot find out how to add hardware acceleration to my ffmpeg build. is there any chance to do it?

currently my ffmpeg get_format callback does not receive anything in pix_fmts, i guess vaapi needs to be added somehow...

any help is welcome!

Greets

[Michael Goffioul]

Make sure VAAPI-enabled codecs are compiled in, then look at external/stagefright-plugins/omx/ffmpeg_hwaccel.c to see how hwaccel is initialized and handled.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/f2e5345c-317b-4d50-bcc2-7ca07f2a55dcn%40googlegroups.com.

[endrich...@googlemail.com]

do you got any more details on how to get the codec compiled in?

i already added ffmpeg_hwaccel.c to my project and it also compiles fine.

but i does not find the codec and keeps saying hw codec disabled pix_fmts=0

[Michael Goffioul]

I don't know how you compile ffmpeg, but the relevant parts for android-x86 are in external/ffmpeg/android/config-x86-x86.mak and external/ffmpeg/android/config-x86_64-x86_64.mak, look for VAAPI. There are also corresponding entries in external/ffmpeg/android/include/config-XXX.h. If you use the ffmpeg configure script, then the easiest is to make sure to use the flags that enable support for VAAPI accel (obviously, you'll also need the libva library). In the end, what you want is to have the relevant vaapi_XXX.c files compiled in your libavcodec.so library (eg. external/ffmpeg/libavcodec/vaapi_h264.c).

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/c7060560-5f63-4836-82d9-49624422081bn%40googlegroups.com.

[Huy Minh Bui]

Can I upgrade to newer version of ffmpeg and vaapi ? I try to merge the latest release of ffmpeg and it seems to change a lot. The most worry part here is that ffmpeg_vaapi.c will be deleted when merging.

Vào Th 6, 24 thg 7, 2020 vào lúc 23:17 Michael Goffioul <michael....@gmail.com> đã viết:

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

[Huy Minh Bui]

Vào Th 7, 25 thg 7, 2020 vào lúc 14:58 Huy Minh Bui <buin...@gmail.com> đã viết:

[Michael Goffioul]

HW acceleration API has been significantly revamped in the recent ffmpeg releases. The main point is whether the glue code in external/stagefright-plugins/omx/ffmpeg_hwaccel.c is still valid. I can't answer that, but the easiest is just to give it a try.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CANPBqUGOXh3aUiwVkqFbK_Lnnf-E%3DuoOEbwh02q8hUhBxqOMOQ%40mail.gmail.com.

[endrich...@googlemail.com]

thanks for your answers!

i made some progress.

just fyi: I got an ubuntu vm running for compiling ffmpeg (3.4 from  http://ffmpeg.org/releases/) and i used the android x86 config files (config.mak) and just ran make.  

sadly i was not able to build the default ffmpeg for android x86. (note: i could not find a way to point to libva and vaapi out of the ffmpeg folder so i just placed both inside for build.)

so finally it built, but i ran into link errors trying to use the ffmpeg libs in my app which i could not get fixed. 

so i gave up on this tried a few other things.

first i changed SoftRenderer to show me every frame, this is what causes the video to stutter and stop (NuPlayerRenderer sets Int32("render") to 0 if the frame is too late)

obiousily this did not help, as the frames are just too late to be rendered

second thought was to update ffmpeg to a newer version - and i found this repo:

https://github.com/tanersener/mobile-ffmpeg 

this offers alot but no vaapi libva support.

so i cloned it, built it with the newest ndk and changed my demo app do use this repo at ffmpeg 4.3.1.

first run kinda shocked me as the frames took arround 300ms for 2160p. i did some research and as metioned alot of the methods used are deprecated by now.

but the main point seemed to be that thread_count default value is set to 1.

found here: https://stackoverflow.com/questions/50481965/ffmpeg-4-0-decoded-h264-slower-than-old-version-onen2-8-14

so i changed it to 4 which resulted my demo app to get me  a frame each ~90ms instead of 300ms+.

back to default android x86 SoftFFmpegVideo.cpp i checked the threads aswell.

to do this i got to SoftFFmpegVideo.cpp and logged with ALOGI("mCtx thread_count %i", mCtx->thread_count); before the context was opened with avcodec_open2.

and my log pointed out that thread_count always returned 1!

so i just changed this to mCtx->thread_count = 4; one line before opening the ctx. (which is the core count of my CPU)

first try: this change did not help at all, as hw acceleration still is only using about 60% cpu .... 

so i tried to disabled it by returning 0 in ffmpeg_hwaccel_init and use soft decoding.

the result was surprising to me: the change worked and my cpu is now at 300%: but my 2160p video is running fluid!

some of my test videos still have peaks up to 60ms per frame and rendering is sometimes at 30ms but most of the time one frame just takes <1ms to be decoded!

even the 1080p video is dropped from 10ms per frame to <1ms...

im not sure whats behind all this but seems that using hwaccel slows things down compared to using all cpu cores available.

maybe there is a way to use all threads and hardware acceleration?

[Michael Goffioul]

These are interesting findings. If you have the opportunity, it would be interesting to determine where is the bottleneck in SoftFFmpegVideo.cpp (the operation that takes most of the time). What do you actually measure in the code for the timing that you've reported? Also how does single-threaded sw-decoding compare to multi-threaded sw-decoding, or single-threaded sw-decoding vs. single-threaded hw-decoding?

Note that the reason multi-threading decoding is not enabled with hwaccel is because it was known to be unstable:

https://osdn.net/projects/android-x86/scm/git/external-stagefright-plugins/commits/f0bdeee0f5095b72f1b950a66c2a4d27881afcd9

Michael.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/2ffae337-2122-4180-adde-fcb76752835en%40googlegroups.com.

[endrich...@googlemail.com]

Okay i will try to get you as many information as possbile.

to measure the time, i used the c code from the github project i mentioned earlier:

so in SoftFFmpegVideo.ccp i added:

struct timespec timespec1, timespec2, diff;

// http://www.guyrutenberg.com/2007/09/22/profiling-code-using-clock_gettime/

struct timespec timespec_diff(struct timespec start, struct timespec end) {

    struct timespec temp;

    if ((end.tv_nsec - start.tv_nsec) < 0) {

        temp.tv_sec = end.tv_sec - start.tv_sec - 1;

        temp.tv_nsec = 1000000000 + end.tv_nsec - start.tv_nsec;

    } else {

        temp.tv_sec = end.tv_sec - start.tv_sec;

        temp.tv_nsec = end.tv_nsec - start.tv_nsec;

    }

    return temp;

}

#define start_time_measure() \

        clock_gettime(CLOCK_MONOTONIC, &timespec1);

#define stop_time_measure(title) \

        clock_gettime(CLOCK_MONOTONIC, &timespec2); \

        diff = timespec_diff(timespec1, timespec2); \

        ALOGI("%-30s timediff: %d.%09ld", title, (int) diff.tv_sec, (long int)diff.tv_nsec);

To measure the time a frame takes to decode i placed start_time_measure() in 

SoftFFmpegVideo::decodeVideo() 

before 

initPacket(&pkt, inHeader);

and stop the measurement  stop_time_measure("decoded frame timediff") before 

if (!inQueue.empty()) {

so this gave me the time for one frame in total, but to get more detail i added more time measurements and just wrapped avcodec_decode_video2  and ffmpeg_hwaccel_get_frame.

the rendering measurements are just at the start and end of SoftwareRenderer::render

the results (2 random frames 2160p):

(just FYI)
SoftFFmpegVideo: drainOneOutputBuffer: frame_width=4096 frame_height=2304 buffer_width=4096 buffer_height=2304 ctx_width=4096 ctx_height=2304 mIsAdaptive=0 

 

with enabled hw accel 

SoftFFmpegVideo: avcodec_decode_video2 frame timediff: 0.002015606

SoftwareRenderer: rendered frame timediff: 0.041044006

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.052104785

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.002841501

SoftwareRenderer: rendered frame timediff: 0.032052146

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.053815337

hw accel disabled 1 thread

SoftwareRenderer: rendered frame timediff: 0.025680238

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.126694790

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000397

SoftwareRenderer: rendered frame timediff: 0.039934787

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.103284072

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000708

hw accel disabled 4 threads:

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.000330084

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000565

SoftwareRenderer: rendered frame timediff: 0.037844522

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.000624958

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000624

SoftwareRenderer: rendered frame timediff: 0.039603814

for 1080p:

SoftFFmpegVideo: drainOneOutputBuffer: frame_width=1920 frame_height=1080 buffer_width=1920 buffer_height=1080 ctx_width=1920 ctx_height=1080 mIsAdaptive=0

with enabled hw accel:

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.001644286

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.008594033

SoftwareRenderer: rendered frame timediff: 0.006332160

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.000907719

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.009753924

SoftwareRenderer: rendered frame timediff: 0.007563253

hw accel disabled 1 thread  

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.032009313

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000480

SoftwareRenderer: rendered frame timediff: 0.008101632

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.031118209

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000564

SoftwareRenderer: rendered frame timediff: 0.007952964

hw accel disabled 4 threads:

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.000213362

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000840

SoftwareRenderer: rendered frame timediff: 0.008062460

SoftFFmpegVideo: avcodec_decode_video2 frame timediff timediff: 0.000351297

SoftFFmpegVideo: ffmpeg_hwaccel_get_frame frame timediff timediff: 0.000000768

SoftwareRenderer: rendered frame timediff: 0.008163613

i also checked the commit you mentioned and tried setting thread_count to 4 on every occurance, but this did not change anything when hw accel is enabled.

it seems that to get further now, i'd need to look into ffmpeg itself?

if i can help with anything, please let me know.

[Michael Goffioul]

Can you send a patch with the mods, it'll be easier to see where the timing is taking place? When I look at the values, they honestly do not make sense (e.g. there's a factor of ~100x for avcodec_decode_video2 between 1 and 4 threads with hw disabled, while "SoftwareRenderer: rendered frame" are about the same).

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/9106da94-0f71-441d-a784-5bac0c86e0f2n%40googlegroups.com.

[endrich...@googlemail.com]

Sure, please find the patches for 

external/stagefright-plugins

 - disabled hw accel

 - set threads to 4

 - added time measurement

and frameworks/av/media/libstagefright

 - render all frames

 - added time measurement

 - converting to BGRA_8888 by default for better video quality

but isn't it normal that the rendering here always takes the same time? i just changed the ffmpeg threads for decoding.

[endrich...@googlemail.com]

Hei guys,

i spent the last few weeks getting ffmpeg 4.3 running and implemented VAAPI hardware decoding with this version.

needed to manually check the config files as my ./configure didnt work at all aswell as some code hacks during unfixable compile errors.

Today i finally managed to get it running using the code from the old ffmpeg_vaapi.c which i added to ffmpeg_hwaccel.c

the result is pretty disappointing as it is as slow as before upgrading to the newer ffmpeg.

its still just using maximum of 80% cpu when told to use 4 threads it does not make any difference. (with software decoding cpu goes up to 380%)

one 4K frame is still arround 38 to 75ms.

i tried to get a little bit more into want is happening here at all.

so as michael said already not everything happens on the GPU, it is really just the decoding - which is probably fast and which is why we only see the low cpu usage!

the problem here actually seems to be that we need to "download" the frame from the GPU to CPU to do color conversion and rendering on screen.

this action seems to be the most time consuming step in all of this.

as i converted the code from ffmpeg_vaapi.c i added a time measurement arround:

    start_time_measure();

    err = av_hwframe_transfer_data(output, input, 0);

    if (err < 0) {

        ALOGE("Failed to transfer data to "

               "output frame: %d.\n", err);

        goto fail;

    }

    stop_time_measure("av_hwframe_transfer_data");

which is excalty the spot where 30 - 60ms pass by. so downloading the decoded frame with av_hwframe_transfer_data seems to actually be the bottleneck here.

this is at least my understanding.

so is there anyone arround here who knows how to perform the color convertion, scaling and rendering on the GPU?

like is there still a chance to speed this up?

i mean the most smartphones play those videos with ease, so there has to be a way, right?

[Michael Goffioul]

Thanks for looking into this. You basically confirmed what I explained/suspected in one of my previous emails. Even though the outcome is disappointing, it's always better to understand what's happening. There's unfortunately no simple solution to this. The ffmpeg-based codec is not a real/full hw-accelerated one, scaling and rendering still happens in software. Changing that is not simple, if possible at all. In consumer devices, the GPU takes care of everything, from the decoding to the rendering.

One thing that might be worth looking into is using VAAPI to do the scaling, ffmpeg has support for scaling filters using VAAPI. So the idea would be to install a vaapi-powered filter in the ffmpeg pipeline to scale the frame down to the target size, which may be smaller than 4K resolution, so the transfer to the software side would be faster.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/07611040-49e7-4f02-b81b-671d6d4fc127n%40googlegroups.com.

[endrich...@googlemail.com]

I'd like to have a 4k screen with 4k video material working so scaling in vaapi is saldy not what i would need here.

im wondering why a 4k frame takes up to 70ms while a 1080 frame is copied in 10ms - which however seems to be normal performance (100fps) as stated here:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/d3c4715e-a14a-e1e5...@gmail.com/ 

maybe there is some place for improvements in downloading the frame from the gpu as the coment in hwcontext_vaapi.c states "It is possible to read much faster with a copy routine which is aware of the limitation"

but im afraid i dont understand whats going on here and - i guess - this isnt the right place to discuss this.

so it seems to be a dead end using the current decoding stack.

i'd prefer staying on this platform, but it seems there is no way at the moment.

Are there any news on using intels MediaSDK? mentioned in this thread:

https://groups.google.com/g/android-x86/c/wceA06d3NVs  

maybe there are some bugfixes in the past year fixing the freezes?

thanks for your support!

[Michael Goffioul]

I already attempted 3 times in the last few years to use the android-ia/celadon media stack on my device (either using directly android/ia/celadon or integrating the media stack into android-x86), and the freeze problem has always been there (it also didn't support deinterlacing, but that's another story). This is related to older chipset, which is not supported (no big tech company is interested in supporting older hardware). Newer hardware probably works fine, but that's not an option for me, I can't really spend time on this.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/508e525f-37a5-46f7-b9e4-09995fca6f6en%40googlegroups.com.

[endrich...@googlemail.com]

the thread states that it would only work on android x86 9+, so pie or newer.

is that true or is it possible to implement it into nougat and oreo?

if so, i might give it a try because pie is not yet usable for my purpose

[Michael Goffioul]

I don't know. Intel is only moving forward and they don't support nougat anymore. You might be able to retrofit, but it's entirely DIY.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/4f9063df-3bcb-4070-8733-0ca6907901d2n%40googlegroups.com.

[Huy Minh Bui]

By the way do you keep the source of ffmpeg 4.3 and vaapi that you made ?

Vào lúc 21:20:28 UTC+7 ngày Thứ Năm, 20 tháng 8, 2020, endrich...@googlemail.com đã viết:

[endrich...@googlemail.com]

Most of the changes are for logging and gathering information.

i did not keep the changes, as i switched to intels mediasdk, check here: https://groups.google.com/g/android-x86/c/wceA06d3NVs

what are you up to?

[Huy Minh Bui]

Just trying to update ffmpeg and vaapi to see if it's usable on nougat-x86.....

Vào lúc 21:13:07 UTC+7 ngày Thứ Hai, 11 tháng 1, 2021, endrich...@googlemail.com đã viết:

[endrich...@googlemail.com]

it should be usable, at least i got it running fine.

you might need to transfer the code in ffmpeg_vaapi.c to the newer version.

[Huy Minh Bui]

So today when checking ProjectCeladon github I realized that Intel is making a new i965_drv_video for new Intel iGPU from Gen 8~12

https://github.com/projectceladon/media-driver

https://github.com/projectceladon/gmmlib

Also I saw they have MediaSDK, don't know if that thing is helpful

https://github.com/projectceladon/MediaSDK

They also have libva 2.10.0 and they prepare to merge 2.11.0

https://github.com/projectceladon/libva

[youli...@gmail.com]

This is my ffmpeg_hwaccel.c for ffmpeg 4.3, https://github.com/youling257/stagefright-plugins/blob/cm-14.1/omx/ffmpeg_hwaccel.c

05-20 15:12:27.376 14400 14446 I HWACCEL : hw codec h264 enabled: s=0xf6c31000 ist=0xf6c34000 pix_fmts=0

05-20 15:12:33.744 14400 14474 I HWACCEL : hw codec h264 enabled: s=0xf377f000 ist=0xf6c34000 pix_fmts=0

05-20 15:12:38.083 14400 14492 I HWACCEL : hw codec hevc enabled: s=0xf6ed1000 ist=0xf6c34000 pix_fmts=0

05-20 15:12:44.956 14400 14515 I HWACCEL : hw codec hevc enabled: s=0xf6ed1000 ist=0xf6c34000 pix_fmts=0
05-20 15:34:07.980 24393 24533 I HWACCEL : hw codec hevc enabled: s=0xf6c31000 ist=0xf6c34000 pix_fmts=0

[youli...@gmail.com]

look the record video, https://drive.google.com/file/d/1FIs_cI1fWgExzCGyFXIM17J7Egkd3Qtf/view?usp=sharing https://drive.google.com/file/d/1615RgtDyFOtaSKa-t3aLo99wnXBW_Rro/view?usp=sharing

setprop media.sf.hwaccel 1, only use one core cpu 100%

setprop media.sf.hwaccel 0, use 8 core cpu.

seem vaapi is working?

[youli...@gmail.com]

ffmpeg_vaapi removed, ffmpeg: Enable generic hwaccel support for VAAPI

https://github.com/youling257/FFmpeg/commit/be510733523016aae7dca74bba6aa3b223c1fed6

[youli...@gmail.com]

hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC" http://git.osdn.net/view?p=android-x86/external-ffmpeg.git;a=blob;f=configure;h=7df776b78e851d2131271fc7d9c4f38de6f11179;hb=refs/heads/nougat-x86#l2638

why androidx86 used hevc_vaapi_hwaccel_deps="vaapi" ? http://git.osdn.net/view?p=android-x86/external-ffmpeg.git;a=commit;h=828107e6e6aacbdacc0f8b2cd35c0224e00caa5d

[Michael Goffioul]

I can't tell why the deps have been changed, but I don't think it matters, because the configure script is not used when building ffmpeg within android-x86: all files have already pre-generated.

On Fri, May 20, 2022 at 6:16 PM youli...@gmail.com <youli...@gmail.com> wrote:

hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC" http://git.osdn.net/view?p=android-x86/external-ffmpeg.git;a=blob;f=configure;h=7df776b78e851d2131271fc7d9c4f38de6f11179;hb=refs/heads/nougat-x86#l2638

why androidx86 used hevc_vaapi_hwaccel_deps="vaapi" ? http://git.osdn.net/view?p=android-x86/external-ffmpeg.git;a=commit;h=828107e6e6aacbdacc0f8b2cd35c0224e00caa5d

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/3800cb8b-6e8e-4c99-a26a-4d33022a4a80n%40googlegroups.com.

[youli...@gmail.com]

not work with ffmpeg 4.3.

now, ffmpeg 3.3 vaapi working. https://github.com/youling257/FFmpeg/commits/release/3.3

[youli...@gmail.com]

I copied "ffmpeg: Use codec hardware config to configure hwaccels" code to ffmpeg_hwaccel.c, https://github.com/youling257/stagefright-plugins/commit/a6685d874981854cd29d8f232b9bb476fb4c5f5a , but vaapi not work.

I read https://programs.wiki/wiki/ffmpeg-hardware-acceleration.html https://zhuanlan.zhihu.com/p/490483683

I tried "ist->hwaccel_id == HWACCEL_GENERIC;     ist->hwaccel_device_type = AV_HWDEVICE_TYPE_VAAPI; " , still not work.

I add back active_hwaccel_id vaapi_device_init vaapi_decode_init on ffmpeg 4.4, not change ffmpeg_hwaccel.c, now ffmpeg 4.4 vaapi working.

https://github.com/youling257/stagefright-plugins/commits/cm-14.1 https://github.com/youling257/FFmpeg/commits/release/4.4

[Michael Goffioul]

What's then the output of `adb logcat -s HWACCEL`?

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/9ea5deb5-431a-47fa-b811-fffb5647a24en%40googlegroups.com.

[youli...@gmail.com]

need care fps and cpu usage ratio, android phone record 4k 30fps h264 and h265, 4k 60fps h264 and h265.

I didn't see 60 frames on intel gpu. 

[youli...@gmail.com]

05-23 21:33:03.306 17163 26132 I HWACCEL : hw codec hevc enabled: s=0xed163800 ist=0xec5a5400 pix_fmts=46

05-23 21:33:10.324 17163 26178 I HWACCEL : hw codec hevc enabled: s=0xf6f53400 ist=0xec5a5580 pix_fmts=46

05-23 21:33:17.653 17163 26219 I HWACCEL : hw codec mpeg4 enabled: s=0xed944400 ist=0xec5a5580 pix_fmts=46

05-23 21:33:17.654 17163 26219 I HWACCEL : hw codec mpeg4 disabled: s=0xed944400 ist=0xec5a5580 pix_fmts=0

05-23 21:33:32.562 17163 26268 I HWACCEL : hw codec h264 enabled: s=0xeaf0d800 ist=0xec5a5580 pix_fmts=46

05-23 21:33:35.877 17163 26302 I HWACCEL : hw codec vp8 enabled: s=0xed6d7000 ist=0xec5a5700 pix_fmts=46

05-23 21:33:35.878 17163 26302 I HWACCEL : hw codec vp8 disabled: s=0xed6d7000 ist=0xec5a5700 pix_fmts=0

05-23 21:33:38.574 17163 26328 I HWACCEL : hw codec h264 enabled: s=0xecedb000 ist=0xec5a5880 pix_fmts=46

05-23 21:33:41.160 17163 26358 I HWACCEL : hw codec h264 enabled: s=0xf3954000 ist=0xec5a5e80 pix_fmts=46

Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 720x404 [SAR 1:1 DAR 180:101], 1024 kb/s

05-23 13:47:00.213 17163 30093 D SoftFFmpegVideo: ffmpeg got codecconfig buffer

05-23 13:47:00.213 17163 30093 D SoftFFmpegVideo: begin to open ffmpeg decoder(mpeg4) now

05-23 13:47:00.213 17163 30093 I FFMPEG : [mpeg4 @ 0xeb8ff000] Requested frame threading with a custom get_buffer2() implementation which is not marked as thread safe. This is not supported anymore, make your callback thread-safe.

05-23 13:47:00.214 17163 30093 D SoftFFmpegVideo: open ffmpeg video decoder(mpeg4) success

05-23 13:47:00.215 17163 30095 I HWACCEL : hw codec mpeg4 enabled: s=0xe9d9e800 ist=0xec97df00 pix_fmts=46

05-23 13:47:00.215 17163 30095 I FFMPEG : [mpeg4 @ 0xe9d9e800] No support for codec mpeg4 profile 0.

05-23 13:47:00.216 17163 30095 I FFMPEG : [mpeg4 @ 0xe9d9e800] Failed setup for format vaapi_vld: hwaccel initialisation returned error.

05-23 13:47:00.216 17163 30095 I HWACCEL : hw codec mpeg4 disabled: s=0xe9d9e800 ist=0xec97df00 pix_fmts=0

在2022年5月23日星期一 UTC+8 14:46:24<michael....@gmail.com> 写道：

[Huy Minh Bùi]

Hey youling257

Can you take a look at the driver that Celadon use ? It seems like the driver that Intel use is very polished
GitHub - projectceladon/media-driver

Beside from libva, the driver require Intel's gmmlib too

GitHub - projectceladon/gmmlib

GitHub - projectceladon/libva

But I don't think that AMDGPUs can be able to use this.

Vào lúc 21:11:35 UTC+7 ngày Thứ Hai, 23 tháng 5, 2022, youli...@gmail.com đã viết:

[youli...@gmail.com]

That is 10 days ago i did thing, ndk build gmmlib and iHD_drv_video available, but media-driver has some shm code, shmdt shmctl shmat only support if __ANDROID_API__ >= 26, iHD_drv_video.so impossible work on cm-14.1,

tested celadon libva a mouth ago, https://github.com/projectceladon/libva/blob/master/va/va_version.h has a big mistake, never will work, Failed to initialise VAAPI connection: -1 (unknown libva error), "define VA_VERSION 2.13.0" is error!  "define VA_VERSION 1.13.0" is right.

I using ndk build mesa libdrm libva vainfo ffmpeg on cm-14.1, but how to android build libffmpeg_omx with ndk build libavcodec.so? copy ndk build libav*.so to android build out/target/product/android_x86/obj/lib, readelf --dyn-syms create so.toc file.