Steve Jobs a superpočítač Cray-1 budou vyobrazeny na pamětních jednodolarových mincích vyražených v příštím roce v rámci série Americká inovace. Série má 57 mincí, tj. 57 inovací. Poslední 4 mince budou vyraženy v roce 2032.
Byl zveřejněn průběžně aktualizovaný program konference OpenAlt 2025 o otevřeném softwaru a datech, IT bezpečnosti, DIY a IoT. Konference proběhne o víkendu 1. a 2. listopadu v prostorách FIT VUT v Brně. Vstup je zdarma.
Senát včera opětovně nepřijal návrh ústavního zákona, který měl do Listiny základních práv a svobod zakotvit právo občanů platit v hotovosti nebo být off-line. Návrh předložila skupina senátorů již v roce 2023. Senát dnes návrh neschválil, ale ani nezamítl. Pokud by ho přijal, dostala by ho k projednání Sněmovna a vyjádřila by se k němu vláda.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 13.0 (Mastodon). Forgejo je fork Gitei.
Společnost Eclypsium se na svém blogu rozepsala o bezpečnostním problému počítačů Framework. Jedná se o zranitelnost v UEFI umožňující útočníkům obejít Secure Boot.
Editor kódů Zed (Wikipedie) po macOS a Linuxu s verzí 0.208.4 už běží také ve Windows.
Apple dnes představil 14palcový MacBook Pro, iPad Pro a Apple Vision Pro s novým čipem M5.
Debian pro mobilní zařízení Mobian (Wikipedie) byl vydán ve verzi 13 Trixie. Nová stabilní verze je k dispozici pro PINE64 PinePhone, PinePhone Pro a PineTab, Purism Librem 5, Google Pixel 3a a 3a XL, OnePlus 6 a 6T a Xiaomi Pocophone F1.
Operátor O2 představil tarif Datamanie 1200 GB . Nový tarif přináší 1200 GB dat s neomezenou 5G rychlostí, a také možnost neomezeného volání do všech sítí za 15 Kč na den. Při roční variantě předplatného zákazníci získají po provedení jednorázové platby celou porci dat najednou a mohou je bezstarostně čerpat kdykoli během roku. Do 13. listopadu jej O2 nabízí za zvýhodněných 2 988 Kč. Při průměrné spotřebě tak 100 GB dat vychází na 249 Kč měsíčně.
Byly publikovány informace o útoku na zařízení s Androidem pojmenovaném Pixnapping Attack (CVE-2025-48561). Aplikace může číst citlivá data zobrazovaná jinou aplikací. V demonstračním videu aplikace čte 2FA kódy z Google Authenticatoru.
LinuxOS.sk informuje o projektu mplayer2 – jak název napovídá, jedná se o fork známého přehrávače MPlayer. Podle porovnání by měl lépe zvládat kontejnery Matroska, umožňovat měnit nastavení a spouštět příkazy během pauzy, lépe podporovat VDPAU, přesněji „skákat“ v souboru (po rámcích), opravovat chyby a podobně.
Zahozena byla podpora MEncoderu (pracuje se na lepším řešení), výchozí GUI gmplayer (byla zvolena cesta zlepšování rozhraní pro externí grafické nadstavby) a také vlastní kopie některých knihoven (například FFmpeg nebo libmpeg2). Přechod z původního MPlayeru by měl být bezproblémový podobně jako používání existujících grafických rozhraní.
Tiskni
Sdílej:
huh a #ifdef je na co?Rozhodně ne na to, na co je fork :).
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.
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.
Protože ffmpeg je projekt prakticky bez release managementu.A přesto funguje a neposere se z toho. Zázrak nebo spiknutí?
tak se dvakrát musí zkopírovat v pamětiZapomněl jsem dodat, že pomocí memcpy.
Bugreporty?
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?
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)
videa v obvyklé kvalitě (tzn. okolo 11 - 15 Mbps)
Kvalita videaje dána bitrate? A obvyklá kvalita je dosažena při 11 - 15Mbps? Jsem se zase dozvěděl super novinky.
CABAC požívají prakticky všechny BluRay ripyVzhledem 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.
Jinak ale souhlasím s dodatkem, že dost často je CABAC použit zcela nesmyslně.
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
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 O2 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íž.
Mohu tě ujistit, že ta videa bez multithreadingu plynule nepřehrajuTo 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).
To si ale dobrá lama teda. Tím bych se teda moc nechlubil.Ne, sorráč. Blbý rýpanec. Nemyslel jsem to nijak urážlivě.
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 x264ne 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í.
okolo 11 - 15 Mbps
:D Čo tak skúsiť > 40Mbps? Intel 1 jadro, 1GHz.