June 2007 - MPlayer-dev-eng - lists.mplayerhq.hu

Problem with Mencoder under Windows XP
by Pavel Zrzavy 02 Jun '07

02 Jun '07

Hi, Ive got specifical problem with mencoder under windows xp sp2. When i use mencoder or mplayer to record or play streamed video from udp address, then i cannot at the same time record or watch other streamed videos from udp. This error will always shown: Failed to connect to server udp_streaming_server failed File not found: '239.194.10.11:1234' <%27 at 239.194.10.11 <http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng>:1234%27> Failed to open udp://'239.194.10.11:1234. <udp://%27@239.194.10.11:1234.> Interesting thing is, that during using mencoder or mplayer,VLC does play or record from this udp source! I think there may be some windows mini port problem with deallocation of UDP address. I hope you will help me, Thx Pavel

1 0

[PATCH] Inlining realloc_struct
by Zuxy Meng 02 Jun '07

02 Jun '07

Hi, I guess functions in header files should be in inline? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6

3 9

Re: [MPlayer-dev-eng] [PATCH] Make mp3lib SIMD optimizations work on AMD64, Part 5
by Zuxy Meng 02 Jun '07

02 Jun '07

Hi, 2007/5/20, Zuxy Meng <zuxy.meng(a)gmail.com>: > As discussed with Guillaume on IRC, I'll split my previous big patch > (Rewrite synth_1to1_MMX....) into several small parts for easier > review. Here's the first one, rewriting the generic code in > synth_1to1_MMX from assembly to C, so we don't need to deal with > different ABIs. I've tested it and confirmed it doesn't hurt > performance. > > Note I removed a conditional jump in the remaining assembly too. By > analyzing the code I'm sure it's never taken so don't worry about > that. Strictly speaking it should be in a seperate patch but then this > patch would break mplayer... > > Part 2 will replace 32-bit leal to equivalent add/sub (without the 'l' > suffix) so pointer arithmetic will be 64-bit under amd64. > > Part 3 will remove hardcoded registers. > > Part 4 will kill tabinit_mmx.c. We don't need to compute the table at > runtime; it can be predetermined. > > Part 5 will correct data types, replacing 'long' with 'int' where necessary. > > The last patch will deal with Makefile and macros. We've reached Part 5. This is again a big diff, replacing many 'long' to 'int', and several 'real' to 'short'. Among those, many are necessary because under LP64 environment, sizeof(long) != sizeof(int) and sizeof(long) != sizeof(float); others are optimizations simply because we really don't need such a long type, or the declaration didn't match its use (declared as float, used as short). -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6

3 16

[PATCH] subreader: recode the whole file to utf-8 before parsing
by Evgeniy Stepanov 01 Jun '07

01 Jun '07

Hi, this patch changes the way subtitle recoding takes place. Instead of recoding each 'struct subtitle', the whole file is read into memory, recoded to utf-8, and a stream is created with new_memory_stream. This patch was created as an attempt to resolve the problem with BOM in the beginning of a unicode subtitle file. The problem is not solved yet, but it is easy now, and will be done in a separate patch. As a side effect, which is arguably more important, it allows to read UTF-16 encoded subtitles. Subtitle related code at the beginning of subreader.c is unused now and can be removed. All in all, it seems like the right thing to do. Opinions ?

2 3

Re: [MPlayer-dev-eng] MJPEG camera support for v4l2 driver
by Juuso Räsänen 01 Jun '07

01 Jun '07

> 2007/5/30, Vladimir Voroshilov : > > Updated patch is attached. > > It was tested with analog capture card (no mjpeg support) with > > yuy2,yv12,i420 and uyvy format and no regressions were found. > > Please test it with mjpeg capable card. > > Any comments are also welcome. > > > > attached patch is synced with r23440. Looks fine. I don't have a tuner card but the patch seems to work at least with Logitech Sphere webcam in both yuy2 and mjpeg formats. Juuso Räsänen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 2

[RFC] disable fastmemcpy on x86-64 by default
by Reimar D?ffinger 01 Jun '07

01 Jun '07

Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks? Greetings, Reimar Döffinger

8 18