CrystalP/xbmc — comment on commit c7b6fffe9d743b8ccc7d2b51ce89955cf1375f08
File:  line 0
By CrystalP:

Can't say I understand hurry_up, when it is set/unset, how it relates to the rest of the decoding process, but depending how that works, it can screw up dxva through decode_nal_units() of h264.c

One problem is with the block if(hx->redundant_pic_count==0 && hx->s.hurry_up < 5 at lines 2855-2871 for multislice streams. Is it guaranteed that when hurry_up changes from 1 to 0, or from >=5 to <5, we're always on the first slice of a frame? In that block dxva code builds internal slice description structures. Not doing that for all slices can't be good.

Another (similar) problem is the if (h->current_slice == 1) block (lines 2845-2850). It needs to be executed once per frame, as that's how the dxva code builds a DXVA_PicParams_H264 structure. If after hurry_up changes 1->0 the h->current_slice variable is not 1, the structure will not be updated to reflect the new frame.

So I'm leaning towards dropping this patch for Eden until we understand better what's happening, especially given the report that it breaks something else.
isidrogar, you need to help figure this out fast to get it in Eden.