Hi Piers,

> Sorry didn't get back to you earlier - Been moving house!

No worries,

> Yes I see the grey band at the top on my OSX [Intel] MacBook - I"m not
> sure what the cause is right now - it looks some miscalculation of the
> padding relating to  PAL/NTSC.

It seems to be okay now with my latest check-in

> I was also trying to look into a performance issue Tom was seeing with
> his gpl vic on OSX:
> http://www.mcs.anl.gov/~turam/AG/vic.intel-osx.tom.gpl
>  the only odd thing I can see is when I run otool -L on the binary and
> on his one I get:
> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
> (compatibility version 1.0.0, current version 200.0.0)
>
> Whereas with mine (which runs fine) I get:
> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
> (compatibility version 1.0.0, current version 70.0.0)
>
> I'm not clear what the "current version" refers to exactly....I've run
> a trace on it and not uncovered anything strange as yet...

MAC_OS_X_VERSION_10_4


> >  I've reverted to ffmpeg svn -r 7110 and libswscale svn -r 21687 and
> VIC
> >  doesn't crash in the MMX2 libswscaler code with i386 Fedora. I think
> I
> >  might just disable the MMX2 code with a patch for the x86-64 build
> by
> >  using a conditional in the RPM spec file for the time being.
> >
> Ah ok that sounds good - it tricky to know which rev of ffmpeg to go
> for as they don't seem to label them 'stable' as far as I've seen. I
> guess picking a release used by Linux distro isn't a bad starting
> point.
>
> Thanks,
>
> Piers.
> >
> >  Thanks,
> >  Doug
> >
> >
> >
> >  Douglas Kosovic wrote:
> >  > Hi Piers,
> >  >
> >  >>>  For Fedora 8 (i386 & x86-64), issue the following:
> >  >>>   yum update AccessGrid
> >  >>>
> >  >>>  which will install the mpeg4/h264 services and a new version of
> vic.
> >  >>>
> >  >>>  Known issues: thumbnails for H.264 and MPEG-4 appear black, but
> video
> >  >>>  windows are fine. This is because the software scaler that
> comes with
> >  >>>  FFMpeg has been disabled to avoid a crash in some MMX2 assembly
> code
> >  >>> and
> >  >>>  the old vic scalar doesn't support the required colorspace. I
> might
> >  >>> have
> >  >>>  a newer version of vic released later in the week if I'm able
> to
> >  >>> resolve
> >  >>>  the issue.
> >  >>>
> >  >> Thanks for sorting the RPMs out -
> >  >
> >  > Actually I haven't sorted the RPMs out yet, I wanted to use
> >  > 'alternatives' mechanism to release several different VIC RPMs
> built
> >  > with different build options, unfortunately there are issues when
> >  > performing a rpm update from an older VIC rpm which doesn't use
> >  > alternatives. The workaround is convoluted and involves RPM
> triggers.
> >  >
> >  > It might be for the better as more choices of VIC would only
> confuse
> >  > things for users.
> >  >
> >  >  > When do you see the crash occurring?
> >  >
> >  > With H.261 CIF video window as soon as I increase the window size,
> >  > color-swscale crashes.
> >  >
> >  > If I do what one version of VLC I found does, which is disable the
> >  > SWS_CPU_CAPS_MMX2 flag, see attached patch, it works for me.
> >  >
> >  >  > It runs ok on my machines - I guess the snag may be compile-
> time
> >  >  > assembly optimisations...though at least some of it is runtime.
> You
> >  >  > could try using a later version of ffmpeg - we just need to
> make sure
> >  >  > its stable on all three platforms.
> >  >
> >  > I think it may have something to do with PIC addressing which
> >  > subsequently results in the wrong register(s) being used with
> MMX2.
> >  >
> >  > I think I might try the Ubuntu ffmpeg patches (
> >  > ffmpeg_0.cvs20070307-5ubuntu6.diff.gz ) available here:
> >  >   http://archive.ubuntu.com/ubuntu/pool/main/f/ffmpeg/
> >  > which has -fPIC and assembly related patches.
> >  >
> >  > I've tried a few version of ffmpeg and libswscale (I made sure
> ffmpeg
> >  > and libswcale had the same datestamps).
> >  >
> >  > When I mentioned I thought the Fedora 8 livna repository's ffmpeg
> was
> >  > built with swscale in an email a few weeks ago, I was wrong, it
> isn't
> >  > built with swscale.
> >  >
> >  >
> >  > Cheers,
> >  > Doug
> >  >
> >  >
> >  > ------------------------------------------------------------------
> ------
> >  >
> >  > Index: render/color-swscale.cpp
> >  >
> ===================================================================
> >  > --- render/color-swscale.cpp  (revision 4125)
> >  > +++ render/color-swscale.cpp  (working copy)
> >  > @@ -70,12 +70,15 @@
> >  >
> >  >  #ifdef RUNTIME_CPUDETECT
> >  >             flags |= (available_cpu_flags & FF_CPU_MMX ?
> SWS_CPU_CAPS_MMX : 0);
> >  > +#if 0
> >  >             flags |= (available_cpu_flags & FF_CPU_MMXEXT ?
> SWS_CPU_CAPS_MMX2 : 0);
> >  > +#endif
> >  >             flags |= (available_cpu_flags & FF_CPU_3DNOW ?
> SWS_CPU_CAPS_3DNOW : 0);
> >  >             flags |= (available_cpu_flags & FF_CPU_ALTIVEC ?
> SWS_CPU_CAPS_ALTIVEC : 0);
> >  >  #elif defined(HAVE_MMX)
> >  >                 flags |= SWS_CPU_CAPS_MMX;
> >  > -     #if defined(HAVE_MMX2)
> >  > +     //#if defined(HAVE_MMX2)
> >  > +     #if 0
> >  >                 flags |= SWS_CPU_CAPS_MMX2;
> >  >       #endif
> >  >  #elif defined(HAVE_3DNOW)
> >
> >

Reply via email to