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

[Nick Kurshev]

Hello, Arpi!

On Thu, 14 Feb 2002 20:38:02 +0100 you wrote:

> 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!
[snip]
> - 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 ;)
IMHO, you've missed video buffer type!
> - we shouldn't lost the ability of using slices
> 
IMHO - it's codec depended.

> 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.

> { 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 problems.
> 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?
>      - 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 updates
> (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).
> changes to libvo are in range zero .. minimal.
> changes to dec_video are big, but we can't avoid that, we should move codecs
> to libmpcodecs anyway, things get ugly and messy there already.
> 
> accepting the above structural change, we should design libmpcodecs API.
> 
> yes, it's a big work, but can be done step-by-step, while keeping the whole
> stuff still working.
> 
Yes

> what do you think?
> comments welcomed, but i want to note, i'm thinking about the above change
> for long time already, but the version described above is the first (and
> maybe the only) easy but working solution for all of the problems.
> 
> we should handle very different behaviour of various libvo drivers, demuxers
> and codecs, and find the best connection betweehn them while reducing
> redundancy and increasing modularity.
> 
Good planes for a non immediate future ;)
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


Best regards! Nick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020215/83287e0a/attachment.pgp>