[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec

[Felipe Contreras]

2010/9/6 M?ns Rullg?rd <mans at mansr.com>:
> Felipe Contreras <felipe.contreras at gmail.com> writes:
>
>> On Mon, Sep 6, 2010 at 12:46 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>>> Felipe Contreras <felipe.contreras <at> gmail.com> writes:
>>>
>>>> I wasn't hoping for inclusion yet, I just wanted to gather some
>>>> feedback, but if somebody fells like merging, go ahead :)
>>>
>>> In case you change your oppinion, please consider using tools/patcheck (tabs,
>>> for example, are not allowed in FFmpeg svn).
>>
>> Ok, I can do that for the code specific to FFmpeg, however, not what
>> is under 'tidsp' directory. If that's spun out as a library for the
>> FFmpeg code to depend on, then that wouldn't be a problem.
>
> If code is not specific to FFmpeg, it does not belong in FFmpeg, and
> the patch is thus implicitly rejected. ?If code does belong in FFmpeg,
> it must adhere to the FFmpeg style rules. ?No exceptions.

As I said, the code was not pushed for acceptance, but for comments,
hence the RFC in the subject.

I was hoping the code in 'tidsp' directory would be acceptable as is;
maybe making an exception on the code-style due to the added benefits
and small size, or maybe somebody would take up the task of
maintaining such code by converting the code-style from libtidsp-ng
(or whatever). If that's not the case, I can make that code a separate
library.

Now, I don't think it makes sense to send the code for acceptance
depending on a library that doesn't exist yet, and thus would be
untestable. I thought it was much more productive to send something
that can be tested, specially since the final code that depends on
libtidsp-ng would be mostly the same, you just have to ignore the code
in the 'tidsp' directory which is just one patch (hence easy to skip).

Anyway, I already said I will change the code-style for the code
actually pushed for acceptance to FFmpeg. Any other comments?

-- 
Felipe Contreras