Date: Tue, 16 Dec 1997 00:00:22 +0200 (EET) From: Petri Helenius <pete@sms.fi> To: Tristan Savatier <tristan@mpegtv.com> Cc: Amancio Hasty <hasty@rah.star-gate.com>, Luigi Rizzo <luigi@labinfo.iet.unipi.it>, multimedia@FreeBSD.ORG, don@partsnow.com Subject: Re: RTP tools (was: Re: Remote and Voice control) Message-ID: <199712152200.AAA02412@silver.sms.fi> In-Reply-To: <3494D55D.37B39EDA@mpegtv.com> References: <199712141206.EAA11703@rah.star-gate.com> <3494D55D.37B39EDA@mpegtv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tristan Savatier writes: > > > And it will play a MPEG AV stream off the network, with A/V > > > synchronization at the playback. > > You can do something a bit more efficient by developing an SII > plug-in (Stream Input Interface). This way you avoid the > copies in the pipe. > The data rate on the pipe is not of major concern. It's only 200 kilobytes per second at maximum. It shouldn't be a major performance hit. Doing it this way would also make the program able to record live data from network and save it as MPEG System stream. > > 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. > > Yes. At the present mtvp does not provide a way to > feed the elementary streams. This is not that simple to > do that, because of the need to also give some timing/ > synchronization infos (like PTS = Presentation > Time Stamps). Maybe some day... > We have the PTS's in RTP header. If the SII would take an ES pack and PTS as input, it would simplify our task greatly. Since this is not the case, there is no added value the SII provides. > Yes but no sync between both... Yes, but you are reading the wrong part of my message. There is a syntax for doing both audio and video at the same time off the network. > > > > 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?) > > Full-screen or zooming is very inefficient when done by software. > It must be done by hardware. The problem is that X, unlike Windows, > does not have an API to do that. Windows has directDraw, and > when hardware acceleration is available, the library takes advantage > of it. The closest think to that with X are foundation libraries > like Sun's XIL (Sun Imaging Library) or OpenGL for the 3D. > The problem is that XIL is currently available only on Sun. > They are talking of porting it of other Unix systems including > Linux, but nothing is available. This is true, however one can decrease the actual resolution the screen runs in to a suitable one for MPEG-decode. > Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712152200.AAA02412>