[MPlayer-dev-eng] DECODING AHEAD - (Initialy Michael's idea)

[Nick Kurshev]

Hello, Arpi!

On Mon, 25 Feb 2002 13:18:35 +0100 you wrote:

> Hi,
> 
[snip]
> 
> > > > So Arpi should decide which way he preferes for mplayer in the future.
> > > > Maybe after release? Or maybe in the forked branch?
> > > fork. it is not a question.
> > > as you said, it needs big rewrite of a-v sync, libvo, decoding and so on.
> > libvo doesn't require rewritting in this case
> why?
> 
Why it should be rewritten?
My idea is very simplest:
1. mplayer will have allocated X buffers in memory
2. after decoding of first frame dec_video will decode next
frame into memory sh_video->our_buffer = buffer_list[i+1];
3. On each timer event our procedure will draw buffer_list[next]
through call of old good libvo->draw_slice().
No threads! Just async timer callback through signal() technique.
> > > and probably never will work with X drivers, as X doesn't like calling fro
> > m
> > > interrupts.
> > Arpi, I have working stuff with timer callback even under WinNT, so X11
> > is not a problem a long ago. It works already 2 year without even hints on p
> > roblems!
> > And it on glibc level - not on X11 one. So don't mix please linux-kernel
> > and X11 as application.
> 
> X11 is not threadsafe. if an X call is interrupted and from the interrupt
> (signal handler) you call another X11 functon, you'll get async i/o reply and
> X11 hangup. it happened also in mplayer GUI before i moved update function
> from timer interrupt (sigalarm handler) to mainloop.
What about disable/enable timer's callback for critical code?
(Full analog of sti/cli)
> 
> i don't know about Win NT, but hey, we 're under linux, so who cares???
> 
my code works under a lot of OSes without any problems, but under Linux
it works better (realtimely) than under NT.

> > > > Anyway, it should be mplayer2, imho.
> > > aviplay2 :)
> > > 
> > > just a note: fps is not constant. rtfs libmpdemux/video.c
> > > there are lots of problems come with "your" idea.
> > > 
> > But other developers have successfuly solved them!
> Yes. But they have different core design. They have threaded players.
> 
No threads as I said, just:
disable_timer()
libvo->draw_slice()
enable_timer()
disable/enable timer will be our routines which will check flags
and support call counter.
[snip]
> > mplayer has interruptible playback in many cases and it's bad.
> > We spend a lot of our time to speedup it but it loses frames as before
> > unlike MS-MediaPlayer8. (Which provides SMOOTH playback of MPEG4 movies
> > on Cel1-266 where mplayer provides the same interruptible playback)
> because of it does direct rendering.
> 
because it does decoding ahead first and direct rendering second!

> > Currently we can solve that and make it by perfect player even on slow
> > machines but you are against of this idea.
> yes
> 
> > Do you have also any reasonable arguments (except - this brings problems
> > and similar)?
> a-v sync won't work as now, it have to be redesigned to ger rid of variable
> fps and its delay
> X11 reentrancy should be solved (threaded player? argh)
> direct rendering?
> 
> if you say it's easy, do it, but do not commit. send a patch, so it can be
> tested and if it's clean enough, it may be commited. anyway i doubt it will
> ever work without big ugly hacks (like your direct rendering) or rewrites.
> 
what about --enable-xp in configure? and #ifdefed code?
Anyway, it would be easy to implement with working libmpcodec stuff!
> 
> A'rpi / Astral & ESP-team
> 


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/20020225/f04ffb8f/attachment.pgp>