Új hozzászólás Aktív témák
-
taranis
addikt
-
kovsol
titán
válasz Teasüti #20616 üzenetére
Ha azt állítom 12000kbps a limit, akkor miért csinálja egyik 12000 a másik 8000? Látszólag így teljesen egyforma a két végeredmény minősége így. Viszont lehet ha hajlandó lenne mind a kettő 12000-ben kódolni ahogy kérem akkor lehet a natív lenne szebb azonos méretben.
May the Force be with you!
-
vond
MODERÁTOR
válasz Teasüti #20622 üzenetére
Azért ez fájt, kolléga.
Egyébként én is így csinálom, hogy kitolom "tömörítetlen" DNxHQ-ba, majd FFmpeg-gel transzkódolom egy arany középúttal a méret és a minőség között, meg attól függően, hogy mi a célhely.
(#20623) taranis: A mágus nagyon túlzó, az inkább te vagy a színekkel, meg profilokkal.
(#20625) hibavissza: Ha szebb végeredményt és kisebb fájlméreteket tudunk így elérni, akkor miért ne csinálnánk? Épp te írtad az imént, hogy neked sem számít a render idő.
A DNxHQ egyébként hamarabb megvan, és ha esetleg még hozzá akarsz nyúlni a H264/H265 kódolás előtt, akkor az is gördülékenyebben és szebben megy, mintha a már letömörített MP4-et kellene csesztetni.
[ Szerkesztve ]
VOND.HU // DESIGN • PHOTO • VIDEO • WEB • IT
-
MrChris
nagyúr
válasz Teasüti #20620 üzenetére
Tudom itt kb. senki se Vegas Pro-ban utazik, de ahhoz van egy Lagarith nevű lossless tömörítő kodek, családi mennyiségehez egy régebbi SSD-vel használom. Meg ugye ki is lehet belőle irányítani a rendert több gépre...
Amúgy meg milyen jogi akadálya van, hogy ezek az editorok ne pluginezve vagy más formában tudják használni az ffmpeg-et? -
hibavissza
veterán
válasz Teasüti #20630 üzenetére
Egyszer renderelsz és hàromszor tömörítesz az eljàràsoddal. Nincs ezzel gond csak még mindig nem làtom az értelmét. A vinyóknak pont mindegy, a tv-nek és a YT-nak is. Jelentős pénzt úgy nem lehet spórolni, hogy néhàny megàval kisebb a fàjl. Gombokért van màr hdd. Csak próbàlom megérteni mi a haszna. Vagy csak tisztàbb-szàrazabb érzés? Ami teljesen valid érv egy tech fórumon.
-
vond
MODERÁTOR
válasz Teasüti #20639 üzenetére
Csináltál teszteket FFmpeg x264 és x265 között? Minőségben, méretben milyen különbségek vannak? Mennyivel nehezebb utólag dekódolni a 265-öt vágó programokban? Vagy egy felső-középkategóriás GPU-val az sem probléma?
Én még mindig inkább x264-gyel archiválok. De sokszor gondolkodtam már a váltáson. Mondjuk annyi archiválandó cuccom nincs, hogy több terabyte-ot nyerjek vele. De ha pl. minőségben is sokkal jobb lenne az x265, akkor meggondolandó.
VOND.HU // DESIGN • PHOTO • VIDEO • WEB • IT
-
Teasüti
nagyúr
válasz Teasüti #20642 üzenetére
Nem tudom ezt mutattam-e már itt a topikban. Ez a 4K verzió a fenti példából*. Ennek az 1080 verziója foglal csak kicsivel kevesebb helyett x264 formátumban.
*Ez volt a legelső videó, ami kiesett a kamerámból. És az első kamerám amúgy. Csak hogy kontextusba helyezzem a bénaságomat.
18-55 XF kitobi, manuál mód, gimbal még nem volt, a ninja járás egyáltalán nem ment (most se megy). És asszem még DR-ből is a Free verzió volt csak meg.
Ekkor egészen tetszett a manuálozás. Szégyen, hogy azóta csak AF módban használom. -
Tuninger
Topikgazda
válasz Teasüti #20648 üzenetére
Nem color managed.
Sgamut3.cine-ből kellene REC709-be konvertálnia illetve Canon C-Gamutból REC709-be.
Ezt ő manuálisan oldja meg a colorchecker és a vektorszkóp használatával. Az eredmény jó, viszont így korlátozva van a pontossága az egésznek. Ha előtte csinálna gamut konverziót, "előjönnének olyan árnyalatok" amiket ezzel a metódussal nem tud előhozni.
Ezért van felháborodva Taranis, Gerald mindig a precízségéről volt ismert és a videó második felében a gradenél "érzésre" tekerget, ami nem az a szint ami tőle megszokott.
De ezt azért teszi hogy mindenki számára érthető legyen, illetve hogy ne legyen még hosszabb a videó.szerk: a checker jó. de 6 db színt közelítesz a referenciához. Ráadásul úgy, hogy ismert, hogy az sgamut egy picit csavarja a színeket a sárga-piros tartományban. Mondjuk az sgamut3.cine sokkal kevésbé, így a hiba nem látványos, de ha pl A fuji f-gamut zöld tolását akarnánk összematchelni egy FS700 S-gamutjának a piros tolásával és megfűszerezzük az egészet egy V-Gamutos felvétellel, ember legyen a talpán aki azt konverzió nélkül megoldja.
Itt most neki működött, mert az sgamut3.cine nem tekeri meg annyira a színeket, a c-gamut meg egyáltalán nem csinál semmit, csak deszaturál. Ezért "szeretik" gradelni a canon logot, mert csak kontrasztot kell neki adni, nem kell hozzá gradelési skill.[ Szerkesztve ]
-
Tuninger
Topikgazda
válasz Teasüti #20651 üzenetére
Bővített mondatba szedve Taranis egysorosa:
A kamera a codec számára leghatékonyabban menti a színeket és abban a tartományban ahol ő több színt lát, többet is akar bementeni a fileba más színek kárára, amikre kevésbé érzékeny.
Pl a te esetedben az FLOG - F-Gamut kicsit zöldbe csúszik, abból lát sokat. Ha kézzel próbálod ezt korrigálni, el tudod tüntetni a zöldességet, de szinte biztos hogy más színeid nem lesznek pontosak pont azért mert a zöld oldalt korrigáltad.
Ha használsz színtér transzformációt akkor szépen minden szín a helyére kerül (ami egyébként sem FLOG sem SLOG esetén nem teljesül, Taranis már írt róla egyszer, de nézzük úgy hogy jobb mint bármi más megoldás) egy olyan kiindulási alapot adva ahol minden szín olyan amilyennek a gyártó elképzeli a REC709-et.A másik fontos dolog: az F-Gamutot lehet konvertálni REC2020-ba, vagy bármilyen más színtérbe is. Azt az életbe nem csinálod meg hitelesen kézzel.
Meg ahogy írtam a fenti hozzászólásban: Gerald a 6 db alapszínt próbálja a referenciához közelíteni, amivel egyfelől kivesszük a gyártó stílusát a színek terén (ugye a canon a bőrt picit piros fele tolja, a Sony a sárga fele), másfelől a köztes színekkel mi lesz?
Én mikor próbáltam megcsinálni a Sony - Canon LUT-omat rengeteget szívtam a sárga - piros referenciák közötti tartománnyal.
A Colorspace transform matematikai alapon húzza helyére az összes színt, expozíciótól függetlenül. -
Tuninger
Topikgazda
válasz Teasüti #20661 üzenetére
Az ACES megcsinálja neked a transzformációt, pont ez a feladata.
Davinci YRGB-nél pedig az kell amiről idáig beszéltünk, F-gamut - Rec709 konverzió és ezt a color space transformmal (CST) a legpontosabb elérni. LUT-ot is használhatsz persze, csak az nem olyan flexibiis.Bárhol gyurmázhatsz bármivel ha tudod mit csinálsz
(#20662) taranis
Most megzavarod szerencsétlent, idáig fgamutról magyaráztam, oszt itt REC2020-zol. Tudom hogy ennél a kameránál megegyezik, de a többinél nem.[ Szerkesztve ]
-
taranis
addikt
válasz Teasüti #20665 üzenetére
Zavar az van itt, több szintű, pedig én már leírtam ezeket többször is.
A gamut az a színtér, ami F-Log rögzítés esetén F-Gamut, ami pöccre megegyezik a Rec.2020 szabvány által leírt színtérrel.
A gamma az a görbe, amivel a lineáris adat enkódolva van, ez teszi "lapossá" a log felvételeket.A másik zavar abból fakad, hogy a Rec.xxxx szabványok nem csak színteret írnak le, hanem pl. azt is, hogy miként kell az RGB adatot YUV-ba konvertálni, így pl. simán használhatja az F-Log a Rec.2020 által leírt színteret úgy, hogy közben a Rec.601 által leírt képletekkel csinál RGB-ből YUV-ot.
Szerk: hozzáteszem amikor HLG-ben rögzítesz, akkor a színteret, és az RGB-YUV konverziót is a Rec.2020 írja le, gondolom ez a HLG követelménye.
[ Szerkesztve ]
colorizer.net
-
vond
MODERÁTOR
válasz Teasüti #20792 üzenetére
Azért messze nem ugyanaz az 5 külön hozzászólás, mint 5 bekezdés egymás után. Nem véletlenül kérjük, hogy mellőzzék a felhasználók a sok egymás utáni új HSZ írását. A fórumnak sem jó, és a topiktársaknak sem. Ezentúl légyszi próbáld meg egybe szerkeszteni, amennyire lehet. Köszi!
(#20802) Teasüti: Ez nem hülyeség. Továbbítom. Talán meg is lehet oldani.
[ Szerkesztve ]
VOND.HU // DESIGN • PHOTO • VIDEO • WEB • IT
-
panoly
tag
válasz Teasüti #20813 üzenetére
[link]
Nekem konkrétan ezzel a hibával ment vissza kétszer a távirányító, elvileg mindkét alkalommal újat kaptam.
FB mavic fórumon leggyakrabban arra panaszkodnak, hogy csipog a táv bekapcsolásnál, ez azért szokott lenni, mert nyugalmi állapotban is beérzekel valamelyik stick. Ugyanez az oka a magától forgásnak is, nekem többnyire fölfele emelkedes közben jön elő.
Sajnos nálam a linkelt igen veszélyes másik karra athallás jött elő.A felszállásra nem mondanám, hogy a táv a legfőbb gyanúsított, de könnyen ellenőrizhető ha megvan még a flightlog.
Btw nincs szerencsém a dji termékekkel, hosszú pihenés után elővettem a ronin sc-t, ennek meg az egyik motorja kezdett el nyekeregni.
-
taranis
addikt
válasz Teasüti #20818 üzenetére
Van olyan hely ahol ennyi elég a cseréhez, ez alatt nem azt kell érteni, hogy kukázom azt a vinyót, csak abban az adott szerverben többet nem fog menni. Ahány ember annyiféle határ van, én ezt húztam meg, jobb a békesség. Lehetne azt is, amit Ropi mond, hogy x évente ha törik ha szakad csere.
Ja és természetesen a raid + mentés az alap.[ Szerkesztve ]
colorizer.net
-
*Ropi*
félisten
válasz Teasüti #20831 üzenetére
A tápellátás instabilitásakor az SSD-knek jellemzően két állapota van: vagy csak a DRAM cache-be írt adatokat vesztik el, vagy sérülnek a NAND alsó lapjára írt adatok is. Az első hiba nyilvánvaló: pufferkondenzátor nélkül minden olyan adat elveszik, amely akkor nincs véglegesen a NAND-ba írva (ugyanez történik a HDD-knél is - ez önmagában összeomlaszthatja a fájlrendszert, amely így nem ad valid fsyncs-eket: a köznyelvben a FAT tábla széteséseként szoktak rá hivatkozni). A második eset az MLC, vagy annál újabb topológiájú, NAND alapú flash meghajtók (tehát nem csak SSD, hanem memóriakártya és pendrive is) sajátja: amikor a magasabb lapokra írt bit újraprogramozásra íródik (visszaíró módszer), akkor egy váratlan áramingadozás törölheti / megváltoztathatja az alsó lapon lévő bitet (vagyis a korábban rögzített, nyugalmi adatokat). Az ultimate megoldás a BBU (Backup Battery Unit) - védett DRAM-gyorsítótár integrálása (általában akkumulátorral / szuperkondenzátorral), ahogyan a korrektebb RAID vezérlőknél is megoldották - azonban ez jelentősen drágítja a meghajtót. A konzumer SSD-k a költséghatékonyság jegyében a legtöbbször nem tartalmaznak áramkimaradás ellen ilyen szinten védett gyorsítótárat, inkább olyan, alternatív megoldásokat használnak, mint részlegesen védett író gyorsítótár (Crucial M500 / M550 / M600 +), vagy a Samsung és a Sandisk meghajtóinál speciális SLC / ál-SLC NAND területek vannak az új írások elvégzésére, de korábbi, veszélyeztetett adatok nélkül. A Samsung SSD-k pl. a NAND journalban jegyzik is a feszültségkimaradásokat, lásd a S.M.A.R.T. PoR (Power Recovery Count) attribútumot. Sokan (be)nyelik a Kingston SSD-it mint kacsa a nokedlit, mert rendkívül olcsók - csak egy baj van velük: a Kingston híres arról, hogy miután a bevezetése után felfuttatott egy szériát és a tesztoldalak lehozták a jó mérési eredményeket, a költséghatékonyság jegyében elkezdik lecserélgetni az alkatrészeket gyengébbekre, így az addig szépen teljesítő széria elsüllyed a többi gagyi elektronikus hulladék tengerében. Nem véletlenül nem ad ki a Kingston sosem specifikációt a vezérlőről és a többi főbb összetevőről: tradicionálisan sosincs nyilvános specifikációjuk. Ebből adódóan semmin sem szabad meglepődni velük kapcsolatban: még azon sem, ha egy hirtelen áramkimaradás megrongálja a korábbi adatokat. Sajnos, még a lemez DRAM-gyorsítótárának letiltása (elfogadva a vele járó, nagyságrendi teljesítményveszteséget, amitől egy átlag HDD szintjére lassul be az SSD) sem oldja meg a problémát, mivel a korábban felírt adatok (vagyis a nyugalmi adatok) is megsérülhetnek és megrongálódnak a nem várt áramkiesések miatt. Ha ezek még régebbi Sandforce vezérlőn (pl. a hírhedt SF2281) alapulnak, akkor "megfelelő" körülmények között akár téglázhatja is a meghajtót. Az Intelnek voltak olyan, hírhedt SSD szériái (ha jól emlékszem a 3-as és a 4-es), amiket egy áramkimaradás lazán téglázott. Ma már szerencsére nem jellemző, de a külső SSD-k korában (ahol a külső ház csatlakoztatása dupla kontakt hibaforrás), bármi is megtörténhet. Láttam már egy-két kínai M.2 ---> USB3.x átalakítót és finoman fogalmazva is látszott rajtuk a költséghatékony tervezés. Pl. egy egyszerű kábel bizonyos kábelhossz felett simán adatátviteli hibákat generál, ha csak dupla árnyékolása van, nem pedig tripla. Van az a mondás, hogy az élet túl rövid ahhoz, hogy egy USB-s eszközt leválasztását kivárjuk - külső SSD esetében ezt el kell felejteni és rendesen le kell választani. De nem megyek bele jobban, mert itt nagyon off.
[ Szerkesztve ]
Weboldalam: http://karpatisandor.hu
-
*Ropi*
félisten
válasz Teasüti #20840 üzenetére
B@kker fáradt vagyok, pont a lényeget nem írtam le. Alapvetően a gyártási technológiák szavatolják, hogy normális használatot feltételezve kb. 8 évig megtartsa a NAND az adatokat. Viszont gyártási hibák mindig is voltak és lesznek - a wafer széléből készülő, B kategóriás NAND chipeket a normális gyártók kizárják selejtként, mások viszont bagóért felvásárolják és valami SSD-nek kinéző dolgot építenek belőle - most ezt az infót tegyük az előző hozzászólásomban, a Kingstonról írtak mellé! De van még pár ilyen gyártó, pl. a Kingfast, Simmtronics, stb. is.
Egyébként a vonatkozó JEDEC szabvány szerint a konzumer SSD-knél a szükséges adatmegőrzési idő 1 év 30C-on, vállalati SSD-knél pedig 3 hónap (!) 40C-on. Ugye milyen optimisták?
Weboldalam: http://karpatisandor.hu
-
Speeedfire
nagyúr
válasz Teasüti #20882 üzenetére
Hát ez nem hangzik túl jól. Ezek szerint egy huzamban kellene felvenni mindent? És mi van azokkal amik pl darabolják a videókat 30 perc, vagy 2gb után? Azt mások hogy fűzik össze? Szemre waveform alapján?
Igen, jelenleg ez van. Copy paste.
Köszi, ez mondjuk így már jó a backspace-el.
Kb folyamatosan 100% a cpu, és van hogy nem tudom pl a megfelelő helyre tenni a videó sávot, mert elugrik.
Egy i5 4. gen, 16gb ram, rx470 van alatta.A sok lagg miatt elég nehéz dolgozni vele, lehet marad a vegas továbbra is.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Teasüti #20893 üzenetére
Igen mp4 videók 4k felbontásban amit az akciókamera csinál.
Timeline felbontás alatt mit értesz, ez lenne a projekt felbontása?
A lejátszás 1/4-re méretre van vége a preview-ban.Egyelőre gép csere nincs tervben, épp elég más szarra ment el a lóvé. De később egy ryzen 5 van tervben.
Optimalizált médiánál van valami beállítás? Mert csak a menüje van.Amúgy a vegas h-h nem fossa magát össze lejátszás alatt? Próbaképp ugyan ezt elkezdtem ott is csinálni, és mérföldekkel gyorsabb. Igaz butább is. Bár amire nekem kell arra jó.
Konkrétan kb 1 óra alatt megvágtam, míg DR alatt több óra alatt se jutottam idáig.
MrChris: De a 4k az csak a forrás, vagy az mindegy? A projekt nekem fhd csak.
Lehet, hogy akkor csak color grade-re használnám a DR-t. Minden másra vegas.
hibavissza: Az elég komoly. Akkor mégis mi kell alá? I9, 32gb ram, meg 2080ti?[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
MrChris
nagyúr
válasz Teasüti #21084 üzenetére
Mi a csuda? Így működik a Resolve? Akkor még nem dolgoztál Vegas Pro-val, abban egyetlen projectben mindenféle gpu-s cuccot rá lehet tenni, akár ACES-ben 32 biten és a végén egyetlen menetben renderelni, még a kodek is lehet GPU-s, a NeatVideo is mehet GPU-val. Mindezt 2GB vram használat mellett.
-
_q
addikt
válasz Teasüti #21084 üzenetére
Most abból indulok ki, hogy én a DNx-es megoldással renderelek ahogy asszem te is. De ez már alapból egy kicsit csökkentett minőséget ad, nem a nyers értékeket úgy tudom. Ha most tegyük fel 3x renderelsz, akkor mindig egy kicsivel rosszabb eredményt kapsz, így a végső 3. render már 3x rosszabb lesz, ami lehet még mindig elenyésző különbséget ad. Jól gondolom ezt vagy másként történik?
-
MrChris
nagyúr
válasz Teasüti #21088 üzenetére
Akkor nem ismered a Vegast. Nyilván nem feküdne neked. Nem gondolnám, hogy almát körtével, mert szinte minden dolgot meg lehet vele csinálni, csak máshogy, mint a Resolve-ban.
Azért csinálod ezt a többszörös rendert, mert egy menetben lassabban dolgozza fel a DR, vagy mert nem bírja és kilép/hibázik/elszáll?
Pont most próbálgattam a DR-ban a saját szűrőjét és a Neat-t, majd csinálok publikus mintát. Eddigi tapasztalatom, hogy a Neat egyszerűen szebben, jobban szűr. Álló képen paraméterezve annyira nem tűnik fel, de ha rendesen kirendereled akkor már igencsak különbözik.
-
mihulino
tag
válasz Teasüti #21073 üzenetére
Kipróbáltam két presetet is flatre, az utolsónak ez lett az eredménye...nem volt könnyű összeszínezni...főleg úgy hogy nagyon okosan felvételek között kitaláltam, hogy fotózni is kéne egyet, így átállítottam landscape-re...majd úgy hagytam
Szóval a földi videó slog2, az air videó meg cinelikeD.
(#21096) Teasüti nekem még szabad az időpontom.
www.mohosfilm.com -
MrChris
nagyúr
válasz Teasüti #21097 üzenetére
Most félreviszed, mert egyikünk se csinál nagyjátékfilmet.
Filmeket nem pár százezres, egymilliós árgépen összevadászot akciós alkatrészekből meggyúrt hobbi, sufni PC-n gradelnek. Csak két forgatáson bámészkodtam, de hatalmas számítógép kapacitást visznek a helyszínre, azon szerintem minden általad elképzelhető szűrő realtime fut. Egy ilyen filléres technikai bizbasz nem lehet akadály, mint egy erre alkalmas számítógép. Apám révén néma szemlélője voltam 20 éve egy film utómunka stúdió munkájának, sima kontroll monitor fél millió, szín ellenőrzésre egy Barco monitor 2 millió, akkoriban újdonságnak számító HD tartalom digitális beolvasására, tárolásra, lejátszásra alkalamas PC-szerű célgép (aszem Silicon graphics) több millió forint, Da vinci renaissance 8:8:8 meg biztosan egy vagyon lehetett. 20 éve.
CGI-t talán nem a helyszínen pöcsölik...Szűkítsük a kérdéseket a minket érintő nehézségekre és megoldásokra.
Azt írtad, hogy klf cuccok miatt megtelik a VRAM-od és emiatt szeded szét a munkafolyamatot, csak nem derült ki, hogy végzetes hiba történik, vagy belassul a rendszer. Ezek szerint utóbbi, ami még a jobbik eset. Most lecseréltem a videó kártyát 8GB-osra és megjavulni látszanak a program leállások, Neat OFX se durrant el eddig, gpu-z 4-5GB használatot jelez. -
Márton
nagyúr
válasz Teasüti #21104 üzenetére
Hát nem tudom, jó 20 éve ültem utóljára programozás/algoritmusok órán, de valami azt súgja ott komoly gondok lehetnek a kóddal, optimalizálatlanság.
Emlékszem, mikor meglátogattam a vidéken élő nagymamámat, azt mondta: "fiam, egy napon még emberek fogják pazarolni az idejüket arra, hogy elolvassák amit írsz"
-
vond
MODERÁTOR
válasz Teasüti #21338 üzenetére
A Zeiss Planar 50mm f/0.7-ről én is hallottam annak idején a Barry Lyndon kapcsán. Kubrick lánya majdnem összeesik alatta.
VOND.HU // DESIGN • PHOTO • VIDEO • WEB • IT
Új hozzászólás Aktív témák
- Politika
- Óra topik
- Gumi és felni topik
- eMAG vélemények - tapasztalatok
- Xiaomi 13 - felnőni nehéz
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Xbox Series X|S
- Aliexpress tapasztalatok
- Teljes verziós játékok letöltése ingyen
- További aktív témák...
- Sony A6000 újszerű kb 1000 expó + Sony 28-70 ob
- Sigma 23mm f/1.4 DC DN (C) Sony E objektív
- Sony Alpha 7R II Body ILCE-7RM2 Sony FE 50mm f/1.8 (SEL50F18F) Tamron AF 28-75mm f/2.8 Di III RX
- DJI Osmo Action 3 Adventure Combo akciókamera +32GB SanDisk Extreme SD kártya
- LEGJOBB ÁR! Feiyutech AK4500 Gimbal + follow focus + hyperlink (standard kit)
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen