Hi, On Thu, Jan 5, 2012 at 5:51 AM, Reinhard Tartler <siret...@gmail.com> wrote: > On Sun, Dec 25, 2011 at 9:57 PM, Reinhard Tartler <siret...@gmail.com> wrote: >> On Mon, Nov 7, 2011 at 10:01 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: >>> Hi, >>> >>> On Mon, Nov 7, 2011 at 12:46 PM, Reinhard Tartler <siret...@tauware.de> >>> wrote: >>>> On Mo, Nov 07, 2011 at 18:20:50 (CET), Måns Rullgård wrote: >>>> >>>>> Reinhard Tartler <siret...@tauware.de> writes: >>>>> >>>>>> tags 647824 upstream >>>>>> stop >>>>>> >>>>>> On So, Nov 06, 2011 at 17:53:30 (CET), Harald Dunkel wrote: >>>>>> >>>>>>> Package: libav >>>>>>> Version: 4:0.7.2-1 >>>>>>> >>>>>>> If I build the current xbmc snapshot, then it dies at runtime when >>>>>>> creating thumbnails for wmv files. See http://trac.xbmc.org/ticket/11789 >>>>>>> for more details >>>>>>> >>>>>>> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/134444 >>>>>>> >>>>>>> provides a workaround. Do you think this could be included in the >>>>>>> libav and libav-extra packages? >>>>>>> >>>>>> >>>>>> That patch does not apply to Debian's libav package. In fact, it seems >>>>>> that this bug is still present in the master branch. >>>>>> >>>>>> I was able to reproduce the segmentation fault using the following >>>>>> command in libav *master* (inspired by >>>>>> https://ffmpeg.org/trac/ffmpeg/ticket/397): >>>>>> >>>>>> ./ffmpeg -v 9 -loglevel 99 -i >>>>>> /srv/scratch/fate-suite/amv/MTV_high_res_320x240_sample_Penguin_Joke_MTV_from_WMV.amv >>>>>> -sws_flags fast_bilinear -vf "scale=640:480" -vframes 1 -vcodec png >>>>>> output.png >>>>>> >>>>>> Unforutnately, this (adapted) patch does not seem to fix the >>>>>> segmentation fault: >>>>>> >>>>>> diff --git a/libswscale/x86/swscale_template.c >>>>>> b/libswscale/x86/swscale_template.c >>>>>> index 5e7df5c..51ea303 100644 >>>>>> --- a/libswscale/x86/swscale_template.c >>>>>> +++ b/libswscale/x86/swscale_template.c >>>>>> @@ -1657,6 +1657,11 @@ static void RENAME(hyscale_fast)(SwsContext *c, >>>>>> int16_t *dst, >>>>>> DECLARE_ALIGNED(8, uint64_t, ebxsave); >>>>>> #endif >>>>>> >>>>>> + // HACK: gcc 4.6 no longer decrements esp, >>>>>> + // use this to make it reserve space for the call >>>>>> + // return address >>>>>> + void *dummy; >>>>> >>>>> The real problem here comes from hiding a call inside inline asm. >>>> >>>> That sounds pretty plausible. >>>> >>>> To make matters more complicated, I've tried disabling the MMX2 version >>>> of hyscale_fast with this patch: >>>> >>>> diff --git a/libswscale/x86/swscale_template.c >>>> b/libswscale/x86/swscale_template.c >>>> index 5e7df5c..b7a75b1 100644 >>>> --- a/libswscale/x86/swscale_template.c >>>> +++ b/libswscale/x86/swscale_template.c >>>> @@ -1843,7 +1843,7 @@ static av_cold void >>>> RENAME(sws_init_swScale)(SwsContext *c) >>>> if (c->srcBpc == 8 && c->dstBpc <= 10) { >>>> // Use the new MMX scaler if the MMX2 one can't be used (it is faster >>>> than the x86 ASM one). >>>> #if COMPILE_TEMPLATE_MMX2 >>>> - if (c->flags & SWS_FAST_BILINEAR && c->canMMX2BeUsed) >>>> + if (c->flags & SWS_FAST_BILINEAR && c->canMMX2BeUsed && 0) >>>> { >>>> c->hyscale_fast = RENAME(hyscale_fast); >>>> c->hcscale_fast = RENAME(hcscale_fast); >>>> >>>> AFAIUI, this makes swscale fallback to the slower hyScale() function and >>>> avoid this buggy implementation. Unfortunately, I get another >>>> segmentation fault here: >>> >>> That's not right, scaling coefficients are different so you need to >>> account for that. >>> >>> I'll have a look at this... I'm not against removing hscale_fast >>> altogether, including the scale coefficient specialcase handling etc. >> >> any news on this? did you have a chance to look at this? > > ping?
As said on IRC, disable the code on x86-64 for now. I've had a look and am working on porting all inline asm (including this) to yasm (which means I can manually control redzone'ness), but it's not ready yet. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
