[FFmpeg-devel] Awakening of FFH264

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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

If you download the FATE test files, you can "make fate-h264-$test" to
run specific h264 tests.  Feel free to suggest subsets worthy of
dedicated shorthand names.  We can easily add that.

-- 
M?ns Rullg?rd
mans at mansr.com