English was used before.
Signed-off-by: Marton Balint <cus@passwd.hu>

fix the call of the unsafe version of slice encoding in interlace mode
fix padding line count in sub image with fill in interlace mode

avcodec/proresenc_aw : use AVframe primaries, transfert, colorspace for frame header instead of default (unknown, unknown, Rec601)

avoid color shift, on some decoding software

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Since there is no information about the source format, "unspecified"
is the correct value to write here.

All tests using the MPEG-2 encoder are updated, as this changes the
header on all outputs.

This improves the quality and reduces the "blocking" in flat areas
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Fixes #6214 and vsynth1-dnxhd-720p-hr-lb.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.

Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>

> seems to break
> make fate-vsynth1-mjpeg-444

Fixed.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

added sws_flags flags and tested against x86_32
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The encoder produces bitstream compatible with the current specification
and version 2 is set as reserved (non-standardizable).

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.

In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.

There are multiple important problems with this approach:
    - the fields in AVCodecContext are in general one of
        * stream parameters
        * codec options
        * codec state
      However, it's not clear which ones are which. It is consequently
      unclear which fields are a demuxer allowed to set or a muxer allowed to
      read. This leads to erratic behaviour depending on whether decoding or
      encoding is being performed or not (and whether it uses the AVStream
      embedded codec context).
    - various synchronization issues arising from the fact that the same
      context is used by several different APIs (muxers/demuxers,
      parsers, bitstream filters and encoders/decoders) simultaneously, with
      there being no clear rules for who can modify what and the different
      processes being typically delayed with respect to each other.
    - avformat_find_stream_info() making it necessary to support opening
      and closing a single codec context multiple times, thus
      complicating the semantics of freeing various allocated objects in the
      codec context.

Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.

lavf/riffenc: Write space for palette
tests/ref/vsynth: Update 1 bpp files for pal8
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This makes sure that white stays white and black black
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

 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>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It was useful to (accidentally?) spot an overflow in the column pass
of the x86 simple_idct10 implementation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

omse goes from 0.03060703 (which fails for dct-test) to 0.01663750.
This also actually improve the error of decoding the sample generated
by fate-vsynth3-dnxhd1080i-10bit using simple_idct10 to FAANI, which
goes (when resampled to yuv422p) from:
stddev:    0.06 PSNR: 72.28 MAXDIFF:    1
to identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Convert them to zigzag order, as the rest of them are.

When I was adding support for 10-bit DNxHD, I just copy-pasted the
missing quant matrices from the spec. Now it turns out the existing
matrices in dnxhddata.c were in zigzag order. This resulted in wrong
quantization for 10-bit DNxHD. The attached patch fixes the problem by
converting 10-bit quant matrices to zigzag order.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Freeze picture release should be set to 1 when we're responding to a
fast update request. For simplicity we set it for all intra frames,
including those that starts a GOP.

Fixes issue where Tandberg MXP1700 does not recover from packet loss
state since it's waiting for the freeze picture relase indication.

Bug-Id: 873
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>