From aa9517f18a139f5522eeff756c8aaa93bda28550 Mon Sep 17 00:00:00 2001 From: arpi_esp Date: Sat, 14 Apr 2001 16:01:33 +0000 Subject: libmpeg2 codec ctrl removed git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@405 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/general.txt | 34 ---------------------------------- DOCS/tech/tech-hun.txt | 35 ----------------------------------- 2 files changed, 69 deletions(-) diff --git a/DOCS/tech/general.txt b/DOCS/tech/general.txt index a6bcafa309..c434942285 100644 --- a/DOCS/tech/general.txt +++ b/DOCS/tech/general.txt @@ -106,40 +106,6 @@ Now, go on: 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 diff --git a/DOCS/tech/tech-hun.txt b/DOCS/tech/tech-hun.txt index 0fa7c23067..4fb2f5f539 100644 --- a/DOCS/tech/tech-hun.txt +++ b/DOCS/tech/tech-hun.txt @@ -106,39 +106,6 @@ na nezzuk tovabb: 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 @@ na nezzuk tovabb: es csak packed formatumot (YUY2, RGB/BGR) tud. ezt hasznaljak a win32 codecek (divx,indeo stb). - - -- cgit v1.2.3