RTCP synchronization packet was broken since commit in ffmpeg version > 2.8.3
(commit: e04b039b1528f4c7df5c2b93865651bfea168a19) Since this commit (2e814d03)
"rtpenc: Simplify code by introducing a macro for rescaling NTP timestamps", NTP_TO_RTP_FORMAT
uses av_rescale_rnd() function to add the data to the packet.

This causes an overflow in the av_rescale_rnd() function and it will return INT64_MIN.
Causing the NTP stamp in the RTCP packet to have an invalid value.

Github: Closes #182

Reverting commit '2e814d03' solves the problem.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

The first X96 channel set can have more channels than core, causing X96
decoding to be skipped. Clear the number of decoded X96 channels to zero
in this rudimentary case.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

In this case container width/height is better however.
Thanks to koda for the sample

Signed-off-by: Umair Khan <omerjerk@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Makes it far easier to spot the issue if e.g.
caused by a typo in the code table.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

I cannot see any point whatsoever to use
double here instead of float, the results
are likely identical in all cases..
Using float allows for much more
efficient use of SIMD.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

seems not useful
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Use the context and level specified to av_pkt_dump_log2(),
instead of panic level (0), for dumping packet payload.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

avformat/avienc: assert that bits_per_coded_sample is within the supported range (out of array access otherwise)
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: Michael Niedermayer <michael@niedermayer.cc>

Regression introduced in 29412821.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes compilation of fft with hardcoded tables
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

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

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

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

This was a leftover from before the slices were encoded in parallel.
Since the put_bits context is initialized per slice aligning it
aferwards is pointless.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

This commit solves most of the crashes and issues with the encoder and
the bitrate setting. Now the encoder will always allocate the absolute
lowest amount of memory regardless of what the bitrate has been set to.
Therefore if a user inputs a very low bitrate the encoder will use the
maximum possible quantization (basically zero out all coefficients),
allocate a packet and encode it. There is no coupling between the
bitrate and the allocation size and so no crashes because the buffer
isn't large enough.

The maximum quantizer was raised to the size of the table now to both
keep the overshoot at ridiculous bitrates low and to improve quality
with higher bit depths (since the coefficients grow larger per transform
quantizing them to the same relative level requires larger quantization
indices).

Since the quantization index start follows the previous quantization
index for that slice, the quantization step was reduced to a static 1
to improve performance. Previously with quant/5 the step was usually
set to 0 upon start (and was later clipped to 1), that isn't a big change.
As the step size increases so does the amount of bits leftover and so
the redistribution algorithm has to iterate more and thus waste more
time.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Adding early support for a subset of the proposed colour elements
according to the latest version of spec:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=hIKLhMdgTMTEwUTeA4ct38h0tmE

I've left out elements for pix_fmt related things as there still
seems to be some discussion around these, and the max_cll/max_fall
are currently not propagated as there is not yet side data for them.

The new elements are exposed under strict experimental mode.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

The wrong member was remove/moved after review of the blacklist API.

10L cola.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This commit is a no-op. We already have these, plus our asm differs.

* commit '257b30af':
  x86: hevc: Fix linking with both yasm and optimizations disabled
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit 'cd846b47':
  fate: Ignore errors from concatenating report files
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '9328adcc':
  fate: Be silent when fetching Git updates
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>