* commit 'e0ab5078a7d865f8f6fd6a6d3cbe0f380ead4a3d':
lavc: do not force the emu edge flag
Conflicts:
libavcodec/utils.c
There should be no such bugs in ffmpeg, but merging it anyway
as its safer.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In particular, avoid to leave around the seg->avf pointer to freed
structure, and fix crash with:
ffmpeg -f lavfi -i testsrc -c:v h264 -map 0 -f segment foo-%d.ts
Fixes these errors with nasm:
libavcodec/x86/lossless_videodsp.asm:86: error: invalid combination of opcode and operands
libavcodec/x86/lossless_videodsp.asm:88: error: invalid combination of opcode and operands
I don't know whether movd or movq was meant, but either way
maskq vs. maskd must match the mov size.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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>
