MPlayer byl forknut (diskuse)

[_M_etalica.vstava]

Hmmm, zrejme lepsi jak vylepsit ten stavajici
Chjo.

[Xerces]

Ty zmeny jsou treba tak zasadni, ze by asi dalo dost politickyho usili to protlacit do mainstremau, tak to forkli, zkusej to a kdyz se to nechyti tak to umre. Prezije vzdy ten nejsilnejsi

[_M_etalica.OBIDECEK]

huh a #ifdef je na co? vzdyt jsou to otevreny zdrojovy kody, ne? Nebo to zakaze nejaky diktator??

[me vakérav]

Já bych teda nechtěl ve svém zdrojáku mít hromadu #ifdefů, které z toho dělají úplně jiný program. Pokud jsou změny větší, je lepší fork a potom si případně navzájem mergovat změny.

[lukove]

takymto sposobom si urobili fork vyvojary distribucie frugalware ked forkli Pacman dali mu meno pacman-g2

[pavlix]

huh a #ifdef je na co?

Rozhodně ne na to, na co je fork :).

[kavol]

myslíš jako třeba že #ifdef není na honění ega?

[pavlix]

Nejen to.

[Sten]

#ifdef je pro Radka Hulána. Slušní lidé se nesnaží násilím natlačit do nějakého projektu svoje názory, ale udělají fork (kdyby měli git, tak je to totéž jako branch) a pak se uvidí.

[Michal Kubeček]

jak název napovídá, jedná se o fork známého přehrávače MPlayer

IMHO to název moc nenapovídá, ten napovídá spíš novou verzi.

a také vlastní kopie některých knihoven (například FFmpeg

V čem přesně je ten rozdíl? Co jsem si všiml, MPlayer2 si stáhne aktuální ffmpeg z gitu, zatímco MPlayer si… stáhne aktuální ffmpeg z gitu.

[Max]

Přesně tak, toto mně také hned bacilo do oka.
Zdar Max

[elenril]

Původní MPlayer používá neveřejné části ffmpegu, kvůli potřebuje při kompilaci zdrojáky ffmpegu a občas se rozbije, pokud se tam něco změní (v neveřejných částech se samozřejmě neudržuje zpětná kompatibilita).

MPlayer2 už nic takového nedělá, a jde v pohodě zkompilovat oproti sdíleným knihovnám.

[Michal Kubeček]

MPlayer2 už nic takového nedělá, a jde v pohodě zkompilovat oproti sdíleným knihovnám.

…ale dokumentace to důrazně nedoporučuje.

[elenril]

Nějak nevidím kde. Jinak napadá mě důvod proč -- libav* knihovny ve mnoha distribucích jsou z paleolitu a často i osekané. V poslední době se to ale zlepšuje a pokud si člověk kompiluje libav/ffmpeg sám, tak není důvod, aby si mplayer tahal vlastní kopii.

[Espinosa]

Protože ffmpeg je (byl?) projekt prakticky bez release managementu. Taková často opomíjená drobnost, ale pokud je to knihovna na které stojí řada dalších knihoven, frameworků, a koncových programů, je to citlivá záležitost.

Y dob kdz jsem si kompiloval kompletně video střižnu Kdenlive, pamatuji jak uživatelé "kompilanti" škemrali aby to MLT dělalo taky, protože stáhnout aktuální ffmpeg z gitu (tehdy svn) znamenalo sázku do loterie jetli výsledné Kdenlive (stojící na MTL a to na ffmepgu) to bude chodit, přičemž chyby se mohly projevit chybou komplilace (v tom LEPŠÍM případě) okamžitým pádem (stále ta lepší varianta) nebo zákeřnš až po nějaké době nenápadně chybami ve výsledném videu (nejlépe když jste ho několik hodin stříhali a pak vypálili na několik DVD a pak promítali u kamaráda, heh),

Prosili, aby MTL obsahovalo přímo kód ověřené staticky zkompilované verze ffmpegu, verze ověřené že s MLT chodí, tak jak to dělá (dělal?) MPlayer. Protože aktuálné verze z gitu je developerská verze, ale jiná použitelná vlastně neexistuje, protože ta poslední stabilné je příliš stará, distribuce už používají opatchované, neobsahuje důležité fixy, je to takový lepší snapshot o který se už dál nikdo nestará. O tom je release management.

Už vývoj Kdenlive/MLT/ffmepgu nějakou dobu nesleduji, moje informace mohou být zastaralé, třeba se to opravdu dramaticky zlepšilo ;)

[elenril]

Zlepšilo, ffmpeg (nebo ted spíš libav) už vydal dvě stabilní verze (zrovna před pár dny vyšly 0.5.4 a 0.6.2) a brzy se chystá 0.7.

[Grunt]

Protože ffmpeg je projekt prakticky bez release managementu.

A přesto funguje a neposere se z toho. Zázrak nebo spiknutí?

[Mandarinka]

Zázrak nevím, ale na spiknutí už došlo. :) Zřejmě nás v budoucnu čekají změny v chování, ale jaké, to se ukáže tak možná do roka a do dne.

[Grunt]

Jo, ale souvisí s tím také takové maličkosti jakože libavcodec knihovna si alokuje vlastní dekódovací (YUV plane) buffer a než se vlastní obraz vůbec dostane na obrazovku, tak se dvakrát musí zkopírovat v paměti a podobně (zvlášť obdivuhodné v době, kdy ještě nebylo v nouveau pořádně implementované DMA a třetí kopírování dělal Xorg). O téměř znefunkčnění Direct renderingu nemluvě už radši vůbec. Stejně jako o rozhraní byrokratickém tak, že když si dá člověk v gbčku replay, tak může i na 3Ghz procesoru na kafe (a to prosím jen rozhraní, takže volání funkcí předávání parametrů, max. nějaká inicializace a žádné kopírování nebo dekódování dat – ale uznávám, furt lepší než C++). Když jsem se nad tím rozčiloval na IRC naposled, tak byly mnohem větší starosti s tím kdo komu ukradl přístup zápisu na servery (proto asi fork).

[Grunt]

Ale jinak to považuju za pozitivní krok.

[Grunt]

tak se dvakrát musí zkopírovat v paměti

Zapomněl jsem dodat, že pomocí memcpy.

[elenril]

To tohoto sice nedělám, ale co vim tak direct rendering by měl celkem fungovat. Bugreporty?

[Grunt]

Nope. Je tam switch, který to přímo vyřadí a fungovalo tak tak max u VDPAU (jako VO, ne jako dekodér). Nebo aspoň to tak bylo u starého mplayeru. Ale to je jedno.

Bugreporty?

No to určitě. Když jsem v tom hledal já, tak bys musel překopat polovinu rozhraní mplayeru což v menším než nekonečném čase není proveditelné, takže na to docela kašlu. DR je stejně zastaralé, flipnout to v případě DR stejně musíš a nakonec ten memcpy algoritmus je implementovaný v assembleru (takže asi pomocí MMX/SSE), akorát naprd když se dostaneš na architekturu jinou než ve které je to napsané v assembleru.

[elenril]

Err...nechápu - bavíme se o lavc nebo mplayeru?

[Grunt]

lavc měl u mplayeru < 2 wrapper v ??_ffmpeg.c, takže bych snad poznal kdybych byl někde jinde než v mplayer rozhraní k libav*.

[mirec]

Zahozena byla podpora MEncoderu (pracuje se na lepším řešení)

Myslíte, že nové riešenie bude vedieť divočiny ako nadrátovanie titulkov priamo do obrazu?

[Erbureth]

Už by konečně pořádně mohlo.

[Michal Kubeček]

Teď možná úplně nerozumím, ale přesně k tomu mencoder nejčastěji používám (mám BD přehrávač, který umí přehrávat videa z USB flashdisku, ale neumí titulky v samostatném souboru).

[mirec]

Jop, presne pre takéto "inteligentné" zariadenia to človek zvyčajne potrebuje. Našťastie toto zostane, takže aspoň niečo pozitívne. Inak forky moc rád nemám, radšej by som bol keby vývojári spolupracovali a namiesto niekoľkých nástrojov typu tomu chýba toto, tomu zas toto urobili jeden poriadny :(

[elenril]

Ano, viz WIP verze.

What works
    * Encoding at variable frame rate (default)
    * Encoding at constant frame rate using -ofps framerate -oharddup
    * 2-pass encoding (specify pass=1 in the first pass's -ovcopts, specify pass=2 in the second pass)
    * Hardcoding subtitles using vobsub, ass or srt subtitle rendering (just configure mplayer for the subtitles as usual)
    * Hardcoding any other mplayer OSD (e.g. time codes, using -osdlevel 3 and -vf expand=::::1)
    * Encoding directly from a DVD, network stream, webcam, or any other source mplayer supports
    * Using x264 presets/tunings/profiles (either using @profile in the -ovcopts, or using -vpre profile)
    * Deinterlacing/Inverse Telecine with any of mplayer's filters for that
    * Audio file converting: mplayer -o outfile.mp3 infile.flac -novideo -oac libmp3lame -oacopts ab=320k
    * inverse telecine filters (confirmed working: detc, pullup, filmdint)

[David Heidelberg]

Dle mého názoru krok správným směrem

[w4rr10r]

Tahle zprávička (jinak napsaná) tu už před časem byla.

[w4rr10r]

Bang!

[xvasek]

Třeba je to další fork.

[⧠ A = 0]

Fork zprávičky...

[Tomáš Heger (geckon)]

Omlouvám se, nevědel jsem o ní. Zprávičku nechám tak jak je, aby nezmizela diskuse.

[condor]

Ten fork je tu uz mnoho rokov.

[xm]

Mě se hlavně líbí využití sdílených systémových knihoven, použití vlastní kopie ffmpegu (a dalších knihoven) byl největší humus na starém mplayeru. Funguje skvěle i multithreading se systémovým ffmpeg-mt (člověk nemusí mplayer2 patchovat či používat mplayer-mt z gitu jako to bylo nutné u starého mplayeru).

[stativ]

Mplayer2 a mplayer-mt jsou jedno a totéž.

[xm]

No vida! Tak to jsem vlastně mplayer2 (respektive jeho předchůdce, prostě zdrojáky z git://repo.or.cz/mplayer.git) používal už několik let aniž bych o tom věděl! V tom případě je pro mě starý mplayer již definitivně mrtvý. Král je mrtev, ať žije král! Mplayer2 forever!

[Grunt]

Já používal jak z SVN, tak z GITu a abych pravdu řekl tak původně jsem nad tím pořádně dumal, protože se zdá, že i hlavní stránce doporučili jako hlavní repositář GIT. Na druhou stranu v SVN verzi aspoň fungoval Smack (čemuž se popravdě dost divím, protože i skrze sdílené libav* skrze ffplay funguje skvěle).

[mirec]

Ja to nejako striedam. Na starej verzii ide rtp, nový mplayer nevie meniť poradie rtp paketov takže po asi 5s padne. Ale zato sa dá použíť na aké-také 720p.

[xm]

S mplayer-mt (nyní tedy mplayer2) naprosto plynule a bez problémů přehrávám H.264 1080p videa v obvyklé kvalitě (tzn. okolo 11 - 15 Mbps). Ještě jsem se nesetkal s videem, které by mi trhalo. Procesor je dvoujádrový AMD Athlon X2 4850e 2,5 GHz.

[xm]

(ještě dodatek - max. TDP procesoru je 45 W, tzn. není to žádný přežraný bumbrlíček)

[Mandarinka]

K8 je pomalé v SSE2 kódu (má jen poloviční šířku, takže to musí počítat nadvakrát), takže jeho výkon při použití SIMD je dost nízký. Takže to je možná částečné vysvětlení... Jinak závisí také na tom, jaký renderer je použit (directx/xv by nemělo žrát moc cpu, pokud hw akcelerace funguje).

[Grunt]

WTF zas? Na 2.6Ghz Celeronu přehrávám H.264 1080p videa i bez mplayeru-mt. H.264 má asi deset profilů a ještě víc voleb (CABAC/CAVLC,…) komplexnosti kdy na nejnižšším přehraje H.264 1080p snad i můj mobil a na nejvyšším to nedá v reálném čase ani nějaká farma. Nesrovnávej prosím už zas nesrovnatelné.

videa v obvyklé kvalitě (tzn. okolo 11 - 15 Mbps)

Kvalita videa je dána bitrate? A obvyklá kvalita je dosažena při 11 - 15Mbps? Jsem se zase dozvěděl super novinky.

[xm]

Mohu tě ujistit, že ta videa bez multithreadingu plynule nepřehraju, trhají jak blázen (jedině se zapnutím "skiploopfilter=all" jsou některá z nich v 1 threadu plynulá, ale to je za cenu snížené kvality a v některých případech i nepříjemných obrazových artefaktů).

Obvyklou kvalitou mám za mysli obvyklou konfiguraci x264 ve světě BluRay ripů (od známých ripovacích skupin). Tzn. 1080p, průměrný bitrate jak jsem psal mezi 11 - 15 Mbps a profil High@L4.1 nebo High@L5.1.

[xm]

Ještě upřesnění - CABAC požívají prakticky všechny BluRay ripy (výjimky jsou, ale je jich hrozně málo, teď jsem to kontroloval). Profil High@L4.1 silně převažuje nad High@L5.1. Počet referenčních snímků se dost liší (cca 4 - 16), průměr je pohledem okolo 8. Tohle já považuji za "standardní kvalitu" u 1080p videa, protože to je to co se mě týká (a na jednom jádru to plynule v 90% případů nepřehraji).

[Grunt]

CABAC požívají prakticky všechny BluRay ripy

Vzhledem k tomu, že BluRay-Rip není žádný standard, tak se tady o tom můžeme jen hádat. Což bych určitě nechtěl. Jinak ale souhlasím s dodatkem, že dost často je CABAC použit zcela nesmyslně.

Profil High@L4.1 silně převažuje nad High@L5.1.

Pak doporučuji YouTube. Tam je všechno snad už od Levelu 1.b.

Tohle já považuji za "standardní kvalitu" u 1080p videa, protože to je to co se mě týká (a na jednom jádru to plynule v 90% případů nepřehraji).

A vše co se snažím říct já, že takhle jednoduše se to prostě srovnávat nedá. On je třeba rozdíl i ve dvou stejných videiích na YouTube a třeba na Apple Trailerech. Viz třeba benchmark, 100 sekund, jedno Apple Trailer, druhé BDRip Matrixu. Říkat který z nich valí na mém počítači bez problémů a který ne už je asi zbytečné:

VO: [null] 1920x800 => 1920x800 Planar YV12 
V: 100.0   0/  0 81%  0%  0.0% 0 0                                              

BENCHMARKs: VC:  81.831s VO:   0.015s A:   0.000s Sys:   1.145s =   82.991s
BENCHMARK%: VC: 98.6023% VO:  0.0183% A:  0.0000% Sys:  1.3793% = 100.0000%

Exiting... (End of file)

VO: [null] 1920x792 => 1920x792 Planar YV12 
V: 100.0   0/  0 130%  0%  0.0% 0 0                                             

BENCHMARKs: VC: 130.740s VO:   0.016s A:   0.000s Sys:   3.023s =  133.779s
BENCHMARK%: VC: 97.7282% VO:  0.0119% A:  0.0000% Sys:  2.2599% = 100.0000%

Exiting... (End of file)

Prostě a jednoduše, jedno H.264 neexistuje ani omylem a zvlášť v oblasti warezu je různorodost víc než kde jinde (už jsem potkal i Rip o velikosti něco málo přes 100MB a kupodivu to nebylo zas tak strašné), takže nezjednodušujme, nemíchejme jabka a hrušky a neporovnávejme.

[Mandarinka]

Hlavní rozdíl v h264 je CABAC / CAVLC. A skutečně, piráti používají CABAC (a vzhledem k tomu, že většinou taky x264, které defaultně používá 8x8 transformaci, tak z toho vyleze high profile), takže bych souhlasi, že high profile a CABAC je deocela norma.

[Grunt]

Jinak ale souhlasím s dodatkem, že dost často je CABAC použit zcela nesmyslně.

[Mandarinka]

Proč nesmyslně? Pokud nejde o nějaké pracovní video (čili nezáleží na velikosti), ale o konečný produkt, a cílem není nějaká blbá hračka, tak cabac a je jednoduše sakramentsky lepší...

[Grunt]

Dobře. Špatně jsem se vyjádřil. Ne nesmyslně, ale neuváženě. Dost často např. právě videa o rozlišení 1080p jsou zkomprimovaná pomocí CABACu a ten je bohužel výpočetně dost náročný. Takže jestli si mám vybrat mezi 4GB verzí co na své plečce nerozjedu v reálném čase ani omylem a nebo 4.8GB verzí co už by jet mohla, tak neváhám ani vteřinu (těch pár stovek mega už mě nezabije, s místem nevím co dělat a linky už jsou také od dob dial-upu trošku rychlejší). Docela ironicky CAVLC vidím používat u malých rozlišení (tipicky mobilních takže něco jako qcif), kde na tom stejně už moc nezáleží.

[Mandarinka]

No jo, ale s touhle argumentací by se mohlo rovnou říct, že by bylo lepší, kdyby se ripovalo do xvidu... (a lidi to občas říkají).

Já to beru tak, že prakticky každé dvoujádro (vyjma asi potvory dělané na nízkou spotřebu jako ULV core2dua, E-350, etc; možná také slabší P4D) v PC segmentu video s 1080p@CABAC (dejme tomu 10-15mbps) dá. Pokud nedá, není až tak velký problém pořídit za 500-700 (podle novosti respektive jetosti - například 8400gs si o to říká) kartu do pcie která to utáhne. Takže imho je cabac dobrá volba, a u větších rozlišení tím spíš. Dokonce bych si dovolil říct, že použití main/high profile a CABAC je to, co ty všechny HD ripy tak nějak umožnilo, nebo aspoň výrazně zrychlilo jejich nástup, vzhledem k tomu, že lidem na velikosti pořád záleží.

[Grunt]

No jo, ale s touhle argumentací by se mohlo rovnou říct, že by bylo lepší, kdyby se ripovalo do xvidu...

MPEG-4 ASP? Proč ne? Zatím se mi nepodařilo dostat žádné MPEG-4 AVC do takového stavu kdy by bylo méně komplexní než ASP a navíc od dob DivXu 3.11 docela dobře ty implementace pokročily…: Kdybych si měl vybrat mezi 4GB AVC, které mi na mém počítači v reálném čase určitě nepojede a 5GB ASP, které utáhne určitě tak neváhám ani sekundu. 2,8 miliardy operací za sekundu prostě není málo. Komplexnost dekódování je určitě validní parametr, jež musí být zvážen. Jsem všemi deseti pro aby krom kdejakých PSNR kravin bylo udáváno i nějaké PSNR/MIPS, tedy aby byl udáván kompresní poměr na jednotky výkonu.

Já to beru tak, že prakticky každé dvoujádro (vyjma asi potvory dělané na nízkou spotřebu jako ULV core2dua, E-350, etc; možná také slabší P4D) v PC segmentu video s 1080p@CABAC (dejme tomu 10-15mbps) dá. Pokud nedá, není až tak velký problém pořídit za 500-700 (podle novosti respektive jetosti - například 8400gs si o to říká) kartu do pcie která to utáhne. Takže imho je cabac dobrá volba, a u větších rozlišení tím spíš.

Hele, brzdi, brzdi, brzdi. Zatím souhlasím, že jít na to Heronovskou cestou typu nestačí, koupím výkonnější asi bude fungovat, ale není daleko doba kdy výkon se bude rovnat energii (zatím to začíná u různých mobilních zařízení) a to už pak půjde zvyšovat výkon těžko. Prostě naráz do něčeho co se nazývá fyzikální zákony. Ty jdou ochcat velmi těžko. Pak už půjde jen snižovat komplexnost. Proč nezačít rovnou?

Dokonce bych si dovolil říct, že použití main/high profile a CABAC je to, co ty všechny HD ripy tak nějak umožnilo, nebo aspoň výrazně zrychlilo jejich nástup, vzhledem k tomu, že lidem na velikosti pořád záleží.

Sorry s tím já zas moc nesouhlasím. Min. velikosti pro kdejaké úložiště jsou dneska v řádech desítek GB. Rychlosti nějakého O₂ jsou tak min. také v řádech jednotek Mbps, takže velikost IMHO zas tak nesejde jako kdysi. A Ripy v řádech 10-15Mbps nebo i více jsou mi svědkem. To je totálně zbytečné plýtvání místem (z čehož vyvozuju, že když jsou lidi schopni tak plýtvat, tak jim asi na velikosti moc nezáleží). Vždyť pro neseřízené MPEG-4 ASP stačí pro blbý trailer o 1080p 5Mbps jako šlupka (dovolím si tvrdit, že by o uši by to snad dal i MPEG-1/2) aby to bylo téměř transparentní a pokud bychom byly schopni tolerovat menší, ale neobtěžující šumovost jako v případě DVB-T nebo dob DivXu z '98, tak by to mohlo jít ještě o mnoho níž.

[Grunt]

Ono když třeba uvážíš, že Level vůbec nijak nepředepisuje třeba takovou skip lambdu…prostě ne. Nesrovnávat. To mi bohatě bude stačit.

[Grunt]

Mohu tě ujistit, že ta videa bez multithreadingu plynule nepřehraju

To si ale dobrá lama teda. Tím bych se teda moc nechlubil.

edině se zapnutím "skiploopfilter=all" jsou některá z nich v 1 threadu plynulá, ale to je za cenu snížené kvality a v některých případech i nepříjemných obrazových artefaktů

Jen tak pro zajímavost, při tak vysoké bitrate in-loop deblocking filtr vypínám v x264 automaticky, protože to jednak dovede ušetřit spousty času a jednak je to zbytečné (je to jako používat SBR u AAC při bitrate nad 64kbps) a občas si to i tak rozmýšlím, protože radši preferuju kostičky než fleky (postprocesní debloking filt si můžu zapnout na dekodéru vždycky).

[Grunt]

To si ale dobrá lama teda. Tím bych se teda moc nechlubil.

Ne, sorráč. Blbý rýpanec. Nemyslel jsem to nijak urážlivě.

[Mandarinka]

Až na to, že když vypneš loopfilter u h264, tak pěkně zprzníš kvalitu videa.

Pokud ho považuješ za zbytečný, tak je třeba ho vypnout při kódování (a ne, není to dobrý nápad). A ani v takovém případě to rozhodně není analogické použití SBR. V dnešních podmínkách ani zdaleka u videa nikdo nepoužívá dostatečnou bitrate, aby došlo k saturaci. Řekl bych, že jsme možná tak u těch 64kbps při stereo MP3!

Deblocking jako postprocessing je něco zase úplně jiného - to zase video akorát tak ještě víc zprzní.

[Grunt]

Až na to, že když vypneš loopfilter u h264, tak pěkně zprzníš kvalitu videa. Pokud ho považuješ za zbytečný, tak je třeba ho vypnout při kódování (a ne, není to dobrý nápad). A ani v takovém případě to rozhodně není analogické použití SBR.

filtr vypínám v x264

ne u ffh264 pomocí lavdopts. A i tak nesouhlasím. Nekdy ta chyba je sice tak veliká, že se v případě inter-framů se naakumuluje a je viditelná, ale není obtěžující (a s dalším I-framem zmizne).

V dnešních podmínkách ani zdaleka u videa nikdo nepoužívá dostatečnou bitrate, aby došlo k saturaci. Řekl bych, že jsme možná tak u těch 64kbps při stereo MP3!

11-15Mbps nebo >40Mbps jak tady bylo navrhováno? No to ani omylem teda. Zajímavě, že dodnes to v případě MPEG-1/2/(4 ASP) bez toho šlo (oni stejně v té rychlosti nejsou postřehnutelné). Jinak i přínos v případě in-loop smyčky je vzhledem k náročnosti dost diskutabilní.

[mirec]

okolo 11 - 15 Mbps

:D Čo tak skúsiť > 40Mbps? Intel 1 jadro, 1GHz.

[Grunt]

Při takové bitrate je lepší to zakódovat jako sérii JFIF obrázků a s nějakými Ghz si nemusíš dělat starosti vůbec, ne? MPEG-1 při 1080p mi dává Celer nad 666Mhz.

[mirec]

No ide skôr o to na čo človek naďabí ;) Tých 40Mbit som myslel nejaké HD demá, ktoré sa snáď nedajú bez HW akcelerácie prehrať na žiadnom rozumnom hardvéri. Inak book mám takmer čiste pracovný, video na tom takmer nepozerám, ak áno tak som občas u h.264 nútený vypnúť powermanagement a zapnúť aj druhé jadro ...

[Mandarinka]

Ještě nikdo tady neřekl 'anime'.

[Mordae]

Jo, docela se tesim, az si ve Fedore sve anime pustim v mplayer2.

[⧠ A = 0]

Hentai.

[JZD]

Chapadla kam se podíváš se sexi kočkami s velkými prsy. ^_^