The issue affects dvdsub subtitles (a.k.a. VOBSUB).
Some players -- in particular hardware players -- cut off
the lowest row of pixels if the number of rows in the subtitle
is odd.
The patch below implements a work-around for that. If the
number of rows is odd, it is simply rounded up to an even
number, adding an invisible (i.e. fully transparent) row.
The work-around can be enabled or disabled with a new
option -even_rows_fix. The default is disabled, so there
is no change of behaviour for users who don't care about it.
The overhead for the fix is low, and in many cases even zero:
For subtitles with an odd number of rows (i.e. in 50% of
cases on average), the size increases by two bytes because
a fully transparent row is encoded as 0x00 0x00. However,
in the VOBSUB standard, all data packets are padded to 2KB
anyway, so in most cases the additional bytes just use some
part of the padding, so there is no overhead. Only in the
rare case that the 2KB boundary is hit (0.1% chance), a full
2KB block is added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Its contents are meaningful only if the stream codec context is the one
actually used for encoding, which is often not the case (and is
discouraged).
Use AVCodecContext.field_order instead.
This fixes timestamps
Based-on: code from pulseaudio
Reviewed-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
AVFormatContext->priv_data is not always a MpegTSContext, it can be
RTSPState when decoding a RTP stream. So it is necessary to pass
MpegTSContext pointer explicitly.
This fixes memory corruption from bug #3721 (RTSPState is smaller than
MpegTSContext thus innocent memory gets overwritten).
Signed-off-by: Alexander V. Lukyanov <lavv17f@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '18fb38fb9ea7e2d5997c096fccfcd4cb43f70294':
mov: Remove a variable that is set but never used
Conflicts:
libavformat/mov.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '52a1c32c0a86e84d43f977c5148e62975a0c6917':
nut: Use nut->version in the version range check
Conflicts:
libavformat/nutdec.c
Note, this bug did not affect ffmpeg
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Disable moved functions to prevent build/test failure,
patch to update and re-enable them is welcome
volunteer to maintain the alpha code is welcome too
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The threshold was choosen so that no further size decrease happened with larger lambda
with the test video.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '79fce1ec8abd017593c003917fc123f7119a78d6':
arm: Avoid using the 'setend' instruction on ARMv7 and newer
Conflicts:
libavcodec/arm/h264dsp_init_arm.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd3cfd7aff86ee3d449ca68aba21d67b9b2136a9b':
af_compand: make sure request_frame always outputs at least one frame
See: 6b68e2a43b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes a segmentation fault because request_frame in fifo.c assumes
that the call to ff_request_frame will populate fifo->root.next.
Before, it was possible for request_frame in af_compand to not do this,
resulting in a null pointer access. Now, request_frame in af_compand
always will return at least one frame or an error, as per the API
specifications in avfilter.h for request_frame.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
