Date: Sun, 14 Dec 1997 23:01:14 -0800 From: Tristan Savatier <tristan@mpegtv.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: Petri Helenius <pete@sms.fi>, 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: <3494D55D.37B39EDA@mpegtv.com> References: <199712141206.EAA11703@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 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 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... > 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. Yes but no sync between both... [snip] > > 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. It would be stupid to implement in each application some code particular to each graphic processor to do the very same basic things (zooming, YUV to RGB etc). This must be provided at the system level i.e. X extensions or foundation graphic libraries on top of X, like XIL or OpenGL, that must in fact use some X extensions to speedup some operations. I will probably use XIL when available (it will speed things up on Sun systems). Amancio Hasty wrote: > > 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 . IMHO it should not be specific to XFree86. It should be standardized on all X systems, like the shared memory extension for example. XIL looks like a good candidate. I don't know what are the licensing and legal aspect of implementing it, though. > 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. Of course most modern graphic controlers are capable of doing that, and microsoft people seem to be smarter than Unix people and have been using it and provided easy way to use it with the win32 API. X is just a few years late... > BTW: if we implement yuv to color expansion vic can also benefit or > for that matter h.261 and h.263 playback. Of course... Note that YUV to RGB is more tricky than it looks, because there are several incompatible standards to do this conversion, using different matric coefficients. Colors look off is the wrong matrix is used. > > Now if a mechanism for doing yuv to color is created , getting Tristan > to use it is a different matter 8) > > Enjoy, > Amancio When it will be a standardized extension of X, I will use it. As I say, I plan to use XIL. But I want to interface with an API, not to write directly in some registers of a perticular controlers. That's not a good thing for applications to do. Regards, -- Tristan Savatier (President, MpegTV LLC) MpegTV: http://www.mpegtv.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3494D55D.37B39EDA>