Mercurial > mplayer.hg

changeset 404:6b6650381723

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
libmpeg2 codec ctrl removed
author arpi_esp
date Sat, 14 Apr 2001 16:01:33 +0000
parents b42eed53b7be
children 0234b20ae147
files DOCS/tech/general.txt DOCS/tech/tech-hun.txt
diffstat 2 files changed, 0 insertions(+), 69 deletions(-) [+]
line wrap: on
line diff
--- a/DOCS/tech/general.txt	Sat Apr 14 15:47:12 2001 +0000
+++ b/DOCS/tech/general.txt	Sat Apr 14 16:01:33 2001 +0000
@@ -106,40 +106,6 @@
 	 And they call the appropriate demuxer, to get the compressed data.
 	 (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:
 
 5.a draw_slice(): this displays YV12 pictures (3 frames, a full sized which
--- a/DOCS/tech/tech-hun.txt	Sat Apr 14 15:47:12 2001 +0000
+++ b/DOCS/tech/tech-hun.txt	Sat Apr 14 16:01:33 2001 +0000
@@ -106,39 +106,6 @@
 	 kell lejatszani (lasd 3. pont elejen)
 	 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
    van benne:
@@ -152,5 +119,3 @@
    es csak packed formatumot (YUY2, RGB/BGR) tud.
 	 ezt hasznaljak a win32 codecek (divx,indeo stb).
 	 
-
-