Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Well, I found a video that appears to fail in a similar way to one of your failure modes, they could both be the same but showing in different ways. I've found a small mpeg1 vid that causes mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl-length' failed at the start of playing with ffmpeg12vdpau, xvmc plays OK. http://www.andyqos.ukfsn.org/testcard-M.avi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote:
Looks like I made the checking a bit too paranoid, causing it to not always
decode last few macroblocks because of fear of reaching end of stream..
Does this work? I removed a few paranoid asserts, and if performance is still
bad, I'll alter the patch to swap between multiple decode buffers to fix it.
That should bring performance back to old level.
This version does fix the macroblocks issue.
Perf is still poor.
The dvd assert is also still present. It doesn't happen with all dvds -
and is not a regression caused by this patch.
When playing with -cache and skipping around I get a different assert -
attached are backtraces from both types.
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl-length' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6b49a10 (LWP 6986)]
0xe424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb6d0715a in raise () from /lib/libc.so.6
No symbol table info available.
#2 0xb6d08787 in abort () from /lib/libc.so.6
No symbol table info available.
#3 0xb6d0069e in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4 0xb5de9573 in motion_vector (bs=0xab51c50, r=value optimized out,
s=value optimized out, dmv=0, delta=0xbfc0e2d4, dmvector=0xbfc0e2d0) at
vl/vl_vlc.h:172
t = 1
__PRETTY_FUNCTION__ = motion_vector
#5 0xb5deab7f in decode_slice (bs=0xab51c50, code=value optimized out) at
vl/vl_mpeg12_bitstream.c:679
inc = 4
mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 28, y = 1,
macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2,
field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select
= 0 '\0', PMV = {{{0, 0}, {0, 0}}, {{0, 0}, {0, 0}}}, coded_block_pattern = 58,
blocks = 0xbfc0dfa4, num_skipped_macroblocks = 3}
dct_blocks = {0, 0, -44, -44, -44, 44, 0 repeats 58 times, -44, -44,
44, -44, 44, 0, 44, -44, 0 repeats 56 times, 44, 44, 0, 0, 44, 0, 0, 0, 0,
44, -132, 0, 0, 0, 0, 0, 0, 0, -44, 0 repeats 74 times, 9220, -44, 0, 0, 0,
0, -44, 0 repeats 156 times}
dct_scale = 44
x = value optimized out
__PRETTY_FUNCTION__ = decode_slice
#6 0xb5deb72b in vl_mpg12_bs_decode (bs=0xab51c50, n=value optimized out,
len=107065, lens=0xbfc0e390, buffer=0xbfc0e3b0) at vl/vl_mpeg12_bitstream.c:982
__PRETTY_FUNCTION__ = vl_mpg12_bs_decode
#7 0xb5de808b in vl_mpeg12_decode_bitstream (decoder=0xaab5f98,
target=0xaac3c70, picture=0xbfc0e3f8, n=1, total_len=107065, lens=0xbfc0e390,
data=0xbfc0e3b0) at vl/vl_mpeg12_decoder.c:707
i = 3
__PRETTY_FUNCTION__ = vl_mpeg12_decode_bitstream
#8 0xb5d84dd4 in vlVdpDecoderRender (decoder=9, target=19,
picture_info=0x8ae38b4, bitstream_buffer_count=1, bitstream_buffers=0xaac3330)
at decode.c:382
total_size = 107065
ret = VDP_STATUS_OK
dec = (struct pipe_video_decoder *) 0xaab5f98
i = 6986
desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 =
{base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0xaabb7f8,
ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3,
frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0,
intra_vlc_format = 1,
concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5},
{14, 14}}, top_field_first = 1, full_pel_forward_vector = 0,
full_pel_backward_vector = 0, num_slices = 35,
intra_matrix = 0x8ae38cf
\b\b\b\b\b\b\b\t\b\b\b\b\b\b\t\t\b\b\b\b\b\t\t\n\b\b\b\b\b\t\t\n\b\b\b\b\b\t\n\f\b\b\b\b\t\n\f\017\b\b\b\t\n\f\016\021\b\b\t\n\f\016\021\025,
'\b' repeats 64 times, non_intra_matrix = 0x8ae390f '\b' repeats 64
times}, mpeg4 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN},
ref_forward = 0xaabb7f8, ref_backward = 0x0, trd = {2, 3}, trb = {1, 1},
vop_time_increment_resolution = 0, vop_coding_type = 0 '\0', vop_fcode_forward
= 0 '\0', vop_fcode_backward = 1 '\001', resync_marker_disable = 0 '\0',
interlaced = 0 '\0', quant_type = 0 '\0', quarter_sample = 0 '\0',
short_video_header = 0 '\0', rounding_control = 0 '\0',
alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002', intra_matrix
= 0x5 Address 0x5 out of bounds, non_intra_matrix = 0x5 Address 0x5 out of
bounds}, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward
= 0xaabb7f8,
ref_backward = 0x0, slice_count = 2, picture_type = 3 '\003',
frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0 '\0', interlace
= 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0 '\0', dquant = 1
'\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0', quantizer = 0 '\0',
extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap = 0 '\0', vstransform
= 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0', range_mapy_flag = 0 '\0',
range_mapy = 0 '\0', range_mapuv_flag = 0 '\0', range_mapuv = 0 '\0', multires
= 0
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Hey Andy, On 12/19/2011 01:50 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Looks like I made the checking a bit too paranoid, causing it to not always decode last few macroblocks because of fear of reaching end of stream.. Does this work? I removed a few paranoid asserts, and if performance is still bad, I'll alter the patch to swap between multiple decode buffers to fix it. That should bring performance back to old level. This version does fix the macroblocks issue. Perf is still poor. The dvd assert is also still present. It doesn't happen with all dvds - and is not a regression caused by this patch. When playing with -cache and skipping around I get a different assert - attached are backtraces from both types. Yeah that version didn't fix performance yet, this one should have the same performance as before. However those backtraces miss the interesting parts, could you build with -O0 instead of -O2 for a complete backtrace? Perf is back to how it was - just good enough (vdpau is not exactly fast compared to anything else), xvmc is better, but has an issue (not new) where sometimes it looks jittery like the frame order is wrong (only seen on HD with my card on low). I compiled with -O0 but the backtraces are different - maybe there is some randomness. When getting the skip one I managed to get a couple of hangs rather than crashes. One of which I could see was trying some strange resize, eg. instead of VO: [vdpau] 720x576 = 1024x576 MPEG2 VDPAU acceleration I could see something like (from memory) VO: [vdpau] 19x1893 = 2032x2125 MPEG2 VDPAU acceleration and it hung in the process of enlarging the window. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Andy Furniss wrote:
I compiled with -O0 but the backtraces are different - maybe there is
some randomness.
Remembered to attach them this time :-)
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl-length' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6c03a10 (LWP 26420)]
0xe424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb6dc115a in raise () from /lib/libc.so.6
No symbol table info available.
#2 0xb6dc2787 in abort () from /lib/libc.so.6
No symbol table info available.
#3 0xb6dba69e in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4 0xb5eafd61 in vl_vlc_get_vlclbf (vlc=0x9e921c8, tbl=0xb5f3d720,
num_bits=11) at vl/vl_vlc.h:172
__PRETTY_FUNCTION__ = vl_vlc_get_vlclbf
#5 0xb5eaf79d in decode_slice (bs=0x9e9216c, code=2) at
vl/vl_mpeg12_bitstream.c:829
inc = 0
mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 92, y = 1,
macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2,
field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select
= 0 '\0', PMV = {{{0, 17}, {0, 0}}, {{0, 17}, {0, 0}}}, coded_block_pattern =
40,
blocks = 0xbfb0b624, num_skipped_macroblocks = 0}
dct_blocks = {0, 0, 0, 5, 0, 5, -5, 0 repeats 57 times, 5, 0 repeats
319 times}
dct_scale = 5
x = 92
__PRETTY_FUNCTION__ = decode_slice
#6 0xb5eaf1bc in vl_mpg12_bs_decode (bs=0x9e9216c, n=1, len=92477,
lens=0xbfb0ba00, buffer=0xbfb0ba20) at vl/vl_mpeg12_bitstream.c:982
code = 2
__PRETTY_FUNCTION__ = vl_mpg12_bs_decode
#7 0xb5eace48 in vl_mpeg12_decode_bitstream (decoder=0x9e91420,
target=0x9faa850, picture=0xbfb0ba68, n=1, total_len=92477, lens=0xbfb0ba00,
data=0xbfb0ba20) at vl/vl_mpeg12_decoder.c:702
dec = (struct vl_mpeg12_decoder *) 0x9e91420
buf = (struct vl_mpeg12_buffer *) 0x9e92114
i = 3
__PRETTY_FUNCTION__ = vl_mpeg12_decode_bitstream
#8 0xb5e40658 in vlVdpDecoderRender (decoder=9, target=17,
picture_info=0x8ae32f4, bitstream_buffer_count=1, bitstream_buffers=0x9fada58)
at decode.c:382
data = 0xbfb0ba20
sizes = 0xbfb0ba00
total_size = 92477
vldecoder = (vlVdpDecoder *) 0x9e621a8
vlsurf = (vlVdpSurface *) 0x9f53888
ret = VDP_STATUS_OK
dec = (struct pipe_video_decoder *) 0x9e91420
i = 1
desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 =
{base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0,
ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3,
frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0,
intra_vlc_format = 1,
concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5},
{4, 3}}, top_field_first = 1, full_pel_forward_vector = 0,
full_pel_backward_vector = 0, num_slices = 35,
intra_matrix = 0x8ae330f
\b\b\n\v\r\016\017\021\b\b\v\f\016\017\021\023\n\v\r\016\017\021\021\023\v\v\r\016\017\021\023\024\v\r\016\017\020\022\024\030\r\016\017\020\022\024\030\035\r\016\017\021\023\027\034#\016\017\022\023\027\034#*\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021,
non_intra_matrix = 0x8ae334f
\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021},
mpeg4 = {base = {
profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0,
ref_backward = 0x0, trd = {2, 3}, trb = {1, 1}, vop_time_increment_resolution =
0, vop_coding_type = 0 '\0', vop_fcode_forward = 0 '\0', vop_fcode_backward = 1
'\001', resync_marker_disable = 0 '\0', interlaced = 0 '\0', quant_type = 0
'\0',
quarter_sample = 0 '\0', short_video_header = 0 '\0', rounding_control = 0
'\0', alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002',
intra_matrix = 0x5 Address 0x5 out of bounds, non_intra_matrix = 0x5 Address
0x5 out of bounds}, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN},
ref_forward = 0x9ef4fa0, ref_backward = 0x0, slice_count = 2, picture_type
= 3 '\003', frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0
'\0', interlace = 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0
'\0', dquant = 1 '\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0',
quantizer = 0 '\0', extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap =
0 '\0', vstransform = 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0',
range_mapy_flag = 0 '\0', range_mapy = 0 '\0', range_mapuv_flag = 0 '\0',
range_mapuv = 0 '\0', multires = 0 '\0', syncmarker = 0 '\0', rangered = 2
'\002',
maxbframes = 0 '\0', deblockEnable = 0 '\0', pquant = 0 '\0'}}
#9 0x080f9855 in draw_slice (image=0xbfb0bb5c, stride=0xbfb0bb4c, w=720,
h=576, x=0, y=0) at
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Hey Andy, On 12/19/2011 10:17 PM, Andy Furniss wrote: Andy Furniss wrote: I compiled with -O0 but the backtraces are different - maybe there is some randomness. Remembered to attach them this time :-) Thanks, but nothing seems to be obviously wrong there. I don't suppose you could find a small sample file that would trigger the problem? ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Hey Andy, On 12/19/2011 10:17 PM, Andy Furniss wrote: Andy Furniss wrote: I compiled with -O0 but the backtraces are different - maybe there is some randomness. Remembered to attach them this time :-) Thanks, but nothing seems to be obviously wrong there. I don't suppose you could find a small sample file that would trigger the problem? I'll try, but I don't think I'll have much luck. I think this one may need a disk involved - maybe also libdvdcss (I can reproduce with different versions of mplayer and softpipe). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
On 12/19/2011 11:46 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Hey Andy, On 12/19/2011 10:17 PM, Andy Furniss wrote: Andy Furniss wrote: I compiled with -O0 but the backtraces are different - maybe there is some randomness. Remembered to attach them this time :-) Thanks, but nothing seems to be obviously wrong there. I don't suppose you could find a small sample file that would trigger the problem? I'll try, but I don't think I'll have much luck. I think this one may need a disk involved - maybe also libdvdcss (I can reproduce with different versions of mplayer and softpipe). Well, I found a video that appears to fail in a similar way to one of your failure modes, they could both be the same but showing in different ways. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: Hey Andy, On 12/07/2011 05:48 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Hm, could you test with some added sanity checks? mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc-valid_bits num_bits' failed. If that works, maybe remove the vl_vlc_fillbits call I added in vl_mpeg12_bs_decode to see if that is what caused it. Unfortunately the bitstream parser just fails to work correctly here on a lot of my test videos, but that happens even without this patch. Yea, since the rewrite I have seen some crashes - only at the end of some transport streams and only so far with svn mplayer, release mplayer doesn't do it. You might want to check with valgrind to see if it tosses any warning, too. I don't suppose you have a short clip of the failing video that reproduces the problem? Anything should do - I haven't found one that works yet, mpeg1, mpeg2 progressive/interlaced, TS, PS, SD, HD with release mplayer or svn, all crash before rendering anything. Ok looks like I found the issue, could you try the version below? It doesn't crash anymore, but there are regressions. On the plus side - some transport streams that used to crash/hang at the end with -vc ffmpeg12vdpau are now OK. Playing dvd from disc without -cache 8192 is still problematic. This only affects vdpau decode, xvmc was and still is OK. With the patch I get an assert rather than a hang/crash. mplayer: vl/vl_vlc.h:138: vl_vlc_eatbits: Assertion `vlc-valid_bits = num_bits' failed. although -cache mostly works around it. I can still rarely trigger it by doing a lot of skipping forward/back. With the patch and vdpau decode on some streams there is occasional corruption where a few of the bottom right macroblocks render as solid colours. The next issue affects xvmc as well as vdpau - performance is quite severely reduced. Looking at top it seems that less Cpu is used with the patch, but fps is 50-60% worse - meaning with vdpau decode I can't even play some 30fps HD with my card on high, these would normally be OK on low. In addition with vdpau decode I get some 1/4 - 1/2 second stalls when testing HD (this was in benchmark mode so I don't think it's just because I haven't got the perf to reach fps). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Hey Andy, 2011/12/19 Andy Furniss andy...@ukfsn.org: Maarten Lankhorst wrote: Hey Andy, On 12/07/2011 05:48 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Hm, could you test with some added sanity checks? mplayer: vl/vl_vlc.h:139: vl_vlc_eatbits: Assertion `vlc-valid_bits num_bits' failed. If that works, maybe remove the vl_vlc_fillbits call I added in vl_mpeg12_bs_decode to see if that is what caused it. Unfortunately the bitstream parser just fails to work correctly here on a lot of my test videos, but that happens even without this patch. Yea, since the rewrite I have seen some crashes - only at the end of some transport streams and only so far with svn mplayer, release mplayer doesn't do it. You might want to check with valgrind to see if it tosses any warning, too. I don't suppose you have a short clip of the failing video that reproduces the problem? Anything should do - I haven't found one that works yet, mpeg1, mpeg2 progressive/interlaced, TS, PS, SD, HD with release mplayer or svn, all crash before rendering anything. Ok looks like I found the issue, could you try the version below? It doesn't crash anymore, but there are regressions. On the plus side - some transport streams that used to crash/hang at the end with -vc ffmpeg12vdpau are now OK. Playing dvd from disc without -cache 8192 is still problematic. This only affects vdpau decode, xvmc was and still is OK. With the patch I get an assert rather than a hang/crash. mplayer: vl/vl_vlc.h:138: vl_vlc_eatbits: Assertion `vlc-valid_bits = num_bits' failed. Full backtrace please? although -cache mostly works around it. I can still rarely trigger it by doing a lot of skipping forward/back. No idea why this would even affect things. With the patch and vdpau decode on some streams there is occasional corruption where a few of the bottom right macroblocks render as solid colours. Might be related to previous issue. The next issue affects xvmc as well as vdpau - performance is quite severely reduced. Looking at top it seems that less Cpu is used with the patch, but fps is 50-60% worse - meaning with vdpau decode I can't even play some 30fps HD with my card on high, these would normally be OK on low. Hm, I was using only a single decode buffer which removed all batching, might be related. Just wanted to be sure this worked before re-enabling it. In addition with vdpau decode I get some 1/4 - 1/2 second stalls when testing HD (this was in benchmark mode so I don't think it's just because I haven't got the perf to reach fps). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Hey Andy,
On 12/06/2011 10:54 PM, Andy Furniss wrote:
Maarten Lankhorst wrote:
create_buffer, destroy_buffer and set_buffer are a curiosity of
vl_mpeg12_decoder
and shouldn't be part of the api.
set_quant_matrix and set_reference_frames shouldn't be separate calls, but
part of
picparm, which is a requirement for h264 to work.
set_decode_target and set_picture_parameters should instead be passed as
argument to
decode_(bitstream,macroblocks). flush is used to signal in XvMC that current
frame has
ended. begin_frame and end_frame are moved into vl_mpeg12_decoder internally.
I get a crash with R600 and mplayer -vc ffmpeg12vdpau after this patch.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6c946d0 (LWP 31981)]
0xb6733579 in vl_mpeg12_decode_macroblock (decoder=0xad83018, target=0x0,
picture=0x0, macroblocks=0xbfc6edb4, num_macroblocks=1) at
vl/vl_mpeg12_decoder.c:644
644 buf-mv_stream[i][mb_addr] = MotionVectorToPipe
(gdb) bt
#0 0xb6733579 in vl_mpeg12_decode_macroblock (decoder=0xad83018, target=0x0,
picture=0x0, macroblocks=0xbfc6edb4, num_macroblocks=1) at
vl/vl_mpeg12_decoder.c:644
#1 0xb6734e8e in vl_mpg12_bs_decode (bs=0xb7b13c0, n=value optimized out,
len=40001, lens=0xbfc6ee60, buffer=0xbfc6ee80) at vl/vl_mpeg12_bitstream.c:930
#2 0xb673314b in vl_mpeg12_decode_bitstream (decoder=0xad83018,
target=0xb81e470, picture=0xbfc6eec8, n=1, total_len=40001, lens=0xbfc6ee60,
data=0xbfc6ee80) at vl/vl_mpeg12_decoder.c:707
#3 0xb66d2d74 in vlVdpDecoderRender (decoder=5, target=14,
picture_info=0x8900728, bitstream_buffer_count=1,
bitstream_buffers=0xb81da18) at decode.c:382
#4 0x080f053f in draw_slice (image=0xbfc6ef9c, stride=0xbfc6ef8c, w=720,
h=576, x=0, y=0) at libvo/vo_vdpau.c:986
#5 0x08241096 in draw_slice (s=0xb70c870, src=0xad847d0, offset=0xbfc6efec,
y=0, type=3, height=576) at libmpcodecs/vd_ffmpeg.c:519
#6 0x0844edd3 in ff_draw_horiz_band (s=0xb71ff80, y=0, h=576) at
mpegvideo.c:2117
#7 0x0850520c in ff_vdpau_mpeg_picture_complete (s=0xb71ff80, buf=0xb6953008
, buf_size=40001, slice_count=36) at vdpau.c:245
#8 0x084267ee in decode_chunks (avctx=0xb70c870, picture=0xb70c7a0,
data_size=0xbfc6f284, buf=0xb6953008 , buf_size=40001) at mpeg12.c:2301
#9 0x08426d26 in mpeg_decode_frame (avctx=0xb70c870, data=0xb70c7a0,
data_size=0xbfc6f284, avpkt=0xbfc6f230) at mpeg12.c:2272
#10 0x084ee9d5 in avcodec_decode_video2 (avctx=0xb70c870, picture=0xb70c7a0,
got_picture_ptr=0xbfc6f284, avpkt=0xbfc6f230) at utils.c:611
#11 0x08240344 in decode (sh=0xad82eb0, data=0xb6953008, len=40001, flags=0)
at libmpcodecs/vd_ffmpeg.c:826
#12 0x08146fcf in decode_video (sh_video=0xad82eb0, start=0xb6953008 ,
in_size=40001, drop_frame=0, pts=0.2399463558197) at
libmpcodecs/dec_video.c:412
#13 0x080c35fb in update_video (blit_frame=0xbfc72564) at mplayer.c:2398
#14 0x080c788d in main (argc=4, argv=0xbfc72634) at mplayer.c:3823
Hm, could you test with some added sanity checks?
If that works, maybe remove the vl_vlc_fillbits call I added in
vl_mpeg12_bs_decode
to see if that is what caused it. Unfortunately the bitstream parser just fails
to work
correctly here on a lot of my test videos, but that happens even without this
patch.
You might want to check with valgrind to see if it tosses any warning, too.
I don't suppose you have a short clip of the failing video that reproduces the
problem?
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
index ddeaf31..2e95da6 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
@@ -924,7 +924,7 @@ decode_slice(struct vl_mpg12_bs *bs)
mb.coded_block_pattern = 0;
vl_vlc_fillbits(bs-vlc);
- } while (vl_vlc_bits_left(bs-vlc) vl_vlc_peekbits(bs-vlc, 23));
+ } while (vl_vlc_bits_left(bs-vlc) = 23 vl_vlc_peekbits(bs-vlc, 23));
mb.num_skipped_macroblocks = 0;
bs-decoder-decode_macroblock(bs-decoder, NULL, NULL, mb.base, 1);
@@ -966,6 +966,7 @@ vl_mpg12_bs_decode(struct vl_mpg12_bs *bs,
vl_vlc_init(bs-vlc, n, len, buffer, lens);
while (vl_vlc_bits_left(bs-vlc) = 32) {
+ vl_vlc_fillbits(bs-vlc);
if (vl_vlc_peekbits(bs-vlc, 24) == 0x01) {
vl_vlc_eatbits(bs-vlc, 24);
if (vl_vlc_get_uimsbf(bs-vlc, 8) 0xaf)
diff --git a/src/gallium/auxiliary/vl/vl_vlc.h
b/src/gallium/auxiliary/vl/vl_vlc.h
index e710862..ca18823 100644
--- a/src/gallium/auxiliary/vl/vl_vlc.h
+++ b/src/gallium/auxiliary/vl/vl_vlc.h
@@ -38,7 +38,7 @@
struct vl_vlc
{
uint64_t buffer;
- unsigned valid_bits;
+ int valid_bits;
uint32_t *data;
uint32_t *end;
};
@@ -74,10 +74,12 @@ vl_vlc_init_table(struct vl_vlc_entry *dst, unsigned
dst_size, const struct vl_v
static INLINE void
vl_vlc_fillbits(struct vl_vlc *vlc)
{
+ assert(vlc-valid_bits = 0);
+ assert(vlc-valid_bits = 64);
if
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: You might want to check with valgrind to see if it tosses any warning, too. I tried valgrind and it does seem that r600 is leaking - below is from a vanilla mesa with a working test stream and vdpau, xvmc leaks half as much with the same stream. In the patched/crashing case the error info looked the same as gdb. snip lots of others - all the definitely were like these - ==6549== 7,056 (960 direct, 6,096 indirect) bytes in 12 blocks are definitely lost in loss record 314 of 320 ==6549==at 0x40222FD: calloc (vg_replace_malloc.c:566) ==6549==by 0x5E909EA: r600_create_sampler_view (r600_state.c:1078) ==6549==by 0x5F10AE7: vl_video_buffer_sampler_view_planes (vl_video_buffer.c:139) ==6549==by 0x5EE4F8C: vl_mpeg12_create_buffer (vl_mpeg12_decoder.c:168) ==6549==by 0x5E851F3: vlVdpDecoderCreate (decode.c:113) ==6549==by 0x80F867C: create_vdp_decoder (vo_vdpau.c:598) ==6549==by 0x80FA23D: control (vo_vdpau.c:1115) ==6549==by 0x81763E3: query_format (vf_vo.c:145) ==6549==by 0x8147E8B: mpcodecs_config_vo (vd.c:195) ==6549==by 0x8215CA2: init_vo (vd_ffmpeg.c:519) ==6549==by 0x8217699: get_format (vd_ffmpeg.c:953) ==6549==by 0x858CA6C: mpeg_get_pixelformat (mpeg12.c:1221) ==6549== ==6549== 7,056 (960 direct, 6,096 indirect) bytes in 12 blocks are definitely lost in loss record 315 of 320 ==6549==at 0x40222FD: calloc (vg_replace_malloc.c:566) ==6549==by 0x5E909EA: r600_create_sampler_view (r600_state.c:1078) ==6549==by 0x5F10AE7: vl_video_buffer_sampler_view_planes (vl_video_buffer.c:139) ==6549==by 0x5EE4FA2: vl_mpeg12_create_buffer (vl_mpeg12_decoder.c:172) ==6549==by 0x5E851F3: vlVdpDecoderCreate (decode.c:113) ==6549==by 0x80F867C: create_vdp_decoder (vo_vdpau.c:598) ==6549==by 0x80FA23D: control (vo_vdpau.c:1115) ==6549==by 0x81763E3: query_format (vf_vo.c:145) ==6549==by 0x8147E8B: mpcodecs_config_vo (vd.c:195) ==6549==by 0x8215CA2: init_vo (vd_ffmpeg.c:519) ==6549==by 0x8217699: get_format (vd_ffmpeg.c:953) ==6549==by 0x858CA6C: mpeg_get_pixelformat (mpeg12.c:1221) ==6549== ==6549== 7,680 bytes in 192 blocks are definitely lost in loss record 316 of 320 ==6549==at 0x40222FD: calloc (vg_replace_malloc.c:566) ==6549==by 0x5E93437: r600_create_surface (r600_texture.c:510) ==6549==by 0x5EF11A3: vl_idct_init_buffer (vl_idct.c:646) ==6549==by 0x5EE5003: vl_mpeg12_create_buffer (vl_mpeg12_decoder.c:177) ==6549==by 0x5E851F3: vlVdpDecoderCreate (decode.c:113) ==6549==by 0x80F867C: create_vdp_decoder (vo_vdpau.c:598) ==6549==by 0x80FA23D: control (vo_vdpau.c:1115) ==6549==by 0x81763E3: query_format (vf_vo.c:145) ==6549==by 0x8147E8B: mpcodecs_config_vo (vd.c:195) ==6549==by 0x8215CA2: init_vo (vd_ffmpeg.c:519) ==6549==by 0x8217699: get_format (vd_ffmpeg.c:953) ==6549==by 0x858CA6C: mpeg_get_pixelformat (mpeg12.c:1221) ==6549== ==6549== LEAK SUMMARY: ==6549==definitely lost: 16,963 bytes in 373 blocks ==6549==indirectly lost: 23,876 bytes in 94 blocks ==6549== possibly lost: 25,753 bytes in 1,367 blocks ==6549==still reachable: 1,174,744 bytes in 1,678 blocks ==6549== suppressed: 0 bytes in 0 blocks ==6549== Reachable blocks (those to which a pointer was found) are not shown. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
Maarten Lankhorst wrote: create_buffer, destroy_buffer and set_buffer are a curiosity of vl_mpeg12_decoder and shouldn't be part of the api. set_quant_matrix and set_reference_frames shouldn't be separate calls, but part of picparm, which is a requirement for h264 to work. set_decode_target and set_picture_parameters should instead be passed as argument to decode_(bitstream,macroblocks). flush is used to signal in XvMC that current frame has ended. begin_frame and end_frame are moved into vl_mpeg12_decoder internally. I get a crash with R600 and mplayer -vc ffmpeg12vdpau after this patch. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6c946d0 (LWP 31981)] 0xb6733579 in vl_mpeg12_decode_macroblock (decoder=0xad83018, target=0x0, picture=0x0, macroblocks=0xbfc6edb4, num_macroblocks=1) at vl/vl_mpeg12_decoder.c:644 644 buf-mv_stream[i][mb_addr] = MotionVectorToPipe (gdb) bt #0 0xb6733579 in vl_mpeg12_decode_macroblock (decoder=0xad83018, target=0x0, picture=0x0, macroblocks=0xbfc6edb4, num_macroblocks=1) at vl/vl_mpeg12_decoder.c:644 #1 0xb6734e8e in vl_mpg12_bs_decode (bs=0xb7b13c0, n=value optimized out, len=40001, lens=0xbfc6ee60, buffer=0xbfc6ee80) at vl/vl_mpeg12_bitstream.c:930 #2 0xb673314b in vl_mpeg12_decode_bitstream (decoder=0xad83018, target=0xb81e470, picture=0xbfc6eec8, n=1, total_len=40001, lens=0xbfc6ee60, data=0xbfc6ee80) at vl/vl_mpeg12_decoder.c:707 #3 0xb66d2d74 in vlVdpDecoderRender (decoder=5, target=14, picture_info=0x8900728, bitstream_buffer_count=1, bitstream_buffers=0xb81da18) at decode.c:382 #4 0x080f053f in draw_slice (image=0xbfc6ef9c, stride=0xbfc6ef8c, w=720, h=576, x=0, y=0) at libvo/vo_vdpau.c:986 #5 0x08241096 in draw_slice (s=0xb70c870, src=0xad847d0, offset=0xbfc6efec, y=0, type=3, height=576) at libmpcodecs/vd_ffmpeg.c:519 #6 0x0844edd3 in ff_draw_horiz_band (s=0xb71ff80, y=0, h=576) at mpegvideo.c:2117 #7 0x0850520c in ff_vdpau_mpeg_picture_complete (s=0xb71ff80, buf=0xb6953008 , buf_size=40001, slice_count=36) at vdpau.c:245 #8 0x084267ee in decode_chunks (avctx=0xb70c870, picture=0xb70c7a0, data_size=0xbfc6f284, buf=0xb6953008 , buf_size=40001) at mpeg12.c:2301 #9 0x08426d26 in mpeg_decode_frame (avctx=0xb70c870, data=0xb70c7a0, data_size=0xbfc6f284, avpkt=0xbfc6f230) at mpeg12.c:2272 #10 0x084ee9d5 in avcodec_decode_video2 (avctx=0xb70c870, picture=0xb70c7a0, got_picture_ptr=0xbfc6f284, avpkt=0xbfc6f230) at utils.c:611 #11 0x08240344 in decode (sh=0xad82eb0, data=0xb6953008, len=40001, flags=0) at libmpcodecs/vd_ffmpeg.c:826 #12 0x08146fcf in decode_video (sh_video=0xad82eb0, start=0xb6953008 , in_size=40001, drop_frame=0, pts=0.2399463558197) at libmpcodecs/dec_video.c:412 #13 0x080c35fb in update_video (blit_frame=0xbfc72564) at mplayer.c:2398 #14 0x080c788d in main (argc=4, argv=0xbfc72634) at mplayer.c:3823 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder
create_buffer, destroy_buffer and set_buffer are a curiosity of
vl_mpeg12_decoder
and shouldn't be part of the api.
set_quant_matrix and set_reference_frames shouldn't be separate calls, but part
of
picparm, which is a requirement for h264 to work.
set_decode_target and set_picture_parameters should instead be passed as
argument to
decode_(bitstream,macroblocks). flush is used to signal in XvMC that current
frame has
ended. begin_frame and end_frame are moved into vl_mpeg12_decoder internally.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
src/gallium/auxiliary/vl/vl_decoder.c | 13 -
src/gallium/auxiliary/vl/vl_decoder.h |6 -
src/gallium/auxiliary/vl/vl_idct.c | 14 +-
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c | 44 ++--
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.h |4 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 124 -
src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |3 +-
src/gallium/auxiliary/vl/vl_vlc.h | 18 +-
src/gallium/drivers/nouveau/nouveau_video.c| 57 +---
src/gallium/drivers/nvfx/nvfx_screen.c |2 -
src/gallium/drivers/r300/r300_screen.c |2 -
src/gallium/drivers/r600/r600_pipe.c |2 -
src/gallium/drivers/softpipe/sp_screen.c |2 -
src/gallium/include/pipe/p_video_decoder.h | 58 +
src/gallium/include/pipe/p_video_enums.h |3 +-
src/gallium/include/pipe/p_video_state.h | 15 +-
src/gallium/state_trackers/vdpau/decode.c | 295
src/gallium/state_trackers/vdpau/vdpau_private.h |3 -
src/gallium/state_trackers/xorg/xvmc/surface.c | 109 +---
.../state_trackers/xorg/xvmc/xvmc_private.h|1 -
20 files changed, 251 insertions(+), 524 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_decoder.c
b/src/gallium/auxiliary/vl/vl_decoder.c
index 383e02d..da905a6 100644
--- a/src/gallium/auxiliary/vl/vl_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_decoder.c
@@ -44,19 +44,6 @@ vl_profile_supported(struct pipe_screen *screen, enum
pipe_video_profile profile
}
}
-unsigned
-vl_num_buffers_desired(struct pipe_screen *screen, enum pipe_video_profile
profile)
-{
- assert(screen);
- switch (u_reduce_video_profile(profile)) {
- case PIPE_VIDEO_CODEC_MPEG12:
- return 4;
-
- default:
- return 1;
- }
-}
-
struct pipe_video_decoder *
vl_create_decoder(struct pipe_context *pipe,
enum pipe_video_profile profile,
diff --git a/src/gallium/auxiliary/vl/vl_decoder.h
b/src/gallium/auxiliary/vl/vl_decoder.h
index a997516..a7abe9c 100644
--- a/src/gallium/auxiliary/vl/vl_decoder.h
+++ b/src/gallium/auxiliary/vl/vl_decoder.h
@@ -38,12 +38,6 @@ bool
vl_profile_supported(struct pipe_screen *screen, enum pipe_video_profile
profile);
/**
- * the desired number of buffers for optimal operation
- */
-unsigned
-vl_num_buffers_desired(struct pipe_screen *screen, enum pipe_video_profile
profile);
-
-/**
* standard implementation of pipe-create_video_decoder
*/
struct pipe_video_decoder *
diff --git a/src/gallium/auxiliary/vl/vl_idct.c
b/src/gallium/auxiliary/vl/vl_idct.c
index a2b3537..8394542 100644
--- a/src/gallium/auxiliary/vl/vl_idct.c
+++ b/src/gallium/auxiliary/vl/vl_idct.c
@@ -614,9 +614,9 @@ init_source(struct vl_idct *idct, struct vl_idct_buffer
*buffer)
}
static void
-cleanup_source(struct vl_idct *idct, struct vl_idct_buffer *buffer)
+cleanup_source(struct vl_idct_buffer *buffer)
{
- assert(idct buffer);
+ assert(buffer);
pipe_surface_reference(buffer-fb_state_mismatch.cbufs[0], NULL);
@@ -665,13 +665,13 @@ error_surfaces:
}
static void
-cleanup_intermediate(struct vl_idct *idct, struct vl_idct_buffer *buffer)
+cleanup_intermediate(struct vl_idct_buffer *buffer)
{
unsigned i;
- assert(idct buffer);
+ assert(buffer);
- for(i = 0; i idct-nr_of_render_targets; ++i)
+ for(i = 0; i buffer-fb_state.nr_cbufs; ++i)
pipe_surface_reference(buffer-fb_state.cbufs[i], NULL);
pipe_sampler_view_reference(buffer-sampler_views.individual.intermediate,
NULL);
@@ -823,8 +823,8 @@ vl_idct_cleanup_buffer(struct vl_idct_buffer *buffer)
{
assert(buffer);
- cleanup_source(buffer-idct, buffer);
- cleanup_intermediate(buffer-idct, buffer);
+ cleanup_source(buffer);
+ cleanup_intermediate(buffer);
pipe_sampler_view_reference(buffer-sampler_views.individual.matrix, NULL);
pipe_sampler_view_reference(buffer-sampler_views.individual.transpose,
NULL);
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
index 936cf2c..ddeaf31 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
@@ -823,7 +823,7 @@ decode_slice(struct vl_mpg12_bs *bs)
inc += vl_vlc_get_vlclbf(bs-vlc,
