Synchronization of players in LAN
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@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)
On Thu, 2003-11-20 at 09:14, J.A. Gutierrez wrote:
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.
Hi, MPlayer's video output is (I think, might be wrong) synchronised to the audio output. You can some "damping" by giving a non-zero value for -autosync, which is what the RTC is used for. So, to do what you're trying to do, you could buy lots of sound cards with an S/PDIF sync input. I suspect you don't want to do this. If you want audio on all the machines, you could write some code to make a master server transmit UDP packets with the current playback time. The slaves could then use af_resample to dynamically change the sample rate to keep in sync. If you don't need sound, you could write a dummy audio driver that just "dumps" audio when requested by the master. .. or there's Video Lan. Cheers, Dave
On Thu, Nov 20, 2003 at 11:35:12AM +0000, Dave Lambley wrote:
On Thu, 2003-11-20 at 09:14, J.A. Gutierrez wrote:
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.
So, to do what you're trying to do, you could buy lots of sound cards with an S/PDIF sync input. I suspect you don't want to do this.
yes, right
If you want audio on all the machines, you could write some code to make a master server transmit UDP packets with the current playback time. The slaves could then use af_resample to dynamically change the sample rate to keep in sync.
If you don't need sound, you could write a dummy audio driver that just "dumps" audio when requested by the master.
in fact, by now, this is the scenario: I don't need audio at all, so it seems it could be a good option. I recall having seen some audio broadcasting udp software (radio.c IIRC); maybe the master could broadcast a low quality null audio stream and then the slaves could have a daemon which receives the stream and passes it to mplayer for synchronisation...
.. or there's Video Lan.
I have been reading their page, but it seems is more oriented to broadcasting of streams; and for 6 video streams I don't think we have bandwidth enough. Thansk! -- finger spd@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)
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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.
Interesting idea, what do you want to achive ?
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.
Possible
- Use NTP to keep in sync all the computers' clocks, and trust mplayer's rtc synchronisation feature.
Mplayer does not sync against an external clock but syncs video to audio. RTC is only used for sleeping, nothing more. See mplayer.c:2205
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?
Wont work.
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?
You'd have to change mplayers sync code to sync against the system clock (or anyother external source) instead of audio. Then you could work with ntp. Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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.
Interesting idea, what do you want to achive ?
Wild guess - video wall? Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 542916, 3073512 torinthiel(at)wp(dot)pl gpg: B06901F1 fpr: FAA3 559F CAE9 34DE CDC8 7346 2B6E 39F2 B069 01F1 "No classmates may be used during this examination"
On Thu, Nov 20, 2003 at 01:56:01PM +0100, Torinthiel wrote:
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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
Interesting idea, what do you want to achive ?
Wild guess - video wall?
good try. A stereo CAVE system. http://giga.cps.unizar.es/fotos/big/cave.html -- finger spd@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)
* J.A. Gutierrez <spd@shiva.cps.unizar.es> [2003-11-20 19:44]:
On Thu, Nov 20, 2003 at 01:56:01PM +0100, Torinthiel wrote:
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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
Interesting idea, what do you want to achive ?
Wild guess - video wall?
good try.
A stereo CAVE system.
I don't know exactly if this may help you but NetJuggler seems to have some synchronization facilities for VR: http://netjuggler.sourceforge.net/ -- Best regards, Pierre Lombard
On Tue, Nov 25, 2003 at 07:25:08PM +0100, Pierre Lombard wrote:
I don't know exactly if this may help you but NetJuggler seems to have some synchronization facilities for VR: http://netjuggler.sourceforge.net/
I didn't know this software, seems really interesting; and maybe is possible to make mplayer use VR Juggler, but seems more oriented to real time 3D graphics... Thank you! -- finger spd@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)
On Thu, Nov 20, 2003 at 01:56:01PM +0100, Torinthiel wrote:
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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.
Interesting idea, what do you want to achive ?
Wild guess - video wall?
For this you should use a single mplayer with -vo ggi.. :) Rich
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
- Use NTP to keep in sync all the computers' clocks, and trust mplayer's rtc synchronisation feature.
Mplayer does not sync against an external clock but syncs video to audio. RTC is only used for sleeping, nothing more. See mplayer.c:2205
ok
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?
You'd have to change mplayers sync code to sync against the system clock (or anyother external source) instead of audio.
I will read the source; I hope it won't be too difficult to implement that. Thanks -- finger spd@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)
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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.
Mplayer does not sync against an external clock but syncs video to audio. RTC is only used for sleeping, nothing more. See mplayer.c:2205
OK, I've reading the source, and it seems it does synchronize to system clock (providing the movie has no audio; which is perfect for my setup). In mplayer.c, it starts getting current time: total_time_usage_start=GetTimer(); which in osdep/timer-lx.c calls gettimeofday(), which returns current time, which is fixed by NTP. Right after the "PLAY VIDEO" comment, it starts decoding video. It reads and decodes the frame; and then "It's time to sleep..." where calculates remaining time with time_frame-=GetRelativeTime(); and if there is no sound, it will sleep for frame_time. So, this is what I've done so far: - Setup NTP for system clock synchronisation. - Add some network code to make an udp server. (two files, network.c/network.h) - Add some lines to mplayer.c so it: * On start will wait for an UDP broadcast packet. * Once the packet has arrived, will wait for the next second boundary (i.e. 0 == GetTimerMS() % 1000) - A minimal program which sends the broadcast packet. If there is someone interested I could make the files available. By now it seems good enough for me, but my in code in mplayer.c is really quick and dirty: * doesn't use options, it always wait for udp, and then for %1000 ms. Should use command line options. * uses RTC only. * about ten lines of new code. -- finger spd@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)
Hi, I'm very interested in your modifications. Can you send me the modified files?. I'm working in a similar project, I tested the mplayerd, but is too slow in response, and the sinchronization between several machines is poor. I'm trying to modify the mplayer code, but I don't have successfully results (not yet...). Thank's. Tono Esteve. PD: Sorry for my bad english... J.A. Gutierrez escribió:
On Thu, Nov 20, 2003 at 01:20:47PM +0100, Attila Kinali wrote:
On Thu, 20 Nov 2003 10:14:24 +0100 "J.A. Gutierrez" <spd@shiva.cps.unizar.es> wrote:
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.
Mplayer does not sync against an external clock but syncs video to audio. RTC is only used for sleeping, nothing more. See mplayer.c:2205
OK, I've reading the source, and it seems it does synchronize to system clock (providing the movie has no audio; which is perfect for my setup).
In mplayer.c, it starts getting current time:
total_time_usage_start=GetTimer();
which in osdep/timer-lx.c calls gettimeofday(), which returns current time, which is fixed by NTP.
Right after the "PLAY VIDEO" comment, it starts decoding video. It reads and decodes the frame; and then "It's time to sleep..." where calculates remaining time with time_frame-=GetRelativeTime(); and if there is no sound, it will sleep for frame_time.
So, this is what I've done so far:
- Setup NTP for system clock synchronisation.
- Add some network code to make an udp server. (two files, network.c/network.h)
- Add some lines to mplayer.c so it:
* On start will wait for an UDP broadcast packet. * Once the packet has arrived, will wait for the next second boundary (i.e. 0 == GetTimerMS() % 1000)
- A minimal program which sends the broadcast packet.
If there is someone interested I could make the files available. By now it seems good enough for me, but my in code in mplayer.c is really quick and dirty:
* doesn't use options, it always wait for udp, and then for %1000 ms. Should use command line options.
* uses RTC only.
* about ten lines of new code.
On Wed, Nov 26, 2003 at 11:36:13AM +0100, Tono Esteve wrote:
Hi, I'm very interested in your modifications. Can you send me the modified files?. I'm working in a similar project, I tested the mplayerd, but is too slow in response, and the sinchronization between several machines is poor.
I've found a problem; now I understand mplayer doesn't really synchronise to system clock. When a player takes more than 1/25 sec to render the frame, it won't resync after that, so eventually synchronisation is lost. I will have to add more code, it seems. By now, you can find my modifications at http://giga.cps.unizar.es/~spd/src/mplayer/ and http://giga.cps.unizar.es/~spd/src/net/tcp-client.c -- finger spd@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)
The first link to your code is not working. J.A. Gutierrez escribió:
On Wed, Nov 26, 2003 at 11:36:13AM +0100, Tono Esteve wrote:
Hi, I'm very interested in your modifications. Can you send me the modified files?. I'm working in a similar project, I tested the mplayerd, but is too slow in response, and the sinchronization between several machines is poor.
I've found a problem; now I understand mplayer doesn't really synchronise to system clock. When a player takes more than 1/25 sec to render the frame, it won't resync after that, so eventually synchronisation is lost. I will have to add more code, it seems.
By now, you can find my modifications at
http://giga.cps.unizar.es/~spd/src/mplayer/ and http://giga.cps.unizar.es/~spd/src/net/tcp-client.c
On Thu, Nov 27, 2003 at 09:44:52AM +0100, Tono Esteve wrote:
The first link to your code is not working.
sorry, this is the correct url:
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/
-- finger spd@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)
Hi,
On Wed, Nov 26, 2003 at 11:36:13AM +0100, Tono Esteve wrote:
Hi, I'm very interested in your modifications. Can you send me the modified files?. I'm working in a similar project, I tested the mplayerd, but is too slow in response, and the sinchronization between several machines is poor.
I've found a problem; now I understand mplayer doesn't really synchronise to system clock. When a player takes more than
of course. it never used system clocks for syncro, when audio is available, video is synced to soundcard's timer only. system clock is used only for nosound case. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
On Thu, Nov 27, 2003 at 10:13:24AM +0100, Arpi wrote:
of course. it never used system clocks for syncro, when audio is available, video is synced to soundcard's timer only. system clock is used only for nosound case.
I don't need to use sound by now... I have some questions: * Why "total_frame_cnt" is incremented only when there is audio to play? * I'm trying to enable frame dropping just before "decode_video" module, so I calculate the difference current_time_usage - expected_time_usage; where current_time_usage=GetTimer(); expected_time_usage = total_time_start + total_frame_cnt * ( 1000000 / sh_video->fps ); total_time_start is the result of GetTimer() at the start of "PAY AUDIO" code. (I have moved the "++total_frame_cnt" outside the "audio" block; and, yes, this is not right when users pauses mplayer, but I don't need pauses) If the difference is greater than a frame; I set drop_frame=frame_dropping; frame_time_remaining=0; ++drop_frame_cnt; ++dropped_frames; and whith this code, when some of the players is late, it just stop at that frame forever; so I'm missing something. (I do use -framedrop and -nosound switches in mplayer invocation) -- finger spd@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)
Hi an update to my quick and dirty patch to mplayer so it will use system clock for synchronising "noaudio" movies: http://giga.cps.unizar.es/~spd/src/graphics/mplayer/ I'm testing it right now, and seems to behave a lot better. Anyway I'd like to get any feedback before start cleaning the code. The patch [1] is really small, so it won't be difficult for someone who knows mplayer code to tell if I'm missing something really obvious... Thanks! [1] http://giga.cps.unizar.es/~spd/src/graphics/mplayer/mplayer.c.patch -- finger spd@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)
Hello Some time ago I sent some mails about LAN synchronisation for mplayer. Now the code is working; you can find it at http://giga.cps.unizar.es/~spd/src/graphics/mplayer/ http://giga.cps.unizar.es/~spd/src/graphics/mplayer/cmplayer.txt but I've found what seems to be a bug in Cinepack decoder: in short, mplayer crashes when there is a drop while playing cinepack compressed movies. I sent a report to MPlayer-users, but there was no answers. You can read the details at http://giga.cps.unizar.es/~spd/src/graphics/mplayer/mplayer_bug.txt -- finger spd@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)
J.A. Gutierrez writes:
Some time ago I sent some mails about LAN synchronisation for mplayer.
Now the code is working; you can find it at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/ http://giga.cps.unizar.es/~spd/src/graphics/mplayer/cmplayer.txt
Looks interesting, one question, though: You have step by step instructions there for making mplayer run with your extensions, but why don't you simply make a patch and provide it there?
but I've found what seems to be a bug in Cinepack decoder: in short, mplayer crashes when there is a drop while playing cinepack compressed movies. I sent a report to MPlayer-users, but there was no answers.
Could you test again with latest CVS? We're now using the cinepak decoder from libavcodec and our native one will be dropped soon. Maybe it does not have these problems.
You can read the details at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/mplayer_bug.txt
You should make that patch with "diff -u" to get a unified diff. It's much easier to read. Diego
On Tue, May 04, 2004 at 12:33:08PM +0200, Diego Biurrun wrote:
J.A. Gutierrez writes:
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/ http://giga.cps.unizar.es/~spd/src/graphics/mplayer/cmplayer.txt
Looks interesting, one question, though: You have step by step instructions there for making mplayer run with your extensions, but why don't you simply make a patch and provide it there?
I'll do it. Anyway, probably it wouldn't be kept as an optional patch; since changes mplayer in an essential way: - Requires sockets, including listening ones. This may have implications from a "configure" level to runtime security considerations. I didn't check for any "configure" option related to sockets, so I don't use the settings it could select. The code compiles on every Unix-like system I tried, anyway... I don't use any authentification scheme, all of this stuff is amied to run on a dedicated LAN where no one could open spureous conecctions and ruin the dialog. I don't think there are any bug wich could allow remote access to mplayer master/slaves, but I haven't checked all the code (should be esasy, there are few new lines of code)
but I've found what seems to be a bug in Cinepack decoder: in short, mplayer crashes when there is a drop while playing cinepack compressed movies. I sent a report to MPlayer-users, but there was no answers.
Could you test again with latest CVS? We're now using the cinepak decoder from libavcodec and our native one will be dropped soon. Maybe it does not have these problems.
I'd try. -- finger spd@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)
Could you test again with latest CVS? We're now using the cinepak decoder from libavcodec and our native one will be dropped soon. Maybe it does not have these problems.
still crashes... I'm not sure which code it's using. Just like before, it says: MPlayer dev-CVS-040504-20:20-3.3.2 (C) 2000-2004 MPlayer Team Opening video decoder: [vfw] Win32/VfW video codecs Loading codec DLL: 'iccvid.dll' Loaded DLL driver iccvid.dll Selected video codec: [cvidvfw] vfm:vfw (Cinepak Video)
You can read the details at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/mplayer_bug.txt
You should make that patch with "diff -u" to get a unified diff. It's much easier to read.
ok; http://giga.cps.unizar.es/~spd/src/graphics/mplayer/mplayer_force_drop.patch -- finger spd@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)
J.A. Gutierrez writes:
Could you test again with latest CVS? We're now using the cinepak decoder from libavcodec and our native one will be dropped soon. Maybe it does not have these problems.
still crashes...
I'm not sure which code it's using. Just like before, it says:
MPlayer dev-CVS-040504-20:20-3.3.2 (C) 2000-2004 MPlayer Team
Opening video decoder: [vfw] Win32/VfW video codecs Loading codec DLL: 'iccvid.dll' Loaded DLL driver iccvid.dll Selected video codec: [cvidvfw] vfm:vfw (Cinepak Video)
It's using the Windows DLL. Please also try the QT and XAnim DLL and most importantly our native decoder with -vc qtcvid -vc cvidxa -vc cvid Diego
On Wed, May 05, 2004 at 01:12:01PM +0200, Diego Biurrun wrote:
It's using the Windows DLL. Please also try the QT and XAnim DLL and most importantly our native decoder with
-vc qtcvid -vc cvidxa
both of them seems to run fine with frame dropping.
-vc cvid
I already commented this one on previous mail; it seems it has some problems even w/o dropping... -- finger spd@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)
On 2004.05.04 12:33, Diego Biurrun wrote:
J.A. Gutierrez writes: [...]
but I've found what seems to be a bug in Cinepack decoder: in short, mplayer crashes when there is a drop while playing cinepack compressed movies. I sent a report to MPlayer-users, but there was no answers.
Could you test again with latest CVS? We're now using the cinepak decoder from libavcodec and our native one will be dropped soon. Maybe it does not have these problems. MPlayer still uses vfw dll decoder as first choice. If you want to test our native imlementation add -vc cvid to your command line. Cinepack using ffmpeg is not supported yet.
Ciao, Roberto
On Tue, May 04, 2004 at 10:22:30PM +0200, Roberto Togni wrote:
MPlayer still uses vfw dll decoder as first choice. If you want to test our native imlementation add -vc cvid to your command line. Cinepack using ffmpeg is not supported yet.
Well, it doesn't crash, but shows a lot of artifacts. Most of the time, the screen is divided in three horizontal bands, one runs smoothly, other runs at random, at the third shows a mostly noise.... (there are also a lot of frame drops, much more than before) Some messages from the log file: [file] File size is 201769984 bytes STREAM: [file] /home/spd/tn.avi STREAM: Description: File MainAVIHeader.dwFlags: (2064) HAS_INDEX TRUST_CKTYPE frames total: 1800 initial: 0 streams: 1 Suggested BufferSize: 203698 Size: 1024 x 768 Found movie at 0x800 - 0xC06520C Reading INDEX block, 1800 chunks for 1800 frames (fpos=0xc065214) stream_seek: WARNING! Can't seek to 0x10B22DFCC ! VIDEO: [cvid] 1024x768 24bpp 25.000 fps 22413.8 kbps (2736.1 kbyte/s) [V] filefmt:3 fourcc:0x64697663 size:1024x768 fps:25.00 ftime:=0.0400 Forced video codec: cvid Opening video decoder: [cinepak] Cinepak Video decoder CVID: unknown chunk_id 00002929 CVID: unknown chunk_id 00000000 [lots of these, usually four for every frame] CVID: unknown chunk_id 00003101 CVID: unknown chunk_id 00007369 CVID: unknown chunk_id 00009cfc CVID: unknown chunk_id 00001f1f CVID: unknown chunk_id 00007a7a -- finger spd@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)
On 2004.05.05 12:18, J.A. Gutierrez wrote:
On Tue, May 04, 2004 at 10:22:30PM +0200, Roberto Togni wrote:
MPlayer still uses vfw dll decoder as first choice. If you want to test our native imlementation add -vc cvid to your command line. Cinepack
using ffmpeg is not supported yet.
Well, it doesn't crash, but shows a lot of artifacts. Most of the time, the screen is divided in three horizontal bands, one runs smoothly, other runs at random, at the third shows a mostly noise.... (there are also a lot of frame drops, much more than before) Can you please upload the file to ftp.mplayerhq.hu/incoming ? (or make it available somewhere)?
I'd like to have a look at it. Ciao, Roberto
On Wed, May 05, 2004 at 08:24:47PM +0200, Roberto Togni wrote:
On 2004.05.05 12:18, J.A. Gutierrez wrote:
On Tue, May 04, 2004 at 10:22:30PM +0200, Roberto Togni wrote:
our native imlementation add -vc cvid to your command line.
Most of the time, the screen is divided in three horizontal bands, one runs smoothly, other runs at random, at the third shows a mostly noise....
Can you please upload the file to ftp.mplayerhq.hu/incoming ? (or make it available somewhere)?
is 200 Mb long; you can find it at http://giga.cps.unizar.es/~spd/src/graphics/mplayer/tn.avi The first 2 Mb are available at http://giga.cps.unizar.es/~spd/src/graphics/mplayer/tns.avi but I haven't tested it for artifacts with cvid, only for crashes with win32 codec... If you prefer I can try to upload it anyway... -- finger spd@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)
On 2004.05.07 12:34, J.A. Gutierrez wrote: [...]
is 200 Mb long; you can find it at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/tn.avi
The first 2 Mb are available at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/tns.avi
but I haven't tested it for artifacts with cvid, only for crashes with win32 codec... Thank you for the file, it's an interesting sample. It works ok here with latest cvs (also with pre4 and pre3try2) using binary dll (vff, qt and xa). It's bad with our native decoder and with ffmpeg native decoder. Do you know what sw and codec was used to make it?
If you prefer I can try to upload it anyway... No problem, i just downloaded it.
Ciao, Roberto
On Fri, May 07, 2004 at 08:21:29PM +0200, Roberto Togni wrote:
It's bad with our native decoder and with ffmpeg native decoder. Do you know what sw and codec was used to make it?
I've asked to the person who made it, but he can't remember. He says it could be SoftImage XSI or Adobe Premiere (from a sequence of PNG files) using native Cinepack codec from Windows 2000. -- finger spd@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)
J.A. Gutierrez writes:
Some time ago I sent some mails about LAN synchronisation for mplayer.
Now the code is working; you can find it at
http://giga.cps.unizar.es/~spd/src/graphics/mplayer/ http://giga.cps.unizar.es/~spd/src/graphics/mplayer/cmplayer.txt
One more thing: If you have something finished and/or a web page about your efforts, please announce it again, I'll add it to our projects page. Diego
On Tue, May 04, 2004 at 12:34:15PM +0200, Diego Biurrun wrote:
J.A. Gutierrez writes:
Some time ago I sent some mails about LAN synchronisation for mplayer.
One more thing: If you have something finished and/or a web page about your efforts, please announce it again, I'll add it to our projects page.
OK, I will try to maintain updated and organized a page and source code tarball: http://persephone.cps.unizar.es/~spd/cmplayer/ -- finger spd@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)
J.A. Gutierrez writes:
On Tue, May 04, 2004 at 12:34:15PM +0200, Diego Biurrun wrote:
J.A. Gutierrez writes:
Some time ago I sent some mails about LAN synchronisation for mplayer.
One more thing: If you have something finished and/or a web page about your efforts, please announce it again, I'll add it to our projects page.
OK, I will try to maintain updated and organized a page and source code tarball:
Thanks, added to the projects page. Diego
Hello Long time ago, I started a quick and dirty patch to MPlayer so you could have serveral mplayer instances running in sync on several slave nodes in a LAN. Lately I have ween working on this subject again, so now I have a similar patch, but for MPlayer-1.0rc2. You can find it at: http://persephone.cps.unizar.es/~spd/cmplayer/ The patch is simpler than the previous version, so I hope it will work with less problems. (in short, it synchronizes the startup of the playback, and then replaces adjust_sync_and_print_status() with a very similar version which uses system clock instead of audio position). -- PGP and other useless info at \ http://webdiis.unizar.es/~spd/ \ finger://daphne.cps.unizar.es/spd \ Timeo Danaos et dona ferentes ftp://ivo.cps.unizar.es/pub/ \ (Virgilio)
J.A. Gutierrez wrote:
Hello
Long time ago, I started a quick and dirty patch to MPlayer so you could have serveral mplayer instances running in sync on several slave nodes in a LAN.
Lately I have ween working on this subject again, so now I have a similar patch, but for MPlayer-1.0rc2.
Patches should be A: submitted against the latest SVN version, not against a released version, and B: submitted as attachments, not as a link to where the patch can be downloaded. See DOCS/tech/patches.txt for the patch submission rules. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Thu, Jun 12, 2008 at 08:04:06PM -0400, The Wanderer wrote:
J.A. Gutierrez wrote:
Hello
Long time ago, I started a quick and dirty patch to MPlayer so you could have several mplayer instances running in sync on several slave nodes in a LAN.
Lately I have been working on this subject again, so now I have a similar patch, but for MPlayer-1.0rc2.
Patches should be A: submitted against the latest SVN version, not
Sorry, I have made a new version for this version. http://persephone.cps.unizar.es/~spd/cmplayer/cave-mplayer-0.3.1.tgz
against a released version, and B: submitted as attachments, not as a link to where the patch can be downloaded. See DOCS/tech/patches.txt for the patch submission rules.
Well, I don't want this patch to be included in the standard mplayer source code, since is interesting only for a few persons, and since it can introduce security problems. It was more an announcement for an update on a project listed on "mplayer related miscellaneous projects". And it's more than a simple "patch", so I guess developers don't really want me to send the 12 KB tar.gz package as attachment. -- PGP and other useless info at \ http://webdiis.unizar.es/~spd/ \ finger://daphne.cps.unizar.es/spd \ Timeo Danaos et dona ferentes ftp://ivo.cps.unizar.es/pub/ \ (Virgilio)
On Fri, 13 Jun 2008 14:24:18 +0200, "J.A. Gutierrez" <spd@daphne.cps.unizar.es> wrote:
Well, I don't want this patch to be included in the standard mplayer source code, since is interesting only for a few persons, and since it can introduce security problems. It was more an announcement for an update on a project listed on "mplayer related miscellaneous projects".
diego updated your project url, thanks for the info! your project could be useful for people making movies, to have one movie play across a whole bunch of screens without much trouble. wasnt there a distro made for 'fake movie computer screens' ? -compn
your project could be useful for people making movies, to have one movie play across a whole bunch of screens without much trouble.
wasnt there a distro made for 'fake movie computer screens' ?
I don't know, when I started this I couldn't find anything similar. Since then I have found two options: * dataton watchout (comercial) http://www.dataton.com/watchout (I haven't tried it) * Net Juggler (mostly for VR, not clear how it could manage video) http://netjuggler.sourceforge.net/ -- PGP and other useless info at \ http://webdiis.unizar.es/~spd/ \ finger://daphne.cps.unizar.es/spd \ Timeo Danaos et dona ferentes ftp://ivo.cps.unizar.es/pub/ \ (Virgilio)
J.A. Gutierrez wrote:
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.
I have thought about this problem before, but never actually implemented it. Problems to overcome: - 1) All players will have to work from the same global clock so a method to accurately set all the local system clocks from a single central clock needs to happen. 2) How much can the different system clocks vary before the viewer notices. 3) The media player must have an interface to the following command: Start playing stream X at global time Y, with the first video frame of stream X being displayed at exactly time Y. Of the above requirements, (2) is about the most important bit of information, because it will decide for us wether we care about CPU scheduling latencies of not. (i.e. are CPU scheduling latencies small enought to not bother us.) (2) is also needed in order to decide what is best for (1). Although (1) could be designed just to be as accurate as possible, and then hope for the best. (3) is also important because we would need to see what the delay between sending an image to the video card and it actually being displayed. Different video cards and different versions of drivers might change this figure. For (1), one approach would be to let all PCs transmit a clock packet over the ethernet. That clock packet would contain a unique PC id, together with all the clock values from all the other PCs it has heard from. Then, all PCs on the network will have an idea of how well all the other PCs are synced together. Then the PC that is most out of time adjusts it's own time to the average of all the other PCs. The process continues, to a point where all the PCs are in sync. For the purposes of control, one might need the control PC to never change it's time, and thus require all the other PCs to fall in line with it. Certain problems occur here. One of which is ethernet packet latency and jitter, and the possiblilty of delays in the transmit and receive queues of the respective network cards/drivers. The proper study of scatter averaging distributions would be required to decide which jitter/latency correction algorith is used. Another method for (1), is to have a single master clock, and use NTP to sync to it. The NTP will have to be the version of NTP that does jitter/latency correction after taking multiple samples over time. A lot of the answers to the about problems would probably be achieved by experiment. Cheers James
On Thu, Nov 20, 2003 at 04:06:29PM +0000, James Courtier-Dutton wrote:
J.A. Gutierrez wrote:
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 have thought about this problem before, but never actually implemented it. Problems to overcome: - 1) All players will have to work from the same global clock so a method to accurately set all the local system clocks from a single central clock needs to happen. 2) How much can the different system clocks vary before the viewer notices.
According to my experiments, using NTP, gettimeofday returns differences below 40 ms: # sec:usec = 1069231417:653136 # sec:usec = 1069231417:653433 # sec:usec = 1069231417:656074 # sec:usec = 1069231417:653073 # sec:usec = 1069231417:653663 # sec:usec = 1069231417:653664 so it seems it could be enough accurate for 25 fps. (these measures are taken after 5 days uptime)
3) The media player must have an interface to the following command: Start playing stream X at global time Y, with the first video frame of stream X being displayed at exactly time Y.
and then, if the player is not synchronising with any audio signal, all of them would would keep in sync?
Of the above requirements, (2) is about the most important bit of information, because it will decide for us wether we care about CPU scheduling latencies of not. (i.e. are CPU scheduling latencies small enought to not bother us.)
maybe running the player with high (real time) priority would help?
(2) is also needed in order to decide what is best for (1). Although (1) could be designed just to be as accurate as possible, and then hope for the best.
(3) is also important because we would need to see what the delay between sending an image to the video card and it actually being displayed. Different video cards and different versions of drivers might change this figure.
Well, having identical hardware/software for all the slaves will help here.
For (1), one approach would be to let all PCs transmit a clock packet over the ethernet. That clock packet would contain a unique PC id, together with all the clock values from all the other PCs it has heard from. Then, all PCs on the network will have an idea of how well all the other PCs are synced together. Then the PC that is most out of time adjusts it's own time to the average of all the other PCs. The process continues, to a point where all the PCs are in sync. For the purposes of control, one might need the control PC to never change it's time, and thus require all the other PCs to fall in line with it. Certain problems occur here. One of which is ethernet packet latency and jitter, and the possiblilty of delays in the transmit and receive queues of the respective network cards/drivers. The proper study of scatter averaging distributions would be required to decide which jitter/latency correction algorith is used.
I think NTP take care of all these questions; it seems too complex to add all these features to mplayer...
Another method for (1), is to have a single master clock, and use NTP to sync to it. The NTP will have to be the version of NTP that does jitter/latency correction after taking multiple samples over time.
A lot of the answers to the about problems would probably be achieved by experiment.
I don't have too much time to dedicate to this problem, so I'll start looking to NTP / internal clock synchronisation, and then, maybe the other solution using audio broadcast... -- finger spd@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)
On Thu, Nov 20, 2003 at 10:14:24AM +0100, J.A. Gutierrez wrote:
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?
In general this is very difficult, unless there's no sound. MPlayer's core sync is based on the sound clock, so if the clock sources on the sound cards vary even slightly, sync will drift over time. The only real fix I know of is to use a common external clock source and add a feature to mplayer to dynamically resample sound to adjust for sound clock skew. Rich
participants (14)
-
Arpi -
Attila Kinali -
compn -
D Richard Felker III -
Dave Lambley -
Diego Biurrun -
J.A. Gutierrez -
J.A. Gutierrez -
James Courtier-Dutton -
Pierre Lombard -
Roberto Togni -
The Wanderer -
Tono Esteve -
Torinthiel