February 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][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

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

20 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 19 Oct '04

19 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

[Fwd: Re: [MPlayer-dev-eng] Re: [PATCH] 422p rawvideo in plus rawuyvy out]
by John Earl 13 Oct '04

13 Oct '04

I think this little patch may have got lost because it was included with another one (which was applied last week). Just adds a full set of size calculations to the rawvideo input codec. -------- Original Message -------- Subject: Re: [MPlayer-dev-eng] Re: [PATCH] 422p rawvideo in plus rawuyvy out Date: Fri, 30 Jan 2004 14:45:22 +0000 From: John Earl <jwe21(a)cam.ac.uk> To: mplayer-dev-eng(a)mplayerhq.hu References: <1074643275.4966.226.camel@jwe21> <20040121072438.7d36de51.albeu(a)free.fr> <1074686442.23179.79.camel@jwe21> <20040129115414.5d0decd2.attila(a)kinali.ch> <20040129165057.GY257(a)brightrain.aerifal.cx> On Thu, 2004-01-29 at 16:50, D Richard Felker III wrote: > On Thu, Jan 29, 2004 at 11:54:14AM +0100, Attila Kinali wrote: > > On Wed, 21 Jan 2004 12:00:43 +0000 > > John Earl <jwe21(a)cam.ac.uk> wrote: > > > > > > Then please, add more format. We are not going to do 2000 little commits. > > > > Take the code in mp_image.h dump the size calculation for ALL know > > > > formats and send one patch, once. I'm not willing to review each colorspace > > > > addition to rawvideo one by one. > > > > > > Done (mplayer-rawvideo, attached). [...] mplayer-rawvideo.patch : adds a reasonably full set of size calculations for the rawvideo input codec John

3 2

[Patch] Recognize "video/x-ms-asf; charset=utf-8" mime type
by Alex Eskin 13 Oct '04

13 Oct '04

This is a one liner. The newer MS tools produce "video/x-ms-asf; charset=utf-8" for asx redirectors. Luckily, we may assume that this is always a playlist or redirector, so none of the crud from my previous patch is needed. An example URL is "http://g.msn.com/0VD0/02/26?m=apprentice_bts.wmv&csid=3&sd=mbr" Thanks, Alex __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 3

Re: [PATCH] enable -ss option on wmv streams
by Karl Bielefeldt 13 Oct '04

13 Oct '04

> > > > This patch enables the -ss option to cause a wmv stream to start at > > > > the specified position instead of at the beginning when the stream is > > > > first being opened. I used snort to reverse engineer the solution and > > > > I'm not sure that I solved it the best way, but it does work well for > > > > my online classes. As far as I can tell, there is no way to seek > > > > after the stream has been already opened, so this works differently > > > > than most seeking code I have seen in mplayer. I welcome any > > > > feedback. > > > Someone familiar with that code? > > > > Not that much but it seems ok. I'm wondering why the stream_time > > variable is not a simple local inside the func. Also seek_to_sec is > > a string option, so it must be freed otherwise that leak some mem. > > Thanks for the feedback. I had put the stream_time variable there > during one of my initial debug versions and forgot to put it back for > clean-up. I have fixed that and freed the seek_to_sec variable in the > attached revised patch. I also did a cvs update to get a more recent > baseline. Please let me know if you have more comments. Thanks. My bad. The stream_time variable is static for a reason. The local function can be called multiple times (I am not familiar enough with the code to figure out why), and it is on the last time that the stream-time parameter really matters. The problem is that seek_to_sec needs to be freed in order to prevent later code from trying to seek an unseekable stream, but the stream_time that is stored in seek_to_sec in string form needs to be saved for every time the function is called, just in case it is needed. The attached patch fixes that. Again, I welcome any feedback.

2 3

Patch: vo_shm - simple embedding vo
by Flemming Frandsen 13 Oct '04

13 Oct '04

I have a project where I want to play a movie as a texture in OpenGL in realtime, so naturally I turned to MPlayer, I copy+pasted from vo_tga and created a video out plugin that outputs frames to shared memory. It doesn't use any locking, so it should be low-overhead for both mplayer and the consumer, but that also means that the consumer must have it's own framerate (which my opengl application does have). It works by having the consumer set up a shared memory segment that holds the shmids of two frame buffers, vo_shm writes to the framebuffer with the lowest frame number and the consumer reads from the framebuffer with the higest frame number, that way they don't step on eachothers toes. I've tested it and it works quite nicely, so here is the patch if you'd like to include it: http://dion.swamp.dk/dl/mplayer-1.0pre1-shm1.diff.gz Any comments? -- Regards Flemming Frandsen - http://dion.swamp.dk PartyTicket.Net co founder & Yet Another Perl Hacker

4 11

[PATCH] MJPEG patch of APP0/COM skip
by John Witford 09 Aug '04

09 Aug '04

Not all JPEG segments necessarily escape marker values. Therefore it is wrong to just ignore an unwanted marker and depend on a generic marker search to skip over the unwanted segment contents. This is particularly important for the APP0 segment because it can include a wide variety of data. For example, an APP0 "AVI1" segment might contain the length of the image (EOI-SOS) and therefore might contain an unescaped marker byte. The following patch for MJPEG decoding (libavcodec/mjpeg.c) forces the use of the segment length when skipping for certain marker types. begin-base64 644 mplayer-20031119-jdw.patch LS0tIE1QbGF5ZXItMjAwMzExMTkvbGliYXZjb2RlYy9tanBlZy5jLmpkdwky MDAzLTExLTEzIDA5OjA2OjE1LjAwMDAwMDAwMCArMTEwMAorKysgTVBsYXll ci0yMDAzMTExOS9saWJhdmNvZGVjL21qcGVnLmMJMjAwNC0wMS0yNiAxMjoy NTo0MC4wMDAwMDAwMDAgKzExMDAKQEAgLTE0NzUsNiArMTQ3NSwyMCBAQAog ICAgIHJldHVybiAwOwogfQogCitzdGF0aWMgdm9pZCBtanBlZ19za2lwKE1K cGVnRGVjb2RlQ29udGV4dCAqcykKK3sKKyAgICBpbnQgbGVuOworICAgIGlu dCBpOworCisgICAgLyoKKyAgICAgKiBub3QgYWxsIHNlY3Rpb25zIG5lZWQg dG8gZXNjYXBlIDB4ZmYgd2l0aCAweGZmIDB4MDAgc28gbXVzdCB1c2UgdGhl CisgICAgICogbGVuZ3RoIHRvIHNhZmVseSBza2lwIHRoZSBkYXRhCisgICAg ICovCisgICAgbGVuID0gZ2V0X2JpdHMoJnMtPmdiLCAxNik7CisgICAgZm9y IChpID0gMDsgaSA8IGxlbiAtIDI7IGkrKykKKwlnZXRfYml0cygmcy0+Z2Is IDgpOworfQorCiBzdGF0aWMgaW50IG1qcGVnX2RlY29kZV9hcHAoTUpwZWdE ZWNvZGVDb250ZXh0ICpzKQogewogICAgIGludCBsZW4sIGlkOwpAQCAtMTc2 OSwxOSArMTc4Myw0OSBAQAogICAgICAgICAgICAgICAgICAgICBhdl9sb2co cy0+YXZjdHgsIEFWX0xPR19ERUJVRywgInN0YXJ0Y29kZTogJVhcbiIsIHN0 YXJ0X2NvZGUpOwogICAgICAgICAgICAgICAgIH0KIAotCQkvKiBwcm9jZXNz IG1hcmtlcnMgKi8KLQkJaWYgKHN0YXJ0X2NvZGUgPj0gMHhkMCAmJiBzdGFy dF9jb2RlIDw9IDB4ZDcpIHsKKyAgICAgICAgICAgICAgICBzd2l0Y2goc3Rh cnRfY29kZSkgeworCQljYXNlIFJTVDA6CisJCWNhc2UgUlNUMToKKwkJY2Fz ZSBSU1QyOgorCQljYXNlIFJTVDM6CisJCWNhc2UgUlNUNDoKKwkJY2FzZSBS U1Q1OgorCQljYXNlIFJTVDY6CisJCWNhc2UgUlNUNzoKIAkJICAgIGRwcmlu dGYoInJlc3RhcnQgbWFya2VyOiAlZFxuIiwgc3RhcnRfY29kZSYweDBmKTsK LQkJfSBlbHNlIGlmIChzLT5maXJzdF9waWN0dXJlKSB7CisJCSAgICBicmVh azsKKworCQljYXNlIEFQUDA6CisJCWNhc2UgQVBQMToKKwkJY2FzZSBBUFAy OgorCQljYXNlIEFQUDM6CisJCWNhc2UgQVBQNDoKKwkJY2FzZSBBUFA1Ogor CQljYXNlIEFQUDY6CisJCWNhc2UgQVBQNzoKKwkJY2FzZSBBUFA4OgorCQlj YXNlIEFQUDk6CisJCWNhc2UgQVBQMTA6CisJCWNhc2UgQVBQMTE6CisJCWNh c2UgQVBQMTI6CisJCWNhc2UgQVBQMTM6CisJCWNhc2UgQVBQMTQ6CisJCWNh c2UgQVBQMTU6CiAJCSAgICAvKiBBUFAgZmllbGRzICovCi0JCSAgICBpZiAo c3RhcnRfY29kZSA+PSAweGUwICYmIHN0YXJ0X2NvZGUgPD0gMHhlZikKKwkJ ICAgIGlmIChzLT5maXJzdF9waWN0dXJlKQogCQkJbWpwZWdfZGVjb2RlX2Fw cChzKTsKKwkJICAgIGVsc2UKKwkJCW1qcGVnX3NraXAocyk7CisJCSAgICBi cmVhazsKKworCQljYXNlIENPTToKIAkJICAgIC8qIENvbW1lbnQgKi8KLQkJ ICAgIGVsc2UgaWYgKHN0YXJ0X2NvZGUgPT0gQ09NKQorCQkgICAgaWYgKHMt PmZpcnN0X3BpY3R1cmUpCiAJCQltanBlZ19kZWNvZGVfY29tKHMpOwotCQl9 CisJCSAgICBlbHNlCisJCQltanBlZ19za2lwKHMpOworCQkgICAgYnJlYWs7 CiAKLSAgICAgICAgICAgICAgICBzd2l0Y2goc3RhcnRfY29kZSkgewogICAg ICAgICAgICAgICAgIGNhc2UgU09JOgogCQkgICAgcy0+cmVzdGFydF9pbnRl cnZhbCA9IDA7CiAgICAgICAgICAgICAgICAgICAgIC8qIG5vdGhpbmcgdG8g ZG8gb24gU09JICovCkBAIC0xODU4LDcgKzE5MDIsMTMgQEAKIAkJY2FzZSBT T0YxNDoKIAkJY2FzZSBTT0YxNToKIAkJY2FzZSBKUEc6CisJCWNhc2UgSlBH MDoKKwkJY2FzZSBKUEcxMzoKKwkJY2FzZSBFWFA6CisJCWNhc2UgREFDOgor CQljYXNlIEROTDoKIAkJICAgIGF2X2xvZyhzLT5hdmN0eCwgQVZfTE9HX0VS Uk9SLCAibWpwZWc6IHVuc3VwcG9ydGVkIGNvZGluZyB0eXBlICgleClcbiIs IHN0YXJ0X2NvZGUpOworCQkgICAgbWpwZWdfc2tpcChzKTsKIAkJICAgIGJy ZWFrOwogLy8JCWRlZmF1bHQ6CiAvLwkJICAgIHByaW50ZigibWpwZWc6IHVu c3VwcG9ydGVkIG1hcmtlciAoJXgpXG4iLCBzdGFydF9jb2RlKTsK ====

4 3