View Issue Details

IDProjectCategoryView StatusLast Update
0000220JVT JM H.264/AVC reference softwaredecoderpublic2011-11-10 16:32
Reporteralanyan Assigned ToYuwen He  
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product VersionJM 17.1 
Fixed in VersionJM 18.1 
Summary0000220: assert of wrong condition which can result in assertion failed when multi-slice is used
DescriptionIn mbuffer.c, line 4365~4382 and 4391~4409, for top/btm field copy to frame, assertion is applied to check range of ref_idx.
But the assumed boundary range for check of the whole frame is just range copied from slice_list[0] (please refer to mbuffer.c line 4030~4042), which may cause error when multi-slice is used and when other slices have their own different boundary ranges.
TagsNo tags attached.

Relationships

related to 0000283 resolvedYuwen He slice number not properly initialized 

Activities

Alexis Michael Tourapis

2010-07-09 06:59

developer   ~0000375

As mentioned earlier, the code should not be using "ref_idx" to set parameters for co-located partitions but only ref_pic. That was primarily also the reason of the reorganization. That should eliminate these asserts and any other similar problems.

alanyan

2010-07-09 07:44

reporter   ~0000378

About the original assertion of "ref_idx<listXsize",

If you need to do the check in dpb_combine_field(), then you will probably need to save "slice_pos" for each 4x4 block.

But if you decide to:
1. skip doing it, or
2. relocate it to each assignment in mb_prediction()
there is really no need to save "slice_pos" for each 4x4 block.

Alexis Michael Tourapis

2010-07-09 07:50

developer   ~0000380

In general there should be no reason to do this assert at all if it is based only on pointers (i.e. ref_pic). Of course, if ideally moved at the block level, then that would also save in terms of computations since computations for partitions that do not use direct modes would be skipped.

Karsten Suehring

2011-11-10 16:32

administrator   ~0000514

this should also be fixed

Issue History

Date Modified Username Field Change
2010-07-07 14:36 alanyan New Issue
2010-07-09 06:59 Alexis Michael Tourapis Note Added: 0000375
2010-07-09 06:59 Alexis Michael Tourapis Status new => assigned
2010-07-09 06:59 Alexis Michael Tourapis Assigned To => Yuwen He
2010-07-09 07:44 alanyan Note Added: 0000378
2010-07-09 07:50 Alexis Michael Tourapis Note Added: 0000380
2011-11-10 16:31 Karsten Suehring Relationship added related to 0000283
2011-11-10 16:32 Karsten Suehring Note Added: 0000514
2011-11-10 16:32 Karsten Suehring Status assigned => resolved
2011-11-10 16:32 Karsten Suehring Fixed in Version => JM 18.1
2011-11-10 16:32 Karsten Suehring Resolution open => fixed