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

Reply via email to