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

• #520 DarkByte addikt PikkPukk #517

  Új Válasz 2008-08-24 10:45:34 #520

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  DarkByte

  addikt

  válasz PikkPukk #517 üzenetére

  Pont a lényeg nincs leírva, hogy hogyan is lesz a váltottsoros adásból korrekt progresszív (ami az LCD monitoron/tévén sem lesz csíkos)
  A fórum hozzászólások között ha megnézed pont ezt kérdeztem PPeter -től. Idézem: "A HDTV készülék a benne található jelfeldolgozó áramköröktől és paneltől függően alkalmaz mindenféle huncut eljárást az 1080i formátumok progresszív megjelenítésére. 1080i50 esetén például minden egyes félképet teljes képkockaként jelenít meg (természetesen ügyelve rá, hogy az egyes félképek sorai a megfelelő "helyre" kerüljenek függőlegesen, hogy ne ugráljon a kép), így valójában 50 fps progresszív képet állít elő belőle, de vannak olyan 100 Hz-es HDTV-k is, amelyek az így előállított 50 képkockát megduplázzák, megpróbálják megbecsülni az egyes mozzanatok közötti állapotot, így valójában 100 fps-t gyártanak az eredetileg 50 mozzanatot tároló 1080i50 képfolyamból. Gyártó- és típusfüggő és persze rengeteg hangzatos technológia eljárás segíti a plazma és LCD TV-ket ebben a feladatban." Ugyan ezt teszik nem mellesleg a PC-s TV tuner kártyák programjai is, ha 1080i -s adást nézel ezért nem vonalkás a kép (keress rá a bob deinterlace, motion compensated deinterlace szavakra, vagy javaslom a 100fps.com átolvasását ha rendelkezel egy kis angol tudással, elég szépen le vannak írva a lényeges dolgok amit interlace -elt PAL anyagokról tudni kell) Az ArcSoft dekóder például Bob deinterlace -eli az MPEG2 váltottsoros videókat míg valamilyen összeillesztést használ a félképekre a H.264 forrásoknál, legalább is a letölthető teszt anyagnál illetve saját tömörítéseknél nálam így viselkedik.

  S szerintem a progresszív kép kevesebb sávszélt igényel (ill. jobb képet ad ugyanakkora bitrate-n), mert ugyan az AVC/H264 video már nem JPEG alapú, de azért itt is számít(hat) (hatással lehet a tömörítés hatékonyságára) az, hogy az egymás mellett lévő képpontok (közeli képrészletek) mennyire egyformák (félképek esetén a sorok közötti különbség nagyobb lehet)
  Mivel már az MPEG-2 -ben is létezik interlace -elt kódolás valószínűleg ezt már régen megoldották a tervezők is. Nem tudom hogyan működik pontosan, de mivel a P és B referencia képkockák H.264 esetén már előre és hátra is hivatkozhatnak - akár több képen keresztül is - ezért gondolom hogy a páros és páratlan képkockákat ha kell tudja külön kezelni.

  Gondolom az kavar meg itt pár embert hogy úgy tűnhet a kodeknek a szétcsúszott egész képet kell tömörítenie (tehát ami "csíkos") pedig a kodek ezt félképekre bontva tömöríti és a dekódoláskor rakja össze (weave) 1080 váltott soros képpé, persze csak ha a kódoláskor tényleg interlace -elt beállításokkal tömörítették. Biztosan van különbség bitrate használatban, de kizártnak tartom a megabites különbségeket, elvégre ugyanannyi makróblokk van a felezett felbontású de dupla képkocka számú videóban mint a dupla felbontású de fele képkockaszámúban. Mindjárt írok a helyi szakiknak hogy nézzenek rá kicsit a topikra, hátha tudnak pontosítani.

  A színkódoláshoz: tudtommal minden MPEG kodek YV12 -es színkódolást használ, ezt valószínűleg nem akarták eldobni a H.264 készítésekor sem. De gondolom Te itt most a forrás minőségére gondoltál.

  Rick4: ugyanezt a linket raktam be ide én is. Viszont visszatérve a tölcsérekhez. Szerinted az 1080i -hez nem kellenek ugyanúgy a féltölcsérek ha már itt tartunk? Nekem továbbra is ugyanaz a véleményem hogy biztosan van ugyanazon minőség mellett különbség a bitsűrűségben, de ez maximum pár száz kilobit és nem megabitek. Lehet téged az kavar meg hogy az 1080p50 -el akarsz hasonlítani nem pedig az 1080i50 -et az 1080p25 -el. Mert 1080p50 -nél nyilvánvaló hogy legalább kétszer akkora sávszélre lenne szükség (ezért nem is terjed).

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