[FFmpeg-devel] Awakening of FFH264

[Baptiste Coudurier]

On 03/23/2010 11:59 AM, Michael Niedermayer wrote:
> On Tue, Mar 23, 2010 at 06:54:23PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer<michaelni at gmx.at>  writes:
>>
>>> On Tue, Mar 23, 2010 at 10:57:04AM -0700, Jason Garrett-Glaser wrote:
>>>> On Tue, Mar 23, 2010 at 10:21 AM, Michael Niedermayer<michaelni at gmx.at>  wrote:
>>>>> On Tue, Mar 23, 2010 at 01:59:46PM +0200, Kvikant, Christian wrote:
>>>>>> M?ns Rullg?rd wrote:
>>>>>>> Sorry, but what is the point of this?  There is already a fantastic,
>>>>>>> open source H.264 encoder in x264.
>>>>>> I agree totally. FFH264 is not up to par nether regarding
>>>>>> quality nor size.  The only reason for this exercise was
>>>>>> licensing. If the feeling is that FFH264 will never become part
>>>>>> of FFmpeg, then we will keep it as a separate patch.
>>>>>
>>>>> a simple and small encoder could be usefull for regression testing.
>>>>
>>>> If the encoder uses practically no features it's totally useless for
>>>> regression testing...
>>>
>>> It shouldnt be hard to use lots of features and just write random values ;)
>>> for regression tests that would be fine.
>>
>> Then we are no longer talking about an encoder in the usual sense.
>> Besides, ensuring the maximally awkward values are used is _hard_.
>> The conformance tests already do that, so there's no need to duplicate
>> that work.
>
> testing the conformance streams need a lot of time, its not something i do
> before every commit.
> but make test is something i try to do before commit unless its a trivial
> change
> with that workflow in mind, a small and fast h264 test would be usefull

Testing the muxers code path with h264 is also useful.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org