Portál AbcLinuxu, 30. dubna 2025 14:09
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.