Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
Prostě o všem o linuxu o životě o práci atd.
mencoder -endpos 10 -tv \ driver=v4l2:device=/dev/video0:normid=0:input=0:amode=0 tv:// \ -o dvd.avi -oac lavc -ovc lavc -lavcopts \ acodec=mp2:vcodec=mpeg2video:vhq:keyint=25:vbitrate=5555:scplx_mask=0.2\ -of mpeg -vf scale=720:528,expand=720:576 -srate 48000Převod nějak probíhal, udělal jsem pár minut testů a dolní pruh stále blikal a byl tam i nějaký chaos v
Tiskni
Sdílej:
>>>Ja si vzpominam, ze na nekterych originalnich VHSkach se delaly "ochrany proti kopirovani"
A uz tehdy lide prisli na to ze je treba jit cestou suntovych znacek (Ambos, Funai ...) videi jez tyto "dokonale" ochrany proste ignorovaly.
Znackove videorekordery (Sony, Thomson, Panasonic) prudily a nechtely nahravat signal z jinyho videa pri kopirovani filmu jez byl chranen. Zkratka se chovaly jako dnes se chova NERO (=NEROzmnozuje). Kterykoli jiny vypalovaci SW bezpripominek zkopiruje jakekoli CD / DVD
Černé pruhy raději ne, a pokud už ano, tak na hranici bloku (tj. dělitelné 16)No a to je právě ta blbost. Černé pruhy vůbec ne, to už radši nedělitelnost šestnácti. Pokud některý rozměr není dělitelný šestnácti, tak se stejně u posledního bloku rozšíří aby šestnácti dělitelný byl a obsah se doplní tím co blok obsahoval jen zrcadlově obráceno aby z toho vznikla nějaká rozumná vlna a při přehrávání se to ořeže do skutečných rozměrů, které jsou zapsány v hlavičce. Ve frekvenční doméně je hrana(kór černá) to nejhorší co může být, protože taková hrana se dá vyjádřit pouze součtem nekonečného počtu koeficientů(u diskrétní varianty konečným počtem, který ovšem zahrnuje komplet celé spektrum) a vzhledem k tomu, že některé koeficienty se vždy zahazují a některé zase vždy kvantizují, tak taková hrana bude mít vliv na celý jeden blok. Je teda pravda, že už jsem se potkal s kodekem co obsah zrcadlově neobrátil, ale prostě rozšířil a doplnil o zelenou barvu(ta pak zespodu prosakovala do videa), ale věřím, že to byla výjimka. Takže klidně ořezat na rozměr nedělitelný šestnácti a pouze v případě, že by z okrajů prosakovalo něco hnusného, tak rozšířit na rozměr dělitelný šestnácti a doplnit o zrcadlově obrácený obsah posledního bloku.
Ten dolny pruh je na VHS informacia ktora sa na VHS nezobrazuje koli nizsiemu poctu riadkov
mplayeru/mencoderu
si stačí v konfiguračním souboru input.conf
namapovat příkaz change_rectangle
, kterým jde za chodu měnit zobrazovaný rámeček v přehrávaném videu. Popis parametrů je v popisu Slave mode protokolu v dokumentaci MPlayeru.
Podmínkou je, aby byl tento filr aktivní, tj. v parmetru -vo
musí být rectangle
s nějakými parametry, třeba pro PAL video rectangle=720:576:0:0
, popř. televizemi oblíbený ořez rectangle=702:576:9:0
.
Já osobně to mám namapované na funkční klávesy, což není moc optimální, ale funguje to:
F1 change_rectangle 0 -1 F2 change_rectangle 0 1 F3 change_rectangle 1 -1 F4 change_rectangle 1 1 F5 change_rectangle 2 -1 F6 change_rectangle 2 1 F7 change_rectangle 3 -1 F8 change_rectangle 3 1
Digitalizoval jsem jednu hodně starou videokazetu do digitální podoby.zajímavé, a dokázal bys digitalizovat i do nějaké jiné podoby, třeba analogové?
Zcela běžný jev. Též jsem jednou nahrával VHSku do počítače a všiml si toho, ale prostě jsem to ignoroval jako běžnou součást té VHSky. Ono je to tam asi běžně (viz. levý a pravý okraj), ale vzhledem k tomu, že s ovládáním paprsku na okrajích obrazovky u CRT je to všelijaké, tak si toho buď nikdo nevšimne a nebo je to ořezáno.
Ono to dokonce není výjimka ani v digitálním záznamu. Třeba v takovém Applu jsou na to přeborníci.
# no ael nezabudnut na rozmer kam to pojde a delitelne 16 neni zle dodrzat takze # v mencodere este pridat okraje na dorovnanie.Nějaký vtipálek?
mencoder -endpos 10 -tv \ driver=v4l2:device=/dev/video0:normid=0:input=0:amode=0 tv:// \ -o dvd.avi -oac lavc -ovc lavc -lavcopts \ acodec=mp2:vcodec=mpeg2video:vhq:keyint=25:vbitrate=5555:scplx_mask=0.2\ -of mpeg -vf scale=720:528,expand=720:576 -srate 48000avidemuxem i tím se to dá dělat. Kde-endlive i cinerrellu celkem znám, již jsem s nimi cosi dělal dopadalo to celkem dobře, akorát zde mne ten pruh celkem dostal. Předtím se nic takového nedělo. Já jsem spíše chtěl vědět co ten pruh, zda se s tím někdo setkal, popř. zda to není rozhozená synchronizace impulsů- :) díky za inspiraci
Proto se snadno edituje, ale stejného výsledku lze dosáhnout třeba s MPEG-4 kodéry tím, že se prostě v nastavení dá počet P snímků na 0 (respektive se vypne odhad pohybu atp.)S tím souhlasím. Rozumná délka GOP, pouze zpětná reference a zero me_method a snad by neměl být problém. Přeci jen v temporální redundanci jsou spousty zbytečných dat. A třeba ještě s Wavelety.
A proč se s tím namáhat (procesorově), když to pak stejně budu převádět dál.Vždyť netvrdím že ne, ale MJPEG na to rozhodně není vhodný. To by musela být sakra vysoká bitrate aby nedocházelo k docela rapidnímu zkreslení, zvláště určenému pro další zpracování. Když se vypne kompenzace pohybu a dopředná reference, tak se to od toho MJPEGu příliš neliší, jen je ve snímcích nedrží pokaždé to samé, ale jen rozdíly mezi snímky. Což dovede ušetřit spousty místa(a u stejné bitrate v porovnání s MJPEGem rozhodně zmenšit zkreslení). Procesorově je o náročnější jen o pár součtů a rozdílů a s krátkými buffery pro udržení právě zpracovávaných GOP by to také nemuselo být o moc složitější než
jen pomocí kopírování dat.
To by musela být sakra vysoká bitrate aby nedocházelo k docela rapidnímu zkreslení, zvláště určenému pro další zpracování.Jak to myslíte?
Když se vypne kompenzace pohybu a dopředná reference, tak se to od toho MJPEGu příliš neliší, jen je ve snímcích nedrží pokaždé to samé, ale jen rozdíly mezi snímky.Jenže pak tam máte ty otravné P a B snímky. Editor by musel umět přepočítat snímek na začátku a konci střihu (a pokud se nemýlím, tak i snímky, které se budou odkazovat na snímky mimo střih) a zbytek jen skopírovat. Umí to nějaký?
Což dovede ušetřit spousty místaTo asi ano, ale těch 60 giga za 8 hodin mi přijde snesitelné, stejně to pak překóduju a smažu.
?Koncem týdne budu mít půjčený DVD recorder, takže se pokusím přes AV kabely propojit AV vstupy a pokusím se to celé nacpat na DVD v co nejlepší kvalitě. Výhoda tohoto řešení, je, že to mohu nechat puštěné přes noc celkem bez dozoru. Každopádně chci zkusit jak bude vypadat záznam z toho DVD-recorderu.
No zase, ale záleží i na tom, kam to nacpe zda do MPEG2 nebo to nacpe do DVD-VIDEO s MPG2 kodekem. No uvidím
Koncem týdne budu mít půjčený DVD recorder, takže se pokusím přes AV kabely propojit AV vstupy a pokusím se to celé nacpat na DVD v co nejlepší kvalitě.Proč kvůli tomu půjčovat DVD-Rekordér? Stejně dobře dovede udělat práci obyčejné PC.
Kvalitanaprosto stejná.
A to je u PC nějaký problém? Nehledě na to, že i můj notebook (ale záleží na parametrech) dovede MPEG-2 kódovat téměř rychlostí přehrávání. Takže proč celou noc? A ještě se to dá projet multi-passem.Výhoda tohoto řešení, je, že to mohu nechat puštěné přes noc celkem bez dozoru.
Jde i o to, že po dobu snímání nebudu muset být u počítače a převod se provede přes noc.
Každopádně chci zkusit jak bude vypadat záznam z toho DVD-recorderu.Pokud si můžu tipnout, tak úplně stejně. Měl by být důvod aby vypadal jinak?
Tak to jsem nepochopil tuplem. Všechno, ať už DVD nebo ten počítač používá naprosto stejné MPEG-1/2. O čem je vlastně řeč?No zase, ale záleží i na tom, kam to nacpe zda do MPEG2 nebo to nacpe do DVD-VIDEO s MPG2 kodekem.
Kamarád má nějaký lepší model DVD-HDD-recorderu, který nahrává přímo do MPG-2. Nevím zda do nativního nebo do DVD-VIDEA s MPG2 kodováním.
Já bych pak jen mohl udělat ořez videa na správnou velikost.Jen bych doplnil, že u perceptuálních kodeků je zakódování→rozkódování→zakódování→rozkódování→… cesta do pekel. Pokud se s daty pracuje, tak by se mělo v bezeztrátové podobě, což je v případě jednoho příkazu téměř bezproblémové. A když už náhodou potřeba je, tak je to lepší ukládat do ffv1 nebo aspoň nějakého formátu co používá DWT.
V podstatě mi šlo jen o vyzkoušení toho recorderu, pokud bude produkovat solidní záznam proč to neudělat i tak?vs
Jak mi kamarád říkal, může se to celé nasnímat i na interní HDD a pak dále s tím nějak pracovat.
Nahrávání dělám do formátu AVI (protože mencoder prakticky nic jiného nezvládne) a do formátu s nejjednodušší kompresí a konstatní bitrate - video do mjpeg (což není totéž co mpeg) a audio do mp3 s CBR.mencoder zvládne i syrové video (RGB nebo YUV), nastavení správného formátu je sice trochu komplikovanější (v případě zájmu zkusím najít použité skripty), nicméně to funguje a není třeba index. Já osobně na grabování z analogové karty používal program
streamer
z balíku XawTV
, kde video šlo do samostatného formátu (Raw YUV) a audio nekomprimovaně do WAVu. S dnešní disky už není problém aní rychlost (pro plný PAL je třeba okolo 20MB/s), ani velikost.
Ale audio bych ponechal nekomprimované až do finální úpravy - vzhledem ke granualitě MP3 rámců (576 samplů) se při sestříhání může zvuk a obraz rozejít, pokud střihací program neumí MP3 překódovávat, zatímco u PCM nic takobvého nehrozí.
mencoder zvládne i syrové video (RGB nebo YUV)Ano, sám s nimi pracuji a pokud nejde o nějaké testování, tak je to jako výměnný formát silně nevhodné. Když už nic tak alespoň komprimované huffmanem(huffyuv formát v ffmpegu) a nejlépe samozřejmě ffv1.
kde video šlo do samostatného formátu (Raw YUV) a audio nekomprimovaně do WAVu. S dnešní disky už není problém aní rychlost (pro plný PAL je třeba okolo 20MB/s), ani velikost.I u projektů jako je ED nebo BBB se používal FLAC. Ten je stejně bezeztrátový a aspoň o 50% menší. Jinak s tím RAWem bych si nebyl tak jistý. 720x576*12*25/1024/1024=118,65234375 Mb/s = 14,83 MB/s což teda IMHO není málo.