The code currently reads the coded dimensions from the extradata, but
expects the display dimensions to be set by the caller, and does not
check that they are compatible (i.e. that the displayed size is smaller
than the coded size).
Make sure that when the display dimensions are set, they are also valid.
Fixes possible invalid memory access.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
It is passed to the get_bits API, which requires buffers to be padded.
Fixes possible invalid reads.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
height - me_y is the line from which we read, so it must be strictly
smaller than the frame height. Fixes possible invalid reads in corrupted
files.
Also, use a proper context for logging the error.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
If we encounter an END element before anything is decoded, we would
return success even though the output frame has not been allocated,
which is invalid.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Not from the underlying frame. Fixes races with frame threading in
field-coded files, where decoding would wait for the wrong field (e.g.
random failures in mixed-nal-coding).
Bug-Id: 954
A non-existent av_buffer_pool_can_uninit() function is mentioned instead
of av_buffer_pool_uninit(). Also, this function is to be called by the
caller, not the pool itself.
In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).
CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>
The reference frames are used in update_thread_context(), so modifying
them after finish_setup() is a race. The frame in question will be
released during the next decode call.
CC: libav-stable@libav.org
The current code will ignore the init_get_bits() failure and do an
invalid read from the uninitialized GetBitContext.
Found-By: Jan Ruge <jan.s.ruge@gmail.com>
Bug-Id: 952
Since we only know whether a NAL unit corresponds to a new field after
parsing the slice header, this requires reorganizing the calls to slice
parsing, per-slice/field/frame init and actual decoding.
In the previous code, the function for slice header decoding also
immediately started a new field/frame as necessary, so any slices
already queued for decoding would no longer be decodable.
After this patch, we first parse the slice header, and if we determine
that a new field needs to be started we decode all the queued slices.
This function's purpose is not very well defined. Currently it does two
(only marginally related) things: selecting the next output frame and
calling ff_thread_finish_setup() for frame threading. The first of those
more properly belongs under field_start(), while the second can be
called directly from decode_nal_units().
Currently, SPS.mb_height is actually what the spec calls
PicHeightInMapUnits, which is half the frame height when interlacing is
allowed. Calling this 'mb_height' is quite confusing, and there are at
least two associated bugs where this field is treated as the actual
frame height - in the h264 parser and in the code computing maximum
reordering buffer size for a given level.
Fix those issues (and avoid possible future ones) by exporting the real
frame height in this field.
This preserves all the information in the codec parameters.
The wavpack ref changes are caused by the fact that now the sample
format is set, so matroskaenc can use it to set the bit depth.
Bug-Id: 945, along with the previous commit
The source frame may be cropped, so that its dimensions are smaller than
the pool dimensions. The transfer_data API requires the allocated size
of the destination frame to be the same as the pool size.
Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.
This should fix the random FATE failures for complex filtergraph tests
after a3a0230a98
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
Currently, a filtergraph will pull in the output constraints from its
corresponding decoder context, which breaks proper layering. Instead,
explicitly send the constaints on the output parameters to the
filtergraph.
This is similar to what is done for filtergraph inputs in
30ab4c51a180610d9f1720c75518d763515c0d9f
Setting the filter input parameters is moved to init_input_stream(),
so that it is done before the decoder is opened, potentially overwriting
the information from avformat_find_stream_info() with less accurate
data.
This commit temporarily disables QSV transcoding with hw frames. The
functionality will be re-added in the following commits.
Currently, calling configure_filtergraph() will pull in the input
parameters from the corresponding decoder context. This has the
following disadvantages:
- the decoded frame is a more proper source for this information
- a filter accessing decoder data breaks proper layering
Add functions for explicitly sending the input stream parameters to a
filtergraph input - currently from a frame and a decoder. The decoder
one will be dropped in future commits after some more restructuring.
Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.
Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.
The current code assumes that encoding_needed is simply an inverse of
stream_copy, which is not true for manually attached files (for which
neither of those is true).
We already have all the necessary information in open_output_file().
This makes the information about the stream/filtergraph mappings
available earlier.
This is a more appropriate place for this. H264Context.recovery_frame is
shared between frame threads, so modifying it where it is right now is
invalid.
Anton Khirnov