Re: [Unichrome-devel] Via HW MPEG API
Brought to you by:
dwdeath
Menu
▾
▴
Re: [Unichrome-devel] Via HW MPEG API
|
From: Terry B. <te...@be...> - 2004-08-31 08:42:53
|
Hi Thomas, Ok, I will have a look at doing this and you can see later if it is worthwhile. I don't think there will be any performance penalty, actually it could be better as we can control the task switching better in the kernel. I have made a first pass at checking the API. I have integrated the HWMpeg API into the vialibXvMC library and implemented a direct client implementation of HwMpeg. This is still very ruidementary and in-complete, but it works fine on my Via M1000. I have put this code on a web site at: http://portal.beam.ltd.uk/misc/via= mpeg/ if you want a look. The macro BEAM_HWMPEG is used for all the changes in the standard vialibXvMC code. There are still some issues with the API: 1. FrameBuffer addresses. 2. Are all the flags passed in hwMpegBegin() generic MPEG or Via Specific. Before I start implementing the HwMpeg in the DRM, do you know who I shou= ld ask to check if they would accept this sort of API (email addresses) ? Thats good news that you have the mpeg2 DMA AGP working. I would be inter= ested in looking at this code. All your work on this is very appeciated. Terry Thomas Hellstr=F6m wrote: > Hi! >=20 > Terry Barnaby wrote: >=20 >> Hi Thomas, >> >> This DRM stuff is all a bit messy (I repeat I know !) >> I can see you are not convinced with my proposed API, (niether am I)=20 >> but I will carry >> on a bit more if that is Ok with you ..... >> >> A few extra points on my proposed API: >> 1. The API would be implemented within the DRM not as a library. >> The simple API function library calls I have defined would be just=20 >> for ease of access. >=20 > Seems OK. >=20 >=20 >> 2. The hwMpegInit() function could take an existing drm file descripto= r >> as an argument and use that connection. This should give the HwMpeg >> interface the same authorisation and memory access ability as the=20 >> client has gained. >=20 > That's also a good choice, I believe. >=20 >> 3. It would be easy to add a flag to hwMpegInit() to ignore performing= =20 >> global locking so that >> the client (X-Server as well) could manage this if desired. >=20 > Which solves the X server locking problem. >=20 >> >> 4. As it would only be possible to access the HwMpeg system via this=20 >> DRM interface >> there would be no requirement for client driven locks. The HwMpeg D= RM >> interface can handle arbitration in a safe and efficient manner. >=20 > OK. With the client's privileges this should work. >=20 >> 5. All of the HwMpeg control code would reside within the DRM (kernel=20 >> mode) >> and so it can easily manage and control the HwMpeg engine in a safe= =20 >> and >> efficient way. >=20 >=20 >> 6. Clients would need no knowledge of the HwMpeg engines workings and = so >> the libXvMC could be implemented in a hardware independent way. >> > This is also desirable. >=20 >=20 >> We haven't listed the main requirements yet, I presume they should be: >> 1. Clients do not have direct access to the HwMpeg controllers registe= rs. >=20 > We can assume read access, and write access through DMA. See coming pos= t. >=20 >> 2. Clients cannot use the HwMpeg registers in a way to cause security = or >> system instability problems. >=20 > They would. Authorized clients can, But this is considered safe enough= .=20 > Actually, DRI allows for a client to crash the computer in most=20 > architectures. What is not good is if the user can gain access to other= =20 > users (or even the system's) memory area which is possible using CLE266= =20 > and system memory BITBLT. That's why write access to registers is going= =20 > to be turned off. Write access through DMA will still be allowed, with=20 > an extra check that system memory bitblt is not going to be performed. >=20 >> 3. The DRM API should be as generic as possible to handle different >> HwMpeg engines. >=20 > That's also good. >=20 >> >> If the client is allowed to access registers, even indirectly through=20 >> the DRM, >> then the DRM would have to check every register setting to make sure t= his >> is valid and will not cause a security issue. The DRM would need some >> very complicated code in order to achieve this and both the client and >> the DRM would need to know a lot about the Mpeg HW engine. It >> would be much simpler and managable to put all of this knowledge and >> code into one place, the DRM (or other driver) and use a higher level=20 >> interface >> than register access. This would restrict usage of the HwMpeg engine=20 >> to do >> just one thing, decode an Mpeg stream into a validated memory area. >> > As long as the user don't have access to other users private memory=20 > areas, it should be safe. See above. In fact, the i915 (i believe it's=20 > called) DRM has implemented checking of DMA buffers without too much=20 > penalty. >=20 >> An updated example HwMpeg API is enclosed. >> >> Does this convince you more ... (or less .... :) ) >> > It does. (more :)). One big player in the game is, however, that I've=20 > just got mpeg2 DMA AGP working, which means that the immediate need=20 > (for security reasons) for implementing it all in DRM is no longer=20 > there, and could possibly be a severe performance penalty. >=20 > Now, it is desirable to have a more generic interface, so please go=20 > ahead and if it seems to be working well, I'll change libviaXVMC to be=20 > compatible. Please also see some needed updates in the API below. >=20 > Regards, > Terry >=20 >> >> Thomas Hellstr=F6m wrote: >> >>> Hi, Terry. >>> >>> >>> >>> =20 >>> >>>> Hi Thomas, >>>> >>>> I don't think I have explained what my proposed HW MPeg API would do >>>> clearly enough to you (or my understanding of the needs is to=20 >>>> incomplete) >>>> :) >>>> >>>> The proposed HW MPeg API would perform the same basic actions as >>>> the viaLowLevel.c but with some bits of viaXvMC.c included. >>>> Its purpose would be to solely drive the HW MPeg controller, but in >>>> a hardware independent way as possible. >>>> It would not be resposible for bliting the pictures to the screen >>>> or anything else. A seperate DRM ioctl would do this. >>>> It would perform all register accesses so the the higher level >>>> viaXvMC.c would not need to know anything of this. Indeed the user >>>> libary code would not know anything about the register access. >>>> >>>> =20 >>> >>> >>> The thing is, that while this might be fine on an mpeg2 decoder on a >>> separate card with separate memory, for the CLE266 we will run into >>> several problems, and that's why I still propose to do just register >>> access IOCTLs: >>> >>> 1. Display memory where surfaces resides are owned by the root proces= s >>> initializing the DRM. Part of the display memory is under DRM control. >>> This means that your library must check that the process calling it=20 >>> really >>> is allowed to use the surfaces that it indicates. For the client to d= o >>> this, it must have authenticated to the X server or another process >>> initializing the drm and obtained permission to use the drm.=20 >>> Otherwise any >>> process could write and read blindly to any part of display memory, j= ust >>> by setting up the decoder display pointers in the right way. This mea= ns >>> that any client using the library will already have authenticated to = be >>> able to use drm, and there is really no use in doing that in the=20 >>> library. >>> Here is where thing differs between CLE266 and a freestanding decoder. >>> >>> 2. While I'm still not convinced that the global hardware lock is nee= ded >>> for PCI register level access to the CLE266 decoder, If we were to=20 >>> use agp >>> DMA it would definitively be needed. Now the X server takes this lock= =20 >>> per >>> definition when it is accessing the hardware, and therefore it could = not >>> call the library if that too did concern about locking. Therefore the >>> library must only make sure that the lock is taken when it is called = and >>> return an error otherwise, if the lock is needed. Having the locking >>> mechanism within the library would exclude either the X server or agp= =20 >>> DMA >>> in the future. The decoder lock for multiple decoding applications=20 >>> must be >>> taken outside of the hardware lock, and it cannot be in the library >>> either. >>> >>> 3. This eventually means that without these mechanisms the API you=20 >>> propose >>> will become more or less identical in function to what's in=20 >>> viaLowLevel.c. >>> >>> >>> /Regards >>> >>> Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> =20 >>> >>>> So the basic operation would be as follows: >>>> The viaXvMC.c would call hwMpegInit(HwMpeg** mpeg) to initialise >>>> access to the HW MPeg controller. This would end up opening "drm" an= d >>>> setting a few things up. >>>> >>>> The viaXvMC.c XvMCBeginSurface() would call hwMpegBegin(HwMpeg* mpeg= , >>>> HwMpegConfig* config) >>>> to begin the next set of pictures. This would set up the >>>> width,height,quantisers etc "AND" the target address where the=20 >>>> resulting >>>> frames would be stored. >>>> >>>> The viaXvMC.c XvMCPutSlice would call hwMpegWriteSlice(HwMpeg* mpeg,= =20 >>>> void* >>>> data, int nBytes) >>>> to write the slices. This would perform the necessary wait for >>>> the MPEG controller and then send the slice data. It could FIFO the >>>> slices so that it would be non blocking. >>>> >>>> The viaXvMC.c would call hwMpegWaitComplete(HwMpeg* mpeg). This=20 >>>> would wait >>>> till all of the processing for the currently sent slices has complet= ed. >>>> The client library could then blit the resulting target memory to >>>> the screen using the separate DRM ioctl as and when required. >>>> >>>> All arbitration for the HW MPEG controller would be done within this= =20 >>>> API >>>> and hence done in the DRM module so the client would not have to >>>> worry about locks. >>>> >>>> The idea of the API is to simplify the HW Mpeg control operation to >>>> its basic functionality. It would be simple to implement as it only >>>> deals with the HW MPEG controllers registers. I could, as a first >>>> pass, create an implementation that uses viaLowLevel to do the work >>>> and then later move this code into to the DRM. >>>> >>>> Does this make more sense and does it seem reasonable to you ? >>>> >>>> Terry >>>> >>>> >>>> >>>> >>>> >>>> Thomas Hellstr=F6m wrote: >>>> =20 >>>> >>>>> Hi, Terry. >>>>> >>>>> Terry Barnaby wrote: >>>>> >>>>> =20 >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> Yes, adding support to the X-Server for the XvMC to be implemented >>>>>> there would be harder. I have implemented XServer extensions in th= e >>>>>> past >>>>>> though .... >>>>>> Maybe the complete xine-lib could be linked into the XServer as we= ll >>>>>> ..... >>>>>> >>>>>> As to the Via Hardware MPEG access API, I could implement it as yo= u >>>>>> suggest with the two DRM ioctl's in a dedicated Via way. >>>>>> However, I thought it would be better to generalise this a bit mor= e >>>>>> so that other MPEG hardware may be able to use the same API. My >>>>>> suggested >>>>>> API was not going to do the whole MPEG decode just drive the HW MP= EG >>>>>> engine in the most simple/generic way possible. >>>>>> =20 >>>>> >>>>> The problem is that to do this generically you'd need an API about = as >>>>> complex as the XvMC library. >>>>> The reason for this is that as well as decoding, the API needs to b= e >>>>> able to display surfaces since reading from the VIA framebuffer whe= re >>>>> the decoded surfaces end up is painfully slow. Not anyway near the=20 >>>>> speed >>>>> it requires to read pictures in real time. This also mean subpictur= es >>>>> need to be there for overlay blending support, and logic to keep tr= ack >>>>> of reference surfaces for the decoder. >>>>> >>>>> In this case, it would be better to write a user space lib that is >>>>> capable of doing what XvMC is doing, but that does not require >>>>> interaction with the X server. But this would require logic to man= age >>>>> the locking and permission mechanisms with whatever system is manag= ing >>>>> the dri. The X server or DirectFB. >>>>> >>>>> That's why I propose a small register-level IOCTL interface to the >>>>> MPEG2-decoder. All register-writing needs to be done either using=20 >>>>> DMA or >>>>> in the kernel. Register reading for waiting purposes could still be= =20 >>>>> done >>>>> in user-space if we want to. From what I have seen from other DRM=20 >>>>> IOCTL >>>>> implementations also locking is done in user space, and the IOCTL o= nly >>>>> verifies that the hardware lock is held when the IOCTL is called. >>>>> >>>>> >>>>> /Thomas >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>>> I thought it would be useful to get the waits for MPEG ready into >>>>>> the DRM driver so that efficient waits and interrupt usage >>>>>> could be implemented. >>>>>> So that was the idea behind my HW MPEG API that would be implement= ed >>>>>> within the DRM module by a set of ioctl calls. I know this is a bi= t >>>>>> different to the viaLowLevel.c and so would need a bit of work in >>>>>> viaXvMC.c to implement, but it could be made compatible with other >>>>>> MPEG hardware. Once implemented it can be used directly by clients >>>>>> or by the XServer. >>>>>> >>>>>> Do you think this would be Ok or would you prefer the simpler >>>>>> Via DRM ioctl's as you suggest ? >>>>>> Below is a rudimentry proposed API (no timeouts etc) >>>>>> >>>>>> ################################# >>>>>> >>>>>> Simple MPEG Decoder API >>>>>> This would handle hardware locking etc as needed and handle waits = for >>>>>> resources as necessary. >>>>>> >>>>>> // MPEG hardware controller data structure (would be private in >>>>>> realality) >>>>>> typedef struct Mpeg { >>>>>> int drmFd; >>>>>> char* frames[4]; >>>>>> } Mpeg; >>>>>> >>>>>> // MPEG configuartion information. All info needed to perform a HW >>>>>> decode. >>>>>> // TargetFrame would be where resulting data would be stored. Idea= ly >>>>>> this >>>>>> // would be abstracted somewhat to allow target to be an onscreen >>>>>> overlay ... >>>>>> // Some more config info is needed here. >>>>>> typedef struct MpegConfig { >>>>>> int flags; >>>>>> int width; >>>>>> int height; char* targetFrame; >>>>>> unsigned char intra_quantiser_matrix[64]; >>>>>> unsigned char non_intra_quantiser_matrix[64]; >>>>>> } MpegConfig; >>>>>> >>>>>> // MpegInit: Initialises MPEG Decoder and returns pointer to=20 >>>>>> allocated >>>>>> Mpeg data structure >>>>>> // This would open the DRM driver and allocate some resources >>>>>> int MpegInit(Mpeg** mpeg); >>>>>> >>>>>> // MpegConfig: Configures MPEG controller for next picture >>>>>> int MpegConfig(Mpeg* mpeg, MpegConfig* config); >>>>>> >>>>>> // MpegWriteSlice: Writes a slice, buffering in a FIFO as necessar= y >>>>>> and waiting for hardware >>>>>> int MpegWriteSlice(Mpeg* mpeg, char* data, int nBytes); >>>>>> >>>>>> // MpegWaitComplete: Waits till MPEG controller has completed all >>>>>> outstanding work >>>>>> int MpegWaitComplete(Mpeg* mpeg); >>>>>> >>>>>> // Closes the MPEG decoder >>>>>> int MpegClose(Mpeg* mpeg); >>>>>> >>>>>> ######################################### >>>>>> >>>>>> Terry >>>>>> >>>>>> Thomas Hellstr=F6m wrote: >>>>>> >>>>>> =20 >>>>>> >>>>>>> Hi >>>>>>> OOps mozilla sent the mail before I completed it :-). >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>>> Hi, Terry. >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> Hi Thomas, >>>>>>>>> >>>>>>>>> Some initial thoughts on providing a Via HW MPEG API. >>>>>>>>> Note please bear with me as I am not up on MPEG or the Via >>>>>>>>> Unichrome as >>>>>>>>> much >>>>>>>>> as you are. >>>>>>>>> >>>>>>>>> First from my perspective I would like, eventually, for the >>>>>>>>> X-Server to >>>>>>>>> implement >>>>>>>>> MPEG decoding internally using whatever hardware is available o= r >>>>>>>>> software >>>>>>>>> as >>>>>>>>> necessary. This seems to me to be the best approach as graphics >>>>>>>>> chips >>>>>>>>> have >>>>>>>>> HW MPEG >>>>>>>>> decode engines and real-time display actions would be best carr= ied >>>>>>>>> out >>>>>>>>> here. >>>>>>>>> It would also allow thin clients to display MPEG video. There=20 >>>>>>>>> would >>>>>>>>> be >>>>>>>>> no >>>>>>>>> hardware >>>>>>>>> specific parts in the MPEG applications or X-Windows libraries >>>>>>>>> themselves. >>>>>>>>> So >>>>>>>>> some of the following ideas are based on that basis ... >>>>>>>>> >>>>>>>>> =20 >>>>>>>> >>>>>>>> This is a good idea, and the only thing required to do this is t= o >>>>>>>> implement the full version of XvMC in the X protocol. Now certai= n >>>>>>>> XvMC >>>>>>>> functions does not have a protocol counterpart, and therefore Xv= MC >>>>>>>> currently must be implemented as a DRI API. Letting the X server= do >>>>>>>> the >>>>>>>> job would be easy as soon as the full protocol is implemented. >>>>>>>> Nobody is >>>>>>>> doing that at the moment, though. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> As a first pass towards this the following could be done .... >>>>>>>>> >>>>>>>>> Improvement to ViaXvMC HW MPeg Decode API >>>>>>>>> >>>>>>>>> 1. It would be good to try and make the viaXvMC more generic an= d >>>>>>>>> not Via >>>>>>>>> specific. This could be called XvMPEG. Maybe create a new >>>>>>>>> X-Windows >>>>>>>>> extension eventually XvMPEG ?? >>>>>>>>> I suppose it would eventually be good to support other >>>>>>>>> compressed >>>>>>>>> video streams .... >>>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>> In fact, it is as generic as my mpeg knowledge allowed it to be.= It >>>>>>>> should >>>>>>>> be possible to implement any mpeg1 and mpeg2 decoder with the >>>>>>>> viaXvMC api. >>>>>>>> Even software. Other type of streams, like mpeg4 might require a= n >>>>>>>> extension of the API, though. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> 2. Move all of the viaXvMC (XvMPEG) implementation to the XServ= er >>>>>>>>> with >>>>>>>>> just API >>>>>>>>> calls in the library. This would result in the ability to >>>>>>>>> provide just >>>>>>>>> one API library for all HW MPEG implementations that can be >>>>>>>>> linked into >>>>>>>>> all applications. >>>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>> Or both. XvMC allows for the client to request an indirect >>>>>>>> (everything >>>>>>>> done in the X server) or a direct (Most things done in the libra= ry) >>>>>>>> context. Unfortunately, nobody has implemented indirect XvMC yet= , >>>>>>>> and the >>>>>>>> means to do it is still not in the X server. The first thing to=20 >>>>>>>> look >>>>>>>> at >>>>>>>> would be the X protocol for the unimplemented XvMC functions, so= =20 >>>>>>>> that >>>>>>>> relevant data could be sent to the X server. A rather big task. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> 3, Remove any hardware specific and MPEG decode specific bits f= rom >>>>>>>>> this >>>>>>>>> API. >>>>>>>>> (past_surface and future_surface are not needed etc ??) >>>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, they do. In fact, the XvMC API is quite client oriented. A=20 >>>>>>>> line >>>>>>>> is >>>>>>>> drawn in the mpeg decoding cycle at different levels >>>>>>>> >>>>>>>> 1. The MOCOMP level which means the API needs to handle everythi= ng >>>>>>>> that >>>>>>>> mpeg requires for motion compensation. >>>>>>>> >>>>>>>> 2. The IDCT level, which means the API needs to handle everythin= g >>>>>>>> that >>>>>>>> mpeg requires for IDCT transformation and motion compensation. >>>>>>>> >>>>>>>> 3. The VLD level, (The up to now via specific extension) which=20 >>>>>>>> means >>>>>>>> that >>>>>>>> the API needs to handle everything neccesary to decode an mpeg1 = and >>>>>>>> mpeg2 >>>>>>>> stream. Now, Nobody is really sure it does that, so thats why it= 's >>>>>>>> not a >>>>>>>> standard yet. >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> 4. Add a MPEG engine API to a suitable device driver (DRM) call= ed >>>>>>>>> from >>>>>>>>> X-Server >>>>>>>>> implementation of XvMPEG. >>>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>> Yes, but here I strongly think that the API should be hardware >>>>>>>> oriented, >>>>>>>> to let suitable clients access the hardware in a secure manner. = To >>>>>>>> implement a full mpeg API here it not wise I think. >>>>>>>> >>>>>>>> I would suggest a DRM api that had two ICOTLS: that implemented = the >>>>>>>> following functions with counterparts in viaLowLevel.c >>>>>>>> >>>>>>>> IOCTL viaMpeg >>>>>>>> setSurfaceStride >>>>>>>> setFB >>>>>>>> beginPicture >>>>>>>> getStatus >>>>>>>> isBusy >>>>>>>> reset >>>>>>>> writeSlice >>>>>>>> =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regarding beginPicture, I think the mpegcontrol structure contain= s >>>>>>> all it >>>>>>> needs. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>>> IOCTL viaVideo >>>>>>>> Video Functions that cannot be moved to the X server for one >>>>>>>> reason or another. >>>>>>>> >>>>>>>> =20 >>>>>>> >>>>>>> And I think the above two is where we should start. >>>>>>> The via DRM will soon be closed for user client direct write-acce= ss >>>>>>> to >>>>>>> registers, for security reasons. Second task would be to complete= =20 >>>>>>> the >>>>>>> X >>>>>>> protocol for XvMC including the VLD level and third task to=20 >>>>>>> implement >>>>>>> a >>>>>>> server side for indirect context that uses the decoder on the X=20 >>>>>>> server >>>>>>> computer. If / When the XvMC library needs to be modified we can = do >>>>>>> that, >>>>>>> but I don't think we should go for an even more complete API,=20 >>>>>>> because >>>>>>> that would mean to implement the whole xine-lib in the X server. >>>>>>> >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>>> >>>>>>>>> 5. The BitBlitter code can be implemented directly in the=20 >>>>>>>>> XServer or >>>>>>>>> via the DRM (Unichrome DMA ??) >>>>>>>>> =20 >>>>>>>> >>>>>>>> >>>>>>>> I agree. It can be done from DRI clients using DMA, or through=20 >>>>>>>> the X >>>>>>>> server. >>>>>>>> >>>>>>>> =20 >>>>>>> >>>>>>> Regards, >>>>>>> Thomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>>>> I know this involves quite a lot of changes, but this would be=20 >>>>>>>>> very >>>>>>>>> useful >>>>>>>>> and not just to the VIA community. What do you think about this= ?? >>>>>>>>> >>>>>>>>> ------------------------------- >>>>>>>>> >>>>>>>>> As to the task in hand, implementing a VIA MPEG engine API=20 >>>>>>>>> (would be >>>>>>>>> stage >>>>>>>>> 4 above >>>>>>>>> and could be used by the current viaXvMC now). How about someth= ing >>>>>>>>> like: >>>>>>>>> >>>>>>>>> Simple MPEG Decoder API >>>>>>>>> This would handle hardware locking etc as needed and handle wai= ts >>>>>>>>> for >>>>>>>>> resources as necessary. >>>>>>>>> >>>>>>>>> // MPEG hardware controller data structure (would be private in >>>>>>>>> realality) >>>>>>>>> typedef struct Mpeg { >>>>>>>>> int drmFd; >>>>>>>>> char* frames[4]; >>>>>>>>> } Mpeg; >>>>>>>>> >>>>>>>>> // MPEG configuartion information. All info needed to perform a= HW >>>>>>>>> decode. >>>>>>>>> // TargetFrame would be where resulting data would be stored.=20 >>>>>>>>> Idealy >>>>>>>>> this >>>>>>>>> // would be abstracted somewhat to allow target to be an onscre= en >>>>>>>>> overlay >>>>>>>>> ... >>>>>>>>> // Some more config info is needed here. >>>>>>>>> typedef struct MpegConfig { >>>>>>>>> int flags; >>>>>>>>> int width; >>>>>>>>> int height; >>>>>>>>> char* targetFrame; >>>>>>>>> unsigned char intra_quantiser_matrix[64]; >>>>>>>>> unsigned char non_intra_quantiser_matrix[64]; >>>>>>>>> } MpegConfig; >>>>>>>>> >>>>>>>>> // MpegInit: Initialises MPEG Decoder and returns pointer to >>>>>>>>> allocated >>>>>>>>> Mpeg data structure >>>>>>>>> // This would open the DRM driver and allocate some resources >>>>>>>>> int MpegInit(Mpeg** mpeg); >>>>>>>>> >>>>>>>>> // MpegConfig: Configures MPEG controller for next picture >>>>>>>>> int MpegConfig(Mpeg* mpeg, MpegConfig* config); >>>>>>>>> >>>>>>>>> // MpegWriteSlice: Writes a slice, buffering in a FIFO as=20 >>>>>>>>> necessary >>>>>>>>> and >>>>>>>>> waiting for hardware >>>>>>>>> int MpegWriteSlice(Mpeg* mpeg, char* data, int nBytes); >>>>>>>>> >>>>>>>>> // MpegWaitComplete: Waits till MPEG controller has completed a= ll >>>>>>>>> outstanding work >>>>>>>>> int MpegWaitComplete(Mpeg* mpeg); >>>>>>>>> >>>>>>>>> // Closes the MPEG decoder >>>>>>>>> int MpegClose(Mpeg* mpeg); >>>>>>>>> >>>>>>>>> >>>>>>>>> Terry >>>>>>>>> --=20 >>>>>>>>> Dr Terry Barnaby BEAM Ltd >>>>>>>>> Phone: +44 1454 324512 Northavon Business Center, >>>>>>>>> Dean Rd >>>>>>>>> Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, U= K >>>>>>>>> Email: te...@be... Web: www.beam.ltd.uk >>>>>>>>> BEAM for: Visually Impaired X-Terminals, Parallel Processing, >>>>>>>>> Software >>>>>>>>> "Tandems are twice the fun !" >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------- >>>>>>>>> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blan= k >>>>>>>>> Media >>>>>>>>> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $= 33 >>>>>>>>> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gif= t. >>>>>>>>> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >>>>>>>>> _______________________________________________ >>>>>>>>> Unichrome-devel mailing list >>>>>>>>> Uni...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unichrome-devel >>>>>>>>> >>>>>>>>> =20 >>>>>>>> >>>> --=20 >>>> Dr Terry Barnaby BEAM Ltd >>>> Phone: +44 1454 324512 Northavon Business Center, Dean= Rd >>>> Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK >>>> Email: te...@be... Web: www.beam.ltd.uk >>>> BEAM for: Visually Impaired X-Terminals, Parallel Processing, Softwa= re >>>> "Tandems are twice the fun !" >>>> >>>> >>>> ------------------------------------------------------- >>>> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Med= ia >>>> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >>>> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >>>> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >>>> _______________________________________________ >>>> Unichrome-devel mailing list >>>> Uni...@li... >>>> https://lists.sourceforge.net/lists/listinfo/unichrome-devel >>>> >>>> =20 >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by BEA Weblogic Workshop >>> FREE Java Enterprise J2EE developer tools! >>> Get your free copy of BEA WebLogic Workshop 8.1 today. >>> http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk >>> _______________________________________________ >>> Unichrome-devel mailing list >>> Uni...@li... >>> https://lists.sourceforge.net/lists/listinfo/unichrome-devel >>> >>> =20 >>> >>-----------------------------------------------------------------------= - >> >>/* HwMpeg.h >> * >> * Copyright 2004 BEAM Ltd. >> * All Rights Reserved. >> * >> * Permission is hereby granted, free of charge, to any person obtainin= g a >> * copy of this software and associated documentation files (the "Softw= are"), >> * to deal in the Software without restriction, including without limit= ation >> * the rights to use, copy, modify, merge, publish, distribute, sublice= nse, >> * and/or sell copies of the Software, and to permit persons to whom th= e >> * Software is furnished to do so, subject to the following conditions: >> *=20 >> * The above copyright notice and this permission notice (including the= next >> * paragraph) shall be included in all copies or substantial portions o= f the >> * Software. >> *=20 >> * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPR= ESS OR >> * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL= ITY, >> * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT S= HALL >> * BEAM LTD, TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY = CLAIM,=20 >> * DAMAGES OR >> * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE= , >> * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE O= R OTHER >> * DEALINGS IN THE SOFTWARE. >> * >> * Authors:=20 >> * Terry Barnaby <te...@be...> >> * >> * >> * Description >> * This code provides access to a Hardware MPEG controller. >> */ >>#ifndef _HWMPEG_H_ >>#define _HWMPEG_H_ >> >>/* Errors */ >>#define HwMpegErrorOk 0 >>#define HwMpegErrorUnspecified 0 >> >>/* HwMpeg* hardware controller data structure */ >>typedef struct _HwMpeg HwMpeg; >> >>/* HwMpeg* configuartion information. All info needed to perform a HW d= ecode. */ >>/* TargetFrame is where resulting data would be stored. Ideally this */ >>/* would be abstracted somewhat to allow target to be an onscreen overl= ay */ >>/* Some more config info is needed here. */ >> >>typedef struct _HwMpegConfig { >> int flags; >> int width; >> int height; >> =20 >> > /* All decoders need reference surfaces. */ >=20 >> char* targetFrame, past_reference_surface, future_reference_surface; >>=09 >> int mpeg_coding; >> int picture_structure; >> int picture_coding_type; >> int intra_dc_precision; >> int FHMV_range; >> int FVMV_range; >> int BHMV_range; >> int BVMV_range; >>=09 >> =20 >> > /* These could be expensive to load, Also there are two additional > matrices in the CLE266 specification. Maybe flags to indicate th= at > they really need to be updated? */ >=20 >> unsigned char intra_quantiser_matrix[64]; >> unsigned char non_intra_quantiser_matrix[64]; >>} HwMpegConfig; >> >>/* MpegInit: Initialises MPEG Decoder and returns pointer to allocated = Mpeg data structure */ >>/* This would open the DRM driver and allocate some resources */ >>int hwMpegInit(HwMpeg** mpeg, int drmFd, int performLocking); >> >>/* HwMpegBegin: Configures MPEG controller for next set of pictures */ >>int hwMpegBegin(HwMpeg* mpeg, HwMpegConfig* config); >> >>/* HwMpegWriteSlice: Writes a slice, buffering in a FIFO as necessary a= nd waiting for hardware */ >>int hwMpegWriteSlice(HwMpeg* mpeg, void* data, int nBytes); >> =20 >> > Please note the difference above in XvMC's putslice and putslice2.=20 > Putslice2 avoids > an extra slice copy in xine. >=20 >>/* HwMpegWaitComplete: Waits till MPEG controller has completed all out= standing work */ >>int hwMpegWaitComplete(HwMpeg* mpeg); >> =20 >> >=20 > /* A flushing function maybe. ? Not really needed for CLE266, but=20 > probably for > other decoders. */ >=20 >>/* Closes the MPEG decoder */ >>int hwMpegClose(HwMpeg* mpeg); >> >>#endif /*_HWMPEG_H_ */ >> =20 >> >=20 --=20 Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: te...@be... Web: www.beam.ltd.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software "Tandems are twice the fun !" |