Otherwise the 'lcov -q --remove' run fails with the following error:
lcov: ERROR: cannot write to coverage.info!
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
When out-of-tree builds now use a relative path, the '-b' option of lcov
is not needed, so just pass the current directory to it in this case.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The parser only parses the core, and thus has a duration relative
to the core sample rate only, not the actual stream sample rate.
FATE references changed due to now correct timestamps.
This reverts commit 8ed82d8174.
SMPTE S377-1-2009c defines in F.4.1 that the Video Line Map should
always be an array with two 32 bit integers as elements. This is
repeated in G.2.12 with actual examples for progressive content,
where the second value would always be 0.
Additionally, the IRT MXF analyser also lists this as the only
error in the MXF output from ffmpeg: https://mxf-analyser-cloud.irt.de
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since timecode_frame)start is a private option now, it stays at the default,
and is no longer written to the file.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
From
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the
bitmap has a color table immediatelly following the BITMAPINFOHEADER
structure. The color table consists of an array of RGBQUAD values. The
size of the array is given by the biClrUsed member. If biClrUsed is
zero, the array contains the maximum number of colors for the given
bitdepth; that is, 2^biBitCount colors."
Nothing about "monochrome" here. Unfortunately, pal8 to monow conversion
seems a bit flaky, but that's another story.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some debuggers/profilers use this metadata to determine which function a
given instruction is in; without it they get can confused by local labels
(if you haven't stripped those). On the other hand, some tools are still
confused even with this metadata. e.g. this fixes `gdb`, but not `perf`.
Currently only implemented for ELF.
This options is only used by huffyuv, ffvhuv, jpegls, mjpeg,
mpegvideoenc, png, utvideo.
It is a very codec-specific options, so deprecate the global variant.
Set proper limits to the maximum allowed values, and update utvideoenc
tests to use the new option name.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is only used by mpegvideoenc, x264, xavs, and vpx.
It is a very codec-specific option, so deprecate the global variant.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
I/S energy, especially when it comes to phase cancellations,
needs to use signed coefficients as input, yet it was using
abs'd coefficients. That was a slight bug.
The relative error between two encoding strategies is the simple
difference of rate-distortion values, and not the absolute
difference. An absolute measure would allow worsening of the
quantization error as well as improving.
1. Fix sf_idx and band_type addressing to address only the first
subwindow in the group (others could hold garbage values)
2. Don't step on ms_mask when is_mask is set. I/S selection
already sets the ms_mask properly and shouldn't be overridden.
3. Use mid/sid cb/sf when computing coding error, as should be
since those are the cb/sfs that will eventually be set.
4. Fix distortion computation on multi-subwindow groups (was
subtracting the bits terms multiple times)
5. Clear ms_mask when one side uses PNS and the other doesn't.
When using PNS, ms_mask signals correlated noise, which can be
detected just like regular M/S detection, so we don't skip
noise bands, but when only one side uses PNS setting the flag
can confuse some encoders, so avoid that.
