[MPlayer-dev-eng] [rfc][patch] mplayer-mt, -lavdopts threads=2 and -vo gl failure on mpeg-1 and theora
Yuriy Kaminskiy
yumkam at mail.ru
Tue Jan 19 15:16:26 CET 2010
On 19.01.2010 11:47, Uoti Urpala wrote:
> On Tue, 2010-01-19 at 07:28 +0300, Yuriy Kaminskiy wrote:
>> Not sure if that belongs here (ffmpeg-mt is not yet complete/stable/supported),
>> but anyway.
>>
>> History: as my X2 4850e insufficient to display h264/1080p movies, I've tried
>> build mplayer with ffmpeg-mt libraries; at first everything worked fine, but
>> then I looked at other mt-aware codecs, and stumbled over nasty problem.
>
> I just answered a similar question on the mplayer-users list yesterday.
> Try -noslices.
As you see, I use -noslices. Did not help.
> I think the slice callback (draw_horiz_band) is the one
> triggering problems with threads enabled.
As announced in doc/multithread*.txt, draw_horiz_band can be called by other
threads in slice-based threading cases; and draw_horiz_band, get_buffer, and
release_buffer can be called by other threads in frame-based cases (and this is
frame-based case).
> You also seem to be using some kind of svn-based FFmpeg-mt build. All
> the ones I've seen have been broken (at least incorrect video vs
> subtitle/audio sync).
That has nothing to do with that problem. Before bothering with that, I've
quickly looked at mplayer.git sources, it /should/ behave same.
And, well, I've just tested (in patch one hunk needed minor correction) - yep,
*exactly* same failure.
> For almost all users the git repo at
> git://repo.or.cz/mplayer-build.git is the best way to use thread
> support. Based on the output your build seems somewhat unusual though
> and could need tweaking to get similar results if you really want those
> (they're not just the result of some weird packaging script or such); at
> least --enable-gui for the internal GUI is no longer supported.
Well, I almost never use gui, so this is not a problem.
I've recompiled slightly less tweaked mplayer.svn ;-), and compiled mplayer.git
(with single gl_multithread-2.patch) - no change.
Result: *all* combination of -noslices & -nodr & -dr did not help.
That is, on that ogv/theora sample.
Similar failure on mpeg-1 sample, except that without -noslices it does not work
at all, even on -vo xv (this looks like [unrelated] ffmpeg-mt bug; with
single-threaded decoding no such problem).
With h264 - no problem whatever, with -dr, without -dr, with -noslices, without
-noslices, on mplayer.svn, on mplayer.git.
With my patch and separate rendering thread enabled (-vo gl:...:thread) - no
problem with theora, no problem with mpeg-1 & -noslices.
./mplayer -noconfig all -msglevel vo=6 -lavdopts threads=2 -demuxer lavf \
-vo gl:yuv=4:rectangle=2:lscale=1:cscale=1:force-pbo -vfm ffmpeg \
-noslices -nodr *.ogv
(same with force-pbo, without force-pbo, with -noslices, without -noslices, with
mplayer SVN-r30206+ffmpeg-mt, with MPlayer git-1f126fc-4.1.2)
=== cut with -dr, without :force-pbo ===
[gl] GLX chose visual with ID 0x2a
[gl] libvo/vo_gl.c:757 (config_internal) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb6529900 != 0xb60e0bb0
[gl] Running on OpenGL by 'NVIDIA Corporation', versions '2.1.2 NVIDIA 177.82'
[gl] Settings after autodetection: ati-hack = 0, force-pbo = 0, rectangle = 2
[gl] Creating 480x270 texture...
[gl] libvo/vo_gl.c:228 (resize) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
[gl] Resize: 480x270
[gl] libvo/vo_gl.c:962 (redraw) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
[gl] libvo/vo_gl.c:936 (flip_page) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
[gl] libvo/vo_gl.c:1023 (get_image) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb6529900 != 0xb60e0bb0
[gl] libvo/vo_gl.c:1023 (get_image) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb6529900 != 0xb50dfbb0
==== cut with -nodr, without :force-pbo ===
[gl] GLX chose visual with ID 0x2a
[gl] libvo/vo_gl.c:757 (config_internal) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb6529900 != 0xb60e0bb0
[gl] Running on OpenGL by 'NVIDIA Corporation', versions '2.1.2 NVIDIA 177.82'
...
[gl] libvo/vo_gl.c:228 (resize) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
[gl] Resize: 480x270
[gl] libvo/vo_gl.c:962 (redraw) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
[gl] libvo/vo_gl.c:936 (flip_page) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb6529900 != 0xb60e0bb0
VD_FFMPEG] DRI failure.
==== with :force-pbo there are additional warning ===
[...]
[gl] libvo/vo_gl.c:919 (flip_page) caller thread mismatch, EXPECT MAJOR FAILURE:
0xb5a64900 != 0xb564bbb0
[gl] could not acquire buffer for dr
Expect a _major_ speed penalty
[VD_FFMPEG] DRI failure.
=== cut ===
That is, -nodr and -dr fails slightly differently, but still fails.
More information about the MPlayer-dev-eng
mailing list