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>
* 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>
