Sounds like a custom build issue. Make sure you're using ffmpeg_branding="ChromeOS" and proprietary_codecs=true.

yes, it's def a custom build, but that's kind of the point.  Yunlian is trying to upgrade glibc in CrOS to a newer version than we have currently and is doing a lot of system testing to make sure it's stable before we make it official.  we obviously don't want to merge newer versions if we can't pass tests.

he's a very competent dev, so if you have suggestions/directions to help him debug, please provide them.

Hi yunlian,
It looks like not a video specific issue.

From the log it seems that Chrome could not get any reply from CRAS through dBus.
I think audio will not be functional at all.

Could you please try the dBus from command line first ?

dbus-send --system  --type=method_call --print-reply --dest=org.chromium.cras      /org/chromium/cras org.chromium.cras.Control.GetNodes

Yes, there is no sound as well. Below is the log

dbus-send --system  --type=method_call --print-reply --dest=org.chromium.cras      /org/chromium/cras org.chromium.cras.Control.GetNodes
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Jimmy. Please find someone to take a look. Thanks.

Hi Yunlian, is there any log in /var/log/messages related to seccomp ?
Also, is cras still alive ?

cras is still alive

localhost /var/log # ps aux | grep cras
root      1979  0.0  0.0   8748   960 ?        Ss   13:55   0:00 minijail0 -u cras -g cras -G -n --uts -v -l -P /var/empty -b / / -k tmpfs /run tmpfs MS_NODEV MS_NOEXEC MS_NOSUID mode=755,size=10M -b /run/cras /run/cras 1 -b /run/dbus /run/dbus 1 -b /run/udev /run/udev -b /dev /dev -b /dev/shm /dev/shm 1 -k proc /proc proc -b /sys /sys -k tmpfs /var tmpfs MS_NODEV MS_NOEXEC MS_NOSUID mode=755,size=10M -b /var/lib/metrics/ /var/lib/metrics/ 1 -S /usr/share/policy/cras-seccomp.policy -- /usr/bin/cras --dsp_config=/etc/cras/post_mp_a/dsp.ini --device_config_dir=/etc/cras/post_mp_a
cras      2202  0.0  0.0  47936  9556 ?        S    13:55   0:00 /usr/bin/cras --dsp_config=/etc/cras/post_mp_a/dsp.ini --device_config_dir=/etc/cras/post_mp_a

When I run the command
/usr/bin/cras --dsp_config=/etc/cras/post_mp_a/dsp.ini --device_config_dir=/etc/cras/post_mp_a manually, it failed with log
localhost /var/log # /usr/bin/cras --dsp_config=/etc/cras/post_mp_a/dsp.ini --device_config_dir=/etc/cras/post_mp_a
ALSA lib ../../../alsa-lib-1.1.6/src/ucm/utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/HDA Intel HDMI at 0xe1218000 irq 65/HDA Intel HDMI at 0xe1218000 irq 65.conf
ALSA lib ../../../alsa-lib-1.1.6/src/ucm/parser.c:1422:(load_master_config) error: could not parse configuration for card HDA Intel HDMI at 0xe1218000 irq 65
ALSA lib ../../../alsa-lib-1.1.6/src/ucm/utils.c:67:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm/HDA Intel HDMI/HDA Intel HDMI.conf
ALSA lib ../../../alsa-lib-1.1.6/src/ucm/parser.c:1422:(load_master_config) error: could not parse configuration for card HDA Intel HDMI
ALSA lib ../../../alsa-lib-1.1.6/src/ucm/main.c:947:(snd_use_case_mgr_open) error: failed to import HDA Intel HDMI use case configuration -2

Summarize testing today on yunlian's DUT:
on yunlian's DUT,
dbus-send talking to powerd works fine:

dbus-send --type=method_call --system   --print-reply --dest=org.chromium.PowerManager /org/chromium/PowerManager org.chromium.PowerManager.GetPowerSupplyProperties

But not for CRAS:

Listing methods does not work either.

dbus-send --system  --type=method_call --print-reply --dest=org.chromium.cras /org/chromium/cras org.freedesktop.DBus.Introspectable.Introspect

So there must be something missing.
Unfortunately I did not see error messages related to seccomp when dBus command ran.

There was no debug message related to dBus either after enabling debug message of CRAS by adding --syslog_mask 7 to cras.sh.

Now I am following the guide at https://docs.google.com/document/d/15A7F7Vo-Sc4AxgocNmj3ig5V3DTuKvkohHVaMQuXxz0/edit to setup a new tree and replicate the issue.

There is selinux_violation log under /var/spool/crash, not sure whether this is related.

type=1400  avc:  granted  { execute } for  pid=3093 comm="init" name="dash" dev="mmcblk0p5" ino=57433 scontext=u:r:cros_init:s0 tcontext=u:object_r:sh_exec:s0 tclass=file

that's most likely unrelated

These are from not setting the right build flags:
[1:17:1017/112219.858083:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: no supported streams"}
[1:1:1017/112219.859507:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_NO_SUPPORTED_STREAMS
[1:17:1017/112219.982300:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: no supported streams"}
[1:1:1017/112219.982751:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_NO_SUPPORTED_STREAMS

So you won't get any playback at all until you use the right flags.

Where should I set these flags? 
Basically what I did is to create a chroot with glibc 2.27,
after that I run
./setup_board --board samus --nousepkg
./build_packages --board samus --nousepkg
./build_images --board smaus test

i'm guessing he means you need to use branding/codec GN options.  which means you prob want to set USE=chrome_media when running build_packages so it'll set the GN args proprietary_codecs=true ffmpeg_branding=ChromeOS.

I installed the image provided by yunlian.

With that image I can not login.
So I added getpid and openat to all policy files under /usr/share/policy.

cd /usr/share/policy
find . -name "*.policy" | xargs -I{} sh -c "echo 'getpid:1' >> {}"
find . -name "*.policy" | xargs -I{} sh -c "echo 'openat:1' >> {}"

Then I noticed that there is a seccomp message for CRAS
2018-10-19T12:10:34.173414+08:00 NOTICE kernel: [  468.990380] audit: type=1326 audit(1539922234.172:655): auid=4294967295 uid=600 gid=600 ses=4294967295 subj=u:r:cros_cras:s0 pid=4457 comm="cras" exe="/usr/bin/cras" sig=31 arch=c000003e syscall=302 compat=0 ip=0x783499b9bae1 code=0x0

syscall 302 is prlimit64

localhost ~ # minijail0 -H | grep 302
 prlimit64 [302]

So I add prlimit64:1 to cras-seccomp.policy

Then after reboot I can login and play youtube fine.

I will submit a CL for prlimit64, and let yunlian handle other policy files that might be missing getpid and openat.

Posted the CL:
https://chromium-review.googlesource.com/c/chromiumos/third_party/adhd/+/1290613

One thing that is not clear to me is that from man page:
http://man7.org/linux/man-pages/man2/getrlimit.2.html

setrlimit and getrlimit are implemented with prlimit64 starting from glibc 2.13.

Currently, Cros uses 2.23, but CRAS does not call prlimit64 system call while it should.


I checked source cose of glibc2.23.

sysdeps/unix/sysv/linux/setrlimit64.c

/* Set the soft and hard limits for RESOURCE to *RLIMITS.
   Only the super-user can increase hard limits.
   Return 0 if successful, -1 if not (and sets errno).  */
int
setrlimit64 (enum __rlimit_resource resource, const struct rlimit64 *rlimits)
{
#ifdef __ASSUME_PRLIMIT64
  return INLINE_SYSCALL (prlimit64, 4, 0, resource, rlimits, NULL);
#else
# ifdef __NR_prlimit64
  int res = INLINE_SYSCALL (prlimit64, 4, 0, resource, rlimits, NULL);
  if (res == 0 || errno != ENOSYS)
    return res;
# endif
  struct rlimit rlimits32;

  if (rlimits->rlim_cur >= RLIM_INFINITY)
    rlimits32.rlim_cur = RLIM_INFINITY;
  else
    rlimits32.rlim_cur = rlimits->rlim_cur;
  if (rlimits->rlim_max >= RLIM_INFINITY)
    rlimits32.rlim_max = RLIM_INFINITY;
  else
    rlimits32.rlim_max = rlimits->rlim_max;

  return __setrlimit (resource, &rlimits32);
#endif
}

Here __ASSUME_PRLIMIT64 is defined in sysdeps/unix/sysv/linux/kernel-features.h

/* prlimit64 is available in 2.6.36.  */
#if __LINUX_KERNEL_VERSION >= 0x020624
# define __ASSUME_PRLIMIT64     1
#endif


And the same code in 2.27:

/* Add this redirection so the strong_alias for __RLIM_T_MATCHES_RLIM64_T
   linking setrlimit64 to {__}setrlimit does not throw a type error.  */
#undef setrlimit
#undef __setrlimit
#define setrlimit setrlimit_redirect
#define __setrlimit __setrlimit_redirect
#include <sys/resource.h>
#undef setrlimit
#undef __setrlimit

/* Set the soft and hard limits for RESOURCE to *RLIMITS.
   Only the super-user can increase hard limits.
   Return 0 if successful, -1 if not (and sets errno).  */
int
__setrlimit64 (enum __rlimit_resource resource, const struct rlimit64 *rlimits)
{
  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlimits, NULL);
}
/* Alpha defines a versioned setrlimit{64}.  */
#ifndef USE_VERSIONED_RLIMIT
weak_alias (__setrlimit64, setrlimit64)
#endif

#if __RLIM_T_MATCHES_RLIM64_T
strong_alias (__setrlimit64, __setrlimit)
# ifndef USE_VERSIONED_RLIMIT
weak_alias (__setrlimit64, setrlimit)
# endif
# ifdef SHARED
__hidden_ver1 (__setrlimit64, __GI___setrlimit, __setrlimit64);
# endif
#endif


So it is not clear why on 2.23, setrlimit was not implemented using prlimit64.

Yunlian, do you know why it works?

Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/adhd/+/65274fe5ea3b6fcd078e4e1218e11cc695678cab

commit 65274fe5ea3b6fcd078e4e1218e11cc695678cab
Author: Cheng-Yi Chiang <cychiang@chromium.org>
Date: Mon Oct 22 13:16:39 2018

seccomp: Add prlimit64 to policy file

Since glibc 2.13, setrlimit and getrlimit are implemented by prlimit,
which calls system call prlimit64.

However, on Cros image built with glibc 2.26,
setrlimit and getrlimit still lead to setrlimit
and getrlimit system call respectively.

On image built with glibc 2.27, setrlimit and getrlimit lead to
prlimit64.

We should remove these calls once we verified they are not needed on
image built with glibc 2.27.
1. setrlimit, getrlimit in amd64 and arm64.
2. setrlimit, ugetrlimit in arm.

BUG= chromium:896372 
TEST=Check Youtube playback on image built with glibc 2.27.

Change-Id: I60bd3937c7abc642e62ad644cabe96e1373f1e9d
Reviewed-on: https://chromium-review.googlesource.com/1290613
Commit-Ready: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/65274fe5ea3b6fcd078e4e1218e11cc695678cab/seccomp/cras-seccomp-arm64.policy
[modify] https://crrev.com/65274fe5ea3b6fcd078e4e1218e11cc695678cab/seccomp/cras-seccomp-amd64.policy
[modify] https://crrev.com/65274fe5ea3b6fcd078e4e1218e11cc695678cab/seccomp/cras-seccomp-arm.policy