[FFmpeg-devel] Questions on adding a FATE test for the HLS muxer

[Raento Mika]

On 19/09/14 01:27, "Michael Niedermayer" <michaelni at gmx.at> wrote:

>On Thu, Sep 18, 2014 at 06:05:38PM +0000, Raento Mika wrote:
>> Hiy'all
>> 
>> As suggested by Michael, I'm trying to add a FATE test for the new
>> single_file option to the HLS muxer.
>> 
>> I have something working, but I'm not sure what's the best way to do
>>this.
>> The wiki page is not very complete.
>> 
>> The HLS muxer produces a number of .ts files (well, one for the
>> single_file case) and a m3u8 file. The m3u8 is output several times
>>during
>> the muxing.
>> 
>> The existing tests I found all use a single output, passing '-' as the
>> output filename to ffmpeg. Doing this generates a file that looks like
>> 
>> <ts contents for first segment><first m3u8 contents><ts contents for
>> second segment><second m3u8 contents>...
>> 
>> checking this against a reference file will indeed verify the whole
>> output, but is not very readable. Should I do this? And if so, how do I
>> add a new reference file to FATE.

Hi, thanks for the great feedback

>
>the output files, each should be checked against a md5 stored in git
>also the whole  should be demuxed again (with framecrc) and that too
>compared against the good framecrc output in git.

Is there an example that does this (multiple outputs)? The ones I found
with some searching all just used one output, a pipe.

(I'm not saying that I won't write the necessary support, I just wish
somebody had already done it :-)

>
>theres no real reference file for the fate-suite for this as theres
>not one correct ts file set. slight changes in the ts muxer or
>encoders would change the output

I would at least personally prefer the actual playlist and framecrc lists
to be used for comparison, rather than an md5 - with the md5 you'd have
very little visibility into _what_ changed.


    Mika

>
>[...]
>
>-- 
>Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>If a bugfix only changes things apparently unrelated to the bug with no
>further explanation, that is a good sign that the bugfix is wrong.
>