[FFmpeg-devel] [PATCH 12/12] avformat/nutenc: Fix repeating headers

[Michael Niedermayer]

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.rheinhardt at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200507/559d858c/attachment.sig>