Re: how to enable VAVDA on chromium OS

[Ami Fischman]

[+cc chromium-os-dev]

vaapi_h264_decoder.cc hard-codes the names of the libs it dlopen()s.  If you need to dlopen other libs I suggest you modify that location, or put a catch-all under one of the existing names.

If it still doesn't work you'll have to trace through to figure out why.  Some things to look at: 

Do the dlopen()s succeed / return non-NULL? 

Do the dlsym()s succeed / return non-NULL?

On attempted playback does GpuVideoDecoder::Initialize() get called?  What does it return?  

After attempted playback what does loading chrome://histograms/Media.G twice say?

And so on.

Cheers,

-a

On Mon, May 13, 2013 at 7:36 PM, <Ros...@viatech.com.cn> wrote:

 

Hi,

  Excuse me, I have a question that I don’t know how to solve.

 

  I want to enable VAVDA on my chromium OS. But now, When I play one h264 file, it calls libffmpegsumo.so, not HW decode. I don’t know how to enable VAVDA  to decode h264 on chromium OS.

 

 I check the GPU process, it loads libva.so* and not loads my VA video driver library which name is s3g_drv_video.so. I have also set environment LIBVA_DRIVER_NAME=s3g.

So Would you mind telling me how to solve it? Thank you very much!

 

 

 

Best Wishes!

Rose

 

[Ami Fischman]

[+chromium-os-dev again]

Sorry, I do not build cros anymore and don't know the answers to your questions.  Perhaps someone else on the list does.

Cheers,

-a

On Mon, May 13, 2013 at 11:58 PM, <Ros...@viatech.com.cn> wrote:

I find a strange problem.

 

I use follow instructions to build chromium and build image inside chroot:

 

$cros_workon --board=x86-generic start chromeos-chrome

$ USE=”chrome_media” CHROME_ORIGIN=LOCAL_SOURCE emerge-x86-generic chromeos-chrome

$./build_image.sh –board=x86-generic

$./image_to_usb.sh –board=x86-generic

 

the chromium out file is on /var/cache/chromeos-chrome/chrome-src/src/out_x86-generic/Release/. The chrome size:1.3G, but I boot chromium OS from USB and the /opt/google/chrome/chrome size:89M.

 

Why these two file are not same?

 

And emerge-x86-generic chromeos-chrome this instruction only install chrome package? Not install compiled chrome file to /build/x86-generic/opt/google/chrome/?

 

 

BRS

Rose

 

 

发件人: fisc...@google.com [mailto:fisc...@google.com] 代表 Ami Fischman

发送时间: 2013年5月14日 14:11
收件人: Rose Yao; ChromiumOS-dev
主题: Re: how to enable VAVDA on chromium OS

[Mike Frysinger]

because one is built with debug and the other has been stripped
-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
 
 
 

[Pawel Osciak]

VAVDA decodes H.264 only and it's a proprietary codec. Support for proprietary codecs is not compiled into ChromiumOS by default and has to be enabled explicitly (potentially with all the licensing/legal implications).

[Jorge Lucangeli Obes]

Also, the GPU process sandbox will likely prevent non-standard driver .so's (like s3g_drv_video.so) from loading.

[yllro...@gmail.com]

Thanks your infos,

But I don’t clearly your means(non-standard driver .so's????). 

The playback loads libffmpegsumo.so to decode h264 files, but can’t load vaapi video driver(s3g_drv_video.so) to decode it. I run $vainfo  is ok, it can load s3g_drv_video.so  functions, thus,

This VaapiH264Decoder::PostSandboxInitialization function can load VAAPI address. 

So, Would you mind telling me how to solve it? thank you very much!

Rose

[Jorge Lucangeli Obes]

You need to take a look in sandbox_seccomp_bpf_linux.cc. That's the implementation of the GPU process sandbox, you'll need to add the needed .so's to the GPU process open() system call whitelist.

If you just want to test, you can run Chrome with the --disable-gpu-sandbox flag, but that will severely impact the security of Chromium OS.

[Jorge Lucangeli Obes]

On Tue, May 14, 2013 at 11:46 PM, <Ros...@viatech.com.cn> wrote:

Thanks very much!

I have many issues:

 

1.       When after chromium OS booting, the chrome process has run. So, how to set –disable-gpu-sandbox flag?

You need to edit /sbin/session_manager_setup.sh 

 

2.       Who calls GpuVideoDecoder::Initialize fuctions?

 

3.       Ffmpegsumo and VAVDA these two path is parallel? If yes, each path how to run?

 

 

Rose

 

发件人: jor...@google.com [mailto:jor...@google.com] 代表 Jorge Lucangeli Obes

发送时间: 2013年5月15日 14:05
收件人: yllro...@gmail.com
抄送: Chromium OS dev; Pawel Osciak; Ami Fischman; Rose Yao

主题: Re: [cros-dev] Re: how to enable VAVDA on chromium OS

[Rose Yao]

thanks your infos!

now, I have new issues:

1.when I run command ./opt/google/chrome/chrome to play video on Chromium OS, the video can enter VAVDA init. but after calling VaapiVideoDecodeAccelerator::InitialDecodeTask, and then, there is erro:ERROR:gpu_watchdog_thread.cc(201)] The GPU process hung. Terminating after 10000 ms. not call VaapiVideoDecodeAccelerator::SubmitDecode to decode. that is to say, the GPU process is not to call real VAVDA decoder.

2. when I open a web tab by mouse(not run command ./opt/google/chrome/chrome) to play video or local play video, these two case, all call libffmpegsumo.so to decode. not VAVDA API. so, this is why? Need I set some flags?

3.by the way, the VAVDA path is OK on chromium OS? and through the test?

Best Wishes!

Rose

[Ami Fischman]

1.when I run command ./opt/google/chrome/chrome to play video on Chromium OS, the video can enter VAVDA init. but after calling VaapiVideoDecodeAccelerator::InitialDecodeTask, and then, there is erro:ERROR:gpu_watchdog_thread.cc(201)] The GPU process hung. Terminating after 10000 ms. not call VaapiVideoDecodeAccelerator::SubmitDecode to decode. that is to say, the GPU process is not to call real VAVDA decoder.

The gpu_watchdog_thread watches the GPU process' main thread and kills it if it appears to be hung.  You need to figure out what the GPU process' main thread is doing for those 10 consecutive seconds that make the watchdog believe it has hung.  --disable-gpu-sandbox may aid you in getting a backtrace (either from a core file or gdb) during the hang.

 

2. when I open a web tab by mouse(not run command ./opt/google/chrome/chrome) to play video or local play video, these two case, all call libffmpegsumo.so to decode. not VAVDA API. so, this is why? Need I set some flags?

This is not enough information to tell.  My guess is that once things go wrong for the GPU process (as in #1 above) chrome falls back to unaccelerated codepaths and doesn't try.  

Opening a new tab vs. opening a new chrome shouldn't behave differently except for failures that happened earlier in the browser's lifetime in the former case.

 

3.by the way, the VAVDA path is OK on chromium OS? and through the test?

I don't understand the question.  If you're asking whether vavda works for other people, then yes, most shipping cros x86 platforms use it successfully.  (all platforms from lumpy/stumpy onwards).

If you still have questions, please post more details about your setup; the HW platform & drivers you're using, the code changes you've made, the exact command-lines you're running, and the exact repro steps you take (UI-wise) to repro the problems (and what the problems are).

Cheers,

-a

[Ami Fischman]

Nothing comes to mind, sorry.

On Sun, May 26, 2013 at 8:14 PM, <Ros...@viatech.com.cn> wrote:

Hi, Ami,

 

For 1 questions, I get a backtrace as follows,

(gdb) bt

#0  0x721e1424 in __kernel_vsyscall ()

#1  0x7174d9c6 in __poll (fds=0x7fc3f454, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87

#2  0x716595c8 in ?? () from /build/x86-generic/usr/lib/libxcb.so.1

#3  0x7165aeaf in ?? () from /build/x86-generic/usr/lib/libxcb.so.1

#4  0x7165b193 in xcb_wait_for_reply () from /build/x86-generic/usr/lib/libxcb.so.1

#5  0x720ef888 in _XReply () from /build/x86-generic/usr/lib/libX11.so.6

#6  0x720d37a1 in XGetImage () from /build/x86-generic/usr/lib/libX11.so.6

#7  0x720d39f9 in XGetSubImage () from /build/x86-generic/usr/lib/libX11.so.6

#8  0x714fa118 in ?? () from /build/x86-generic/usr/lib/libGL.so.1

#9  0x704a3a16 in ?? () from /build/x86-generic/usr/lib/dri/swrast_dri.so

#10 0x704a4d72 in ?? () from /build/x86-generic/usr/lib/dri/swrast_dri.so

#11 0x714fa330 in ?? () from /build/x86-generic/usr/lib/libGL.so.1

#12 0x714d0b16 in ?? () from /build/x86-generic/usr/lib/libGL.so.1

#13 0x730a14ca in gfx::RealGLXApi::glXBindTexImageEXTFn (this=0x77b38f60, dpy=0x77b57200, drawable=12582924, buffer=8414, attribList=0x0)

    at c/Release/obj/gen/ui/gl/gl_bindings_autogen_glx.cc:687

#14 0x72e3af40 in content::VaapiH264Decoder::DecodeSurface::DecodeSurface(const GLXFBConfig &, Display *, VADisplay, const base::Callback<bool()> &, VASurfaceID, int32, uint32, int, int) (this=0x77f00b80, fb_config=@0x7bb30404, x_display=0x77b57200, va_display=0x77b9cc30, make_context_current=..., va_surface_id=67108864, picture_buffer_id=0,

    texture_id=188, width=640, height=368) at content/common/gpu/media/vaapi_h264_decoder.cc:289

#15 0x72e48aef in content::VaapiH264Decoder::AssignPictureBuffer (this=0x7bb302ac, picture_buffer_id=0, texture_id=188) at content/common/gpu/media/vaapi_h264_decoder.cc:584

#16 0x72dfd893 in content::VaapiVideoDecodeAccelerator::AssignPictureBuffers (this=0x7bb30180, buffers=...) at content/common/gpu/media/vaapi_video_decode_accelerator.cc:426

#17 0x72e1f473 in content::GpuVideoDecodeAccelerator::OnAssignPictureBuffers (this=0x7b5f9b10, buffer_ids=..., texture_ids=..., sizes=...)

    at content/common/gpu/media/gpu_video_decode_accelerator.cc:243

#18 0x72e1feb5 in DispatchToMethod<content::GpuVideoDecodeAccelerator, void (content::GpuVideoDecodeAccelerator::*)(std::vector<int, std::allocator<int> > const&, std::vector<unsigned int> const&, std::vector<gfx::Size> const&), std::vector<int, std::allocator<int> >, std::vector<unsigned int>, std::vector<gfx::Size> > (this=0x7b5f9b10, msg=...)

    at ./base/tuple.h:559

#19 Dispatch<content::GpuVideoDecodeAccelerator, content::GpuVideoDecodeAccelerator, void (content::GpuVideoDecodeAccelerator::*)(std::vector<int, std::allocator<int> > const&, std::vector<unsigned int> const&, std::vector<gfx::Size> const&)> (this=0x7b5f9b10, msg=...) at ./content/common/gpu/gpu_messages.h:645

#20 content::GpuVideoDecodeAccelerator::OnMessageReceived (this=0x7b5f9b10, msg=...) at content/common/gpu/media/gpu_video_decode_accelerator.cc:85

#21 0x72de2eae in content::MessageRouter::RouteMessage (this=0x796179ac, msg=...) at content/common/message_router.cc:49

#22 0x72e1174c in content::GpuChannel::HandleMessage (this=0x79617960) at content/common/gpu/gpu_channel.cc:544

#23 0x72e0b7c3 in Run (base=0x7afd80c0) at ./base/bind_internal.h:134

#24 MakeItSo (base=0x7afd80c0) at ./base/bind_internal.h:882

#25 base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (content::GpuChannel::*)()>, void(content::GpuChannel*), void(base::WeakPtr<content::GpuChannel>)>, void(content::GpuChannel*)>::Run(base::internal::BindStateBase *) (base=0x7afd80c0) at ./base/bind_internal.h:1172

#26 0x7588ea59 in Run (this=0x7fc415dc, pending_task=...) at ./base/callback.h:391

#27 MessageLoop::RunTask (this=0x7fc415dc, pending_task=...) at base/message_loop.cc:470

#28 0x7588e91c in MessageLoop::DeferOrRunPendingTask (this=0x7fc415dc, pending_task=...) at base/message_loop.cc:482

#29 0x758666a8 in DoWork (this=0x7fc415dc) at base/message_loop.cc:665

#30 MessageLoop::DoWork (this=0x7fc415dc) at base/message_loop.cc:644

#31 0x75866408 in base::MessagePumpDefault::Run (this=0x77b37920, delegate=0x7fc415dc) at base/message_pump_default.cc:28

#32 0x75865fff in MessageLoop::RunInternal (this=0x7fc415dc) at base/message_loop.cc:427

#33 0x75865e4a in base::RunLoop::Run (this=0x7fc41020) at base/run_loop.cc:45

#34 0x75865d05 in MessageLoop::Run (this=0x7fc415dc) at base/message_loop.cc:307

#35 0x72a29c3f in content::GpuMain (parameters=...) at content/gpu/gpu_main.cc:266

#36 0x7585649e in content::RunNamedProcessTypeMain (process_type=..., main_function_params=..., delegate=0x7fc41a4c) at content/app/content_main_runner.cc:448

#37 0x75856119 in content::ContentMainRunnerImpl::Run (this=0x77b41f60) at content/app/content_main_runner.cc:741

#38 0x75849518 in content::ContentMain (argc=9, argv=0x7fc41b44, delegate=0x7fc41a4c) at content/app/content_main.cc:35

#39 0x758493dd in ChromeMain (argc=9, argv=0x7fc41b44) at chrome/app/chrome_main.cc:32

#40 0x724cf4e7 in main (argc=9, argv=0x7fc41b44) at chrome/app/chrome_exe_main_aura.cc:17

 

BRs

Rose

 

发件人: fisc...@google.com [mailto:fisc...@google.com] 代表 Ami Fischman

发送时间: 2013年5月27日 10:58
收件人: Rose Yao
抄送: Jorge Lucangeli Obes; Rose Yao; Chromium OS dev; Pawel Osciak
主题: Re: 答复: [cros-dev] Re: how to enable VAVDA on chromium OS

 

1.when I run command ./opt/google/chrome/chrometo play video on Chromium OS, the video can enter VAVDA init. but after callingVaapiVideoDecodeAccelerator::InitialDecodeTask, and then, there is erro:ERROR:gpu_watchdog_thread.cc(201)] The GPU process hung. Terminating after 10000 ms.not callVaapiVideoDecodeAccelerator::SubmitDecode to decode.that is to say, the GPU process is not to call real VAVDA decoder.

 

The gpu_watchdog_thread watches the GPU process' main thread and kills it if it appears to be hung. You need to figure out what the GPU process' main thread is doing for those 10 consecutive seconds that make the watchdog believe it has hung. --disable-gpu-sandbox may aid you in getting a backtrace (either from a core file or gdb) during the hang.

2. when I open a web tab by mouse(not run command./opt/google/chrome/chrome) to play video or local play video, these two case, all call libffmpegsumo.so to decode. not VAVDA API. so, this is why? Need I set some flags?