Keresés

Új hozzászólás Aktív témák

  • julius666

    addikt

    válasz floatr #138 üzenetére

    Videó kódolásnál teljesen más paraméterekkel használja többnyire ugyanazt az algoritmust, mint állókép készítésénél, mivel ott a sebesség a legnagyobb prioritású. De neki nem is az volt a célja, hogy igazán összehasonlítsa, csak talált egy pontot, ahol szerinte jól belekötött.

    A --best beállítás libvpx-nél a maximum minőség, amit ki lehet hozni a tömörítő algoritmusból. Gyakorlatilag "kompromisszumok nélküli". Olyan lassú is mint az állat, próbáltam már.

    És a csóka mint írtam, elég jól ismeri a formátumot, az ffvp8 kódjának egy jelentős részét ő írta. Így még talán annyira részrehajlással sem lehet megvádolni. Nem mellesleg le is írta a rossz minőség okát. Lehet hogy idealista vagyok, de nekem ez így egyáltalán nem tűnik belekötésnek.

    közben WonderCSabo megelőzött. :P

  • julius666

    addikt

    válasz ddekany #135 üzenetére

    http://webkit.org/blog/181/css-masks/

    Persze ez még baromira nem támogatott, ha nem tévedek csak a webkit tudja jelenleg.
    De nem mintha a WebP-vel nem ugyanígy lenne.

  • julius666

    addikt

    válasz ddekany #128 üzenetére

    Designelemekre gondoltam, nem összetett ábrákra. Komolyabb grafikus dolgokra ott az svg illetve a png, logókat veszteségesbe menteni azért elég ótvar dolog.
    A veszteséges tömörítést elsősorban az összetettebb, nem "rajzolt" (fotók, 3D-s renderek) képekhez használják, ahol a veszteségmentes png gyenge eredményt ad. Oda meg nem igazán kell transparency.

  • julius666

    addikt

    válasz WonderCSabo #125 üzenetére

    lesz az a tömörítés jobb, amint elkezdenek a guglinál PSNR helyett valami normális pszichovizuális modellre optimalizálni a VP8 esetén. Csakhogy olyan 30%-nál kétlem hogy sokkal többet javulna a JPEG-hez képest, az meg szvsz kevés egy ennyire bejáratott formátum leváltásához.

    Az átlátszóság önmagában annyira nem nagy fegyvertény, ahol szükség van rá (designelemek), ott általában a veszteséges tömörítés nem igazán játszik. Illetve ezek egyre inkább megoldhatóak css-ből, ahogy floatr is említette.

  • julius666

    addikt

    válasz floatr #122 üzenetére

    Most a gugli -- gondolom a vp8 keyframe tömörítésének algoritmusa alapján -- kreált egy állóképes tömörítéses formátumot. Nem tudom hogy hogyan lehetne bármiféle összevetést végezni egy tesztvideóból kiragadott frame (még ha keyframe is) alapján jelen cikk esetében, amikor is a letömörített kép létrehozásánál egy teljesen más minőségi rátát használtak, alkalmazkodva a JPEG minőségéhez.

    A cucc lényegében vp8 keyframe-be tömörít. A lényeg, hogy csak egy I-framet csinál, és ez lesz a kép. Ugyanez könnyen megtehető H264-el is, így van jogalapja az összehasonlításnak. Mindamellett egy JPEG-gel is összehasonlítja a linkelt blogbejegyzés, és pszichovizuális minőségben veri a WebP-t.

    Másrészt meg hogy a fenébe ne mutatna előnyt, amikor átlagjózsi szemmel nem mérhető minőségváltozás mellett lényeges méretbeli különbségek mutatkoznak.

    Ez az ami nem igaz, pont erről papolunk WonderCSabo-val. Egyazon fileméret mellett jelenleg sz*rabb a WebP a JPEG-nél, de jelentősen - amit esetleg átlagjózsi is észrevenne - valószínűleg sohasem lesz jobb.

    Arról nem is beszélve, hogy ettől egy kicsit többet is terveznek, a már említett PNG-szerű funkciókkal bővítve.

    Link?

  • julius666

    addikt

    válasz L3zl13 #109 üzenetére

    Másrészt a mov->mp4 az nem átkonvertálás, csak a konténer formátum más, szóval itt meg nincs minőségromlás.

    Az attól függ, mit akarsz.
    A videómegosztók átkonvertálják.

  • julius666

    addikt

    válasz Sanya #104 üzenetére

    Na szóval a cikk leírja, hogy a neten található dolgoknak kb 65%-a kép

    De az adatforgalomban a videók mellett egyre inkább eltörpül, nem a képforgalom miatt fő a hálózatok üzemeltetőinek a feje.

    mi lenne, ha ezt lehetne egy másik veszteséges tömörítéssel tárolni? mi lenne, ha ez a veszteséges tömörítés 39%-ot tömörítene az egészen?

    Nagyon szép lenne, csakhogy a cucc nem tud ennyit, sőt, gyakorlatilag rosszabb mint az elődje (legalábbis jelenleg).

    ha elterjed a neten, ha átkonvertálják, akkor minden megoldval, kb 2 évig nem kell tárhelyet bővíteni.

    OMG, ezt a marhaságot honnan szedted?

    hány fényképező vesz fel mov-ba videót?
    szinte az összes? hány mov kiterjesztésű videót találsz a neten?
    mp4? gp3? flv? yutube formátumok ezek, mégis hány kamera tudja ezt? mégis, ha feltöltesz egy avit, vgy egy movot, csak nem átkonvertálja a google, anélkül, hogy ezt az átlag user megtenné?

    A videós piac nagyon széttöredezett, rengeteg szabvány van. Ennek isszuk is a levét az általad is említett átkonvertálgatósdival, illetve a gagyi minőséggel. Mindamellett ott is jellemzően egy irányba, a H264 mint über-szabvány irányába halad a piac, gyakorlatilag már minden normális, új eszköz abba rögzít. Tehát ott is kialakulóban van egy hasonló formátum (ott is a gugli kavarta meg a kakit a vp8-al).

    Képeknél majd' 20 évnyi eszközállományt, szoftvert, hardvert hajíthatnánk ki a WebP-re való átállással, mindezt pár százaléknyi potenciális ("majd egyszer" lehet fog tudni annyit alapon) plusz tömörítésért. Van olyan a földön akinek ez megéri? :F

  • julius666

    addikt

    válasz Bici #87 üzenetére

    - tényleg jobb legyen a tömörítés/minőség arány

    Már itt elbukott a dolog, mivel ez nem áll fent. De ha annyit is javítanak a vp8 enkóderen, hogy jobb legyen, a difi akkor sem lesz akkora bazi nagy, hogy érdemes lenne az átállással vacakolni. Ajánlom a WonderCSabo által linkelt képeket, nézd meg mennyit tud a H264 intra frame (ennél többet nem nagyon fognak kihozni a vp8-ból, ez kb egy felső korlát) vs a JPEG. Normálisabb JPEG jömörítővel (mert van), kicsit megnöveled a fileméretet és megkapod ugyanazt a minőséget. Pár kB-on meg nem hiszem hogy sokat szaroznának ilyen facebook, a videóforgalom mellett egyszerűen eltörpül.

    - legyen böngésző támogatás (IE-t kivéve szerintem tuti támogatni fogja minden elég hamar.)

    Ez ismételten csak a pofáraesést erősíti meg. Az IE9 ugye, ami majd csak most fog kijönni, nem támogatja. Mikor lesz következő IE, amelyikbe belekerülhetne a feature? 3 év múlva? Ráadásul akkor tuti még mindig nagy lesz majd a régi IE-k részesedése, pont mint most.
    Azt pedig te is tudod, az IE felhasználói bázis mennyire nem elhanyagolható.

  • julius666

    addikt

    Na akkor így kicsit megkésve én is hozzászólnék (elnézést az esetleges fogalmazási hibákért, de egy piálás után írom a hsz-t :B ):

    Ez eddig a google egyik legesélytelenebb kezdeményezése, egyszerűen nem is értem hogy hogyan juthatott eszükbe:

    1. A képformátum jelenleg minőség/fileméret szempontjából ROSSZABB mint a JPEG. Ha valaki nem hisz nekem, itt az x264 (illetve az ffvp8, thehát nem vádolható részlehajlással) fejlesztőjének az írása a témában: [link], de tessék kipróbálni, ne csak a b*zi marketinganyagokat nézegetni.

    2. Ami miatt (a minőség mellett) a JPEG elavultnak számíthatna (transparency, veszteségmentes tömöríthetőség hiánya), azt ugyanúgy NEM tudja a WebP sem. Sőt, gyakorlatilag kevesebbet tud, egy csomó, amúgy hasznos fícsör (pl a 4:4:4-es színtér támogatása) hiányzik.

    Most komolyan, mi a franc értelme lenne a váltásnak? Úgy, hogy ráadásul a JPEG egy univerzális formátum, amit tényleg minden, a kenyérpiritótól kezdve a nagymama pacemakerén át jóformán minden meg tud jeleníteni. De még ha esetleg jobb is lenne a tömörítési aránya mint a jpeg-nek (amire a jövőben a vp8 kodek fejlődése mellett azért lehet számítani), most őszintén: melyik az a honlap, aki WebP-ben fogja tárolni a képeit, mert emiatt 350 kB helyett csak 280 kB lesz átlagosan egy kép mérete, de cserébe a userek 80%-a nem fogja tudni megnyitni?
    Ráadásul úgy hogy mivel semmi nem készít WebP-be képet natívban, jó eséllyel egy JPEG-ből kéne WebP-be áttömöríteni, ami a LOL a köbön kategória... :U

    Ha ezt át tudja verni a gugli az iparban, akkor tényleg mindenre képes, holnap már kopogtat a terminátor az ajtón. :DDD

Új hozzászólás Aktív témák