November 2008 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] vertical alignment of standard subtitles (not ASS)
by Rafał Miłecki 16 Nov '08

16 Nov '08

Hello MPlayer team :) I noticed that using -subalign 0-2 doesn't work for me and It's not only about reading console argument as shortcut "a" also doesn't work. I found reason of that which I consider a bug and created fix which I hope is OK. This patch adds lacking brackets (do I use some weird cc configuration as nobody noticed that earlier?) and removes whole calculating code for top alignment. Could you review this, please? -- Rafał Miłecki

2 1

[PATCH] Do not use hostinfo to detect CPU on all x86 variants
by Guillaume Poirier 15 Nov '08

15 Nov '08

Hello, Attached patch fixes configure so that it doesn't use "hostinfo" to detect the running CPU. I think the reason why current code is like it is is probably an overlook, but since I couldn't find the original commit that added MacIntel support, I may have missed smth, so I post the patch here instead of committing it right away. BTW: this patch is needed to add support for Darwin/x86_64 support. Guillaume

3 2

PATCH - PNG transparency in vo_png.c
by it＠tidetamerboatlifts.com 15 Nov '08

15 Nov '08

I needed to export transparency from a Quicktime file for use with Cinelerra. A simple change in vo_png.c fixes this for me. This is patched against 1.0rc2 not CVS. -Joseph P.S. - Thanks for MPlayer ;-)

2 3

nVidia released CUDA accelrated video decoding
by Benjamin Zores 14 Nov '08

14 Nov '08

Hi, In case anybody here is interested in this ... nVidia released its latest Linux drivers on today which provide their PureVideo GPU decoding capabilities. Thus, it is now possible to use GPU to have accelerated h/w decoding for MPEG 1/2, H.264 and VC-1 using proprietary nVidia driver on cards that support CUDA, i.e. GeForce 8 and above. More info on http://www.phoronix.com/scan.php?page=article&item=nvidia_180_vdpau&num=1 And for once, they did a pretty good job as they do provide patches for ffmpeg/mplayer to add support to their new technology. Some dev with CUDA capable GPU might look at ftp://download.nvidia.com/XFree86/vdpau/mplayer-vdpau-3076399.tar.bz2 Ben

3 2

Re: [MPlayer-dev-eng] [PATCH] yadif SSE2/SSSE3 optimization
by Zhou, Zongyi 13 Nov '08

13 Nov '08

> BTW, where is this branch hosted? How can I pull the sources? https://ffdshow-tryout.svn.sourceforge.net/svnroot/ffdshow-tryout/branches/… ZZ

1 0

development project "mplayer encapsulation for Apple TV"
by Apple TV & More 12 Nov '08

12 Nov '08

Hello, first of all I would like to apologize to send out an email to a distribution list, but that was the suggested solution to reach this audience. My name is Thomas Ziehl and we offer custom software for the AppleTV (we have finished the first development a few days ago and are now in testing phase). We would be very interested in working together with skilled developers to bring mplayer functionality to the AppleTV. As you might know,there is already an application, nitoTV, which is not very user friendly and causes more issues than necessary. We would like to take an "Apple-like" approach to create a truely user friendly interface for mplayer on the AppleTV. If you are interested in this project, please contact us. Thomas Ziehl _________________________________________________________________ On-Site and Remote Support for Apple TV and other Apple Products web - http://www.patchstick.ca/

1 0

[PATCH] A/V sync improvement for TV streams
by Laurent 12 Nov '08

12 Nov '08

Greetings, I've been trying to get a correct A/V sync on TV streams using immediatemode=0 (audio going through MPlayer). Basically, my command is (under Windows, using tvi_dshow acquisition tuner): mplayer.exe -tv immediatemode=0 tv://1 Autosync is disabled. As far as I undestand it, autosync only correct pts drift, which does not exist in my case. And from experience, autosync is failing to sync the TV A/V, even with the patch I propose. I encountered a number of issues which the proposed patches intend to fix. Issue 1: * pts_bytes, which gives the number of bytes read since the last pts, is not computed correctly within the libmpdemux/demuxer.c file. It is updated when buffers are filled, while it should be updated when they are read. With the proposed patch, the a_pts calculation, that relies on sh_audio->pts_bytes in mplayer.c gets accurate. Issue 2: * the pts from the TV audio stream is not passed through the PCM decoder (libmpcodecs/ad_pcm.c), and hence is lost and cannot be used in mplayer.c for A/V sync. This is fixed by the second patch. Issue 3: * TV streams are particular because mplayer cannot read frames faster than they are acquired. Eventually, you can get short of audio frames to grab from the demuxer. This is usually not a problem as there are still audio frames buffered in the audio pipe to the speakers (in audio filters and audio output drivers), and new audio frames will be available soon enough from the demuxer. The proposed (3rd) patch just ensure that mplayer continues to make its sync work as long as there is some audio frames to sync with in the audio pipe. I've seen that other people having issues with dvb a/v sync. These patches might help them, as the use case seems similar. Thanks,

6 17

Removal of backing store
by Stephane Marchesin 09 Nov '08

09 Nov '08

Hi, I'm writing about an issue I encountered with mplayer and the use of the backing store. Basically, backing store reduces performance on some recent drivers (notably the open source ones using EXA). There are two major reasons for this: - when using a hardware overlay, backing store uses video memory to store only blue (colorkey) pixels. This will obviously not show up under an mplayer benchmark, but puts more pressure on vram usage - most importantly, backing store prevents from using a real hardware overlay (as opposed to blitter/texture adapters) because this forces window redirection. You then have to fallback to using the blitter port, which is a lot slower than a native hardware overlay. Also FWIW, neither vlc nor xine (with its xine-ui frontend) enable backing store, as seen in the following files/places: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/gui/skins2/x11/x11_wind… http://xine.cvs.sourceforge.net/xine/xine-ui/src/xitk/videowin.c?revision=1… (look for XCreateWindow calls in both) Now, here are some benchmarks obtained when running mplayer -nosound -benchmark -frames 2000 ~/big_buck_bunny_480p_h264.mov. "with backingstore" is using the standard mplayer, "without backingstore" is with the attached patch applied; each benchmark is run 3 times. On GeForce 5200/powerpc/nouveau driver: with backingstore: V: 83.3 2001/2001 46% 18% 0.0% 0 0 BENCHMARKs: VC: 39.005s VO: 15.673s A: 0.000s Sys: 26.715s = 81.393s BENCHMARK%: VC: 47.9220% VO: 19.2562% A: 0.0000% Sys: 32.8218% = 100.0000% V: 83.3 2001/2001 46% 19% 0.0% 0 0 BENCHMARKs: VC: 38.688s VO: 16.048s A: 0.000s Sys: 26.526s = 81.262s BENCHMARK%: VC: 47.6090% VO: 19.7481% A: 0.0000% Sys: 32.6430% = 100.0000% V: 83.3 2001/2001 48% 19% 0.0% 0 0 BENCHMARKs: VC: 40.114s VO: 16.043s A: 0.000s Sys: 27.641s = 83.798s BENCHMARK%: VC: 47.8699% VO: 19.1452% A: 0.0000% Sys: 32.9849% = 100.0000% without backingstore: V: 83.3 2001/2001 47% 16% 0.0% 0 0 BENCHMARKs: VC: 39.242s VO: 13.882s A: 0.000s Sys: 7.504s = 60.628s BENCHMARK%: VC: 64.7259% VO: 22.8974% A: 0.0000% Sys: 12.3767% = 100.0000% V: 83.3 2001/2001 45% 15% 0.0% 0 0 BENCHMARKs: VC: 38.082s VO: 13.193s A: 0.000s Sys: 8.368s = 59.643s BENCHMARK%: VC: 63.8492% VO: 22.1206% A: 0.0000% Sys: 14.0302% = 100.0000% V: 83.3 2001/2001 45% 16% 0.0% 0 0 BENCHMARKs: VC: 37.904s VO: 13.373s A: 0.000s Sys: 8.431s = 59.707s BENCHMARK%: VC: 63.4826% VO: 22.3972% A: 0.0000% Sys: 14.1202% = 100.0000% On GeForce 8400/Athlon X2/nvidia driver: with backingstore: V: 83.3 2001/2001 12% 7% 0.0% 0 0 BENCHMARKs: VC: 10.125s VO: 6.074s A: 0.000s Sys: 16.142s = 32.342s BENCHMARK%: VC: 31.3062% VO: 18.7817% A: 0.0000% Sys: 49.9120% = 100.0000% V: 83.3 2001/2001 12% 9% 0.0% 0 0 BENCHMARKs: VC: 10.347s VO: 7.998s A: 0.000s Sys: 14.590s = 32.935s BENCHMARK%: VC: 31.4152% VO: 24.2852% A: 0.0000% Sys: 44.2996% = 100.0000% V: 83.3 2001/2001 11% 10% 0.0% 0 0 BENCHMARKs: VC: 9.979s VO: 8.629s A: 0.000s Sys: 14.178s = 32.787s BENCHMARK%: VC: 30.4373% VO: 26.3195% A: 0.0000% Sys: 43.2432% = 100.0000% without backingstore: V: 83.3 2001/2001 12% 9% 0.0% 0 0 BENCHMARKs: VC: 10.331s VO: 7.606s A: 0.000s Sys: 14.574s = 32.511s BENCHMARK%: VC: 31.7757% VO: 23.3963% A: 0.0000% Sys: 44.8281% = 100.0000% V: 83.3 2001/2001 11% 8% 0.0% 0 0 BENCHMARKs: VC: 9.982s VO: 7.390s A: 0.000s Sys: 15.062s = 32.434s BENCHMARK%: VC: 30.7779% VO: 22.7840% A: 0.0000% Sys: 46.4381% = 100.0000% V: 83.3 2001/2001 12% 7% 0.0% 0 0 BENCHMARKs: VC: 10.027s VO: 6.134s A: 0.000s Sys: 16.711s = 32.872s BENCHMARK%: VC: 30.5026% VO: 18.6605% A: 0.0000% Sys: 50.8369% = 100.0000% So the bottom line is: backing store will slow down rendering with some driver/hardware combinations, and make no difference in some other combinations. This is why I'm proposing that it's removed. The corresponding patch is attached. Stephane

9 31

Add external program as action handle
by fft 1980 07 Nov '08

07 Nov '08

Hi there, i would like to configure that a mouseclick or keyboard event calls an external program with the actual frame as parameter from within mplayer. for example: ## ## MPlayer input control file ## RIGHT seek +10 LEFT seek -10 ## ... ENTER exec('/usr/bin/program --frame=$frame') How might i solve this issue? Any Ideas? Thanks in advance, fft1980

1 0

MPlayer segfaults in avg_pixels16_sse2 within dsputil_mmx.c, or in filtbank.c - update
by Douglas Pearless 05 Nov '08

05 Nov '08

An update, when it segfaults in filtbank.c, I notice that the memory address for 'overlap' is 0x0 and cannot be read be Eclipse/gdb, whereas the other variables in the block of the "for" loop can all be read. ideas? Cheers Douglas. ----- Forwarded message from Douglas.Pearless(a)pearless.co.nz ----- I have just recompiled the latest mplayer from source: ./configure --enable-debug=3 ./make -j 30 mplayer dvb://"TV ONE" I run it using Eclipse and GDB and it runs for a short while and then segfaults, at the asm volatile block: static void avg_pixels16_sse2(uint8_t *block, const uint8_t *pixels, int line_size, int h) { asm volatile( "1: \n\t" "movdqu (%1), %%xmm0 \n\t" "movdqu (%1,%3), %%xmm1 \n\t" "movdqu (%1,%3,2), %%xmm2 \n\t" "movdqu (%1,%4), %%xmm3 \n\t" "pavgb (%2), %%xmm0 \n\t" "pavgb (%2,%3), %%xmm1 \n\t" "pavgb (%2,%3,2), %%xmm2 \n\t" "pavgb (%2,%4), %%xmm3 \n\t" "movdqa %%xmm0, (%2) \n\t" "movdqa %%xmm1, (%2,%3) \n\t" "movdqa %%xmm2, (%2,%3,2) \n\t" "movdqa %%xmm3, (%2,%4) \n\t" "subl $4, %0 \n\t" "lea (%1,%3,4), %1 \n\t" "lea (%2,%3,4), %2 \n\t" "jnz 1b \n\t" : "+g"(h), "+r" (pixels), "+r" (block) : "r"((x86_reg)line_size), "r"((x86_reg)3L*line_size) : "memory" ); } I am using an intel QX6800 with MythBuntu (up to the latest patches here too) and a NOVA T 500 tuner here in New Zealand. Sometimes I get from the console: A:15621.3 V:15618.1 A-V: 3.238 ct: 1.571 924/924 50% 4% 43.8% 411 0 A:15621.3 V:15618.1 A-V: 3.209 ct: 1.573 925/925 50% 4% 43.8% 412 0 A:15621.3 V:15618.2 A-V: 3.156 ct: 1.575 926/926 50% 4% 43.7% 413 0 A:15621.3 V:15618.1 A-V: 3.186 ct: 1.577 927/927 50% 4% 43.7% 414 0 A:15621.3 V:15618.2 A-V: 3.134 ct: 1.579 928/928 50% 4% 43.6% 415 0 [h264 @ 0x86e6cd0]concealing 3047 DC, 3047 AC, 3047 MV errors A:15621.3 V:15618.4 A-V: 2.962 ct: 1.581 929/929 50% 4% 43.6% 416 0 A:15621.3 V:15618.3 A-V: 3.058 ct: 1.583 930/930 50% 4% 43.5% 417 0 A:15621.4 V:15618.2 A-V: 3.111 ct: 1.585 931/931 50% 4% 43.5% 418 0 A:15621.3 V:15618.2 A-V: 3.120 ct: 1.587 932/932 50% 4% 43.4% 419 0 A:15621.4 V:15618.3 A-V: 3.090 ct: 1.589 933/933 50% 4% 43.4% 420 0 A:15621.4 V:15618.3 A-V: 3.037 ct: 1.591 934/934 50% 4% 43.3% 421 0 A:15621.4 V:15618.3 A-V: 3.067 ct: 1.593 935/935 50% 4% 43.3% 422 0 A:15621.6 V:15618.3 A-V: 3.207 ct: 1.595 936/936 50% 4% 43.6% 423 0 A:15621.5 V:15618.5 A-V: 3.016 ct: 1.597 937/937 50% 4% 43.5% 424 0 A:15621.6 V:15618.4 A-V: 3.113 ct: 1.599 938/938 50% 4% 43.5% 425 0 A:15621.6 V:15618.4 A-V: 3.151 ct: 1.601 939/939 50% 4% 43.4% 426 0 A:15621.6 V:15618.4 A-V: 3.182 ct: 1.603 940/940 50% 4% 43.4% 427 0 A:15621.6 V:15618.4 A-V: 3.150 ct: 1.605 941/941 50% 4% 43.4% 428 0 FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! and mplayer segfaults in filtbank.c: /* add second half output of previous frame to windowed output of current frame */ for (i = 0; i < nlong; i+=4) { time_out[i] = overlap[i] + MUL_F(transf_buf[i],window_long_prev[i]); time_out[i+1] = overlap[i+1] + MUL_F(transf_buf[i+1],window_long_prev[i+1]); time_out[i+2] = overlap[i+2] + MUL_F(transf_buf[i+2],window_long_prev[i+2]); time_out[i+3] = overlap[i+3] + MUL_F(transf_buf[i+3],window_long_prev[i+3]); } in the first line of the "for" loop, with i = 4 Ideas? Cheers Douglas. ----- End forwarded message ----- I have just recompiled the latest mplayer from source: ./configure --enable-debug=3 ./make -j 30 mplayer dvb://"TV ONE" I run it using Eclipse and GDB and it runs for a short while and then segfaults, at the asm volatile block: static void avg_pixels16_sse2(uint8_t *block, const uint8_t *pixels, int line_size, int h) { asm volatile( "1: \n\t" "movdqu (%1), %%xmm0 \n\t" "movdqu (%1,%3), %%xmm1 \n\t" "movdqu (%1,%3,2), %%xmm2 \n\t" "movdqu (%1,%4), %%xmm3 \n\t" "pavgb (%2), %%xmm0 \n\t" "pavgb (%2,%3), %%xmm1 \n\t" "pavgb (%2,%3,2), %%xmm2 \n\t" "pavgb (%2,%4), %%xmm3 \n\t" "movdqa %%xmm0, (%2) \n\t" "movdqa %%xmm1, (%2,%3) \n\t" "movdqa %%xmm2, (%2,%3,2) \n\t" "movdqa %%xmm3, (%2,%4) \n\t" "subl $4, %0 \n\t" "lea (%1,%3,4), %1 \n\t" "lea (%2,%3,4), %2 \n\t" "jnz 1b \n\t" : "+g"(h), "+r" (pixels), "+r" (block) : "r"((x86_reg)line_size), "r"((x86_reg)3L*line_size) : "memory" ); } I am using an intel QX6800 with MythBuntu (up to the latest patches here too) and a NOVA T 500 tuner here in New Zealand. Sometimes I get from the console: A:15621.3 V:15618.1 A-V: 3.238 ct: 1.571 924/924 50% 4% 43.8% 411 0 A:15621.3 V:15618.1 A-V: 3.209 ct: 1.573 925/925 50% 4% 43.8% 412 0 A:15621.3 V:15618.2 A-V: 3.156 ct: 1.575 926/926 50% 4% 43.7% 413 0 A:15621.3 V:15618.1 A-V: 3.186 ct: 1.577 927/927 50% 4% 43.7% 414 0 A:15621.3 V:15618.2 A-V: 3.134 ct: 1.579 928/928 50% 4% 43.6% 415 0 [h264 @ 0x86e6cd0]concealing 3047 DC, 3047 AC, 3047 MV errors A:15621.3 V:15618.4 A-V: 2.962 ct: 1.581 929/929 50% 4% 43.6% 416 0 A:15621.3 V:15618.3 A-V: 3.058 ct: 1.583 930/930 50% 4% 43.5% 417 0 A:15621.4 V:15618.2 A-V: 3.111 ct: 1.585 931/931 50% 4% 43.5% 418 0 A:15621.3 V:15618.2 A-V: 3.120 ct: 1.587 932/932 50% 4% 43.4% 419 0 A:15621.4 V:15618.3 A-V: 3.090 ct: 1.589 933/933 50% 4% 43.4% 420 0 A:15621.4 V:15618.3 A-V: 3.037 ct: 1.591 934/934 50% 4% 43.3% 421 0 A:15621.4 V:15618.3 A-V: 3.067 ct: 1.593 935/935 50% 4% 43.3% 422 0 A:15621.6 V:15618.3 A-V: 3.207 ct: 1.595 936/936 50% 4% 43.6% 423 0 A:15621.5 V:15618.5 A-V: 3.016 ct: 1.597 937/937 50% 4% 43.5% 424 0 A:15621.6 V:15618.4 A-V: 3.113 ct: 1.599 938/938 50% 4% 43.5% 425 0 A:15621.6 V:15618.4 A-V: 3.151 ct: 1.601 939/939 50% 4% 43.4% 426 0 A:15621.6 V:15618.4 A-V: 3.182 ct: 1.603 940/940 50% 4% 43.4% 427 0 A:15621.6 V:15618.4 A-V: 3.150 ct: 1.605 941/941 50% 4% 43.4% 428 0 FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! and mplayer segfaults in filtbank.c: /* add second half output of previous frame to windowed output of current frame */ for (i = 0; i < nlong; i+=4) { time_out[i] = overlap[i] + MUL_F(transf_buf[i],window_long_prev[i]); time_out[i+1] = overlap[i+1] + MUL_F(transf_buf[i+1],window_long_prev[i+1]); time_out[i+2] = overlap[i+2] + MUL_F(transf_buf[i+2],window_long_prev[i+2]); time_out[i+3] = overlap[i+3] + MUL_F(transf_buf[i+3],window_long_prev[i+3]); } in the first line of the "for" loop, with i = 4 Ideas? Cheers Douglas.

2 2