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? -- regards, Reinhard _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel