From owner-freebsd-multimedia Sun Dec 14 04:06:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA01650 for multimedia-outgoing; Sun, 14 Dec 1997 04:06:57 -0800 (PST) (envelope-from owner-freebsd-multimedia) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA01643 for ; Sun, 14 Dec 1997 04:06:52 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id EAA11703; Sun, 14 Dec 1997 04:06:32 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712141206.EAA11703@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Petri Helenius cc: Luigi Rizzo , multimedia@FreeBSD.ORG, don@partsnow.com, tristan@mpegtv.com Subject: Re: RTP tools (was: Re: Remote and Voice control) In-reply-to: Your message of "Sun, 14 Dec 1997 12:57:16 +0200." <199712141057.MAA28409@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 04:06:32 -0800 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The full screen playback is a low level X thingie and either we will have to implement it or ask the XFree86 team to do it . On one of my contracts I did hardware assist fax decompression so I sort of have an idea on how to do full screen playback. At the low level it requires storing the image in yuv format in the off display region then doing yuv to color expansion to the display region and I believe vga controllers are also capable of doing dma yuv to color display directly to the display region -- the latter one I am not too sure however I have the specs for my S3 968 laying around so I can check on this later on. BTW: if we implement yuv to color expansion vic can also benefit or for that matter h.261 and h.263 playback. Now if a mechanism for doing yuv to color is created , getting Tristan to use it is a different matter 8) Enjoy, Amancio > Luigi Rizzo writes: > > > controller and helping Petri for an rtp to mtv glue logic. > > > > this is a very interesting project. > > Yes, I'm not sure how much you cut off from Amancio's email, I'll > expand a little. The idea is that you run this like: > mrtp VVV.VVV.VVV.VVV/video_port AAA.AAA.AAA.AAA/audio_port | mtv - > > And it will play a MPEG AV stream off the network, with A/V > synchronization at the playback. The problem this addresses is that > the usual case is that we have two RTP streams in the network which > must be multiplexed together to an ISO MPEG system stream. Amancio is > doing the system stream generation and I've put together a single > stream RTP decoder so far which works like this: > mrtp VVV.VVV.VVV.VVV/video_port | mtv - > > And you'll get the video off the network. Or: > mrtp AAA.AAA.AAA.AAA/audio_port | mpg123-m - > > And you'll have a MPEG-audio net radio. The idea here is that one uses > multicast but there is no reason why the tool could not be used with > unicast also. (Actually it checks for unicast/multicast address before > calling things like IP_ADD_MEMBERSHIP) > > So if you want to improve on your transcoder you might want to change > it into a transmitter, reading .mp2 and .mp3 files and transmitting > them with RTP headers over multicast. > > The next step might be to add encryption to both the transmitter and > receiver. > > The good side about both mtv and mpeg123 is that they are very > tolerant to bad MPEG data, so the wrapper can pass partial frames into > them and they'll just klick and hiss and life goes on. (unlike > mpeg_play which complains and quits or crashes) > > Also, I observed that mtv is about 20-35% more performant on the same > hardware than similar function performed under Win95. I only wish we > could get full screen operation for mtv in the future (Tristan?) > > Pete