[MPlayer-dev-eng] [rfc][patch] mplayer-mt, -lavdopts threads=2 and -vo gl failure on mpeg-1 and theora

[Yuriy Kaminskiy]

Hello!
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.
=== cut ===
$ mplayer -v -lavdopts threads=2 -demuxer lavf -vfm ffmpeg -dr -noslices \
-correct-pts -vo gl:yuv=4:rectangle=2:lscale=1:cscale=1:force-pbo \
'http://people.xiph.org/~maikmerten/youtube/fred-K170-V2050.ogv'
MPlayer SVN-r30206+ffmpeg-mt-5eb0c64+local-4.1.2 (C) 2000-2009 MPlayer Team
141 audio & 308 video codecs
CPU vendor name: AuthenticAMD  max cpuid level: 1
CPU: AMD Athlon(tm) Dual Core Processor 4850e (Family: 15, Model: 107, Stepping:  2)
extended cpuid-level: 24
extended cache-info: 33587520
Detected cache-line size is 64 bytes
Testing OS support for SSE... yes.
Tests of OS support for SSE passed.
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0
Compiled with runtime CPU detection.
Configuration: --target=pentium3-linux --enable-runtime-cpudetection
--enable-cmov --enable-gui --enable-menu --disable-openal --disable-arts
--disable-esd --disable-nas --disable-dvdread-internal
--disable-libdvdcss-internal --disable-ass-internal --language=en
--extra-cflags=-mtune=k8
Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay
Using nanosleep() timing
[...]
Playing http://people.xiph.org/~maikmerten/youtube/fred-K170-V2050.ogv.
[...]
libavformat file format detected.
[ogg @ 0x8f477a0]max_analyze_duration reached
[...]
[theora @ 0x8f86570]7 bits left in packet 82
[ogg @ 0x8f657a0]max_analyze_duration reached
[lavf] Video stream found, -vid 1
[lavf] Audio stream found, -aid 2
VIDEO:  [theo]  1280x720  0bpp  25.000 fps    0.0 kbps ( 0.0 kbyte/s)
[...]
[gl] using extended formats. Use -vo gl:nomanyfmts if playback fails.
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
[theora @ 0x891f860]Theora bitstream version 30201
[theora @ 0x891f860]7 bits left in packet 82
INFO: libavcodec init OK!
Selected video codec: [fftheora] vfm: ffmpeg (FFmpeg Theora)
[...]
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
[ffmpeg] aspect_ratio: 0.000000
A:   0.0 V:   0.0 A-V:  0.001 ct:  0.000   1/  1 ??% ??% ??,?% 0 0 0%
Dec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
Trying filter chain: menu vo
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO Config (1280x720->1280x720,flags=0,'MPlayer',0x32315659)
Unicode font: 2129 glyphs.
REQ: flags=0x64B7  req=0x0
VO: [gl] 1280x720 => 1280x720 Planar YV12
VO: Description: X11 (OpenGL)
VO: Author: Arpad Gereoffy <arpi at esp-team.scene.hu>
[gl] GLX chose visual with ID 0x2a
[gl] libvo/vo_gl.c:757 (config_internal) caller thread mismatch, EXPECT MAJOR FA
ILURE: 0xb61926e0 != 0xb13f1bb0
[gl] Running on OpenGL by 'NVIDIA Corporation', versions '2.1.2 NVIDIA 177.82'
[gl] Settings after autodetection: ati-hack = 0, force-pbo = 1, rectangle = 2
[gl] Creating 1280x720 texture...
[gl] Deciding colorspace for 1280 x 720
>>>>>>> with my patch (but without :thread suboption), it also report here:
>>> [gl] libvo/vo_gl.c:228 (resize) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb61926e0 != 0xb13f1bb0

[gl] Resize: 1280x720
>>> [gl] libvo/vo_gl.c:962 (redraw) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb61926e0 != 0xb13f1bb0
>>> [gl] libvo/vo_gl.c:936 (flip_page) caller thread mismatch, EXPECT MAJOR
FAILURE: 0xb61926e0 != 0xb13f1bb0
>>>> <<<<<
*** [menu] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
*** [menu] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
*** [vo] Exporting mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
[gl] could not acquire buffer for dr
Expect a _major_ speed penalty
Unicode font: 2129 glyphs.
A:   0.3 V:   0.0 A-V:  0.248 ct:  0.002   2/  2 ??% ??% ??,?% 0 0 0%
  =====  PAUSE  =====
[VD_FFMPEG] DRI failure.
[VD_FFMPEG] DRI failure.
*** [menu] Exporting mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
A:   0.3 V:   0.1 A-V:  0.198 ct:  0.002   4/  4 ??% ??% ??,?% 2 0 0%
[...]
A:   7.4 V:   7.4 A-V: -0.000 ct:  0.000 186/186  4%  2%  0.6% 3 0 0%
=== cut ===

And then nothing is displayed. I've looked at code, and, I think, found where
problem lies: threaded decoder calls get_buffer callback from another thread
(this is actually documented in ffmpeg-mt/doc/multithreading.txt: with mt-aware
decoders, draw_horiz_band, get_buffer and release_buffer callbacks can be called
from different threads), but GL context is per-thread, and all GL function fails.

With -vo xv all [mostly] fine [after I've added XInitThreads() in mplayer.c:main()].

Seems multi-threaded mpeg-1 decoder has same issue too.

Well, good news is, somehow there are no such issue with multithreaded ffh264
decoder, and I'm not really interested in theora and mpeg-1 acceleration :-)

At first I've tried simple, but inefficient approach: I've started separate
rendering thread and passed all requests in that thread.

This is, of cause, not fine, as it causes way more context switches and
synchronization overhead (even thread != pthread_self() check eats few percent
of systime!). Maybe, it would be better to allocate GL context per thread and
somehow replicate their state? But that task would be beyond me. Or somehow make
main thread wait from other thread calls? (at check_events?) That way at least
some vo calls would not need cross-thread passing; but it feels too deadlock-ish
to try without better knowledge of mplayer internals.

Preliminary patch attached.

==== cut with patch ===
$ mplayer ... -vo gl:thread:[...]
[...]
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO Config (1280x720->1280x720,flags=0,'MPlayer',0x32315659)
Unicode font: 2129 glyphs.
REQ: flags=0x64B7  req=0x0
VO: [gl] 1280x720 => 1280x720 Planar YV12
VO: Description: X11 (OpenGL)
VO: Author: Arpad Gereoffy <arpi at esp-team.scene.hu>
[gl] GLX chose visual with ID 0x2a
[gl] Running on OpenGL by 'NVIDIA Corporation', versions '2.1.2 NVIDIA 177.82'
[gl] Settings after autodetection: ati-hack = 0, force-pbo = 1, rectangle = 2
[gl] Creating 1280x720 texture...
[gl] Deciding colorspace for 1280 x 720
[gl] Resize: 1280x720
*** [menu] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
*** [menu] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
*** [vo] Exporting mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
Unicode font: 2129 glyphs.
Unicode font: 2129 glyphs.
A:   0.3 V:   0.0 A-V:  0.266 ct:  0.000   2/  2 ??% ??% ??,?% 0 0 0%
  =====  PAUSE  =====
[VD_FFMPEG] DRI failure.
*** [menu] Exporting mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
A:   0.3 V:   0.1 A-V:  0.241 ct:  0.000   3/  3 ??% ??% ??,?% 1 0 0%
[VD_FFMPEG] DRI failure.
[...]
A:   7.2 V:   7.2 A-V: -0.000 ct:  0.000 181/181  5% 19%  0.6% 4 0 0%
=== cut ===
And then everything work nice (well, with higher -vo gl:thread overhead; there
are question if -vfm libtheora would not be faster even without multithreading :-))
-- 
PS btw, with native (ogg) demuxer fftheora fails, and with lavf demuxer
libtheora fails.

PPS I though I knew how to use synchronization primitives of ptheads. Writing
this rather trivial patch I've discovered I've been completely wrong ;-) Good
thing, it failed early; bad thing, it was race condition, and there was chance I
did not learn that in time ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gl_multithread.patch
Type: text/x-diff
Size: 13171 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100119/152634f3/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-XInitThreads.patch
Type: text/x-diff
Size: 442 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100119/152634f3/attachment-0001.patch>