January 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] 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: 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

Ugly H.263 display bug
by Shan 07 Aug '04

07 Aug '04

Hi, I just noticed a really ugly bug which affects VLC as well as mplayer when an AVI or MOV containing a H.263 stream with no aspect set is displayed on screen and I'm at a loss over how best to fix it without possibly screwing the RTP demuxer display size up! What happens is both parse the correct display size from the file header, but during the video setup both VLC and mplayer set the display size that is passed from ffmpeg's H.263 codec. Which ends up being a default size of 352x288 so you can imagine that a video that's really 160x120 or 320x240 would end up having black borders added to the right and bottom. Of course ffplay, JMF, quicktime and other players don't have a problem as they take the header value as the only indication of the display size. Shan

4 5

Release schedule
by Alex Beregszaszi 21 Jul '04

21 Jul '04

Hi, Pre4 is scheduled on this weekend Any not yet committed but worth committing patches out there? -- Alex Beregszaszi <alex(a)fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)

16 27

[PATCH] volume control for arts audio output
by Bernd Leibing 21 Jul '04

21 Jul '04

Hi, ao_arts.c doesn't have volume control. I't seems that arts doesn't have an interface for hardware mixers. Hence we have to use oss or alsa mixers. The following patch adds volume control via the oss mixer. The code is copied from ao_oss.c with minor changes. -- Bernd 'Bing' Leibing KIZ Infrastruktur, University of Ulm, Germany Email: <bernd.leibing(a)kiz.uni-ulm.de> Tel. 0731-50-22516 Homepage (PGP-Key): http://www.uni-ulm.de/~leibing O26/5215 --- libao2/ao_arts.c.orig 2003-03-21 17:42:50.000000000 +0100 +++ libao2/ao_arts.c 2004-01-19 19:06:05.000000000 +0100 @@ -10,12 +10,17 @@ #include <artsc.h> #include <stdio.h> -#include "audio_out.h" -#include "audio_out_internal.h" -#include "afmt.h" +#include <sys/ioctl.h> +#include <fcntl.h> + #include "../config.h" #include "../mp_msg.h" +#include "afmt.h" + +#include "audio_out.h" +#include "audio_out_internal.h" + #define OBTAIN_BITRATE(a) (((a != AFMT_U8) && (a != AFMT_S8)) ? 16 : 8) /* Feel free to experiment with the following values: */ @@ -34,9 +39,49 @@ LIBAO_EXTERN(arts) -static int control(int cmd, void *arg) -{ - return(CONTROL_UNKNOWN); +// to set/get/query special features/parameters +static int control(int cmd,void *arg){ + switch(cmd){ + case AOCONTROL_QUERY_FORMAT: + return CONTROL_TRUE; + case AOCONTROL_GET_VOLUME: + case AOCONTROL_SET_VOLUME: + { + ao_control_vol_t *vol = (ao_control_vol_t *)arg; + int fd, v, devs; + + if(ao_data.format == AFMT_AC3) + return CONTROL_TRUE; + + if ((fd = open(PATH_DEV_MIXER, O_RDONLY)) > 0) + { + ioctl(fd, SOUND_MIXER_READ_DEVMASK, &devs); + if (devs & SOUND_MASK_PCM) + { + if (cmd == AOCONTROL_GET_VOLUME) + { + ioctl(fd, SOUND_MIXER_READ_PCM, &v); + vol->right = (v & 0xFF00) >> 8; + vol->left = v & 0x00FF; + } + else + { + v = ((int)vol->right << 8) | (int)vol->left; + ioctl(fd, SOUND_MIXER_WRITE_PCM, &v); + } + } + else + { + close(fd); + return CONTROL_ERROR; + } + close(fd); + return CONTROL_OK; + } + } + return CONTROL_ERROR; + } + return CONTROL_UNKNOWN; } static int init(int rate_hz, int channels, int format, int flags)

5 5

TOOLS : a new shell script to rip DVD and encode DIVX
by Seb 20 Jul '04

20 Jul '04

Hi, This is a new interactive shell script to rip DVD and encode DIVX with the best options and parameters (I think). You can rip, encode audio, encode video, separately into different sessions. Type makedivx.sh --help for options. You can put it in the TOOLS directory. Seb.

8 12

bug on vob subtitles
by Jean-Yves Simon 18 Jul '04

18 Jul '04

Hello, i've been searching the whole evening on this bug, and i think i found some explanation: bug resume: when playing ftp://ftp.mplayerhq.hu/MPlayer/incoming/vobsubtitlesbug/trigun2tmp.vob with -sid 0, the sub at ~ 0:12:13 isn't shown the same happens when playing the vobsub. explanation: from the mpeg demuxer, it seems that every video & subtitle packet are pushed into the same queue (d_video), the problem is that, that particular sub is splitted in 2 chunks, and in between there IS a video chunk! so in the d_video we have: .., vid, vid, sub, vid, sub, vid, ... with the subs that can't be put again together Is this case indeed possible? do you think there's some way around possible? -- Jean-Yves Simon <lethalwp(a)tiscali.be>

2 1

[BUG] gmplayer (CVS snapshot) always rebuilds index file
by Vassilis Virvilis 18 Jul '04

18 Jul '04

Halo, I noticed after my CVS update that the gmplayer always tends to rebuild the index. This leads to bigger startup times and in many cases errors since the index cannot be completed up to the end of the stream (Seek Error I believe). I can give more details upon request if you specify the procedure (compile flags, debug options etc) However mplayer does not have this problem. For now I use the following workaround: In libmpdemux/aviheader.c around line 38 I explicitly set index_mode = -1; I am aware that this cripples the gmplayer ability to build/save/load index files but hopefully some more knowledgeable than me will step in and fix this issue since it looks a frontend problem and I was not able to find from where the read_avi_header() was called. .Bill PS: I am not subscribed to the list so please CC me in any replies. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

2 1