[FFmpeg-devel] Awakening of FFH264

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Mar 23, 2010 at 05:35:17PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > 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.
>> 
>> Having a _crappy_ encoder in FFmpeg is detrimental to users and to our
>> reputation.  I regularly hear complaints about the terrible quality of
>> the AAC and Vorbis "encoders" in FFmpeg. As most of them never make it
>> to this list, you're probably unaware of them.
>
> having a encoder for regression tests and making this encoder available
> to users by default are 2 seperate things

At least 2...

>> For regression testing the H264 decoder, we have the official
>> conformance tests, which exercise every last bit of the decoder,
>> something a simple encoder would never manage to do.
>
> with that argument we should drop many tests from "make test"
> i suspect though this would increase the number of commits that break the
> affected codecs.

"make test" serves as much to test the encoders as the decoders.  None
of the encoders to date exist solely to provide test vectors for the
decoders.

> anyway the point is moot, the patch here is not fit for anything currently

Glad we agree on that.

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