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

Michael Niedermayer michaelni at gmx.at
Fri Sep 19 13:39:31 CEST 2014


On Fri, Sep 19, 2014 at 04:15:13AM +0000, Raento Mika wrote:
> 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.

there are the image tests like fate-lavf-bmp which have multiple
files, though iam not sure if they are a good reference


> 
> (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.

yes, for framecrc & the playlist, still the generated ts file(s) needs
a md5 or similar check too. Not just framecrc from them being
demuxed, as that could be unchanged and the ts still changing.
And while it doesnt give any details of what changes its still usefull
to detect bugs if for exampe one makes a change thats not supposed to
change the generated ts


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140919/6d1583e6/attachment.asc>


More information about the ffmpeg-devel mailing list