[FFmpeg-devel] [PATCH] libmpcodecs support

[Luca Barbato]

On 1/15/11 6:29 PM, Michael Niedermayer wrote:
> On Sat, Jan 15, 2011 at 04:47:56PM +0100, Luca Barbato wrote:
>> On 1/15/11 12:25 PM, Michael Niedermayer wrote:
>>> On Sat, Jan 15, 2011 at 03:17:24AM +0100, Luca Barbato wrote:
>>>> On 1/14/11 3:19 PM, Michael Niedermayer wrote:
>>> [...]
>>>>> i can just merge the changes in, but IMHO if it takes you more than a few days
>>>>> to run indent or sed over the code and get it approved then waiting longer has
>>>>> zero sense. Because indent takes seconds, and getting it approved either will
>>>>> happen or will not happen. And its twice as much code than there is in swcale so
>>>>> doing anything by hand is (from experience of swscale) something taking years
>>>>> and i think we all agree that blocking 80% of functionality of libavfilter
>>>>> for years is not worth the style changes to code that is semantically not even
>>>>> part of ffmpeg.
>>>>
>>>> I'd rather have clean and maintainable code in ffmpeg. I could accept
>>>> this kind of devils deal only if it gets first a full regression test so
>>>> trying to clean it up later would be half of the work.
>>>
>>> dont forget the full regression test for swscale as condition to your
>>> cleanup there
>>
>> I'm assuming the one currently present covers everything, point me to
>> what's missing if I'm wrong, I didn't check while running it so far ^^;
>
> missing ->  fate

Ah, it might be tricky I'll add to the todo =)

> but me writing 50+ regression tests for filters, some of which need
> external image files, some need interlaced or telecined material some need
> keypresses once pasing that is implemenzted ...

I wasn't aware you wanted to implement/import even those that need 
external input. I thought that you already had something that you used 
to check the interesting filters were ok with the wrapper.

>     is really hard and a shitload of work which is why iam a little upset
>     about your requesting me to do that, its close to saying "never commit this"
>
> swscale in fate is fun too, iam not sure its all binary identical accross
> platforms, iam not sure what should be tested, there are too many cases to
> test all ...
> so a subset has to be selected that is quick to test but covers as much as
> possible

I see I'll look into it soon, once I'm home I'll make the 
swscale-cleanup branch public.

lu