[OUT OF PLACE]Direct HW mpeg decoding in Xv.

2004-02-20
2004-02-21
  • Thomas Hellström

    Hi!

    This is more like a developer issue, but since initially not very many people can se the devel list as yet, I'd give the post here.

    Following the discussions of cozzap and Dead Dingo's donger on the via forum at least three persons more or less simultaneoulsy have come up with a good way to have ddmpeg in the X (Xv) driver and I have started to give it a go. Don't hold your breath.

    Some elements are missing from Xv and FOURCC standards (?) and I have to come up with some things myself, that we will easily change once there is a proper way to do this.

    First design:
    Mpeg data chuncs is transmitted as "pictures" to the Xv driver, where they are defined as YUV pictures of a large fixed maximum size so that a large shared memory region is allocated for their transfer. This currently implies that shared memory has to be used, otherwise performance will be bad. I'll define the picture type as FOURCC_MPEG2a, (which does not exist, I believe.) Each "picture" has an operation field, a size field and the actual mpeg data. Not very neat, but until there is an "XvCodedPic" data type of variable size in the Xv standard, this is probably the best way.  If the videodata size exceeds the preallocated buffer, initially an error will be posted, later on, an option for sending oversized data as multiple consecutive "pictures" will be added, and even later on we might press the XFree86 people to add an extension to Xv for XvCodedPic.

    The implementation in the Xv layer is straightforward as outlined by Cozzap and Dead Dingo's Donger on the via Arena forum. The YUV420 codepath will be followed until the blitting part where a routine VIADDDecode will be called to do the decoding, and to put the result directly in the apropriate Color space / scaling buffer without blitting. In the VIADDDecode routine we have a choice either to use libddmpeg.so or to use the tiny code by Andreas Robinson that manipulates the registers directly. I'll start with that one, since it seems very simple and easy to understand, and in the end we will be free of additional kernel dependencies.

    From this, making plugins for mplayer / xine etc will be straightforward, and also one will be able to run as normal user having access to a nice movable and scalable window.

    Unresolved issues: Subtitles / Navigation menues?
    I'm not sure as to where in process these should be added.

    Comments / suggestions will be appreciated.

    /Thomas

     
    • Terry Barnaby

      Terry Barnaby - 2004-02-20

      Hi,

      Yes, I think the best way to implement hardware MPEG decoding is in the XServer. I have been thinking this way for some time. (It would be nice to have a simple X-Terminal interface with MPEG display !).

      I did see some where a Xv extension, I think like XvMC that implemented this, although it seemed a bit young in development. I could dig out this info if it would be of help ....

       
    • Thomas Hellström

      That would be great.
      Even if the very first implementation is done like above as a proof of concept because the Xv code change will be minimal, it would be good to see if there is a more mature way of doing this and also in the purpose of supporting a new standard evolving.

      /Thomas

       
    • Terry Barnaby

      Terry Barnaby - 2004-02-21

      I've just had a quick look at the XvMC extension and it seems
      that this has been extended to support the IDCT level of MPEG2
      decoding. So is it just a case of implementing the XvMC extension in the driver (my MPEG knowledge is limited) ?

       
    • Thomas Hellström

      Thanks, Terry, I will have a look into that. I'm totally new to Xv and mpeg myself, although I had a quick scan through the Xv code in the via driver.

      Meanwhile, since we've got a new devel list, I'll move this discussion over there!

      Thanks..
      /Thomas

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks