For some obscure reasons avcodec_set_dimensions() resets the width/height
so that the resulting value set in the stream is equal to the
corresponding coded_width/height, which is not the same as the correct
width/height in case of the H.264 and VP6F codecs.
This adds a codec-specific hack for VP6F which disables the call to
avcodec_set_dimensions() in avcodec_open2(), like it is done with H264. A
proper fix needs to be found yet.
Fix trac ticket #1386.
Based on a patch by Michael Niedermayer.
Trolled-By: Daemon404
See thread:
Subject: [FFmpeg-devel] [PATCH] ffprobe: Stash and use width and height before opening the codec
Date: Fri, 1 Mar 2013 10:41:34 -0500
Avoid access to uninitialized values, which may result in a crash.
This happens for example in case of option parsing failure, since in that
case the internal AVBprint buffers are not initialized.
Also extends documentation for timestamp related ffmpeg options, in order
to make more apparent the fact that muxer processing may change the
timestamps values.
List of clobbered registers fixed and added where it is lacking.
Signed-off-by: Nedeljko Babic <nbabic@mips.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Number of planes is not always equal to the number of components even
for formats marked with PIX_FMT_PLANAR -- e.g. NV12 has three components
in two planes.
Problem found using ASAN.
In some case, the ff_mov_get_channel_layout_tag function will not find 0
as termination for lookup in the array mov_ch_layouts_wav.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This race will always happen sooner or later in a multi-threaded
environment and it will over time lead to OOM.
This fix works by spinning, there are other ways by which this
can be fixed, like simply detecting the issue after it happened
and freeing the over-allocated memory or simply using a mutex.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
