Michael Niedermayer: > On Tue, Dec 03, 2019 at 04:19:47PM +0100, Andreas Rheinhardt wrote: >> Up until now, the TrackUID of a Matroska track which is supposed to be >> random was not random at all: It always coincided with the TrackNumber >> which is usually the 1-based index of the corresponding stream in the >> array of AVStreams. This has been changed: It is now set via an AVLFG >> if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set >> now (the only change happens if an explicit track number has been >> chosen via dash_track_number, because the system used in the normal >> situation is now used, too). In particular, no FATE tests need to be >> updated. >> >> This also fixes a bug in case the dash_track_number option was used: >> In this case the TrackUID was set to the track number, but the tags were >> written with a TagTrackUID simply based upon the index, so that the tags >> didn't apply to the track they ought to apply to. > > LGTM > thx > Good to hear. When merging, the fix for ChapterUIDs (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253440.html) should get merged first. > >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> >> --- >> I have updated the patchset to rely on the AVLFG to provide sufficiently >> many distinct values, as you said. I could add a check and a for if we still >> have a collision after (say) 1000 tries in order to avoid the >> potentially infinite loop. > > You could replace the LFG if you dont trust it. > But i dont understand why you would use it when you dont trust it and then > add a check > I actually trust that it works; it's just that I can't furnish a proof.
- Andreas _______________________________________________ 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".
