- Fix field selection for skipped macroblocks
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field
> being predicted.
I did it.
- Fix motion vector rounding for chroma components
In 16x8 motion compensation, for lower 16x8 region,
ing field pictures
>
> On Fri, Feb 09, 2018 at 02:03:24AM +0900, Nekopanda wrote:
>> - Fix field selection for skipped macroblocks
>>
>> For B field pictures, the spec says,
>>
>> > The prediction shall be made from the field of the same parity as the
&
> From: Carl Eugen Hoyos
>
> 2018-02-09 3:07 GMT+01:00 Nekopanda
> :
>>> How did you find this bug ?
>>>
>>> do you have a testcase / file which shows artifacts without this change
> ?
>>
>> Yes, I have files that show artifacts
> From: Carl Eugen Hoyos
>
> 2018-02-09 3:51 GMT+01:00 Nekopanda
> :
>>> From: Carl Eugen Hoyos
>
>>>> Yes, I have files that show artifacts without this change.
> Recently,
>>>> Japanese satellite television started to use fie
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field
> being predicted.
I did it.
---
libavcodec/mpeg12dec.c | 2 +
tests/ref/fate/mpeg2-ticket186 | 328 -
2 files changed, 166 insert
In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion()
for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0,
chroma scaling for y is dividing by two and rounding toward zero. When motion_y
< 0 and motion_y + 16 > 0, the rounding direction of "motion_y"
> On Fri, Feb 09, 2018 at 02:03:24AM +0900, Nekopanda wrote:
>> - Fix field selection for skipped macroblocks
>>
>> For B field pictures, the spec says,
>>
>> > The prediction shall be made from the field of the same parity as the
> field being pre
In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion()
for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0,
chroma scaling for y is dividing by two and rounding toward zero. When motion_y
< 0 and motion_y + 16 > 0, the rounding direction of "motion_y"
