No subject

X B-frame continiously.

> as examples, consider a couple scenes from the matrix divx. zooming
> through the 0 at the very beginning and the helicopter explosion scene
> were both too slow for my k6-2/450 to handle (without framedrop) until
> recently. since pretty much all the rest of the movie was a plenty
Matrix contain I,P-frames between B-frames anyway

> fast, buffering should have been able to fix this -- but buffering a
> measly 8 frames would have made no difference whatsoever; it would
> take at least a second worth of buffering or so.
> 
> the second moral of this example is that the problem *was fixed* in
> the correct way: optimizing the codec and other parts of mplayer. and
> this is still without direct rendering.
> 
Why you need direct rendering?
Direct rendering is usefull for current mplayer.
If I wil be able to finish my idea there will be direct rendering too
but only through fastmemcpy already decoded frames in memory.
> the biggest key to performance at this point is getting direct
> rendering working with libavcodec (and other codecs) and other video
> out modules (mga, xmga) as opposed to just vidix. buffering may be
> able to help, but only at the expense of tons of memory.
You are wrong! Direct rendering can't be imlemented anywere except vidix.
But it already works with all working drivers.
What about libavcodec - it requires to be rewritten to implement
direct rendering with its codecs.
And even in this case I don't get 50% of speedup.
> 
> finally, i would like to point out that some of the remarks and terms
> in your original post on this matter just sounded idiotic. "FIFO
> technology"? since when is a fifo technology? "Fortunately, linux
> support real-priority timer's callback."? as many other people have
> pointed out, this is probably a super brain-damaged way of doing
> things. there's no need for it. i'm not even sure exactly what you
> mean by that, but if you're talking about some kinda realtime
> scheduling (which would need root), thats even stupider. and last but
> not least, as i pointed out to begin with, "PLUSES: Direct rendering
> will be die :)" is the ultimate accomplishment of crack smoking.
> direct rendering is a huge performance benefit. with write combining
direct rendering gives only 10-20% of speedup. Where you found out "huge"?

> and agp 4x, the actual writes themselves are a ton faster than writes
> to system memory, and can be carried out in parallel with system
Try learn this question from some technical sources first
> memory access. that doesn't even begin to factor in the fact that,
> without direct rendering, there's a whole extra copy operation to
> perform! granted there are some issues with direct rendering (slow
> reads from video memory and the like), and it may not be a good
> solution for every codec out there, but it is nonetheless huge.
> 
> is that enough already??
> 
Yes! I even don't to discuss that anymore. You didn't imagine self
idea but already velify it.
> rich
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


Best regards! Nick

--cW'x1'h'aLZCit=.
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE8eziIB/1cNcrTvJkRAsMKAKDQhH3Vhl9oK8vRUZKjINsoJVhYrgCfaYbG
YIQeMIZWdQuH3JcECuRb4xk=
=bbwN
-----END PGP SIGNATURE-----

--cW'x1'h'aLZCit=.--