Can you try Google Chrome?

It appears that html5 video works in the dev-channel version of google chrome, so I 
take it this is a problem with chromium and it's codecs?

wfm using ToT (ubuntu builds) on x64.
I've fixed the -extra-dbg broken dependencies, just need the builders to catch up now.

for some reason, the last update of ffmpeg-mt regressed for me:

up to chromium-codecs-ffmpeg-0.5+svn20100330r43036+43030+43160, i was able to watch html5 videos on youtube & vimeo.
with chromium-codecs-ffmpeg-0.5+svn20100401r43316+43240+43297, nothing, i get flash instead
I checked and the html API no longer even claims to support any codecs (not even vorbis).
(that's with the same chromium ToT - 5.0.367.0~svn20100401r43319)

I also checked my sumo binaries, -extra has been built with h264 as expected (ffmpeg_branding=Chrome).
If i strace chromium (without the sandbox), i see the lib is loaded, yet, there's no error message claiming that something doesn't work (there's a nice 
"TODO(ajwong): We need error resolution" in the code).

I didn't change my build rules for those codecs in between those two versions.
I see that the patch stack changed, as did ffmpeg-mt.tar.gz:

-rw-r--r-- 1 fta fta 3973836 2010-03-13 04:00 chromium-codecs-ffmpeg-0.5+svn20100330r43036+43030+43160/ffmpeg-mt.tar.gz
-rw-r--r-- 1 fta fta 4265260 2010-04-01 08:15 chromium-codecs-ffmpeg-0.5+svn20100401r43316+43240+43297/ffmpeg-mt.tar.gz

so it seems it's an upstream regression (in trunk)

(i'm hijacking this bug, i should probably file another one) 

I am using ubuntu-daily ppa

I am on Karmic, 64 bit, Chromium r43430, codecs-extra version is 0.5+svn20100401r43359+43240+43297-
0ubuntu1~ucd1~karmic.

Youtube says that you don't have codecs. Vimeo HTML5 crashes. 

 Issue 40363  has been merged into this issue.

Just tested 0.5+svn20100406r43776+43794+43724, it's fine with youtube.
I've just published it in all 3 PPAs.

@Ripps, could you please upgrade and try to reproduce your crash? (the -dbg should be 
fine now)

I confirm that the version above fixes the issue ;)

Okay, the codec pack now has the proper codecs, but it still causes chromium to crash. 
On the bright side, I now have a much more complete backtrace to share.

gdb-chromium-browser2.txt 57.3 KB View Download

Ripps818: thanks!  I think we've tracked it down to FFmpeg's llrint() function, which 
we're assuming was inlined into some optimized assembly that might not be supported on 
your CPU.  What kind of CPU are you using?

fta: have you upgraded your machine recently in a way that might be causing FFmpeg to 
build using some newer generation CPU instructions?

@scherkus, I'm using an AthlonXP 2500+. Not a new CPU by any standard, but not 
terribly ancient that it's unreasonable to be supported.

I think I figured it out!

The particular line of code that was crashing (libavcodec/opt.c:422) corresponds to the following instruction:
cvttsd2si 0x10(%ebx),%eax

...which stands for "Convert Scalar Double-Precision Floating-Point Value to Signed Doubleword Integer with Truncation" (phew!)

It's an SSE2 instruction, which Athlon CPUs do not support.  fbarchard filed  issue 40770  to make sure we disable such instruction sets 
on ia32 systems.

Also looks like we're not the only ones who have been bitten by this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=471868

In  40770 I'm more concerned with ffmpeg's SSSE3 assembly, which should be dispatched to with cpuid

rint() is a <math.h> function.  The problem is our compiler and settings compile all of chrome with SSE2 
enabled. 
src/build/common.gypi
           'conditions': [
              ['branding=="Chromium"', {
                'cflags': [
                  '-march=pentium4',
                  '-msse2',
                  '-mfpmath=sse',
                ],
              }],

I carry a patch in chromium to disable that:
http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-
browser.head/annotate/head:/debian/patches/drop_sse2.patch

this is messy in the 1st place. I can carry that patch in the codecs package too, but 
a real fix would be better (and help other distros)

For linux, the same compiler settings are used, but you might want to extend your patch to config.h
src\third_party\ffmpeg\source\config\Chromium\linux\ia32\config.h
This particular crash is likely avoided by changing these
#define HAVE_LLRINT 1
#define HAVE_SSSE3 1

More context for fbarchard: we turn of -msse2 for official builds.  It's only there as 
a workaround for one of our older bugs:
  http://code.google.com/p/chromium/issues/detail?id=8475
  http://code.google.com/p/chromium/issues/detail?id=9007

It is too bad we have a hardcoded config.h within ffmpeg, but that's how the rest of 
the project works too...

Fixing up summary.

 Issue 40770  has been merged into this issue.

*sigh* Updated chromium and chromium-codecs, it still crashes. Here's another 
backtrace fta asked for.

gdb-chromium-browser3.txt 49.8 KB View Download

it's still cvttsd2si, yet it's with HAVE_LLRINT=0 and HAVE_SSSE3=0.

Here are the build logs:
http://launchpadlibrarian.net/43464869/buildlog_ubuntu-lucid-amd64.chromium-codecs-
ffmpeg_0.5%2Bsvn20100406r43776%2B43809%2B43834-0ubuntu1~ucd2_FULLYBUILT.txt.gz

(I patch at the very beginning - with perl - and expose the diff)

HAVE_SSSE3 reflects the ability to assemble SSSE3, not run it. Any SSSE3 code is runtime guarded by (mm_flags & 
FF_MM_SSSE3). I think something else is going wrong here. 

I don't know much about gyp but can we get the full command that is run (including all cflags) for the compiler?

Also to prove how pointless setting HAVE_LLRINT=0 is:

libavutil/libm.h:
#if !HAVE_LLRINT
#undef llrint
#define llrint(x) ((long long)rint(x))
#endif /* HAVE_LLRINT */

It's totally valid for the compiler to generate cvttsd2si here if it thinks it is 
targeting SSE2.

alex.converse: yeah I'm fairly certain its the compiler inlining llrint() from libm/math.h to cvttsd2si 

here are the flags for building libavcodec/opt.c (crashing file in question)

ia32
ccache distcc gcc  -pthread -fno-exceptions -Wno-unused-parameter -Wno-missing-field-initializers -D_FILE_OFFSET_BITS=64 -m32 -march=pentium4 -msse2 -mfpmath=sse -fno-strict-aliasing -fomit-frame-
pointer -std=c99 -pthread -fno-math-errno -O2 -fno-ident -fdata-sections -ffunction-sections  '-DNO_HEAPCHECKER' '-DDISABLE_NACL' '-DCHROMIUM_BUILD' '-DENABLE_GPU=1' '-DHAVE_AV_CONFIG_H' '-
D_POSIX_C_SOURCE=200112' '-D_ISOC99_SOURCE' '-D_LARGEFILE_SOURCE' '-DNDEBUG' '-DNVALGRIND' -Ithird_party/ffmpeg/source/config/Chrome/linux/ia32 -Ithird_party/ffmpeg/source/patched-ffmpeg-mt -
Ithird_party/ffmpeg/source/config -MMD -MF out/Release/.deps/out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.o.d.raw -c -o 
out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.o third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.c

x64
ccache distcc gcc  -pthread -fno-exceptions -Wno-unused-parameter -Wno-missing-field-initializers -D_FILE_OFFSET_BITS=64 -fno-strict-aliasing -fomit-frame-pointer -fPIC -std=c99 -pthread -fno-math-
errno -O2 -fno-ident -fdata-sections -ffunction-sections  '-DNO_HEAPCHECKER' '-DDISABLE_NACL' '-DCHROMIUM_BUILD' '-DENABLE_GPU=1' '-DHAVE_AV_CONFIG_H' '-D_POSIX_C_SOURCE=200112' '-DPIC' '-
D_ISOC99_SOURCE' '-D_LARGEFILE_SOURCE' '-DNDEBUG' '-DNVALGRIND' -Ithird_party/ffmpeg/source/config/Chrome/linux/x64 -Ithird_party/ffmpeg/source/patched-ffmpeg-mt -Ithird_party/ffmpeg/source/config -
MMD -MF out/Release/.deps/out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.o.d.raw -c -o 
out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.o third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.c


...and ia32 has -msse2 -mfpmath=sse :)

And for Google Chrome ia32:
ccache distcc gcc  -pthread -fno-exceptions -Wno-unused-parameter -Wno-missing-field-initializers -D_FILE_OFFSET_BITS=64 -m32 -fno-strict-aliasing -gstabs -fomit-frame-pointer -std=c99 
-pthread -fno-math-errno -O2 -fno-ident -fdata-sections -ffunction-sections  '-DUSE_LINUX_BREAKPAD' '-DNO_HEAPCHECKER' '-DDISABLE_NACL' '-DGOOGLE_CHROME_BUILD' '-DENABLE_GPU=1' '-
DHAVE_AV_CONFIG_H' '-D_POSIX_C_SOURCE=200112' '-D_ISOC99_SOURCE' '-D_LARGEFILE_SOURCE' '-DNDEBUG' '-DNVALGRIND' -Ithird_party/ffmpeg/source/config/Chrome/linux/ia32 -
Ithird_party/ffmpeg/source/patched-ffmpeg-mt -Ithird_party/ffmpeg/source/config -MMD -MF out/Release/.deps/out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-
mt/libavcodec/opt.o.d.raw -c -o out/Release/obj.target/ffmpegsumo/third_party/ffmpeg/source/patched-ffmpeg-mt/libavcodec/opt.o third_party/ffmpeg/source/patched-ffmpeg-
mt/libavcodec/opt.c

...looks like we inherit the -msse2 -mfpmath=sse settings from build/common.gypi.  As mentioned we don't include those flags in ia32 builds of Google Chrome.

fta: if it's just the codecs you're concerned about, you could presumably patch build/common.gypi or ffmpeg.gyp to remove -msse2 -mfpmath=sse

@scherkus: ffmpeg.gyp seems to build sse2 source files unconditionally on ia32/x64
(like source/patched-ffmpeg-mt/libavcodec/x86/idct_sse2_xvid.c and source/patched-
ffmpeg-mt/libavcodec/x86/vp3dsp_sse2.c)

this is the downside of skipping configure :P


note that it also impacts Celerons:

model name      : Intel(R) Celeron(TM) CPU                1133MHz
flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pse36 mmx fxsr 
sse up

@fta, That is intentional! No code from that file is executed without a runtime CPU 
check.

Just removed the HAVE_LLRINT/HAVE_SSSE3 workaround and patched build/common.gypi like 
i did for chromium, it solved it. no more crash.

fbarchard, sergeyu: want to give an update based on the recent work?

fta: any new issues popping up?

scherkus: no one complained since i dropped sse2 from build/common.gypi in all the 
ubuntu builds.

I've made 2 changes
1. yuv scaler respects compiler options and uses mmx is sse2 if disabled, or C if mmx
is disabled.
2. common.gypi enables -mmmx for Chrome, and -msse2 for chromeos (atom) for ia32.
Chromium remains sse2, due to a skia layout test issue.

can we consider this fixed?

do you mean i can drop my patch? I don't think i can.

I still don't understand why sse2 is set globally for Chromium (and not for Chrome) 
while it's a known cause of crashes for the browser. Why not set it only for the 
layout test file(s) that needs it?

build/common.gypi is updated far too often, breaking my patch and then my builds, 
creating unnecessary work.

Would you please consider something like the following so i don't have to patch 
anything just to disable sse2 in the future?

http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-
browser.head/annotate/head:/debian/patches/add_enable_sse2_flag.patch

At this point we're blocked on 8475, which is why SSE2 is enabled for Chromium.

@fta, that patch looks like a reasonable work around.  But the real issue is 8475.

Change is up for review
http://codereview.chromium.org/1611034

fta: I added you to the CL for comments

Update: there is now a flag, disable_sse2, that fta can use to build chromium without sse2.

Ubuntu now builds with sse2 disabled, so I think we can mark this as fixed in practice

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.