Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>
The total frame size is a combination of the 12 bits in the sequence
header and 2 more bits in the the sequence extension. While the
specification explicitly forbids the dimensions from the sequence header
from being 0 (thus ruling out multiples of 4096), such videos
apparrently exist in the wild so we should attempt to decode them.
Based on a patch by Michael Niedermayer <michaelni@gmx.at>
Fixes Bug 416.
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes some of the issues with segment.mov
See: 0226 15:16 Joseph Artsimov (2.1K) [FFmpeg-devel] Two problems with MPEG2 decoder
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously avctx->hwaccel would have been set to a dummy value,
now an explicit check is necessary instead.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since we can't know which stride a custom get_buffer() implementation is
going to use we have to allocate this scratch buffers after the linesize
is known. It was pretty safe for 8 bit per pixel pixel formats since we
always allocated memory for up to 16 bits per pixel. It broke hoever
with cmdutis.c's alloc_buffer() and high pixel bit depth since it
allocated larger edges than mpegvideo expected.
Fixes fuzzed sample nasa-8s2.ts_s244342.
This avoids having a stray pointer left that may not represent the current picture
and state.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In ISO/IEC 13818-2, bit rate is differently determined according to video type
1) MPEG1 Video
Bit_rate and vbv_delay are set to 3FFFF and FFFF respectively
to indicate variable bitrate. Other values are for constant bitrate.
VBV is only defined for constant bit rate operation.
Ths STD supersedes the VBV model for vbr.
2) MPEG2 Video
Even if the bitrate is constant, the value of bit_rate may not be the actual bitrate
since bit_rate need only be an upper bound to that actual bitrate.
VBV is only defined for variable bit rate operation.
Constant bit rate is viewed as a special case of vbr.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This table doesn't need to be shared with libavformat any longer.
Add mpeg12 to the name to make it less ambiguous, while renaming it.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is intentional (and a reason why fast usually should not be used),
but a few people sent patches to "fix" this recently so it would be
better to document this.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
There have been multiple user complaints about loosing this feature
while its not clear the 3% speedloss claims where real or fabricated.
My own testing indicates no statistically significant speed difference
both with mpeg2 and mpeg4, and if at all the code with lowres support
is a tiny bit faster than without.
This reverts commit 92ef4be4ab, reversing
changes made to 2e07f42957.
Conflicts:
cmdutils.c
libavcodec/arm/vp8dsp_init_arm.c
libavcodec/mpegvideo.c
libavcodec/mpegvideo.h
libavutil/arm/Makefile
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This ended up corrupting data structures and may possibly
lead to a double free.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If user opted to present fields as they come, then the first field
picture needs to be submitted to the HW for decoding. In particular,
this fixes MPEG-2 decoding of interlaced streams.
Tested on Intel Cedar Trail, Sandy Bridge and Ivy Bridge platforms.
Someone reported on the ffmpeg-devel@ list this also works on DXVA
(Windows) and other Linux platforms (NVIDIA, through the VA wrapper).
This also means a similar patch to non-hwaccel VDPAU may be necessary.
Note: I believe the SLICE_FLAG_ALLOW_FIELD is useless since the first
field shall always be submitted to the HW anyway. Nobody uses HW accels
(dxva, vaapi, vdpau, etc.) without that flag though.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
In most places where it's used, it's as a pointless write-only field.
Only rv10 decoder actually reads from it, but it stores some internal
version info in it. There is no reason for it to be in a public field.
Diego Biurrun
Janne Grunau
Martin Storsjö
Michael Niedermayer
Anton Khirnov
Reimar Döffinger
Ronald S. Bultje
Joseph Artsimovich
Heesuk Jung
Hendrik Leppkes
Mans Rullgard
Gwenole Beauchesne
Anne Aaron