Új hozzászólás Aktív témák
-
gyulank
addikt
Miért nincs vektorgrafikus videóformátum? A mai rajzfilmek többségét úgy is olyan képek alkotják. Lehetne vegyes is, mert pl. ahol totál feketeség van, az sokkal egyszerűbb lenne. Most megszenved a konvertálás egy akármilyen felbontású feketeségért is, pedig csak fekete kéne valamennyi ideig.
-
#52
#57638400
törölt tag
kameraman77
#32
#57638400
törölt tag
válasz
kameraman77
#32
üzenetére
"... az illegális tolvaj oldalak szerepe a lopott filmekkel - magyarul torrent ..."
A torrent nem illegális tartalmat, meg kalózokat jelent, hanem ezt. Az egy dolog, hogy illegális tartalmak megosztására is használják - a Tort sem azért találták ki, hogy illegális kereskedelem folyjon rajta. Tudom, hogy ez most nem erről szól, meg a kommented sem, de nem szeretem, hogy a legtöbben azt gondolják, hogy torrent = kalózkodás, illegális tartalom.
-
#51
quarros
tag
attila9988
#50
quarros
tag
válasz
attila9988
#50
üzenetére
Olyat olvasol bele ami nincs ott. Egy percig sem állítottam hogy a szarabb kód a jobb megoldás. Csak azt hogy nyílt jóval munkásabb nehezebb hosszabb fejlesztési idejű. De ezért cserébe jobb terméket kapsz.
Egyrészt kevered a titkosító eljárás kidolgozásának, és az implementáció megírásának kérdéskörét
Kérlek ezt fejtsd ki. Én mindig szívesen veszem ha értelmesen rávilágítanak hogy hol tévedek és hasonlóan értelmesen megmagyarázzák.
-
#50
attila9988
őstag
quarros
#48
attila9988
őstag
Tudom hogy röhejesen hangzik de igen nehezebb, időigényesebb. Mivel a folyamatos széleskörű auditálás nem enged annyi hibát keresztül.
Egyrészt kevered a titkosító eljárás kidolgozásának, és az implementáció megírásának kérdéskörét, másrészt pedig, ha programozásról van szó, akkor álláspontod szerint a "gyorsabban írhatunk szarabbat" a jó, és követendő megoldás, egy széleskörű terjesztésre szánt megoldás esetében? Most komolyan?
-
Azt azért viszont áruld el kérlek hogy arányosan kulcsméret növekedésével százalékosan mekkora plusz teherről beszélünk?
Kulcsméret bitben van megadva, elméletben bitenként duplázódik a számítási igény. Gyakorlatban a számítási igény a kulcs entrópiájától függ. Random kulcs esetén az entrópia a véletlenszámgenerátor entrópiája (jó esetben közelít a kulcsmérethez). Humán kulcs esetén viszont ez jóval kisebb. Pl egy 8 karakteres véletlen jelszó entrópiája 64 bit. Egy 8 karakteres kisbetű + kötelező nagybetű és szám entrópiája maximum 51 bit. Csak kisbetű és legalább egy szám esetén pedig csak maximum 45 bit.
Mivel bitenként duplázódik a számítási igény, ezért a random és a komlex között 2^13 (8 192-szeres) a különbség, míg a kevésbé komlex esetében már 2^19 (524 288-szoros) - félmilliószorosával, 52 428 800%-al erősebb a random, mint az ember. -
quarros
tag
Oké ez a te álláspontod elfogadom.
"azért nehezebb titkosítást csinálni, mert nem tartalmazhat titkosítást gyengítő kódot???"
Tudom hogy röhejesen hangzik de igen nehezebb, időigényesebb. Mivel a folyamatos széleskörű auditálás nem enged annyi hibát keresztül. Ezért a végtermék minősége magasabb mint zárt-kódú társainak de az oda vezető út is jóval rögösebb.
-
-
quarros
tag
"Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". ": ez nemcsak, hogy marhaság, de még önellentmondásos is.
Kérlek legyél kifejtőbb erre így nem tudok reagálni.
"ez meg egy terelés, féligazság. nem az a kérdés, hogy a jogosult dekódolás számítási igénye mennyi, hanem az, hogy az illegális dekódolási kísérlet mekkora számítási igénnyel vihető végbe."
Hát izé azt mondod hogy én terelek... Jó megkérdem ez a szabvány kinek is készülne vagy pontosabban milyen céllal? Mert abból amit mondasz úgy tűnik hogy elsődleges a Hackerek számítási teljesítménye és az ö ellehetetlenítésük. Viszont másodlagos a célszemély tabletének telefonjának számítási teljesítménye (csak feldobtam mint célplatformot) amin a videotartalom lejátszásra kerül... Hmm?? (Someting not compute)
De legyen mivel nem rendelkezem mért adatokkal ezen a téren ezért elfogadom amit mondtál. Azt azért viszont áruld el kérlek hogy arányosan kulcsméret növekedésével százalékosan mekkora plusz teherről beszélünk?
-
Az a legjobb, hogy minden résztvevő mást vár a projekttől
42# Titkosítást miért is akartnak megvalósítani? Amúgy azért nő a számítási igény a titkosítás mértékével, mert a bruteforce ellen jelenleg (az extrém hosszú kódhosszon kívül) csak a nagy számítási kapacitás és a nehéz párhuzamosíthatóság az egyetlen bevált módszer.
Amúgy az AES-sel semmi gond nincs online titkosítás esetén. SSL/TLS esetén disztributált (pl. DH) AES kulccsal kommunikálnak a felek ([link]).
-
bambano
titán
"Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". ": ez nemcsak, hogy marhaság, de még önellentmondásos is.
"Minél biztonságosabb titkosítást akarnak megvalósítani azzal arányosan nőni fog a szükséges számítási igény is!": ez meg egy terelés, féligazság. nem az a kérdés, hogy a jogosult dekódolás számítási igénye mennyi, hanem az, hogy az illegális dekódolási kísérlet mekkora számítási igénnyel vihető végbe. ilyen a pgp is, ha tudod a kulcsokat, akkor nagyjából mindegy, hogy mekkora kulcsokkal dolgozol, mert nem nő vészesen a számítási igény a kulcs méretével, ha meg nem tudod, akkor peched van, mert sosem töröd fel.
-
#42
quarros
tag
attila9988
#33
quarros
tag
válasz
attila9988
#33
üzenetére
Ez kezd fárasztó lenni hogy kibogozzam mit is szeretnél mondani ezért engedd meg kérlek hogy leegyszerűsítsem...
Jelentősen Nehezebb nyílt forráskódon titkosítást létrehozni mivel a kód a nyilvános auditálás miatt, egy részében sem tartalmazhat "gyengébb kódot". Egyetért / Nemért egyet
"Az aes -t is ismerheted, ha akarod... na és? Küldök egy állományt, és törd fel nekem... a titkosító program forráskódjával együtt megkaphatod... na? Vállalod?"
Komolyan srácok mi ez a személyeskedési hullám??? Először is az AES egy remek megoldás amikor a saját gépeden egy állományt akarsz titkosítani mert ott minden kulcs lokális. Nehezen törhető, mivel minimálisan is 128 bites kulcs titkosít! De nem is igazán arra van kitalálva hogy egy online streaming szolgáltatásnál több szereplő (peer) esetén alkalmazni lehessen. Minden kriptográfiai eljárásnak az növeli leginkább a megvalósítási nehézségét minél több peer között kell hogy mozogjon az adat, és az csak hab a tortán hogy a kézfogás online valósul meg.
De ha ez még nem lenne elég fejfájás. Akkor ott van a másik probléma amiről még nem beszéltünk (mert őszintén nem hittem hogy kelleni fog). Minél biztonságosabb titkosítást akarnak megvalósítani azzal arányosan nőni fog a szükséges számítási igény is! Ezért egy külön tortúra lesz annak a kibalanszozása hogy mennyi extra terhelés az ami még elfogadható...
Mindezek figyelembevételével mondtam azt amit mondtam. Tehát ha nem értetek egyet azzal hogy ezek meglehetősen megfogják nehezíteni ennek az új szabványnak a megvalósítását, akkor tiszteletben tartom a véleményeteket. Viszont akkor tényleg semmi értelme itt koptatnom a billentyűzetet.
-
CPT.Pirk
Jómunkásember
Nekem is volt egy csomó ilyen felvételem, meg csak SD-ben létező filmem. Rászántam egy kis időt, mindet átkódoltam x264-be, így jó pár giga tárhelyet nyertem azonos képminőség mellett.
Kaeraman77-et nem igazán értem. Ma már az a ciki, ha valami nem játszik x264-es mkv-t. Hála az égnek az nCore-on is kitiltották az xvidet.
-
#40
bambano
titán
kameraman77
#32
bambano
titán
válasz
kameraman77
#32
üzenetére
"Viszont az Xvid-et egy 233-as proci is megeszi, lényegében minden támogatja. Én itthon a házi videóimat próbáltam mindennel VHS-ről...": hát ja, az ócska félsd 325 soros vhs forrásodat valószínűleg tényleg jobban eszi az xvid.
próbáltad már egy rendes, 1080p-s anyaggal ugyanezt?
az emberek többsége nem akar encode-olni, tehát a kódolás erőforrásigénye senkit nem zár ki semmiből (vagyis csak pár embert). a dekódolás meg már a málnán is hardverből megy, és mindenki boldog, pedig az aztán egy gyenge cucc.
-
#38
Fred23
nagyúr
kameraman77
#32
válasz
kameraman77
#32
üzenetére
Haladni kell a korral! Mire ebbôl lesz valami, egy Atom IGP-je is 500 GFLOPS körül lesz ( +2 generáció ), és a 4 vagy több mag is 3 GHz felett járhat. Ez lesz a kis teljesítmény, amit majd az új kodek igényel.
-
#37
Kékes525
félisten
attila9988
#36
Kékes525
félisten
válasz
attila9988
#36
üzenetére
Már kitaláltak, csak kell hozzá egy kvantumszámítógép. A Kvantum titkosítás. kvantum titkosítás
-
#35
attila9988
őstag
kameraman77
#32
attila9988
őstag
válasz
kameraman77
#32
üzenetére
Az átlagos 4 magos cpu, az azt jelenti, hogy a 4 magos cpu -k bármelyike.
Hidd el nekem, egy core2quad -on, ami egy 2007 -es eresztés, azon is gyorsabb az x264 encoder, mint az xvid. Egyszerűen azért, mert 4 szálra képes bontani a feladatot, jó hatékonysággal, míg az xvid nem.
Ezt írtam fentebb, hogy hiába komplexebb h264 -et kódolni, mégis nagyobb sebességet érsz el, egy minimum négy magos, 8 évesnél nem régebbi cpu -val.Ma pedig, amikor már a létező leggagyibb mobil biztbaszok, és az összes létező vga, az 5000 ft -ostól kezdve, 5 - 10 éve rendelkezik hardware -es decoder -el, nem hinném hogy bárkinek is gond lenne a h264 lejátszása.
Akinek meg p1 233 -asa van, az nyilván nem is nagyon akar videót kódolni, semmilyent sem... Ha meg nézni akar, akkor meg a telefonjával is jobban jár, mint a p1 -el... tesco gazdaságos 40 ropis pc -t is vehet, és azon is tud majd h264 -et nézni, mert már jó ideje a procik mellé pakolt vga -k is tudják hardware -ből ezt a formátumot. De a tesco pc még software -ből is elég lenne a feladatra, a 8000 ft -os pentium cpu -val...
Szóval nem értem hogy mi a gondod pontosan. A hardware -es decoder -ek miatt, gyakorlatilag kevesebb lesz a terhelés, mint ha xvid -et néznél...
A h265 ideje még valóban nem jött el, és egyelőre csak skylake -el, vagy gtx 960/50 -el lehet gyorsítani a lejátszást, de 720p -ig még software -ből is le tudod játszani akármelyik pc -vel, ami (mint fentebb is írtam) nem régebbi 8 évnél.
Az x265 -el csak az a gond, hogy 10x nagyobb számítási kapacitás kell neki (nem lejátszásról van szó, encoder -ről... ), mint az x264 -nek, mert a h265 -ös szabvány sokkal komplexebb... és cserébe kb 40% -ot kapsz méretben, de ez is erősen felbontás függő. Bizonyos szint fölött pedig egyelőre a végletekig csiszolt x264 jobb eredményt produkál.....
-
#34
Kékes525
félisten
attila9988
#33
Kékes525
félisten
válasz
attila9988
#33
üzenetére
Kvantum számítógéppel ripsz-ropsz feltörhető.
Csak még nincs ami rendesen működne. 
-
#33
attila9988
őstag
quarros
#30
attila9988
őstag
Mert nem lehet elbújni a kód titkossága mögé
Éppen ez az, hogy nem is kell... Egy jól kitalált titkosítási eljárás esetén, teljesen mindegy, hogy te ismered -e a módszert, vagy sem. SŐT... mivel nem lehet maga az eljárás a megfejtés kulcsa (cézár kódtól azért már messze vagyunk... ) ezért minél többen látják azt, annál többen lesznek képesek megtalálni benne az esetleges problémás részeket. Az aes -t is ismerheted, ha akarod... na és? Küldök egy állományt, és törd fel nekem... a titkosító program forráskódjával együtt megkaphatod... na? Vállalod?
-
#32
kameraman77
tag
attila9988
#28
kameraman77
tag
válasz
attila9988
#28
üzenetére
Mi az, hogy átlagos négy magos cpu? Az nagyon nem átlagos...nagyon sok ember még pentiumon1-es, p2-esen, vagy dual core procis gépet hajt otthon! (esetleg core2duo-t) Így azon cs.szheted az h265-öt (meg az h264-et is bizonyos esetekben), el sem indul a legtöbb esetben az illegális film lejátszása. Főleg nem 720p, vagy afelett.
Viszont az Xvid-et egy 233-as proci is megeszi, lényegében minden támogatja. Én itthon a házi videóimat próbáltam mindennel VHS-ről... h265 (264-t is), és társai siralmas kompatibilitást mutattak amikor arra próbáltam váltani és újrakódolni a videókat VHS-ről ilyen formátummal, nagyon sok tv nem játszotta le őket USB-ről a családban, asztali lejátszók sem, a telefonokon sem remekelt.. viszont az XviD ment mindennel. És nem tartom magam balf.sznak, lényegében '97-óta kódolok házi videókat szóval végigjártam a VCD korszaktól mindent és minden buktatót, tehát nem arról van szó, hogy rosszul állítom be a kódoló programot.
Amióta felbomlottak az íratlan méretbeli szabványok értsd cd méret, két cd-nyi méret stb.. azóta méretről beszélni felesleges szerintem. Az adattárolás dinoszauruszai, mint én foglalkoznak még ilyennel, hiszen én mindent duplán DVD-re mentek winyó mellett... A házi videókat csak így tárolom. (sőt mind a mai napig 8 karakternél hosszabb fájlneveket sem alkalmazok! Soha nem lehet tudni! Meg "old habits die hard", a 80-as évek végén-90-es elején a pc korszakban megszokta az ember, úgy tanulta meg
)A gond az új formátummal az erőforrásigényben van. Ha csak nagyon erős gépekre lesz elérhető, akkor jelentős réteget zár ki a használatból - ergo a terjedés lassul. Persze itt jön be az illegális tolvaj oldalak szerepe a lopott filmekkel - magyarul torrent, hiszen megfelelő (illegális) anyagi ösztönzéssel a nagy cégek elérhetik, hogy ne fogadjanak be pl XviD állományokat, vagy más formátumokat, de az új formátumot igen, ezzel is növelve a terjedést... lássuk be ez így működik. Ha a vezető - világszintű és lokális helyi - oldalakat erre a cégek ráveszik, akkor a terjedés felgyorsulhat. - és vissza is üthet, mert megjelennek a downkódolt filmek a kisebb oldalakon pl Xvidben... így azok erősödnek, ezzel növelve a kalóz másolatok terjedését!
-
#30
quarros
tag
attila9988
#29
quarros
tag
válasz
attila9988
#29
üzenetére
Nem azt mondtam hogy lehetetlen sem azt hogy jobb ha kód titkos. Csupán annyit hogy a megvalósítás nehézségi szintje látványosan magasabb nyílt forráskód esetén. (Mert nem lehet elbújni a kód titkossága mögé egy silányabb minőségűvel arra bazírozva, hogy úgysem fejtik meg csak az adatfolyamból, hanem kénytelenek rendesen megírni). És egyet értek a kód minősége annál jobb minél több ember auditálja. Mind a mai napig a legjobb kriptográfiai programnak tartom a Truecrypt utolsó előtti változatát.
-
#29
attila9988
őstag
quarros
#24
-
#28
attila9988
őstag
kameraman77
#16
attila9988
őstag
válasz
kameraman77
#16
üzenetére
Az xvid, egy korábbi mpeg szabvány, részmegvalósítása, vagyis azon technológiák segítségével működő, pc -s codec. Sosem volt szabványos, de a nagy gyártók rácuppantak, és végül már mindenki támogatta. A divx meg a fene tudja, hogy maradt életben az üzletpolitikájával...
Viszont, ma már szinte értelmetlen használni, mert a codec -et egy szálra tervezték, és sosem fogják már átírni. Így lehet az, hogy egy átlagos 4 magos cpu -n, az x264, a komplikáltabb kódolási eljárás ellenére is, gyorsabb tud lenni, az eredmény minősége pedig, a h264 szabványnak megfelelő, és elég jó minőségű. Mivel szabványos lesz, ezért az ég világon minden lejátssza, pár régebbi dvd lejátszón kívül. Még a telefonokon is hardware -es decoder van, így nem zabálja az aksit...
Jelen pillanatban, a h264 a leghasználhatóbb formátum.
A videó tömörítés azonban mindig is a sávszél, és tárhely igényről szólt... és ha ezeket le lehet szorítani, akár 10x -es számítási kapacitásért cserébe, akkor meg is fogják tenni, mert megéri.... Ezért jött létre a h265 szabvány, és a vp9 codec is....
Ez pedig, végső soron mindenkinek csak jó... És újabb bizonyíték is egyben, hogy az opensource jól működő fejlesztési forma, a software -ek világában, amit mindenki tévesen, pár hobbi programozó játékszerének szokott gondolni...
-
#26
attila9988
őstag
atike
#6
attila9988
őstag
Az nem úgy megy ám, hogy akkor most két nap alatt összedobják a cuccot...
Már csak azért sem, mert rengeteg szabadalom közt kell lavírozni. A dct alapú codec -eket gyakorlatilag már körbe bástyázták, és jelenleg ez a leghatékonyabb megoldás. Mondjuk a vp9 -el sikerült olyan képfelbontási eljárást kidolgozni, ami úgy működik mint a h265, nem ütközik azokba a szabványokba...
Viszont, vélhetően ezek a nagy cégek most nem ilyet akarnak. A hatékonyságot muszáj nekik a h265, és vp9 -el minimum megegyező mértékűre emelni, vagy túl is szárnyalni azt...
Mire ezt megcsinálják, az 5 - 6 év... Ha a gugli bedobja a közösbe a vp tanulságait, még akkor is... Igazság szerint a vp9 sem lett túl nagy eresztés, mert még egy olyan ótvar lassú encodert, mint a libvpx, nem találsz a piacon....
Évek alatt sem tudtak írni hozzá egy normálisat. És ha ki is várod az időt, akkor is egy széttaknyolt videó lesz az eredmény. (bár... az x265 sincs még abban az állapotban, amiben kellene neki, de az legalább sokkal gyorsabb...)Egyébként igazán jó ötlet... az audió codec -ek piacán már megcsinálták, amit meg kellett.. Alacsony bitrate mellett az opus igazán jó darab. Most végre a videóval is komolyabban foglalkoznak.
-
quarros
tag
Ez a próbálkozás csak egy ponton fog elbukni. Nyílt forráskódon nehezen, illetőleg hosszú ideig nem törhető titkosítást csinálni katasztrofálisan nehéz lesz mert ez lesz az első amit a kalózhackerek támadni fognak. De sok sikert nekik, ebből mindenki csak jól jöhet ki ha megvalósul.
-
Gdi
senior tag
Skálázható az összes modern eszközre és sávszélességre
Alacsony számítási igénnyel és hardveres optimalizációval rendelkezzenNa most melyik.. mert nekem az elsőből az jön le, hogy továbbra is b*szhatod a P4 és Centrino M éra gépeit (amit még nagyon sokan használnak, és hát akarnak rajta webezni is, sőtmitöbb: videót nézni online).
Az alacsony számítási igény (ha nem tesszük oda zárójelben, hogy "modern" eszközön) azért ad némi reményt. Hardveres optimizáció megint egy olyan hogy most ez lehet jó is meg rossz is. -
#21
huskydog17
addikt
huskydog17
addikt
Tehát akkor ez az új csapat a H.265 (HEVC) utódján dolgozik? Esetleg egy alternatív, de nagyon hasonló hatékonyságú kodeken?
-
#20
scarabaeus
őstag
[CsuCsu]
#17
scarabaeus
őstag
"Narancs - orange. Eszre sem veszed, pedig magyaritva irt angol kiejtes (kicsit deformalva az idok alatt)"
Mondjuk az elkerülte az angolt, délről jött. Az arabig tudtam, de hogy ne legyen elírás, direktben a wiki:
"A magyar narancs szó az északolasz narancia [narancsa] – sztenderd olasz arancia – közvetítésével a spanyol naranja [naranha] szóból származik, a spanyolba pedig az arab nárandzs(a) útján került, melynek végső forrása talán (perzsa közvetítéssel) a szanszkrit (óind) náranga ’narancsfa’. (A szanszkritban eredete tisztázatlan, valószínűleg nem indoeurópai, hanem dravida forrásból származik, vö. tamil naru, ’illatos’.)" -
#19
CPT.Pirk
Jómunkásember
Armagedown
#18
CPT.Pirk
Jómunkásember
válasz
Armagedown
#18
üzenetére
Illetve azonos képminőség mellett kb. fele méretet eredményez. - ez talán szemléletesebb.
-
#18
Armagedown
őstag
kameraman77
#16
Armagedown
őstag
válasz
kameraman77
#16
üzenetére
Elavult, pl. a h.264 ugyanakkora méret mellett jobb minőségre képes
-
#16
kameraman77
tag
kameraman77
tag
Mi a gond az Xvid-del? még a kenyérpirítóval is kompatibilis, és jól skálázható..világszinten elterjedt...és nincs gépigénye.... Jaaaaa hogy akkor nem lehetne elnyomni egy halom felesleges új eszközt?
-
#13
-szp-
aktív tag
aprokaroka87
#7
-szp-
aktív tag
válasz
aprokaroka87
#7
üzenetére
Az nem fizetős, viszont lassú.
#9: meggyőztél, rövidítettem. -
#11
UnSkilleD
senior tag
aprokaroka87
#7
UnSkilleD
senior tag
válasz
aprokaroka87
#7
üzenetére
miután a gugli megcsinálta őket (vp8-9) utánna lebegtette be pár cég hogy bizonyos szabadalmakat sért és akkor a gugli fizetett nekik, és így nekünk végfelhasználókak már ingyenes a de a guglinak nem volt az
ezek most tejesen saját kútfőből akarják csinálni, de elég nehéz lesz minden szabadalmi dolgot kikerülniük
-
Csak még nincs ami rendesen működne. 
)
Új hozzászólás Aktív témák
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Vírusirtó, Antivirus, VPN kulcsok
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- GYÖNYÖRŰ iPhone 13 mini 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3048, 94% Akkumulátor
- Audio-Technica ATH-M20x fejhallgató
- Akció! Paidashu 10600MAH / 20700MAH Powerbank olcsón!
- Apple iPhone 13 Mini / 128GB / Gyárifüggetlen / 12Hó Garancia / 84% akku
Állásajánlatok
Cég: FOTC
Város: Budapest