March 2004 - MPlayer-dev-eng - lists.mplayerhq.hu

Synchronization of players in LAN
by J.A. Gutierrez 18 Jun '08

18 Jun '08

Hello I'm trying to synchronise several players running on several computers connected to a dedicated 10/100 Ethernet switch. Each one reads a different movie (video only) from its internal hard disk, and resolution will be 768x576. I'm thinking of a simple solution: - Add some code at mplayer startup so it will wait for an UDP broadcast packet (sent by a central master in the LAN). This way all the players would start at the same time. - Use NTP to keep in sync all the computers' clocks, and trust mplayer's rtc synchronisation feature. With this simple setup, could we be sure all the players would keep the synchronisation? Or should the master computer track them all and take control on their speeds? How difficult would be to add code so all the player synchronise using the LAN? Or should I use some external clock connected to all serial ports? Or use a totally different approach? Thanks. -- finger spd(a)shiva.cps.unizar.es for PGP / .mailcap tip of the day: / La vida es una carcel application/ms-tnef; cat '%s' > /dev/null / con las puertas abiertas text/x-vcard; cat '%s' > /dev/null / (A. Calamaro)

14 40

[PATCH] don't skip first mp3 frame
by Nehal 08 Jan '05

08 Jan '05

for some reason, the current code skips the first frame of mp3 files (using any decoder), i'm assuming this is a bug as i can't see any good reason for this. this probably isn't noticeable with most files, but i have a couple of test cases that have audible sound data in the first frame. if someone wants, email me and i'll send you the starting part of the files for testing purposes. please apply the patch that i've attached Nehal

8 35

Stuck mouse buttons
by Marius Gedminas 23 Nov '04

23 Nov '04

Hi, (resending this to mplayer-dev-eng as requested) Occasionally (but often enough to get annoying) when I click a mouse button on an mplayer window the button gets stuck -- hitting any key afterwards produces messages like No bind found for key MOUSE_BTN1-SPACE although MOUSE_BTN1 is *not* held down. It is easy for me to reproduce the problem by hitting a mouse button for a very brief period of time. It is even easier with tp-scroll[1], which is a gpm-like program that lets me emulate the mouse wheel on a ThinkPad with its 3-button trackpoint. Tp-scroll emits the middle button release event immediately after the press event and always triggers the problem. [1] http://rsim.cs.uiuc.edu/~sachs/tp-scroll/ More than one mouse button can get stuck. I managed all three of them. I've traced the problem to mplayer_put_key in fifo.c. After uncommenting the line that warns about dropped key events (FIFO full) I started seeing these messages every time a button got stuck. While ignoring keypresses on a full FIFO buffer is a sensible thing to do with normal keys, it does not work well with mouse button release events... I should mention that HAVE_NO_POSIX_SELECT is not defined here and thus the first version of mplayer_put_key is used (the one which uses select on a pipe). This is a Debian system (mixed stable/testing/unstable) with glibc 2.3.2 (libc6 2.3.2.ds1-11), and kernel 2.4.24. I do not use the mplayer GUI. What seems strange to me is that the FIFO becomes full with just one key event in it. Apparently trying to use a Unix pipe as a generic FIFO buffer does not work as expected. When I defined HAVE_NO_POSIX_SELECT in config.h and recompiled mplayer the problem went away. I suspect that select on a pipe will not say the fd is ready for writing if the buffer is not completely empty. Normally you can write up to PIPE_BUF bytes without blocking, but if the buffer already contains something, then writing PIPE_BUF bytes would block. IOW using select for a generic FIFO buffer does not work well. I think a better solution would be to use nonblocking writes. Something like the attached patch (tested here, but not tested for portability -- and the #ifdef with HAVE_NO_POSIX_SELECT should be changed to something different as well). Or maybe it would be simplest to always use the in-memory array solution (mplayer_put_key + mplayer_get_key). I expect it to be marginally faster as well (no syscalls, no context switches). Marius Gedminas -- QOTD: "A child of 5 could understand this! Fetch me a child of 5."

20 39

[PATCH][RFC] Font layer fixes/improvements
by Krzysztof Rusocki 09 Nov '04

09 Nov '04

Hi, While using MPlayer 1.0pre3 we've encountered few issues related to font handling, attached patch (against CVS as of 2004-02-13) (implicitly or explicitly) tries to deal with them. Before you go on and your blood pressure reaches extraordinarily high values... keep in mind that: - although I've tried not to break mplayer's design it is quite possible that I missed something (these are my first steps with mplayer sources), - this patch does not tend to be a complete solution (docs modification is not done, console messages are probably excessive), I'd rather would like to hear from you whether the steps I've taken are the good way to fix things, THE DETAILS If mplayer is compiled with HAVE_FREETYPE and HAVE_FONTCONFIG following things happen: 1. When launched: $ (g)mplayer -font nonexistant mplayer segfaults when it's about to show osd see libvo/sub.c:~610 - vo_font->font[40] is -1 thus we end with negative array offset (the patch does not fix this since I didn't figure out how to cope with this cleanly) 2. In Gui font is reloaded on every widget activity (size bars and scale radio buttons), it seems to be quite significant and needless (?) overhead. 3. With -fontconfig, it is impossible to load font via file dialog in Gui (or by -font parameter), this seems pretty confusing - one would expect a .ttf/.pfb to be loaded from file dialog. 4. Despite being configured with Freetype, mplayer tries (needlessly) to load .desc font on startup and if such font gets loaded - then: 4.1. If -font is specified - loaded .desc font is overridden by freetype font_load_ft codepath anyway 4.2. If -font is NOT specified - default freetype font (subfont.ttf) isn't touched at all, while (I believe) it should be tried. 5. When launched: $ mplayer -zoom -fs (with autoscale enabled) font is scaled to original (unzoomed) movie dimensions. The patch is fairly large, but, I think that changes will ease future development... Here's what has been done (in general), I've created a fairly unified interface for font loading (libvo/font_if.{c,h}), so there's no need to put so many #ifdefs around or wonder ,,what if we have freetype enabled? or not?'' int init_font(); int uninit_font(); void render_one_glyph(font_desc_t *desc, int c); int kerning(font_desc_t *desc, int prevc, int c); These work similarily to the previous ones, i.e. they do things when freetype is enabled, otherwise they are no-ops. void free_font_desc(font_desc_t *desc); free_font_desc() has been moved from load_font_ft.c, since it's rather common function for fonts. #define load_font(n, w, h) _load_font(n, w, h, __FILE__, __LINE__) void _load_font(char * name, int width, int height, char * fn, int ln); That's the most tricky thing, load_font tries to load font with specified name, the font is loaded in either of three cases: - no font has been loaded at all - screen dimensions's changed - force_load_font variable was set to non-zero value The way font is loaded depends on HAVE_FREETYPE. If defined - the order of things is as follows (font_if.c/try_load_font_ft()): - load font "name" via freetype, if it fails, - load font "name" via freetype+fontconfig (if supported), if it fails, - load default font (subfont.ttf) via freetype, if it fails, - load default fontconfig font ("sans-serif") (if supported), If font still isn't loaded, there is a codepath that loads only OSD face, however that causes a segfault mentioned earlier (1), hence it is disabled. Now, let's move to the case when there's no freetype (try_load_font_desc()). That is a simple - load font "name" - load default font fallback. Mentioned changes allow easier font (re)loading and unloading, see changes in Gui/interface.c, mplayer.c, mencoder.c. I have removed -fontconfig/-nofontconfig options since they seem superfluous in face of font load code proposed in the patch, I didn't find any reason why they should be kept. If you need more info, feel free to mail, also, any feedback is welcome (including napalm). Cheers, Krzysztof

7 15

single step patch
by Marc Hoffman 20 Oct '04

20 Oct '04

single step just piggy backs on top of pause. Single step is entered via pause command which by default is bound to TAB. toggling TAB toggles in and out of single step mode.

3 2

[PATCH] ffw-av - interactive fastforward/slow with audio speed adjust (1st draft)
by Steven Mueller 19 Oct '04

19 Oct '04

Hello, Here is a first attempt at a live interactive fast/slow-forward patch that also modifies the speed of sound playback to (approximately) match the video playback rate. It applies cleanly against current cvs as of the time of writing. It's still rather quirky, owing to my not quite understanding the A-V sync structure and the various audio output layers, and possibly due to limitations in the demuxers as postulated below. I've implemented sound output reinitialization to scale the sample rate, but I'm not sure if what I did was kosher, so I'd appreciate a few eyes on it. The patch adds three new mappable commands for input.conf: speed_set float set the playback rate. 1.0 is normal speed speed_mult float multiply the current speed (positive only) speed_incr float increment the current speed (can be negative) Default keyboard mappings: [, ] Decrease/increase the speed by a small factor (= 1.1) {, } Decrease/increase the speed by a large factor (= 2) Backspace Reset the speed to normal The playback_speed is implemented using the infrastructure for the -speed commandline argument, so the allowable range is .01 to 100. Caveats: 1. Not all sound drivers can accelerate the sound speed past a certain sample rate. Some also hold back the video speed. (For example, alsa9 on my system on certain divx files limits the playback rate to 1.0. However, the OSS emulation of my alsa driver does not suffer the same problem... The divx5.0 files from www.redvsblue.com exhibit this behavior, for example.) One can sort of work around this by specifying "-aop list=resample" on the commandline. This causes the speed modifications to apply to the resample audio plugin, and therefore uses more cpu but can have a wider range of possibilities. It also will not limit the video playback rate as far as I've seen. However (this is a big however!) increasing or decreasing the speed too much can cause the A-V sync to go very out of control. Using "-mc 10" can slightly alleviate this problem, but only to a certain extent (about 5x on my 1.3 ghz tbird). Every time I change the speed, alsa9 reports the same samplerate (48000) until I increase the speed too high (~10x), at which point the debug message suddenly shows the resampling being applied to the alsa chain directly and the sound reverts to 1x speed. Of course, this problem also happens with the -speed commandline option. 2. Changing the speed rate can cause minor jumps in the video file. On some files (notably quicktime and wmv), the movie is sped up for a short moment so that you miss a half second or so, regardless of whether you're slowing way down or speeding way up. Note that this phenomenon occurs when pausing and resuming in normal speed playback as well, so I'm thinking this could be limitations with the individual codecs' demuxers rather than with the way I reinitialize the sound. 3. Using a very low speed can make mplayer very unresponsive, since mplayer can only accept one command per rendered frame... 4. The speed display at the end of the status display line only appears when both audio and video are being played, but I'm not sure this field is good anyway since it easily puts the line length at more than 80 characters. Regardless, I can easily add it to the audio/video-only lines if anyone is interested. Another option would be to make it display the speed only when it is not 1x (which I kinda like best, actually...) TODO: * Add an OSD to display the new speed for a short while whenever it's changed (and the osd level is high enough) * Display speed on status line iff playback_speed != 1.0 +/- delta * Add an option to partially mute the sound volume a given amount whenever the speed is not exactly 1.0x (or maybe there should be some (configurable?) tolerance?) * Write proper documentation (changes to manpage and DOC files) * Examine the play loop more closely to determine whether the skips of accelerated playback in certain videos (as described above) can be avoided, and perhaps get the audio to more instantaneously sync, too... Anyway, I hope people find it useful, and I hope to get it to a point where it can be included in mplayer. After writing the bulk of the patch, I discovered the following thread in the archives, so I'm hoping there's still a bit of interest: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2003-February/015835.html Thanks, Steve PS - Sorry for the excessively long description. :) -- Steven Mueller diffusor(a)ugcs.caltech.edu

16 28

[PATCH] FRIBIDI fix (subreader.c)
by Eliran Gonen 18 Oct '04

18 Oct '04

Hey! I'm quite new in here... Anyway there is a problem reading bidirectional text lines that contains dots or commas. To fix this replace: base = FRIBIDI_TYPE_ON; with base = FRIBIDI_TYPE_L; Regards, Eliran Gonen

6 13

[Patch] Audio detection
by Michael Behrisch 18 Oct '04

18 Oct '04

Hello, this patch cleans up the detection loop in demux_audio and enhances mp3 detection. Michael

6 22

Patch: Filter to change luminance on a box
by Erik Waling 17 Oct '04

17 Oct '04

Patch to add a filter which will allow you to change the luminance on a box. The original code is from the rectangle filter by Kim Minh Kaplan. Usage: -vf lumbox=width:height:x:y:luminance Erik Waling

6 6

[PATCH] check backup IFO files in libmpdvdkit2
by Keith Lyon 17 Oct '04

17 Oct '04

I have some dvds where the IFO files don't read correctly. This patch just makes the dvdread code check the backup BUP files if it finds any problems. It made those titles playable, I'm surprised someone didn't do this along time ago. -- Keith Lyon <kglyon(a)uwyo.edu>

4 7