Hi Piers, Just wondering if you get the grey bar at the top of a 1/4 NTSC (i.e shift-M) or NTSC (shift-L) video window? See attached PNG file (ignore the blue mute, I don't have a camera to connect to my DVB PCI card at home). It looks like the image is pushed down by the same number of pixels as the bar. I seem to have that issue regardless of which version of FFMpeg/SWScaler is used.
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. 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)
<<attachment: test.png>>
