The default get_buffer2() implementation (and possibly some
user ones) does not allocate edges when this flag is set, which may
expose bugs in some decoders. Until the 10 release is out, it is safer
to remove this part.
* commit '5b2b23f2d69e05c5fcd1c933e383fe60e185574d':
dxva2: Retry IDirectXVideoDecoder_BeginFrame()
This also adds a missig #include to prevent breaking building
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a246d06fe0dc6c2ea65e95327624b4537ff9bd0d':
hevc: clip pixels when transquant bypass is used
See: c9fe0caf7a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The T-REC-H.265-2013044 page 79 states it has to be in the range
[-s->sps->qp_bd_offset, 51].
Sample-Id: 00001386-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
The src buffer should only contain values in the interval
[0, (1 << BIT_DEPTH) - 1].
Since shift = (BIT_DEPTH - 5), src[x] >> shift must be in
the interval [0, 31], so no clip is needed.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The reconstructed picture should always be clipped (see section 8.6.5),
previously we did not clip coding units where
cu_transquant_bypass_flag == 1.
Sample-Id: 00001325-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
And use unsigned datatypes.
Otherwise it would overflow.
Sample-Id: 00001315-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This matches how its done for SPS/PPS.
Fixes null pointer dereference.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Set duration to 10 seconds, after it was increased from 5 to 200 seconds
in 8d80f3cb87.
200 seconds will generate too much data which is annoying especially when
testing.
* qatar/master:
vc1: Always reset numref when parsing a new frame header.
Conflicts:
libavcodec/vc1.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '89564be444d24f75ea5add8b6987e414cf7aa7d5':
rtmpproto: Send a full, absolute timestamp if it isn't monotonically growing
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd01e684186bc1631bc176f06b89d33c27ec0d24d':
mov: do not set avg_frame_rate in the demuxer
Conflicts:
libavformat/mov.c
Not merged
The default fallback code that sets avg_frame_rate guesses the value
from a very small number of frames at the videos start and is wrong in
some cases for the file as a whole.
Now that makes it guess vs guess, but the code in mov is much faster
Also ideally the mov code should be fixed and give a exact avg_frame_rate
based on the actual cts from the index (CTTS/STTS)
If someone has sample(s) which show wrong fps values, please open a ticket
on trac or mail me if its private.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes an issue where the B-frame coding mode switches from interlaced
fields to interlaced frames, causing incorrect decisions in the motion
compensation code and resulting in visual artifacts.
CC: libav-stable@libav.org
Signed-off-by: Tim Walker <tdskywalker@gmail.com>
The normal differential timestamps can't handle negative
differences, thus send a full packet header with an absolute
timestamp in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
If the url ends with .flv, we stripped it but didn't initialize
rt->playpath, doing av_strlcat on an uninitialized buffer.
Signed-off-by: Martin Storsjö <martin@martin.st>
The track duration is often not reliable or is not the duration
represented by the number of frames. In those cases, avg_frame_rate
was reported incorrectly. Removing this code falls back to the
default calculation in avformat_find_stream_info().
This is a partial revert of commit c3aeaa540.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* cehoyos/master:
Avoid a possible overflow when reading Nikon avi files.
Add h263dsp dependency to mpeg1video and mpeg2video encoders.
Fix compilation with --disable-hwaccel=mpeg1_xvmc,mpeg2_xvmc
Merged-by: Michael Niedermayer <michaelni@gmx.at>
