Steve Lhomme:
> Not sure how FATE works but I suppose the pseudo-random becomes deterministic
> ? In that case the size should always be the same. And if not having a fixed
> size will make no difference.
>
> If FATE can skip random parts of a file (which your patch would solve) it
> will miss inconsitencies of UIDs that should be the same in two places of the
> file. So IMO it's not good. I suggest to have a flag in the muxer to force
> the seed to a fixed value when using FATE.
>
The output of FATE was always deterministic. Here is the relevant
snippet from patch #3:
+ if (s->flags & AVFMT_FLAG_BITEXACT) {
+ track->uid = i + 1;
+ } else {
+ track->uid = mkv_get_uid(mkv->tracks, i, &c);
+ }
The rest of the code does simply refer to track->uid and does not care
about whether these values have been set randomly or not.
Patch #6 has been made to address concerns [1] that adding random values
all over the place could inhibit catching bugs.
We can already check the UIDs for consistency: By muxing a file and then
checking whether the metadata is read correctly. I have recently applied
a patch [2] that allows to do exactly that and I intend to add more
tests using this capability.
- Andreas
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253377.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260592.html
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
