Próbáltad a Shift gombot lenyomva tartani mikor bezárod az ablakot?
(elvileg ekkor megjegyzi a méretet és pozíciót a win és ugyanoda nyitja meg legközelebb)

Clint Eastwood FTW

Eddig sose hallottam erről, az összes inteles konfiggal ment rendben. It tmég az se megy, hogy majd a vlc-ből élesítek, kontrasztot, telítettséget állítok.. Szóval mostmár tuti öze van hozzá. Most próbáltam, semmi, sajnos ugyanaz.

Amúgy szerintem ez konkértan nem vlc probléma, hanem amd cpu probléma, szóval elég szorosan kapcoslódik a topichoz...

Samsung 49" monitorok eladók: https://hardverapro.hu/apro/samsung_49_32_9-es_monitor_elado_meg_2_honap_papir/friss.html

Az x264/265 esetében nem maga a cuda mag a probléma, hanem a sok mag miatti sok thread. Sajnos működéséből fakadóan nem skálázódik az encoder lineárisan. CPU esetében is szoktak ajánlani egy limitet. Az x264 12, az x265 18 thread felett látványosan romló minőséget kezd produkálni, amit a bitrate növeléssel lehet kompenzálni. Ennek a felnagyított eredményét látod nvenc esetén is.
Én azt szoktam csinálni x264 esetén (5900x), hogy:
a , kikapcsolom az smt-t és csak 12 real maggal enkódolok
b., sorozat esetén 4 csoportra szedem és egyszerre 4 ffmpeg fut 4*6 thread-en

ha valami, akkor biztos nem a cpu. az Intel integralt GPUja eleg sokmindent gyorsit, neha egy-egy uj formatumot elobb "tud", mint az NV vagy az AMD.
VLCben hw (GPU) gyorsitas be van kapcsolva ?

[ Szerkesztve ]

Első AMD-m - a 65-ös - a seregben volt...

NVENC az nem egy önálló részegysége a GPU-nak? Az is a Cuda magokon fut? Mert ha külön gyorsítóról beszélünk dedikált területtel/tranyókkal, akkor ott nem értelmezhető a thread szerintem. Nekem ez fura lenne, mert általában az NVENC párhuzamos használata (pl Shadow Play) semmilyen hatással nem szokott lenni mondjuk a 3D teljesítményre.
Meg nem is ez a tapasztalat NVENC-el hanem, hogy alacsony bitrátán egyszerűen egy x265 slow preset sokkal szebb eredményt ad*, mint bármi más. De ha nem vmi ADSL-hez való streaming a cél, akkor szerintem ma már nem szempont a 10 Mbit/s alatti bitráta. Főleg, hogy már SD felbontás se nagyon van. 1080p-hez én nem tartom túlzónak a 30 Mbit-es átlagot.

*Először hallok erről a párhuzamosítás okozta minőségromlásról. Én ffmpeg-ben nem is találkoztam még ilyen beállítással, szóval nyilván eddig 100% cpu használattal kódoltam, ha kódoltam. Nem tapasztaltam minőségromlást. Igaz ott én CQ módban szoktam tömöríteni és azt az algoritmus dönti el mekkora bitráta legyen. De ott is a "vizuális lossless" a mérvadó nekem, szóval ilyen apró bitrátát ott se látok.

[ Szerkesztve ]

Nvenc nem tudom min fut, de az biztos, hogy sok szálas cucc.

Most így hirtelen: [link] [link]
Ez egy létező probléma, aminek az oka a keyframe generálás. De amúgy keress rá megfelelő címszavakkal, találkozni fogsz a problémával. Én 24 thread esetén már eleve látom egyrészt, hogy nincs csak 60-70% cpu kihasználás, illetve látható a minőségi romlás.
Fix bitrate esetén rosszabb a kép, fix quality esetén megnövekszik a méret.
Ffmpeg esetén szerencsére (illetve handbrake-cli esetén is) van lehetőség thread limitre.
Ahogy fentebb írtam 5900x cpu-val trükközöm, egyrészt a jobb minőség, másrészt a jobb cpu kihasználás miatt.

[ Szerkesztve ]

Teasüti:
Közben újra átolvasva a hozzászólásod felmerült bennem, hogy nem ugyanarról a felhasználásról beszélünk. Te a streaming-et említed, ahol ugye más szempontok elsődlegesek, én pedig az offline konténerizált video-ról beszéltem, ahol megint más.
Stream esetén simán megfelel egy nvenc x minőség magasabb bitráta mellett alacsony latency-vel, míg egy tárolt, non-stream esetében szempont a kis méret és a megfelelő minőség is. Itt már jobban teljesít ugye a cpu. (Azt hiszem a cuda3.0 előtti időkben volt tisztán cuda az encoding, most valami részben más megoldás van már, van szerepe most is a cuda magnak, de van valami spéci fix hw is benne)
Mindegy, a lényeg amit el szerettem volna mondani, hogy ezekkel a kódolásokkal a kulcsframe-ek miatt nem lineáris a skálázódás a thread-ek számának növekedésével.
Leegyszerűsítve: Az encoding elmélet szerint vagy be kell várni a sok thread-et a keyframe-hez (sebesség csökkenés), vagy több keyframe-et kell csinálni (méret növekedés cq esetén, minőségromlás cb esetén). A vicc, hogy igazából mindkettő megtörténik.
Ez nem sw és hw függő, hanem az algoritmus ilyen. Az x265 valamennyire jobb már ebben.
Ha teheted próbálj ki egy 24+ thread feletti cpu encoding-ot és meglátod miről beszélek.

De kicsit off lett a dolog, bár annyiban nem, hogy magam sem tudtam erről, amíg nem futottam bele az 5900x-el encoding közben abba, hogy nem gyorsult a várt módon a folyamat. Akkor kezdtem utánaolvasni a dolognak, hogy sok thread esetén miért lazsál láthatóan a cpu.

[ Szerkesztve ]

igen, csak ugye az a megallapitas, hogy az Intel procival nem volt az a jelenseg, ami a Ryzen apuval van. Szvsz ha az Amd proci az add, sub, mul, div es hasonlo utasitasokat maskepp csinalna, mint az Intel, akkor azert joval tobb anyazas lenne a forumokban, mint pl. anno a K5 idejen, amikor az ures idozitesnek hasznalt

mov cx,xxxxx
varakoz: loop varakoz

kodot siman 0 ido alatt atlepte, ami miatt viszont az osszes Clipper program elszallt, mint a gyozelmi zaszlo.
ellenben a gpu az definialtan nem utasitasszinten kompatibilis, ott lehetnek gubancok.

Első AMD-m - a 65-ös - a seregben volt...

Sajnos el kell keserítselek. Semmi köze a jelenségnek az APU-d GPU-jához.

Nem használok VLC-t, de kíváncsi voltam erre a SHIFT bezár kombóra valóban működik-e. VLC-vel néztem meg és működik ill. nem működik, mert anélkül is pont ugyanott nyílik, akkora méretben, ahol/ahogy utoljára bezártam

Viszont a VLC nem a nálad beállított minimál módban indult, hanem normál ablakban és többszöri nyitogatást követően sem vettem észre méretcsökkenést, pont ugyanott, ugyanakkora méretben indult, ahogy előzőleg bezártam (nem is kel ehhez videót, .m3u-t nyitogatni, egyszerű indítás is megteszi)

Ekkor beállításokban bekapcsoltam az Indítás minimális felület módban opciót. Ezt követően folyamatosan csökkenő méretben indult a VLC, pont ahogyan leírtad. Nálam viszont 5800X + GTX1060 kombó van, tehát semmiféle AMD-s GPU nincs, ami belejátszhatna.

Szerintem az idióta VLC a normál ablak extra felületeit, ami minimál módban ki van kapcsolva minden egyes indításkor újra és újra elveszi az előző bezáráskori méretből, ami nálad már a csökkentett minimál kinézet/méret. Ezek a felületek ugye csak függőleges irányban módosítják a méretet.

Nálam a c:\Users\xxxxx\AppData\Roaming\vlc\vlc-qt-interface.ini útvonalon van a VLC beállításokat tartalmazó konfig/ini fájlja. Ennek elején a [General] szekcióban lévő geometry= sor tárolja az ablak méretét, ami minden minimál felületű bezárást követően módosul, míg normál ablakú indításnál, ha nem mozgatjuk/méretezzük át a VLC ablakát, akkor nem módosul.

Sajnos a VLC beállításaiban nem találtam olyan beállítást, amivel az ablak helyzet/méret auto mentését ki lehetne kapcsolni, de....

De, ha normál ablaknézetben elhelyezed a VLC ablakot úgy, hogy pont annyira csússzon ki alul a képernyőről, ha CTRL+H kombóval minimálra váltva képernyő szélen legyenek a video ablak határai, majd normál kinézettel zárod be a VLC-t (minimál felületű indítás legyen bepipálva), és a következő indítás előtt !!!! az előbbi útvonalon a vlc-qt-interface.ini
fájlt írásvédetté teszed, akkor mindig ugyanoda fog nyílni a VLC ablaka minimál felülettel és nem lesz csökkenő ablakméret indításkor

Egyébként pedig nyugodtan vedd fel a kapcsolatot a fejlesztőkkel, hogy ezt tegyék rendbe, mert hibás a működés VAGY visszadowngrade-elsz a korábbi még jól működő VLC verzióra

[ Szerkesztve ]

read-only mode on the forum

Sikerült nekem is reprodukálni a hibát, ha az alapértelmezett "resize window to video size" ki- és "start in minimal mode" be volt kapcsolva.

Itt lehet panaszkodni.
[link]

[ Szerkesztve ]

Nade írtam, hogy az elmúlt 15 év során mindvégig intel procijaim voltak, két héttel ezelőttig nem tapasztaltam ezt, a régi gépemen, ami most az asszony asztalán van, és egy intel i5-10600-as proci van benne, nálam tökéletesen működött, és nála most is tökéletesen működik. A két gép között az eltérés a másik alaplap és a másik proci, mivel az alaplap erről valószínű nem tehet, csak a proci marad, pontosabban a benne lévő video feldolgozó rész.

A vlc beállítások megvannak, sok sok éve minden új telepítésnél azokkal írtam felül a meglévőket, és intelnél mindig jó lett, nálam amd procival (vagy vga-val) ezek nélkül se volt jó, ezekel sem, a másikról lementett friss beállítások ott jók, itt nem. Win10-zel friss telepítéssel, win11 friss telepítéssel se jók, amd szoftverrel, és anélkül sem.

Ezért is maradt végül egyetlen lehetőség, a proci, vagy a benne lévő VGA. Namost érdekes lenne mindezt inteles procis gépen is megcsinálni, gyanítom uugyanúgy nem tapasztalná senki, míg AMD vonalon igen.

Több, mint érdekes. Köszönöm, hogy szántál illetve szántatok rá időt, megnézzük, mit tudnak tenni ezzel.

Samsung 49" monitorok eladók: https://hardverapro.hu/apro/samsung_49_32_9-es_monitor_elado_meg_2_honap_papir/friss.html

Nézz már rá a jól működő gépen arra az .ini fájlra. Mentegetésnél elő szokott fordulni, hogy read only attribútum rá kerül a mentett fájlokra, hátha meg lesz az anomália oka.

read-only mode on the forum

Van egy szerverem, annak a mappái vannak a gépekre felcsatolva, csak egy- egy C-D meghajtós nvme SSD van a gépekben, ami bármikor cserélhető, a fontos adatok nem a gépen vannak. Arról a gépről TC-rel lementem a megfelelő mentés mappába az user/appdata/roaming/vlc mappa tartalmát, majd itt TC-vel ugyanoda belépve felülírok mindent. Most megcsináltam egyesével a felülírást, változott a megfelelőre a fálj, azaz ebből kellene az induló programnak kiolvasni az adatokat. Ott tökéeltesen ynílik 10X indítva is, itt nem sajnos. Sőt, a másik gépen nagyra húztam az ablakot, kiléptem a programból, csináltam a mentésnek egy új mappát, abba kerültewk a fájlok, egyesével felülírva minden fűjlt itt is ugyanolyna nagyban nyílik, a megfelelő méretre teszem, és a következő nyitáskor már nem jó.

Samsung 49" monitorok eladók: https://hardverapro.hu/apro/samsung_49_32_9-es_monitor_elado_meg_2_honap_papir/friss.html

es ugyanazt a vlc verziot tetted fel, mint ami a regi inteles gepen van, vagy letoltotted a legfrissebbet ?

[ Szerkesztve ]

Első AMD-m - a 65-ös - a seregben volt...

A másikon is a legfrissebb van, meg ezen is. Próbáltam 32 bittel, semmi változás.

[ Szerkesztve ]

Samsung 49" monitorok eladók: https://hardverapro.hu/apro/samsung_49_32_9-es_monitor_elado_meg_2_honap_papir/friss.html

Pedig ott a hibajelentés is, amit linkeltem. 4 hónapja ismert hiba. Nem értem mit értetlenkedsz ezen. Én egy i7+nVidia laptopon reprodukáltam, ha ez vigasztal. Semmi köze a hardverhez. Szoftveres bug.

Próbáld ki a 3.0.12-t!

[ Szerkesztve ]

Ha úgy írod, hogy sikerült neked is reprodukálni, az megerősítés, ha odaírod, hogy i7+nvidia laptopon, az cáfolat. De végülis teljesen jogos, hogy még te kéred számon, hogy én értetlenkedek!
a 3.0.12 tökéletesen megy, köszi a rengítséget, rendes srác vagy!

[ Szerkesztve ]

Samsung 49" monitorok eladók: https://hardverapro.hu/apro/samsung_49_32_9-es_monitor_elado_meg_2_honap_papir/friss.html