2011-06-23, 03:57
As reported a few times on this forum, there's a bug in the DXVA2 MPEG code, that causes partial black picture at the bottom of the screen. Testvideo here: http://www.mediafire.com/?d37o11fcg19wc4g
This is caused by the fact that in the dxva2_mpeg.c code a maximum is set to the amount of slices, being the difference between the highest and the lowest startcode. However, as I found out, some startcodes appear 3 times in a frame, hence there are more slices than different startcodes. The current code rejects slices above the max and that causes those slices not to be decoded.
The reason the code checks for that maximum slices is that an array is being made with the size of max_slices. It's part of the 'dxva2_picture_context':
DXVA_SliceInfo slice[MAX_SLICES];
The most 'beautiful' way to proceed would probably be to make that array dynamic. However that would need a few more changes. I'd suggest just to set that max_slices to a factor 3 of what it currently is right now:
#define MAX_SLICES (SLICE_MAX_START_CODE - SLICE_MIN_START_CODE + 1) * 3
This will only add a few kb of memory. This should work, but of course it's not a really 'beautiful' solution. If somebody wants to change it to dynamic allocation (and then create a ticket for it), that's perfectly fine with me.
This is caused by the fact that in the dxva2_mpeg.c code a maximum is set to the amount of slices, being the difference between the highest and the lowest startcode. However, as I found out, some startcodes appear 3 times in a frame, hence there are more slices than different startcodes. The current code rejects slices above the max and that causes those slices not to be decoded.
The reason the code checks for that maximum slices is that an array is being made with the size of max_slices. It's part of the 'dxva2_picture_context':
DXVA_SliceInfo slice[MAX_SLICES];
The most 'beautiful' way to proceed would probably be to make that array dynamic. However that would need a few more changes. I'd suggest just to set that max_slices to a factor 3 of what it currently is right now:
#define MAX_SLICES (SLICE_MAX_START_CODE - SLICE_MIN_START_CODE + 1) * 3
This will only add a few kb of memory. This should work, but of course it's not a really 'beautiful' solution. If somebody wants to change it to dynamic allocation (and then create a ticket for it), that's perfectly fine with me.
Hence, again, I'm suggesting to just go with the easy way, at least for now, unless somebody of course wants to invest the time to create that 'better' solution (change mpegvideo.c to dynamically allocate the framebuffer, depending on the number of slices in the frame, instead of the current fixed size way)
