- Mobil flották
- iPhone topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S24 - nos, Exynos
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- Apple iPhone 15 Pro Max - Attack on Titan
- Bemutatkozott a Moto G32 4G
- Xiaomi Mi 10T Pro - a házon belüli ellenfél
- Ezek a OnePlus 12 és 12R európai árai
Hirdetés
-
Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
ma Részletes anyag került fel az internetre a Sony idei középkategóriás telefonjáról, három helyett két hátlapi kamera várható.
-
Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
ph A vállalat ezért irgalmatlan pénzt fizetne a FIFA-nak, és ezzel rajzolná át az online streaming platformok háborújában a frontvonalakat.
-
Letartóztatták a bitcoin-Jézust
it Amerikai adókerülés vádjával, Spanyolországban tartóztatták le a bitcoin-Jézusként ismert Roger Vert.
Új hozzászólás Aktív témák
-
#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?
-
#79335424
törölt tag
-
#79335424
törölt tag
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.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest