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

• #44 #79335424 törölt tag chris-v #43

  Új Válasz 2015-05-05 23:33:23 #44

  Ú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

  

  #79335424

  törölt tag

  válasz chris-v #43 üzenetére

  Annyira nem fontos, csak ha már van vkinek ilyen, akkor gondoltam, rákérdezek. Nincs konkrét tapasztalatom, csak logikusan végiggondolva azt gyanítom, hogy ez lehet a kamerák közötti nagy árkülönbség oka. Framen belül nem lehet hatékony tömörítést csinálni. Nézd meg egy azonos időtartamú, MJPEG videó méretét, egy h264 -gyel kódoltéhoz képest! Pedig már a jpeg is csúnyán veszteséges. Hatékony tömörítést csak úgy lehet csinálni, ha csak bizonyos időközönként használunk valós képinformációkat tartalmazó képkockákat, a többiben pedig csak az ezekhez viszonyított változásokat definiáljuk. Ez jó egy végfelhasználásra (megnézésre) kódoláshoz, de nyilván nem azért rögzítünk másodpercenként 1200 képkockát, hogy házivideón nézegessük. Utófeldolgozás szempontjából viszont jó lenne, ha minden képkocka valós képinfót tartalmazna. De ez óriási adatmennyiség és akkor még szóba sem került a jpeg helyett, a raw. Sztem nincs olyan külső interfész, amin ezt át lehetne préselni. Szvsz marad a ram -ba pufferelés. De 4GB ehhez nagyon kevés, márpedig 32biten ennyi a maximálisan megcímezhető memória. Tehát alap a 64bites rendszer, stb., stb. Így növekszik a minőséggel a kamera ára.

• #40 #79335424 törölt tag chris-v #39

  Új Válasz 2015-05-05 19:57:10 #40

  Ú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

  

  #79335424

  törölt tag

  válasz chris-v #39 üzenetére

  Rögtön rájöttem, mihelyst felfogtam, amit írtál. A raw a feldolgozás előtti, közvetlenül a szenzorból kiolvasott adat. Abban nem lehet semmilyen szoftveres tömörítés, hiszen épp ez a lényege.

• #38 #79335424 törölt tag chris-v #36

  Új Válasz 2015-05-05 19:35:52 #38

  Ú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

  

  #79335424

  törölt tag

  válasz chris-v #36 üzenetére

  Köszönöm! Sztem ez egy elég lényeges infó, ami kimaradt a cikkből. Pedsze, a hsz. -eket olvasva már nem csodálkozom ezen.
  Azt még elárulnád, hogy milyen egy frame -en belül tömörített raw? Mert elég ritka megoldás, mondhatni még nem hallottam ilyenről.

• #35 #79335424 törölt tag chris-v #33

  Új Válasz 2015-05-05 19:18:11 #35

  Ú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

  

  #79335424

  törölt tag

  válasz chris-v #33 üzenetére

  Hoppá! Te tudsz esetleg válaszolni az 1. hsz. -ben feltett kérdésre? Mik az exportált videó paraméterei?

• #1 #79335424 törölt tag

  Új Válasz 2015-05-04 17:58:42 #1

  Ú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

  

  #79335424

  törölt tag

  Az biztos, hogy ez nem az én árkategóriám. Egy kicsit kevésnek találom az infót a kimeneti fájl tulajdonságait illetően és ezzel kapcsolatban vmi nekem nem kerek. Ez nem házivideós célra való, fontos szempont kell legyen a feldolgozhatóság. Egy ilyen szintű kameráról én azt gondolnám, hogy raw -ban dolgozik, vagy legalább olyan formátumban, ami legfeljebb frame -en belüli tömörítést használ, GOP -on belülit nem. Vagy ez egy olyan h264, amiben minden kocka keyframe? Mert ha nem, akkor a GOP kulcskockái között nem valós képkockák vannak, hanem csak deltafame -ek, vagyis, a kulcskockákból számolt, viszonyított változásokat tartalmazók. Ráadásul a kódolás valósidejű, tehát nem lehet szó a záró kulcskockát is figyelembe vevő, kétirányú deltaframe -ekről. Ha a vágószoftver a deltaframe -ekből generál szerkeszthető képkockát, az újabb minőségvesztéssel jár. Hogy van ez a gyakorlatban ennél a kameránál?

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