Up until now, it was completely unspecified what the content of the
destination packet dst was on error. Depending upon where the error
happened calling av_packet_unref() on dst might be dangerous.
This commit changes this by making sure that dst is blank on error, so
unreferencing it again is safe (and still pointless). This behaviour is
documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_packet_ref() mostly treated the destination packet dst as uninitialized,
i.e. the destination fields were simply overwritten. But if the source
packet was not reference-counted, dst->buf was treated as if it pointed
to an already allocated buffer (if != NULL) to be reallocated to the
desired size.
The documentation did not explicitly state whether the dst will be treated
as uninitialized, but it stated that if the source packet is not refcounted,
a new buffer in dst will be allocated. This and the fact that the side-data
as well as the codepath taken in case src is refcounted always treated the
packet as uninitialized means that dst should always be treated as
uninitialized for the sake of consistency. And this behaviour has been
explicitly documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Validate the value of ST field in the TLM marker of JPEG2000.
Throw an error when ST takes value of 0b11.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The specifications are de-facto frozen now as they've already been used in
production for years, the author has indicated reluctance on IRC to change
it further, and the only potential changes would, from what I understand,
be forward-compatible.
Add overflow test for hevc_add_res when int16_t coeff = -32768.
The result of C is good, while ASM is not.
To verify:
make fate-checkasm-hevc_add_res
ffmpeg/tests/checkasm/checkasm --test=hevc_add_res
./checkasm --test=hevc_add_res
checkasm: using random seed 679391863
MMXEXT:
hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
- hevc_add_res.add_residual [FAILED]
SSE2:
hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
- hevc_add_res.add_residual [FAILED]
AVX:
hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
- hevc_add_res.add_residual [FAILED]
AVX2:
hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
- hevc_add_res.add_residual [FAILED]
checkasm: 8 of 14 tests have failed
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
check_func will return NULL for functions that have already been tested. If
the func is tested and skipped (which happens several times), there is no
need to prepare data(randomize_buffers and memcpy).
Move relative code in compare_add_res(), prepare data and do check only if
the function is not tested.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Resolution/format changes lead to re-initialization of hardware
accelerations(vaapi/dxva2/..) with new hwaccel_priv_data in
the worker-thread. But hwaccel_priv_data in user context won't
be updated until the resolution changing frame is output.
A termination with "-vframes" just after the reinit will lead to:
1. memory leak in worker-thread.
2. double free in user-thread.
Update user context in ff_frame_thread_free with the last thread
submit_packet() was called on.
To reproduce:
ffmpeg -hwaccel vaapi(dxva2) -v verbose -i
fate-suite/h264/reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12
-f rawvideo -vsync passthrough -vframes 47 -y out.yuv
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The comments for some of the markers were incorrect.
This patch fixes the comments associated with the markers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The classical ptr = av_realloc(ptr, size).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also return 0 after successfully reading a packet.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also simply return 0 in case a packet has been successfully read.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Increasing it by 2048 entries per realloc is exessive.
Reduces memory usage, especially on long, non fragmented output.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
beginning referencing the main level 1 elements (i.e. not the Clusters)
and one at the end, referencing the Clusters. This second SeekHead was
useless and has therefore been removed. Yet the SeekHead-related
functions and structures are still geared towards this usecase: They
are built around an allocated array of variable size that gets
reallocated every time an element is added to it although the maximum
number of Seek entries is a small compile-time constant, so that one should
rather include the array in the SeekHead structure itself; and said
structure should be contained in the MatroskaMuxContext instead of being
allocated separately.
The earlier code reserved space for a SeekHead with 10 entries, although
we currently write at most 6. Reducing said number implied that every
Matroska/Webm file will be 84 bytes smaller and required to adapt
several FATE tests; furthermore, the reserved amount overestimated the
amount needed for for the SeekHead's length field and how many bytes
need to be reserved to write a EBML Void element, bringing the total
reduction to 89 bytes.
This also fixes a potential segfault: If !mkv->is_live and if the
AVIOContext is initially unseekable when writing the header, the
SeekHead is already written when writing the header and this used to
free the SeekHead-related structures that have been allocated. But if
the AVIOContext happens to be seekable when writing the trailer, it will
be attempted to write the SeekHead again which will lead to segfaults
because the corresponding structures have already been freed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This fixes memleaks if an error happens after one of the allocations
in init; or if the trailer isn't written (e.g. because there was an
error when writing a packet).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
chunk_start_index (which was set via an option) was only used to
initialize chunk_index and otherwise unused. So initialize chunk_index
directly via the option and remove chunk_start_index.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Instead just reuse the filename string that is given via an option
for the child muxer's url field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is no longer needed given that the function pointers of the child
muxer's AVOutputFormat are no longer called directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The webm_chunk muxer caches its output to a dynamic buffer and when it
outputs anything, it explicitly flushes it. So set the flags indicating
that flushing after each packet should not be done automatically
(basically avoiding avio_write_marker() to be called by flush_if_needed()
in libavformat/mux.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
instead of calling the write_header/packet/trailer functions directly
via the function pointers. Also, use distinct AVStreams for the child
AVFormatContext (up until now the two AVFormatContexts shared their
AVStreams because allocating their own was deemed too onerous).
Using the function pointers directly meant that the Matroska muxer's
init-function was never called, because init-functions were only
introduced a few months after webm_chunk has been added and no one
thought of/bothered to adapt webm_chunk for this (when the init-function
was added in b287d7ea, the code setting the timebase was moved to it,
so that the timebases were no longer set to ms-precision when using
the webm_chunk muxer; this has been fixed after some time in 42a635dd
by setting the timebases direcly (instead of calling the init-function)).
And when 982a98a0 added a deinit-function for the Matroska muxer, it
introduced memleaks in webm_chunk, because the child muxer's internal
structures were no longer freed when calling write_trailer directly.
(Given that the init function has never ever been called, the child
muxer has never ever been properly initialized, so that the
deinit-function was not called when freeing the child context.)
This commit stops calling the function pointers directly and instead
uses the standard API functions for muxers. This fixes the above
mentioned memleaks. (Memleaks are still possible on error. This will be
fixed in a future commit that adds a deinit-function to webm_chunk
itself.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In particular the flags are important so that AVFMT_FLAG_BITEXACT can be
honoured by the child muxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The WebM DASH Manifest muxer can write manifests for live streams and
these contain an entry that depends on the time the manifest is written;
an AVOption to make the output reproducible has been added for tests.
But this is unnecessary, as there already is a method for reproducible
output: The AVFMT_FLAG_BITEXACT-flag of the AVFormatContext. Therefore
this commit removes the custom option.
Given that the description of said option contained "private option -
users should never set this" and that it was not documented in
muxers.texi, no deprecation period for this option seemed necessary.
The commands of the FATE-tests for this muxer have been changed to no
longer use this option.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
