On Tue, May 05, 2020 at 04:16:57PM +0200, Andreas Rheinhardt wrote: > Commit 14b3f9961f3cf9173c43c936eb0cfb5a35fb8419 introduced header > repetition (used to improve resilience) in the NUT muxer; a variable > header_count was added for this to the NUTContext. It contained the > number of times the header has already been sent. > > Yet a few months later a712d725c0d466cc3672d626883319ef828ca8d6 and > 3b4f69ae8ceac45dd815d26e17d83a7dda4c4057 were merged which added support > for header elision in the NUT muxer resp. demuxer. Both of these commits > used the header_count variable to denote the number of stored headers. > This effectively initialized header_count to seven; it was still > incremented when writing a header (in particular, it was eight after > writing the first header at the beginning of the file), yet given that > it started from such a high level the first repeated header would only > be inserted after 16TiB. > > (The NUTContext supports up to 128 stored headers in order to satisfy > the needs of the demuxer (which shares this context with the muxer). > If the muxer had its own context that only contained seven entries for > headers, then this would have been very dangerous, because after writing > the initial header the number of actual stored headers and header_count > differ.) > > This commit fixes this by separating the two variables. The number of > written headers is now stored in header_written. > > Given that NUT output is used in a large number of FATE tests that have > nothing to do with NUT (like the filter-pixdesc tests that use NUT with > the md5 output protocol) a large number of tests had to be updated. The > only difference is that now repeated headers are written when writing > the trailer. Notice that the part of the tests that actually test the > file's contents did not need to be modified as seen with the acodec-pcm > tests. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > --- > This commit is simply about fixing the regression caused by a712d725 and
> restoring the previous behaviour. In particular, it potentially repeats > the header twice when writing the trailer, although I don't know why. if there is damage to one of 2 headers it is not neccessarily always clear what is damaged, with 3 one can simply take the majority. > I am also unsure why the size difference between successive headers > grows exponentially. I think i dont understand what you say here. The size of each header should not grow exponentially relativly to the previous > > And maybe we should stop using NUT in all these tests that have nothing > to do with NUT. One advantage of NUT is that we can extend it whenever we need. So theres never a feature we couldnt test with nut. That makes nut a simple choice to use universally when the container is not the article of the test itself thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ 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".
