[FFmpeg-devel] lavfi state of affairs

Michael Niedermayer michaelni
Thu May 7 22:21:18 CEST 2009


On Thu, May 07, 2009 at 09:40:12PM +0200, Vitor Sessak wrote:
> Michael Niedermayer wrote:
>> On Wed, May 06, 2009 at 10:31:54PM +0200, Vitor Sessak wrote:
>>> Michael Niedermayer wrote:
>>>> On Wed, May 06, 2009 at 08:46:58PM +0200, Vitor Sessak wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> On Sun, Feb 08, 2009 at 07:10:22PM +0100, Vitor Sessak wrote:
>>>>>>> Michael Niedermayer wrote:
>>>>>>>> On Sun, Feb 08, 2009 at 01:39:02PM +0100, Vitor Sessak wrote:
>>>>>> [...]
>>>>>>>> could you please use unambigous command lines that do not depend on
>>>>>>>> automatcally inserted scale filters!
>>>>>>> ffmpeg -i in.avi -vfilters "format=rgb32, scale=256:256,format=rgb32, 
>>>>>>> fifo,slicify=32, format=yuv410p, fifo" out.avi
>>>>>> [...]
>>>>>>> [format @ 0x88b9170]auto-inserting filter 'scale'
>>>>>>> [format @ 0x88be990]auto-inserting filter 'scale'
>>>>>>> [fifo @ 0x88ef990]auto-inserting filter 'scale'
>>>>> It do not _depends_ on auto-inserted filters, but I understand what you 
>>>>> mean:
>>>> good so lets restart the questions
>>>> 1. does this problem depend on the used scaler / bitexact / accurate
>>>> 2. does it also happen when actual scaling is used?
>>>> 3. full output please (highest verbosity and all the crap that sws can
>>>>    print)
>>>> and i know the awnsers to 1 & 2 where yes but there where 4 scalers,
>>> Indeed I either missed something or it was among one of Cedric's bug 
>>> fixes. For this example, either adding "bitexact" or doing scaling solves 
>>> the problem. For example:
>>>
>>> ffmpeg_g -an -i /tmp/levis.avi -vfilters 
>>> "slicify=32,scale=152:116:sws_flags=bilinear+bitexact" -pix_fmt yuv420p 
>>> -vcodec rawvideo -y /tmp/out.avi
>>>
>>> works fine. About the full output, the only additional line is
>>>
>>> [swscaler @ 0x8a1d330]using unscaled yuv410p -> yuv420p special converter
>> good, so next figure out in what case that is printed
>> hint: its yvu9toyv12Wrapper()
>> the function is just a few lines, the bug is obvious -> earn some karma
>> points fixing it
>
> You mean as attached?

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090507/ba7ded22/attachment.pgp>



More information about the ffmpeg-devel mailing list