2018-03-14 0:26 GMT+01:00, Martin Vignali <martin.vign...@gmail.com>:
>> >> Patch in attach, add test for hap encoding
>> Why is this a good idea?
> The question, is maybe why is this a wrong idea ?
We usually don't test external libraries, the main reason is probably
that if they change behaviour, fate breaks (and we cannot fix it
in a reliable way).
>> Does the specification explain how encoding has to be done?
> Not sure i understand, the spec explain that hap use DXT
> encoding and snappy, and explain the frame organization.
If the specification defines encoding, the hap encoding fate test
is not necessarily a good idea but it may be acceptable. Afaiu,
modern specifications never define encoding, they (always)
define decoding. If the (snappy) specification defines decoding
(decompression), then the fate test is not only not a good idea,
it is plain wrong and should be reverted.
>> This is very unusual, no?
>> Even if so: Why are we testing an external library?
> Hap encoding inside ffmpeg use an external lib (libsnappy),
> only for one step of the encoding process (the lossless part)
> DXT encoding, and frame organization is done "inside" ffmpeg.
If snappy is so reliable that it can be used for fate, and if
our wrapper is so fragile that is has to be tested, the test
should at least be a round-trip to avoid issues with new
ffmpeg-devel mailing list