[Mplayer-cvslog] CVS: main/DOCS tech-eng.txt,1.7,1.8 tech-hun.txt,1.5,1.6

[GEREOFFY]

Update of /cvsroot/mplayer/main/DOCS
In directory usw-pr-cvs1:/tmp/cvs-serv28502

Modified Files:
	tech-eng.txt tech-hun.txt 
Log Message:
libmpeg2 codec ctrl removed

Index: tech-eng.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech-eng.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** tech-eng.txt	2001/04/10 23:27:06	1.7
--- tech-eng.txt	2001/04/14 16:01:33	1.8
***************
*** 107,144 ****
  	 (see 2.)
  
- 5.a Codec controller: this is the greatest hack in the whole :)
- 	 The libmpeg2 is so unstable, that I can't believe it.
- 	 Of course I don't mean it's bullshit :) rather it only accepts
- 	 totally perfect, error-free streams. If it founds error, it
- 	 just segfaults ;) And don't start laughing, this is great this way,
- 	 from the view of speed it would be 50-100% slower if stuffed full with
- 	 verifications. That's why I solved it by running it in a separate
- 	 process, and if it dies, who cares, just start another.
- 	 However, a few things are needed for this:
- 	 - codec controller process: a separate process, which sleeps, but if
- 		 its child (the libmpeg2 process) dies, it quickly starts another.
- 		 So the MPlayer doesn't have to care about this, it just pumps the
- 		 compressed stuff into the child, which displays it.
- 	 - shmem: the compressed data, and the uncompressed frames are both
- 		 in shared memory, so all 3 processes (mplayer, codeccontrol,
- 		 libmpeg2 codec) sees 'em, so they can trade data fast.
- 	 - FIFO is used for the communication between them.
- 	 - If the child dies while decoding, the succesfully decoded data
- 		 isn't lost, it's inherited by the new child through the
- 		 shared mem! So only a little error can be seen in the video,
- 		 it won't disappear or turn green, as in the older versions.
- 
- 	 The disadvantage of this all is that since the libvo and libmpeg2
- 	 are closely related, the libvo needs to run in the same process as
- 	 the libmpeg2, in the one that keeps dying/reborning, and not in the
- 	 one that has the controlling process, the MPlayer. This causes a
- 	 lot of problems, mostly at the handling of events in the libvo window
- 	 (keypresses, etc). So there are miscellaneous workarounds, a lot of
- 	 FIFO, and trick which exploits that X doesn't care which process
- 	 queries its events.
- 
- 	 I'd like to solve this in the near future, and use the signal/longjmp
- 	 (this is a hack, too:)) method, developed on the mpeg2dec-devel list.
- 
  5. libvo: this displays the frame. There are 2 different output routines in it:
  
--- 107,110 ----

Index: tech-hun.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech-hun.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -r1.5 -r1.6
*** tech-hun.txt	2001/04/10 23:27:06	1.5
--- tech-hun.txt	2001/04/14 16:01:33	1.6
***************
*** 107,143 ****
  	 ezek pedig hivjak a megfelelo demuxert hogy megkapjak a tomoritett
  	 adatokat (lasd 2. pont).
- 	 
- 4.a codec controller: na ez a legnagypbb gány az egeszben :)
- 	 a libmpeg2 ugyanis annyira instabil hogy az mar hatareset.
- 	 persze ezt nem ugy kell erteni hogy szar :) hanem ugy, hogy csak
- 	 teljesen szabvanyos, hibatlan mpeg streamet eszik meg. ha hibat
- 	 talal, egyszeruen segfault ;)  es nem rohogni, ez nagyon jo igy,
- 	 teljesitmeny szempontbol 50-100%-al lasabb lenne ha teleraknak
- 	 ellenorzesekkel. ezert csinaltam azt a megoldast, hogy kulon
- 	 processzben futtatom, es ha elszall, hat kit izgat, majd inditok
- 	 egy masikat. ehhez azert kell par dolog:
- 	 - codec controller process: egy kulon processz, ami sleep-el, de
- 	   ha a gyereke (a libmpeg2 processz) meghal, akkor indit gyorsan
- 		 egy masikat. igy az mplayer-nek nem kell ezzel fogallkoznia, o
- 		 csak pumpalja a gyerekbe a tomoritett adatot az meg rakja kifele.
- 	 - shmem: a tomoritett adatok, es a kitomoritett framek is shared
- 	   memoryban vannak, tehat mind a 3 processz (mplayer, codeccontrol,
- 		 libmpeg2 codec) is latja. igy tudnak gyorsan adatot cserelni.
- 	 - a koztuk levo kommunikaciora meg FIFO van.
- 	 - valamint ha dekodolas kozben meghal a gyerek, az altala sikeresen
- 		 dekodolt adatok nem vesznek el, hanem a shmem-en keresztul oroklodik
- 		 az uj gyereknek! ezert max egy pici hiba latszik a kepen, nem tunik
- 		 el az egesz meg zoldul be, mint a regi verzioban.
- 	 hatranya ennek az egesznek, hogy a libvo-libmpeg2 szoros kapcsolodasa
- 	 miatt a libvo is abban a processzben kell fusson, amiben a libmpeg2,
- 	 tehat abban ami allandoan megdoglik-ujraszuletik, es nem abban amiben
- 	 a vezerlo processz, az mplayer fut. ez eleg sok gondot okozik, foleg
- 	 a libvo ablakban tortent esemenyek (billentyunyomas pl) kezelesekor.
- 	 erre mindenfele workaroundok vannak, FIFO-k minden mennyisegben, meg
- 	 trukk ami kihasznalja hogy az X-nek mind1 melyik processz kerdezi
- 	 le az Event-jeit.
- 	 
- 	 szeretnem a kozeljovoben ezt megszuntetni, es az mpeg2dec-devel
- 	 listan kidolgozott signal/longjmp (szinten gány :)) modszert hasznalni.
  
  5. libvo: ez vegzi a kep kirakasat. jelenleg 2 kulonbozo kepkirako
--- 107,110 ----
***************
*** 153,156 ****
  	 ezt hasznaljak a win32 codecek (divx,indeo stb).
  	 
- 
- 
--- 120,121 ----


_______________________________________________
Mplayer-cvslog mailing list
Mplayer-cvslog at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-cvslog