Fórum Root.cz
Hlavní témata => Software => Téma založeno: Pavouk106 17. 03. 2014, 19:55:13
-
Ahoj,
snažím se nahrát plochu pomocí příkazu
ffmpeg -f alsa -f x11grab -r 30 -s 1920x1080 -i :0.0 -acodec pcm_s16le -vcodec libx264 -qp 0 -threads 0 output.mkvale nedaří se mi udělat ho lossless, bezztrátový. Chci absolutní zachování barev a ideálně žádnou kompresi.
Netušíte někdo?
(příkaz jsem "opsal" z netu...)
-
Zvolit jiný -vcodec ???
-
Zvolit jiný -vcodec ???
Hm, to má něco do sebe (mělo mě to napadnout, vždyť je to jako se zvukem). Máš nějaký tip?
-
Zvolit jiný -vcodec ???
Hm, to má něco do sebe (mělo mě to napadnout, vždyť je to jako se zvukem). Máš nějaký tip?
Hele, nemám, nikdy jsem to nepotřeboval.
-
https://trac.ffmpeg.org/wiki/x264EncodingGuide#LosslessH.264
-
http://lmgtfy.com/?q=ffmpeg+lossless+codec
-
Kromě volby jiného kodeku je pro to potřeba rychlý disk/pole. Nekomprimované 1920p30 v RGB24 má datový tok 190MB/s.
-
https://trac.ffmpeg.org/wiki/x264EncodingGuide#LosslessH.264
http://lmgtfy.com/?q=ffmpeg+lossless+codec
A zkoušeli jste to? Já totiž jo a to je ten důvod proč se nakonec ptám lidí a nesnažím se to vyčíst...
TIGER: I tak díky za nasměrování.
Kromě volby jiného kodeku je pro to potřeba rychlý disk/pole. Nekomprimované 1920p30 v RGB24 má datový tok 190MB/s.
Heh... dobrý vědět :-) Takže nakonec budu hledat nějakej kompromis.
Úprava původní otázky: Jakej kodek (potažmo nastavení) použít pro celkem slušný zachování barev i kvality? Ideálně bych rád vyzkoušený věci.
-
Problém je v tom, že ty kodeky jsou primárně určené pro TV a tak obvykle pracují se vzorkováním 4:2:0 a navíc v rozsahu hodnot pro složku 16-240, nikoliv 0-255 jako PC. Takže je potřeba se zaměřit na kodeky, které umožňují vzorkování 4:4:4, v nejhorším aspoň 4:2:2, při kterém však už drobný barevný text vypadá rozmazaně a s menší sytostí. 4:2:2 by mělo jít nastavit v mpeg2 i mpeg4, u 4:4:4 netuším. Omezený rozsah hodnot nebývá problém, konverze PC-TV kodek zvládne.
-
pozrel by som sa na huffyuv ffvhuff kodeky ktore ukladaju nekomprimovane YUV video.
-
pozrel by som sa na huffyuv ffvhuff kodeky ktore ukladaju nekomprimovane YUV video.
Používal jsem ho kdysi pod Windows na grabování. Je fajn, ale komprese asi tak 2:1, takže v HD z toho bude pořád pěkná obluda. I když při záznamu plochy by mohl být účinnější.
-
Technicky to muzes ukladat jako sekvenci bitmap - proste budes nekam ladovat pozadovanej pocet obrazku/s. Pokud me skleroza slouzi, tak to dokonce v tyhle podobe defakto primo jde narvat do mkv, pricemz jen definujes pocet snimku/s ... aby prehravac vedel, jak rychle to ma prehravat. Samo je holej nesmysl to ukladat nekomprimovane, protoze i bezztratova komprese ti zmensi vysledek pomerne razantne.
Jinak tu mas nakej postup https://stackoverflow.com/questions/6701805/h264-lossless-coding
-
pozrel by som sa na huffyuv ffvhuff kodeky ktore ukladaju nekomprimovane YUV video.
Používal jsem ho kdysi pod Windows na grabování. Je fajn, ale komprese asi tak 2:1, takže v HD z toho bude pořád pěkná obluda. I když při záznamu plochy by mohl být účinnější.
1680 ... bmp 5M, png 90kB => komprese (neztratova) 1:50 .., realita je takova, ze jpeg nebude o moc mensi, pri mym hokuspokusu (pouzit widli paint) je naopak jpeg znacne vetsi (350kB). To je dany prave tim, ze nekde o fotku, ale o grafiku kde sou ohromny stejnobarevny plochy (a jpeg to vlastne rozbije).
-
ja pouzivam tenhle prikaz:
## nahravani videa z desktopu +0,0 je posunuti obrazu v ose x a y
ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+0,0 -vcodec huffyuv test.avi
pred editaci v cinelere to jeste konvertuju do png.
je to bezstratovy jenom se podle mne zmneni barevna paleta (z puvodni rgb do yuv a pak pokud to budes konvertovat do png tak zase do rgb) zmnena barev ale neni (alespon pro mne) okem postrehnutelna.
-
ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+0,0 -vcodec huffyuv test.avi
Vyzkouším. Kolik si to vezme (třeba za minutu) místa? :-)
Jinak zachytávat se chystám obecně obraz, ne plochu nebo terminál (takže žádný PNG výhody apod.). Jsem zvedavej, jestli to doplácám do nějakýho použitelnýho stavu (aby obraz za něco stál a přitom nesežral místo za minutu). Na textu to testuju, je tam krásně vidět jak jsou barvy a detaily v hajzlu...
Nadále uvítám nápady, jak zachytávat obraz tak, aby nebyly rozhozený barvy a byl dostatečně detailní. Klidně s kompresí, ale "hezky".
-
1680 ... bmp 5M, png 90kB => komprese (neztratova) 1:50 .., realita je takova, ze jpeg nebude o moc mensi, pri mym hokuspokusu (pouzit widli paint) je naopak jpeg znacne vetsi (350kB). To je dany prave tim, ze nekde o fotku, ale o grafiku kde sou ohromny stejnobarevny plochy (a jpeg to vlastne rozbije).
To je výsledek konverze v grafickém programu, kdy je času dost. Při grabování je problém ještě v tom, že tuhle konverzi je potřeba stihnout 30x za vteřinu, takže žádná větší komplexnost není možná. Nagrabovat to nekomprimovaně a pak pustit konverzi dává proto lepší výsledky.
-
z mych skusenosti ma bezstratove video cca 2gb/min zalezi na rozliseni a frameratu. v dobe kdy jsem mel jeste upc a linku z malym uploadem jsem dycky videa pred nahranim na utube prekonvertoval, pouzil jsem treba tenhle prikaz:
ffmpeg -r 20 -i dwarf00%4d.png -i ../dwarf.mp3 -c:v libx264 -preset slow -crf 5 ../dwarf2.mkv
vysledny sopubor mel asi 12 mb a po te co jej utube znovu prekonvertoval tak to porad vypada slibne viz:
http://www.youtube.com/watch?v=3lBQoe1hihc
zajimavy je parametr crf:
Constant Rate Factor (CRF)
This method allows the encoder to attempt to achieve a certain output quality for the whole file when output file size is of less importance. This provides maximum compression efficiency with a single pass. Each frame gets the bitrate it needs to keep the requested quality level. The downside is that you can't tell it to get a specific filesize or not go over a specific size or bitrate.
1. Choose a CRF value
The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn't technically lossless.
The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.
Note: The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using with x264 --help listed under Output bit depth. 8-bit is more common among distributors.
-
1680 ... bmp 5M, png 90kB => komprese (neztratova) 1:50 .., realita je takova, ze jpeg nebude o moc mensi, pri mym hokuspokusu (pouzit widli paint) je naopak jpeg znacne vetsi (350kB). To je dany prave tim, ze nekde o fotku, ale o grafiku kde sou ohromny stejnobarevny plochy (a jpeg to vlastne rozbije).
To je výsledek konverze v grafickém programu, kdy je času dost. Při grabování je problém ještě v tom, že tuhle konverzi je potřeba stihnout 30x za vteřinu, takže žádná větší komplexnost není možná. Nagrabovat to nekomprimovaně a pak pustit konverzi dává proto lepší výsledky.
... to je jen a vyhradne otazka vykonu CPU/GPU ... standardni desktop dneska vetsinou zvladne bezproblemu komprimovat fulhd v realnym case. Navic pouzivani ztratovych algoritmu je o poznani narocnejsi. V kazdym pripade ukladat 200MB/s je v domacich podminkach, pripadene podminkach maly/stredni firmy naprosto mimo realitu. Tohle ti neda ani low range diskovy pole.
-
Asi jsem měl na začátku prostě a jednoduše říct, že chci zachytit FullHD hru v realtime na normálním počítači v relativně dobrý kvalitě. "Relativně" znamená v praxi to, že by to mělo být co nejpodobnější skutečnýmu obrazu. Mám k dispozici Core i5-750 (fyzický čtyřjádro, 2,66GHz), 8GB RAM a nic moc disk (budeme uvažovat o 60MB/s a kapacitě 50GB, vyhradím na to starší kousek, bude jen na zachytávání). Chci zachytit alespoň 15 minut záznamu.
Takže v tomhle místě restartuju otázku a odpovědi :-)
(Pro Petra: Pokud by to bylo možný, šlo by zašmodrchat tenhle příspěvek i do toho úvodního? Aby případný nově příchozí věděli na co odpovídat... Díky)
-
... to je jen a vyhradne otazka vykonu CPU/GPU ... standardni desktop dneska vetsinou zvladne bezproblemu komprimovat fulhd v realnym case. Navic pouzivani ztratovych algoritmu je o poznani narocnejsi. V kazdym pripade ukladat 200MB/s je v domacich podminkach, pripadene podminkach maly/stredni firmy naprosto mimo realitu. Tohle ti neda ani low range diskovy pole.
160MB/s pro nekomprimovaný záznam 1080i50 (karta Decklink) mi dává už roky pole 4xSATA v Raid0. Původně jen z 320GB disků, dnes 4x1TB pod XP. Na doma to moc není, ve firmě zcela bez problémů.
-
a co tohle? - http://en.wikipedia.org/wiki/FFV1
-
a co je to za hru? jestli je to 3dcko na zpusob open areny tak to ffmpegem uspokojive nepude nikdy, ale budes muset pouzit glc-capture
-
a co tohle? - http://en.wikipedia.org/wiki/FFV1
Radsi neco co ma inter-frame prediction. Intra-frame Ti bude znovu zapisovat/prenaset data z cele obrazovky, kdyz jen hyber kurzorem mysi.
Asi bych dal prednost tomu H.264 Lossless...
-
a co je to za hru? jestli je to 3dcko na zpusob open areny tak to ffmpegem uspokojive nepude nikdy, ale budes muset pouzit glc-capture
Je to X3. GLC vypadá dobře. Doteď jsem myslel na ffmpeg kvůli tomu, že je to docela univerzální...