Ano, bude to fungovat. Len nie za behu filmu (audia), samozrejme.
Ano, bude to fungovat. Len nie za behu filmu (audia), samozrejme.
Další možnost je napevno nastavit zvukovku v aplikaci (MPC-HC). Takže běžné zvuky (web, hudba, hry, ...) pak půjdou z výchozího zařízení (analogový výstup), kdežto MPC-HC bude zvuk vždy posílat na HDMI. To je ale pochopitelně vhodné jen tehdy, pokud to MPC-HC na nic jiného nepoužíváš.
A do třetice jde zprovoznit i ten synchronní výstup na obou výstupech zároveň, je ale třeba použít MPC-BE. Tohle má zase jiné drobné nevýhody a asi bych se moc nesnažil to kombinovat se zdejším návodem, ale funguje to.
@vivid - dík, to je v prípade, že nemá inštalovaný Reclock.
Účel Reclocku je vysvetlený v návode. Nie je to len synchronizácia audia a videa, ale aj WASAPI exclusive režim. WASAPI exclusive režim znamená okrem kvality audia aj to, že vyradí všetky ostatné aplikácie a do zvuku nič nezasahuje.
http://wiki.xbmc.org/index.php?title=Windows_audio_APIs
@Mao7 - Použivaj Reclock. O Reclocku a WASAPI je na strane 10 v návode. Ja použivam Directsound a default zvukovú kartu ( RME Babyface ) pre PC monitor a WASAPI a AMD HDMI out pre prehrávanie filmov. Directsound je vhodný na surfovanie a bežnú prácu v PC, lebo pri ňom sa audio zdieľa ale v prípade WASAPI je to je ako som písal hore.
K tomu WASAPI bych si dovolil doplnit, že právě MPC-BE jej umožňuje využít i bez ReClocku. To pro případy, kdy člověk o dodatečnou synchronizaci audia nestojí, a mít tak další (občas nestabilní) aplikaci v řetězci je zbytečná přítěž.
Naposledy upraveno uživatelem tdlmarek: 02-04-2014 v 19:57
Nutnosť Reclocku je vysvetlená v návode. Zásadným dôvodom je A/V desynchronizácia lebo neexistuje adaptácia audia k videu ( master/slave ). A/V timing nie je ideálny. Druhý je, že ak nastavíme 23Hz režim na TV, tak sa panel nerefreshuje presne na 23.976 Hz ale osciluje okolo tejto hodnoty. Intel Haswell je tomuto číslo najbližie, potom AMD a najhoršie je na tom stále Nvidia. Film si beží 23.976fps a TV nám uteká lebo naša GPU refreshuje na vyššej hodnote 23.978Hz = hrozí riziko výpadku A/V snímkov. Reclock toto rieši excelentne. Iná možnosť je zrýchliť video a audio na 24fps ( original snímková rýchlosť filmu ) pomocou Reclocku a všetko nechať synchronizovať na 24Hz, ktoré grafiky zvládajú presne.
MPC-HC preferujem hlavne preto, lebo autor LAVfiltrov ( už dnes natívnych dekodérov v MPC-HC ) spolupracuje s autorom madVR renderera.
@tdlmarek Aké výhody vnímaš na MPC-BE oproti MPC-HC? Netestoval som ešte, skúsim.
Predpokladam, ze ma navrch nejake vylepsenia (uz spomenuta priama podpora WASAPI)
Já výhody ReClocku nepopírám, v tom co jsi popsal je to nenahraditelný nástroj. Bylo by ale naivní si myslet, že úplně každý uživatel vyžaduje toto ultimátní řešení jak je popsané v návodu. Prostě někteří jsou méně nároční a spokojí se i s přehráváním kvalitativně na úrovni např. XBMC, ale kvůli tomu jim přece není důvod MPC zcela odpírat. Navíc je třeba zohlednit i hardware, protože návod vyžaduje relativně silné desktopové PC, ale spousta lidí chce přehrávat třeba jen na notebooku, domácím servříku bez eGPU, apod. Pravda, takové diskuze by pak možná bylo vhodnější řešit v jiném vlákně, protože zde ti vlastně odbíháme do off-topicu.
Jako hlavní výhodu MPC-BE vidím právě tu integrovanou podporu WASAPI, jak píše vivid.sk. Dávám přednost bitstreamovanému audiu bez synchronizace (ano, i za cenu výpadku několika málo osamocených snímků během dvouhodinového filmu, nevidím to jako zásadní problém), a tam je potom ReClock v podstatě nevyužitý. Naopak, je to zbytečná komplikace a jak jsem naznačil výše, není vždy úplně stabilní, tedy alespoň při tom bitstreamovaném audiu.
Další jsou spíše kosmetického charakteru - přehlednější konfigurace, místy rozšířené menu o nějakou užitečnou funkci, pohodlnější přepínání audio a titulkových stop přímo na hlavní liště, již zmíněná podpora duálního zvukového výstupu, atd. Integrace LAV filtrů do základní instalace MPC-HC je určitě plus, u MPC-BE je třeba stále používat jejich stand-alone verzi. Není s tím ale žádný problém, provozoval jsem to v této konfiguraci (MPC-BE + LAV) řadu měsíců.
Update 12-04-2014
MadVR 0.87.9 - update
LAV filters 0.61.2 + MPC-HC - update
https://www.mediafire.com/?vd5eos1mc3abh9t
Tým užívateľom, ktorý chcú pochopiť nové funkcie madVR a zistiť aký GPU hardware je treba na tieto funkcie, doporučujem stiahnuť nový pdf návod, kde som doplnil celkom dosť nových informácii.
Naposledy upraveno uživatelem Plutotype: 12-04-2014 v 11:26
Ahoj Plutotype,
mal by som na Teba dotaz..
V sekcii: "Trade quality for performance" je 3.položka zhora "use random dithering instead of OpenCL error diffusion", ktorú keď odznačím (štandardne ju mám označenú), tak vyťaženie GK (HD 5770) ide z 25% na 85%. Keď ju mám však označenú (je tam fajka ako na priloženom obrázku), tak pri setupe pre scaling algorithm:
chroma upscaling - JINC, 3taps, AR ON
image doubling - none
image upscaling - JINC, 3 taps, AR ON, Linear line ON
image downscaling - Catmull-Rom, AR ON, LL ON
ide GK v pohode na 25% a všetky queque a stats sú OK. Znamená to niečo ako, aby využíval iba náhodný dithering namiesto OpenCL error diffusion, tým pádom nerobí "plný" dithering, ale iba náhodný/v určitých intervaloch a preto to vyťaženie GK klesá?
Ak to nastavím na hodnoty, ktoré máš v návode:
Chroma upscaling( 4:2:0→4:4:4 ) – Bicubic 75, antiringing ON
Image upscaling – Lanczos, antiringing ON
Image doubling - Off
Image downscaling –Catmull-Rom, antiringing ON
tak mi zaťaženie klesne na 72%, čo je aj tak veľmi veľa. Akonáhle však aktivujem "use random dithering...", tak zaťaženie spadne okamžite dole.
Mám zatiaľ madVR 0.87.4, vrátil som sa z nového, lebo mi robil neplechu...Pričom v novom táto položka nefiguruje.
![]()
1. Support na staré verzie madVR Ti bohužiaľ neposkytnem. Nainštaluj novú verziu a napíš mi, kde Ti robí neplechu.
2. Vždy keď hlásiš problém na fóre, uveď prosím aký máš OS, CPU, GPU a aké prehrávaš video na akom displeji. Prilož prosím screen z CTRL+J vo windowed/exclusive mode.
3. Error Diffusion je náročný typ ditheringu, ktorý autor madvr renderera v novej verzii umiestnil do sekcie rendering - dithering a píšem v návode o ňom, že je náročný na GPU. Šiaha na procesory grafickej karty cez rozhranie OpenCL (http://en.wikipedia.org/wiki/OpenCL). V návode neuvažujeme už o random ditheringu, lebo ho autor madVR renderera nahradil ordered ditheringom ( ako defaultná dithering metóda ), ktorý je teoreticky a aj prakticky kvalitnejší . Kedže interná processing pipeline madVr renderera je v 16-bit, aby sme video mohli poslať na výstup, musí sa naspäť zkonvertovať na 8-bit kde sa aplikuje dithering, ktorý zakryje menší počet gradientov u 8-bitového videa. V nových verziách madVr ponúka niekoľko možností ( každý máme inú grafickú kartu, že áno ).
Naposledy upraveno uživatelem Plutotype: 12-04-2014 v 22:04
Plutotype, ďakujem Ti za reakciu
1. neplecha bola v tom, že v nastaveniach si to pamätalo napr. Tvoje monitory a ďalšie veci, pričom pri prehrávaní bola GK veľmi zaťažovaná...Preto som sa vrátil na tú staršiu verziu. Stiahol a pouzil som však teraz najnovší z netu (nie z Tvojho balika) a je to už OK.
2. OK, do budúcna sa v tom polepším
3. v najnovšej verzii už bezpredmetné
Naposledy upraveno uživatelem zimcol: 14-04-2014 v 10:28
Ja mám v balíku najnovšiu madVr 0.87.9 a dokonca ešte beta3 edíciu, ktorá fixla pár vecí pre windowed mód. Bol to určite problém nejakého nastavenia a chápem, že je náročné to odsledovať.
Naposledy upraveno uživatelem Plutotype: 15-04-2014 v 07:00
Nebylo by od věci do toho řetězce zapojit avisynth? Především pro doostření 720p ripů - FineSharp. Případně InterFrame ... no, to by asi nebylo košér a kvalita té interpolace je taky dost diskutabilní mírně řečeno. Ale to doostření je docela bomba - jeden by nepoznal, že to není FullHD pokud ten obraz detailně nezkoumá ... Místo LAVu by bylo tedy zřejmě nutné použít FFDShow
viz. http://www.ezoden.com/684/tutorial-htpc/9
Môj názor je, že sharpening nie je treba, lebo ten kto to myslí s kvalitou videa vážne, nebude prehrávať 720p a doostrovať cez avisynth, ktorý si vyžiada minimálne Core i5 CPU len za cenu umelého doostrenia ( ktoré pôsobí navyše nenaturálne ). Blu-ray film je dostatočne ostrý. Autor MadVR renderera funkciami v madvR primárne rieši nedokonalosť blu-ra videa a nesústredí sa na sharpening alebo iné "efekty". Užívatelia už aj dnes majú problém dnes pochopiť prečo madVr berie na chroma upscaling, dithering, scaling a rendering taký výkon z GPU.
MCFI, resp. SVP projekt je podobná záležitosť. Nedoporučujem. Berie si Core i7 CPU a výsledok je telenovela. Pokiaľ chceme zlepšiť vnímanú pohybovú ostrosť, treba aby to výrobcovia vyriešili na úrovni displeja, nie vyrábaním umelých snímkov.
Z pohľadu dizajnu HTPC - Keď povieme, že HTPC má mať okrem R9 270X ešte aj Core i7 CPU s chladením, jemnou spotrebou, teplotou a hlukom navyše, nebudeme príliš populárni.![]()
Naposledy upraveno uživatelem Plutotype: 22-04-2014 v 21:57
Jan10> Lanczosz alebo aj Spline (ktore su z tych lepsich bezne dostupnych pouzitelnych upscaling algoritmov) tiez doostruju. Naco potom doostrovat este viac? To si mozes doostrit v TV![]()