[MPlayer-users] (S)MP hack(s) for mplayer

[Arpi]

Hi,

> > Not (yet).
> > We're working on libvo2 design, which will replaces current libvo.
> > Btw if it really helps on SMP, i'll make libvo2 to allow blitting (copy)
> > in different process to utilize second cpu.
> Yes, I think this helps - this is the way how the vo_fbdev is hacked.
> Maybe also YUV->RGB conversion should be redirected to second thread.
> Conversion could be done indepedently on blit time -> less memory as there
> is no need
> for big buffers, just only one fullsize for actual frame to display and 1 or
> 2 smaller (YUV).
for whole frames - yes.
but for mpeg 1/2 decoder, it blits by slices. it speeds up things a lot by
better cache utilization.

btw teh best and fastest way is hadrware blitting - i mean busmaster dma.
a few Xv driver already support it.

> Question about MJPEG
> 
> I would like to try write MJPEG (means hw mjpeg decoding via v4l) module for
> mplayer.
> This could be done in two ways as video decoder or video out driver.
> I prefer second way, but this requires some type of null=bypass decoder
> module, which
> simply passses through frame to videooutdriver - is there a such one (I
> assume null decoder does nothing
> - will not serve me data).
i also prefer vo driver. check vo_mpegpes, it does the same, but for mpeg
1/2 video (hardware decoeder). don't get confused, it also contains software
encoding, for non-mpeg source (YV12).

> Second problem is that playing via hw mjpeg is normally video
> synchronised -> I must specify framerate
> and is good to serve more than one frame. I must check this.
yes. it is my problem with mpegpes too. mplayer currently adjust video
timing to audio, while hardware decoders needs the inverse.
i'll workaround using the hardware decoder card for audio playback too.

> Are You interested in this vo driver?
yes


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu