[MPlayer-dev-eng] libmpcodecs vs. filter layer

[Arpi]

Hi,

> > Problems given:
> > - we should move codecs to libmpcodecs, something similar to libao/vo
> > modular api
> If you mean splitting of dec_video.c then it's good idea!
yes

> > - we should implement direct rendering (supporting static, temp and mixed
> > (2*static+1*temp) buffer types)
> temp - imho it's case when buffer is located in RAM, isn't?
> Then such "direct rendering" exists in every player ;)

nope
static mean buffer which 'remember the content' so if only a part of the
image changes at next frame it's enough to update just that part.
temp buffer mean it don't have to keep its content, can be changed or moved
in memory at every frame. it can be altered by osd, postprocess and stuff.

> IMHO, you've missed video buffer type!
?

> > - we shouldn't lost the ability of using slices
> > 
> IMHO - it's codec depended.
yes
but we should make interface between codec and libvo, including optional
colorspace conversion and such stuff

> > current way of video decoding:
> > - open demuxer, it MUST provide image dimenstions
> > - init libvo
> > - init video codec, allocate decoder buffer
> video codec initizalization is before libvo init.
> Due that I can pass vo_tune info into libvo.
hmm

> > { for each frame:
> > - read frame from demuxer
> > - call video decoder
> > - call libvo draw_ function (sometimes made inside the codec)
> > }
> > 
> > it's simple, old, but bad, as it doesn't support solution of the above pro
> blems.
> > my today ideas about new way, including some talk with Ponstcho:
> > 
> > - open demuxer. it MAY provide image dimensions (and they MAY be wrong)
> > - init video codec, it should provide supported outfmt list
> > { for each frame:
> > - call video decoder, it will use callbacks for:
> >    - read frame from demuxer (should solve B frames problem)
> >    - call buffer allocation code -> this is the main point!
> >      this function will get requested buffer parameters (dimensions, type,
> >      stride restrictions) and should be handled by some common code.
> >      (we planned this into libvo2 core earlier).
> >      - if image parameters changed, then (re)init libvo (it's really
> >        config() now, as init is started erlier to get outfmt list)
> Do you have such movies with variable width,height?
concatenate 2 different mpeg files :)
anyway i mean files with bad or missing w/h values in file header.
it's often bad for quicktime files (they include display size into header
while the codec work on buffer size) and missing for vivo, multifile

> >      - allocate buffer. it may be handled by libvo (using control() if
> >        supported -> direct rendering) or by dec_video core (memalign()).
> >        it should return a surface struct, containing buffer addresses,
> >        selected stride, optional slice updating callback func, and so on.
> > }
> > 
> > with this (not so big to be never implemented) change we will be able to
> > solve many problems, and also implement direct rendering and partial updat
> es
> > (like draw_slice calls from libmpeg2)
> > 
> I've tried to hack of libavcodec for direct rendering but it seems
> that it requires rewritting many places (include location of forward frame
> "next_frame" and prev_frame in video_memory which will slowdown execution
> due READING from video memory).
yes

> Good planes for a non immediate future ;)
i will start working on it in very nera soon...
i need it for proper DV in quicktime and multifile support


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu