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@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-cvslog