[FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer

[Moritz Barsnick]

On Thu, Sep 12, 2019 at 13:44:57 +0200, Peter B. wrote:
> If I understand this correctly, does it mean that the order of streams
> output by the streamhash muxer will be "in order of type" (video, audio,
> etc), independent of the order in the source?

Since it's a muxer, and not a hashing demuxer (unfortunately - or
rather a different use case[*]), it has the standard ffmpeg muxing
order, unless you specify something else. In other words, best video
and best audio from first input, skipping all else. If you want to
preserve the original mapping, you'll need to specify "-map 0". And
possibly some option to mux unknown streams, and definitely "-c:s copy
-c:d copy". I tried "-copy_unknown", but the unknown data stream seems
to ruin "-t", because of missing timestamps. Perhaps "-ignore_unknown"
should be preferred.

> So 2 files (source/target) will have matching streamhash output order,
> independent of their actual stream order inside their containers?

Yes, if you don't specify otherwise.

> Since this streamhash is intended for content-validation and not
> remux-validation, I would say the way it's now is great!

For content validation, I guess the above recommendation and a general
"-c copy" is advised, to make yourself independent of the decoders.
(E.g. native aac and libfdk_aac can give different decoded output).

> > Looks fine.
>
> +1 from me, too :)

Implemented as such in the v3 patchset.

> I guess with multiple A/V tracks it will then be like this?
>
> 0,v,SHA256=...
> 1,v,SHA256=...
> 2,a,SHA256=...
> 3,a,SHA256=...
> 4,a,SHA256=...
> 5,s,SHA256=...

See above. Not if the input is v,a,a,v,a,a,s.

Moritz

[*] It make make sense as part of a demuxer as well, and as a bitstream
filter, which creates and dumps this data *while* creating other
output. I'm open for requests. ;-)