Re: video scaling issue with clang 2.8 mmx
Ruben
> We have some custom assembly scaling routines that are probably not
> clang friendly.
>
> Here's a quick test without digging into too much code... see if the
> scaling problem still happens if you set the video's opacity to anything
> other than 1.
>
> That should trigger our slower painting code that doesn't rely on as
> much assembly.
OK, I suppose it's the assembly scaling routines in this file that break
with clang 2.8?
http://src.chromium.org/viewvc/chrome/trunk/src/media/base/yuv_row_posix.cc?view=markup
How does one set the video's opacity? I don't see a command-line flag
for it.
> On Oct 29, 2010 8:38 AM, "Evan Martin" <ev...@chromium.org
> <mailto:ev...@chromium.org>> wrote:
> > Another trick is to cc cl...@chromium.org
> <mailto:cl...@chromium.org>, as one of the clang
> > developers lurks on there. :)
Added.
> > On Fri, Oct 29, 2010 at 8:20 AM, Nico Weber <tha...@chromium.org
> <mailto:tha...@chromium.org>> wrote:
> >> On Fri, Oct 29, 2010 at 2:25 AM, Ruben <chro...@hybridsource.org
> <mailto:chro...@hybridsource.org>> wrote:
> >>> Hey guys, as you may know, I've been building Chromium on FreeBSD
> with clang
> >>> for a while now, but it appears there was a regression in clang 2.8
> recently
> >>> that screwed up HTML5 video scaling. Any HTML5 video that isn't
> played at
> >>> its native resolution is garbled when FreeBSD Chromium has been
> compiled
> >>> with clang 2.8. I think it's related to this MMX patch as I bisected
> >>> Chromium and clang builds to narrow it down:
> >>>
> >>> http://llvm.org/bugs/show_bug.cgi?id=8200
> >>>
> >>> I don't know exactly why that would mess up how Chromium is scaling
> video as
> >>> I'm not familiar with the relevant Chromium or clang code. Any
> input is
> >>> appreciated.
> >>
> >> Does it work with ToT clang?
> >>
> >> If you build ffmpeg with clang and use the resulting binary to scale a
> >> movie, does the output have the same problems? Maybe a good first step
> >> is to just comment on the bug ("I believe this patch might have broken
> >> ffmpeg because of XXX. Do you any ideas why that might have
> >> happened").
I haven't tried ToT clang, but I notice that that MMX patch was
strangely never added to llvm trunk, not a good sign. Since I was able
to bisect the release_28 branch of llvm/clang and confirm that that MMX
patch is at fault, I don't believe this bug will show up in anything
other than the final llvm 2.8 release. This is clearly not an ffmpeg
issue but an issue internal to Chromium and how its video scaling code
interacts with clang 2.8, as I was able to reproduce by using the exact
same ffmpeg version (same ffmpegsumo_nolink and libffmpegsumo.so files)
with different Chromium builds. I mentioned this to scherkus last night
over irc, should have stated it in my email also.
I will post this info to that llvm bugreport, along with some
screenshots. If any of you know exactly which assembly lines that mmx
patch might have screwed up or can confirm this bug by building Chromium
with the final llvm/clang 2.8 release on another OS, that would help.
Nico Weber
If it only happens with clang 2.8, then I just wouldn't bother. clang
2.8 doesn't even compile chromium out of the box without hacks to
chromium. And all of the chromium clang watefall bots are somewhat
loosely tracking clang trunk.
Nico
Andrew Scherkus
Ruben
> Paste this into an HTML file:
> <video autoplay
> src="http://shapeshed.com/examples/HTML5-video-element/video/320x240.ogg" style="opacity:
> 0.5"></video>
setting a different video height, so that it was scaled from the native
resolution. I'll report on that llvm mmx bug just so the llvm devs know
it's a problem with the 2.8 release, even if it doesn't affect ToT right
now. Here are two screenshots that I generated to demonstrate the problem.
http://chromium.hybridsource.org/Chromium-html5-unscaled.png
http://chromium.hybridsource.org/Chromium-html5-scaled.png