Re: [Unichrome-users] initialisation problem of XV output...

[<uni...@sh...>]

Jamie Lokier wrote:

>Thomas Hellstr=F6m wrote:
> =20
>
>>   Yes it is. CLE266 supports mpeg2 acceleration of all "XvMC"
>>   levels: Motion compensation, IDCT (and VLD).  But libviaXvMC
>>   currently only supports VLD.
>>   =20
>>
>
>Would it be difficult to suport IDCT and MOCO modes in addition to VLD?
>
>It would be great if existing media players could take advantage of
>libviaXvMC without having to add extra code to handle the VLD case -
>and then using VLD becomes a desirable optimisation, rather than a
>necessity.
>
> =20
>
I have the docs, which aren't exactly very clear but no code examples, wh=
ich
means that once it works for I-pictures (which do not need motion
compensation) I would have to send out an incomplete version with API's h=
ow
to program the motion vectors and everybody interested would have to help
in a big trial-and-error operation.

It's also a matter of priorities.

You would probably have to expect much less performance gain with MOCOMP
and IDCT, though.

>>   KM400 has only Motion compensation, as far as I can tell. There
>>   is still a potential gain with this, however, since motion
>>   compensation data can be transferred over the AGP bus using DMA.
>>   Otherwise PCI transfers of images imposes a hefty 15% cpu-time
>>   overhead on the KM400, which does not share it's memory with the
>>   processor other than over the PCI bus.
>>   =20
>>
>
>Why can't image transfers be done over AGP?
>
> =20
>
Lack of docs. AGP DMA info is not released by VIA even under NDA.

>>   My guess is that CN400 has the roughly same mpeg2 accelerator as
>>   CLE266, but only a motion compensation or IDCT mpeg4
>>   acceleration. One of the reasons is probably the many different
>>   flavours of mpeg4 formats and codecs out there. Still, IDCT +
>>   motion compensation should probably be a big gain.
>>   =20
>>
>
>If anybody adds MOCO or IDCT XvMC support to the MPEG-4 media players
>(including the very popular divx and xvid formats), this is another
>reason why it would be good if libviaXvMC supported it on the CLE266.
>
> =20
>
VIA has added support to ffmpeg for their VeXP player. This should be
easy to modify to something MOCOMP / IDCT - XvMC like.

>>   It's interesting to note, however, that for raw mpeg2 decoding,
>>   libmpeg2 in its latest version is almost as fast on my M10KN as
>>   the hardware decoder.
>>   =20
>>
>
>Interesting - on my 766MHz VIA Eden board with a CLE266 (quite similar
>to your M10KN), I see 80% CPU utilisation when playing MPEG-2 files in
>software with the latest version of mplayer.  Curiously, I see 40-60%
>when playing divx or xvid files!  (These are both using Xv.)
>
>Are you saying that libmpeg2 has improved significantly on this?
> =20
>
Yes. mplayer (using ffmpeg) is significantly slower that xine, that uses=20
an old
version of libmpeg2. (This is for software decoding).

Do download and try "mpeg2dec" (the libmpeg2 reference player) with
the null output device, and observe the frame rate.

Do expect that an Eden 766 to be considerably slower than a C3 Nehemiah=20
M10K,
though

> =20
>
>>   Subtitle blending and image
>>   transfer will probably make it
>>   slower in a real player application, though.
>>   =20
>>
>
>Isn't it possible to use the overlay hardware to do subtitle blending?
>I have read the CLE266 is capable of 8-bit alpha channel overlay.
>
>Perhaps the current X architecture makes this too difficult to use?
>If so, perhaps the RENDER extension - the one which is supposed to
>make translucent windows hardware accelerated - would provide a
>suitable architecture to use the hardware alpha channel?
> =20
>
My understanding of the Alpha channel is that it is used for the=20
standard video overlay
instead of colorkeying. No support in X for this yet, though.

There is a possibility to blend subpictures in hardware and XvMC uses=20
this, but it is limited
to a 16 color palette and the YV12 video format. Still, no support for=20
this in standard X.

> =20
>
>>Being as unknowledgeable as always on these matters, this page, to me,
>>suggests that the cn400 mpeg2 decoder has just about the same
>>functionality as the mpeg2 decoder on the cle266 (even though it
>>probably has some implementational differences). If "mpeg-4
>>acceleration" is only motion compensation, then the CN400 looks pretty
>>pale and the marketing becomes seriously overstated. Or is this "mpeg-4
>>acceleration" actually more than that?
>>   =20
>>
>
>I think at least one chipset offers advanced de-interpolation as well,
>although I'm not sure which one or if it is any of these.
>
> =20
>
CN400 has an advanced de-interlacer. Via's 40047 lite souce contains=20
examples on how
to program it.

>-- Jamie
> =20
>
/Thomas