The existing code is not in the right place and it should cover both
interlaced frame and field pictures.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This is required due to the way VC-1 handles chroma pull-back which may end
up causing negative chroma MV for zero luma MV. Edge emulation needs to be
invoked in such cases.
This only affects vertical component of chroma motion vector.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Interlaced field pictures can have one or two reference pictures, signaled
by NUMREF syntax element. For single reference pictures, reference picture
is determined by REFFIELD syntax element.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This is a preparatory step for the MSS2 decoder which needs to use
the WMV9 decoder to decode some kinds of frames.
From the patch by Alberto Delmás <adelmas@gmail.com>
The scaling process for obtaining direct MVs from co-located field MVs
is the same for interlaced field and progressive pictures.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
In VC-1 interlaced field pictures, chroma motion vectors can extend beyond
picture boundary even if luma vectors are bounded. The problem shows up
only for hpel interpolated MVs, and may be due to the way motion vectors
are scaled / cropped.
Thanks to Konstantin Shishkov for suggesting the fix. This fixes
long-known segfaults in MC-VC1.ts from videolan streams archive.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
This fixes out of array writes
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
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>
The parser uses VLC tables initialized in vc1_common_init(), therefore
we should call this function on parser init also.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
MVDATA may or may not be transmitted. If it is not, both
dmv_x and dmv_y is to be assumed zero.
This may not trigger wrong picture in all systems, but
it's a bug nevertheless. Fixes SA10116.vc1 on my 64-bit
Windows 7.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
For small video dimensions, these calculations of the upper bound
for pixel access may have a negative result. Using an unsigned
comparison to bound a potentially negative value only works if
the greater operand is non-negative. Fixed by doing edge emulation
when the upper bound is probably negative, everywhere that this
pattern appears.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
This patch is a generalization of what Michael Niedermayer
fixed in a single case.
The wmv8-drm fate test had been updated accordingly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Interlaced videos can contain progressive frames too and now wrong scantable
is selected for them.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The current code is a generalization of the earlier progressive MV
prediction code. This was supposed to predict MVs for both interlaced
and progressive pictures. But the interlaced MV prediction is buggy
and works mostly by luck.
This partially fixes interlaced MV prediction.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code was mistakenly removed in cad16562c8.
It stored some motion vector data for future use in B-pictures.
This fixes Bugzilla bug #57.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
