Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Je to stále omílaný problém, ale stále jej hodně lidí ignoruje, takže si budeme muset nuceně zopakovat, co je to formát videa/audia a kontejner.
Video soubor se velmi jednoduše řečeno skládá z těchto částí:
Když se vás tedy někdo zeptá, v jakém formátu máte nějaké video, tak informace o kontejneru je spíše irelevantní (mám to v avi, mkv apod.) a důležitější je informace o formátu, ve kterém byla video a audio stopa encodována (mám to v H.264 a AAC).
Nějaký rozsáhlejší text je třeba: Multimediální kontejner, Kontejner, Matroska: multimédia v úhledném balíčku
Nejvíce se dnes používá toto:
BD-Ripy
MPEG-4 AVC, H.264 + AC3, DTS a to celé zabalené do kontejneru matroska (mkv)
Web
MPEG-4 AVC, H.264 + AAC + flv kontejner
Youtube
MPEG-4 AVC, H.264 + AAC + MP4 kontejner
MPEG-4 AVC, H.264 + AAC + flv kontejner
VP8 + Vorbis + webm kontejner
FFmpeg známe všichní, je to kolekce svobodného multiplatformního software, která nám přinesla možnost kódovat/dekódovat/převádět aj. pracovat s A/V streamy. Od začátku se jednalo o velmi kvalitní projekt, který nejen toto všechno umožnil na Linuxu, ale i na Windows a jiných platformách. Tento projekt stále žije a implementuje nové a nové funkce. A jak už to bývá, voda se občas vře, a tak se nám situace trochu komplikuje.
Libav je fork FFmpegu, zde na AbcLinuxu o tom bylo několik zmínek: Libav: fork FFmpegu, Libav 0.7, Libav 0.8
Podle některých jazyků jsou lidi kolem Libav ti hodní, kterým by se mělo fandit. Stručný souhrn událostí (pohled z jedné strany):
Co tedy teď? Pro co se rozhodnout? Dáme Libav šanci? Kdo do poslední chvíle neví, tak nechť to přenechá náhodě hlava(FFmpeg)/orel(Libav): Dice
Ne, na minci mi nepadla hlava, ale dáme šanci oběma projektům. Začneme tedy starou klasikou, projektem FFmpeg.
Jak dostat do debianu nějakou novější verzi FFmpeg místo postarší distribuční?
ffmpeg -version FFmpeg version SVN-r0.5.6-4:0.5.6-3, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --extra-version=4:0.5.6-3 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libdirac --enable-libgsm --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-runtime-cpudetect --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libfaad --enable-libdc1394 --enable-shared --disable-static libavutil 49.15. 0 / 49.15. 0 libavcodec 52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Dec 31 2011 16:14:46, gcc: 4.4.5
Jednoduše, nainstalujeme si FFmpeg z debian-multimedia, vizte http://wiki.debian.org/MultimediaCodecs.
Přesně tedy takto, nejdříve přidáme další repositář do balíčkovacího systému:
nano /etc/apt/sources.list deb http://www.debian-multimedia.org squeeze main non-free
Ještě je potřeba přihodit klíče, ať máme do budoucna aspoň nějakou úroveň zabezpečení ze zmíněného repositáře :
wget http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2010.12.26_all.deb dpkg -i debian-multimedia-keyring_2010.12.26_all.deb
Nyní už jen stačí nainstalovat FFmpeg a nezbytné věci kolem :
aptitude update aptitude install ffmpeg lame faad x264 w64codecs libvpx0 libtheora0
ffmpeg -version ffmpeg version , Copyright (c) 2000-2011 the FFmpeg developers built on Jan 13 2012 08:07:42 with gcc 4.4.5 configuration: --enable-libdc1394 --prefix=/usr --extra-cflags='-Wall -g ' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-avfilter --enable-libdirac --disable-decoder=libdirac --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-libvpx --enable-librtmp --extra-libs=-lgcrypt --disable-altivec --disable-armv5te --disable-armv6 --disable-vis libavutil 50. 43. 0 / 50. 43. 0 libavcodec 52.123. 0 / 52.123. 0 libavformat 52.111. 0 / 52.111. 0 libavdevice 52. 5. 0 / 52. 5. 0 libavfilter 1. 80. 0 / 1. 80. 0 libswscale 0. 14. 1 / 0. 14. 1 libpostproc 51. 2. 0 / 51. 2. 0
Na Libav si ukážeme kompilaci ze zdrojových kodů, která je velmi primitivní a lze takto samozřejmě postupovat i u projektu FFmpeg. U GNU/Debian Lenny se musely kompilovat všechny potřebné knihovny okolo, protože nebyly v repositáři „debian-multimedia“, ale u Squeezeho je to jiná káva, vše máme připraveno, takže se můžeme zabývat jen Libav.
Jen ještě připomenu, že repositář „debian-multimedia“ máme přidaný, jen jsme nic zatím neinstalovali a kdo instaloval, tak si zase odinstaluje :
aptitude remove ffmpeg
Nejdříve budeme potřebovat potřebné balíčky a vývojové nástroje :
aptitude install build-essential checkinstall yasm libtheora-dev libtheora0 libx264-dev libx264-118 libvpx0 libvpx-dev rtmpdump libopencore-amrnb-dev libopencore-amrwb-dev libmp3lame-dev libvorbis-dev libxvidcore-dev libopenjpeg-dev libfaac-dev libspeex-dev libdirac-dev libavc1394-dev libschroedinger-dev libx11-dev libgsm1-dev librtmp-dev libdc1394-22-dev libavutil-dev
Stáhneme si poslední verzi Libav, rozbalíme a jdeme na to:
wget -c http://libav.org/releases/libav-0.8.tar.gz tar xvfz libav-0.8.tar.gz cd libav-0.8 ./configure --enable-libdc1394 --prefix=/usr --extra-cflags='-Wall -g ' --enable-shared --enable-libmp3lame --enable-gpl --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --enable-avfilter --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-libvpx --enable-librtmp --disable-altivec --disable-armv5te --disable-armv6 --disable-vis --enable-libgsm --disable-debug make checkinstall --pkgname=libav --pkgversion "0.8.0`date +%Y%m%d`" --backup=no --default --maintainer=max@devaine.cz --install=no dpkg -i libav_0.8.*_amd64.deb
Tak, máme nainstalováno, jen to tedy zkoukneme:
ffmpeg -version ffmpeg version 0.8, Copyright (c) 2000-2011 the Libav developers built on Jan 27 2012 23:33:18 with gcc 4.4.5 This program is not developed anymore and is only provided for compatibility. Use avconv instead (see Changelog for the list of incompatible changes). ffmpeg 0.8 libavutil 51. 21. 0 / 51. 21. 0 libavcodec 53. 34. 0 / 53. 34. 0 libavformat 53. 20. 0 / 53. 20. 0 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 15. 0 / 2. 15. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 52. 0. 0 / 52. 0. 0
Jednoduše řečeno, spouštěč s názvem ffmpeg máme, ale s varováním, že již existují nekompatibilní změny a máme použít rovnou avconv, který ho nahrazuje. K přejmenování došlo u těchto nástrojů :
ffmpeg -> avconv
ffplay -> avplay
ffprobe -> avprobe
ffserver -> avserver
avconv -version avconv version 0.8, Copyright (c) 2000-2011 the Libav developers built on Jan 27 2012 23:33:18 with gcc 4.4.5 avconv 0.8 libavutil 51. 21. 0 / 51. 21. 0 libavcodec 53. 34. 0 / 53. 34. 0 libavformat 53. 20. 0 / 53. 20. 0 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 15. 0 / 2. 15. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 52. 0. 0 / 52. 0. 0
Na seznam podporovaných kodeků a formátů kontejnerů, které je schopné avconv kodovat a dekodovat, se můžeme podívat takto :
# seznam kodeků avconv -codecs # seznam formátů kontejnerů : avconv -formats
Jelikož budeme pracovat s A/V, tak by nebyl špatný nástroj, který by uměl číst metadata z A/V souborů. Mediainfo v tomto ohledu není vůbec špatný a je stále vyvíjený. Můžeme si ho tedy naistalovat:
wget -c http://dfn.dl.sourceforge.net/project/zenlib/ZenLib/0.4.23/libzen0_0.4.23-1_amd64.Debian_6.0.deb wget -c http://garr.dl.sourceforge.net/project/mediainfo/binary/libmediainfo0/0.7.51/libmediainfo0_0.7.51-1_amd64.Debian_6.0.deb wget -c http://freefr.dl.sourceforge.net/project/mediainfo/binary/mediainfo/0.7.51/mediainfo_0.7.51-1_amd64.Debian_6.0.deb dpkg -i libzen0_0.4.23-1_amd64.Debian_6.0.deb dpkg -i libmediainfo0_0.7.51-1_amd64.Debian_6.0.deb dpkg -i mediainfo_0.7.51-1_amd64.Debian_6.0.deb
Použití je pak velmi jednoduché :
mediainfo WebM-demo.webm General Complete name : WebM-demo.webm Format : WebM Format version : Version 2 File size : 1.12 MiB Duration : 36s 459ms Overall bit rate mode : Variable Overall bit rate : 257 Kbps Writing application : google Writing library : google Video ID : 1 Format : VP8 Codec ID : V_VP8 Duration : 36s 458ms Bit rate : 110 Kbps Width : 854 pixels Height : 480 pixels Display aspect ratio : 16:9 Frame rate : 24.000 fps Compression mode : Lossy Bits/(Pixel*Frame) : 0.011 Stream size : 488 KiB (43%) Language : English Default : Yes Forced : No Audio ID : 2 Format : Vorbis Format settings, Floor : 1 Codec ID : A_VORBIS Duration : 36s 459ms Bit rate mode : Variable Bit rate : 128 Kbps Channel(s) : 2 channels Sampling rate : 44.1 KHz Compression mode : Lossy Stream size : 570 KiB (50%) Language : English Default : Yes Forced : No
Mediainfo není samozřejmě nic povinného, vše lze udělat i třeba za pomocí mplayeru, ale není to tak pěkné a neumí toho tolik :
mplayer -vo null -ao null -frames 0 -identify WebM-demo.webm MPlayer2 c4093e7 (C) 2000-2011 MPlayer Team 162 audio & 361 video codecs mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing WebM Demo with Leonardo Dicaprio - Shot with Red Camera.webm. Cache fill: 13.95% (1169840 bytes) ID_VIDEO_ID=0 [mkv] Track ID 1: video (V_VP8), -vid 0 ID_AUDIO_ID=0 ID_AID_0_LANG=und [mkv] Track ID 2: audio (A_VORBIS), -aid 0, -alang und [mkv] Will play video track 1. Detected file format: Matroska VIDEO: [VP80] 854x480 24bpp 24.000 fps 0.0 kbps ( 0.0 kbyte/s) Load subtitles in . ID_FILENAME=WebM-demo.webm ID_DEMUXER=mkv ID_VIDEO_FORMAT=VP80 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=854 ID_VIDEO_HEIGHT=480 ID_VIDEO_FPS=24.000 ID_VIDEO_ASPECT=0.0000 ID_AUDIO_FORMAT=vrbs ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=44100 ID_AUDIO_NCH=2 ID_START_TIME=0.00 ID_LENGTH=36.46 ID_SEEKABLE=1 ID_CHAPTERS=0 [ass] auto-open ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Asking decoder to use 4 threads if supported. Selected video codec: [ffvp8] vfm: ffmpeg (FFmpeg VP8) ========================================================================== ID_VIDEO_CODEC=ffvp8 ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->176400) ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=44100 ID_AUDIO_NCH=2 Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis) ========================================================================== AO: [null] 44100Hz 2ch s16le (2 bytes per sample) ID_AUDIO_CODEC=ffvorbis Starting playback... Exiting... (End of file) ID_EXIT=EOF
Něco podobného umí i ffprobe/avprobe:
avprobe -show_streams -show_format WebM-demo.webm avprobe version 0.8, Copyright (c) 2007-2011 the Libav developer built on Jan 27 2012 23:33:18 with gcc 4.4. [matroska,webm @ 0x12e2740] Estimating duration from bitrate, this Input #0, matroska,webm, from 'WebM-demo.webm': Duration: 00:00:36.45, start: 0.000000, bitrate: Stream #0.0: Video: vp8, yuv420p, 854x480, PAR 1:1 DAR 427:240, 24 fps, 24 tbr, 1 Stream #0.1: Audio: vorbis, 44100 Hz, stereo, s16 ( [STREAM] index=0 codec_name=vp8 codec_long_name=On2 VP8 codec_type=video codec_time_base=1/1000 codec_tag_string=[0][0][0][0] codec_tag=0x0000 width=854 height=480 has_b_frames=0 pix_fmt=yuv420p level=-99 r_frame_rate=24/1 avg_frame_rate=1312499997/54687499 time_base=1/1000 start_time=0.000000 duration=N/A [/STREAM] [STREAM] index=1 codec_name=vorbis codec_long_name=Vorbis codec_type=audio codec_time_base=0/1 codec_tag_string=[0][0][0][0] codec_tag=0x0000 sample_rate=44100.000000 channels=2 bits_per_sample=0 r_frame_rate=0/0 avg_frame_rate=0/0 time_base=1/1000 start_time=0.000000 duration=N/A [/STREAM] [FORMAT] filename=Webm-demo.webm nb_streams=2 format_name=matroska,webm format_long_name=Matroska/WebM file format start_time=0.000000 duration=36.459000 size=1169840.000000 bit_rate=0.000000 [/FORMAT
Kdo má ještě GNU/Debian Lenny, tak zde jsou moje poznámky z dob minulých, jak jsem bojoval s nasazením na jeden server (holt požadavek zákazníka): lenny-ffmpeg-git-howto.txt
Dnes to bylo přecijen takové hodně informativní a moc jsme si s ničím nepohráli, ale aspoň jsme připraveni. Příště by to mělo být mnohem lepší. Ukážeme si nějaké vzorové příklady pro převod videa, nějaké tipy, na co si dát pozor, zmíníme se o nějakých přehrávačích, povíme si něco o youtube a mnoho dalšího.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Když už se nakouslo téma "kontejner formát kodek", nemohl by někdo poradit nástroj pro práci s kontejnery videa a audia? Např když bych chtěl překontejnerovat mkv do mp4, flac do ogg a tak podobně?Tohle umí avconv nebo ffmpeg, takže předpokládám, že o tom bude další díl.
Díky za odpověď. Taky jsem slyšel, že HC Encoder je nejlepší freewareový mpeg2 encodér. Ale už neumím posoudit o kolik je lepší tj. jestli se vyplatí ho používat, protože to není komplet soft, kterému bych předhodil video i se zvukem (z DV kamery) a výsledkem bylo mpeg2 (DVD kompatibilní) video. Kvůli jednoduchosti používám HCbatchGUI a rebootuji k vůli němu do Windows (tam je jednodušší instalace).
Proč mpeg2 nepoužíváš? Co používáš?
Proč mpeg2 nepoužíváš?Já proto, že existují formáty, které jsou o dost dál.
Co používáš?H.264. Ne každý lpí na lesklých placičkách (DVD), ještě k tomu aby je přehrával v hardwarovém přehrávači, který neumí nic lepšího…
Jaký nastavuješ bitrate?Vzhledem k tomu, že je pro mé skromné potřeby irelevantní VBV a podobná omezení, tak tomu dávám tolik, kolik tomu dá x264 (--crf ...), s tím, že někdy jsem nucen činit kompromisy, je-li zdrojové video příliš nenažrané (snažím se udržet pod cca 3000-3500 kbps pro ~dvd rozlišení/24fps). Ale x264 dokáže udržet rozumnou kvalitu i při o hodně nižším toku, to jen já jsem tak velkorysý (obsedantní...).
Právě, když dneska není tlak na kapacitu, tak proč ne mpeg2?
Někde jsem zahlédl nějaké komentáře o tom, jaký typ chyby zavádí H.264 a vydedukoval jsem si z toho myšlenku, že moderní komprimační mechanismy (H.264 apod.) vyrobí video o malém bitrate s dobrou kvalitou, ale vždy je trochu horší než mpeg2 s velkým bitrate.
Někde jsem zahlédl nějaké komentáře o tom, jaký typ chyby zavádí H.264 a vydedukoval jsem si z toho myšlenku, že moderní komprimační mechanismy (H.264 apod.) vyrobí video o malém bitrate s dobrou kvalitou, ale vždy je trochu horší než mpeg2 s velkým bitrate.
To určitě není pravda. Viděl bych tu minimálně 2 důvody:
1) mpeg2 má některé technické nedostatky, které tomuto brání. Jako první mě napadá absence weighted prediction, takže když máte stmívačky rztmívačky (nebo například osvětlení měnící barvu), tak enkodér nezvládá predikci, má tuny residuálu a výsledkem je kopa artefaktů nebo rovnou bloků. H.264 umožňuje weighted prediction (zkrátka uloží multiplier/offset - IIRC - který se aplikuje na predikovanou hodnotu, a hned je residual mnohem menší). Dále, mpeg2 nemá bit-exaktní DCT/iDCT, takže dekodér může mít drobnou odchylku od výsledku, s kterým pracuje enkodér. V rámci jednoho framu to může být jedno, ale tato chyba se pak kumuluje predikcí v dalších framech (jeden z důvodů, proč mpeg2 obvykle používá krátký interval mezi klíčovými snímky). Něco, čím si nejsem jistý je maximální vzdálenost, o kterou můžou predikovat pohybové vektory, viděl jsem na DVD scény, které byly prostým globálním posuvem nehybného obrazu, ale i prři vysoké bitrate v tom byla kupa bloků. Je však možné, šlo o selhání enkodéru, který neviděl 'dost daleko'.
2) není důležitý jen formát, ale i enkodér. x264 je v současnosti určitě nejpokročilejší enkodér, a tyto schopnosti nejsou dobré jenom k tomu, aby se dosáhlo nejnižší možné velikosti, ale i pro to, aby kvalita na konstantní velikosti rostla, to, že by H.264 nějak snižovala strop dosažitelné kvality myslím nehrozí, spíš i naopak... x264 je určitě pokročilejší než HC Encoder nebo jiné mpeg2 nástroje.
Jestli mi nevěříte, tak zkusím vysvětlit, proč by to tak mělo být: komprese probíhá tak, že se nejprve najde pohyb, aby se daly budoucí snímky predikovat z předchozích. V tomto kroku má h264 výhodu, protože dokáže používat menší plošky (4x4,4x8,8x4,8x8,8x16,16x8), takže dokáže predikovat přesněji. Také má vyvinutější intra predikci, která zase něco přihodí do mlýna. A výhodu tu také budou mát velmi sofistikované enkodéry - jako je x264. V dalším kroku vezmeme rozdíl mezi predikovaným framem a zdrojem - residual. Čím lépe jsme si v předchozím kroku vedli, tím méně dat bude tento rozdíl obsahovat. V třetím kroku pak tento rozdíl transformujeme (DCT/"HCT") a protože těch dat bude hodně, tak některé koeficienty umažeme (quantization), snažíce se přitom, aby efekt toho byl co nejméně znatelný. Zde vlastně dochází ke ztrátové kompresi. Čím pokročilejší byl náš formát, tím méně zde tedy musíme tlačit na pilu. To, kolik, a kterých koeficientů enkodér vypustí je pak ta nejhorší část, kde se toho dá hodně posrat :) Takže v tomto kroku je důležitý pokročilý enkodér. Následující krok (entropy coding, který operuje nad údaji predikujícími frame a těmi koeficienty transformovného residuálu, které nebyly vypuštěny) už je bezeztrátový, takže nás nezajímá (ale v h.264 je tato bezeztrátová komprese také účinnější).
A teď k té otázce, jestli může pokročilejší formát znamenat, že už se sníží maximální dosažitelná kvalita. V principu je to možné u špatného enkodéru, ovšem špatný enkodér staršího formátu taky bude mít špatné výsledky, takže... Když se podíváte na předchozí odstavec, tak vidíte, že v krocích provádějících predikci nemohou pokročilé techniky h.264 uškodit, protože jakákoliv chyba bdue opravena residuálem. Naopak starší techniky v mpeg2 nebudou tak úspěšné a residuálu bude víc. Čili mpeg2 bude muset víc vypouštět koeficienty, což přímo zasahuje kvalitu. Co se týče té kvantizace, tak mi není známo, že by formát h.264 v tomto ohledu zaváděl něco, co by ubližovalo kvalitě, a navíc dobrý enkodér se v tomto kroku může různým nebezúpečím vyhnout. Tzv. adaptive quantization je zdá se skoro nejdůležitější částí jakéhokoliv slušnějšího enkodéru...
Existuje jedna vyjímka z toho, co jsem řekl, a tou je loopfilter - ten je aplikován až po na celkově hotový snímek, takže v principu může umazat nějaké detaily, které v snímku byly (a už ho residual nemůže opravit). Jenže tento filtr je poměrně dobře vyvážen, jeho síla závisí na síle kvantizace (pokud má blok qp 15 a lepší, neprovede se už vůbec), takže moc neškodí, navíc dobrý enkodér si ho dokáže pohlídat tak, že kdyby někde škodil, sníží qp příslušného bloku, aby se loopfilter oslabil nebo vypnul. Moje zkušenost je taková, že to funguje dobře a škody skutečně nevznikají (oni ti týpci z H.264 a MPEGu nejsou úplně na kočku, heh).
TL;DR
1. x264 je nejlepší současný enkodér (a h.264 nej formát). Není reálné, že by způsobil problémy s kvalitou, které by mpeg2 nepostihly v prvé řadě, a navíc mnohem hůře.
2. Lepší komprese znamená, že máme zdrojů k upotřebení, takže naše video bude vypadat lépe.
3. Lepší enkodér opět přináší více zdrojů k upotřebení -> lépe vypadající video. Naopak špatný enkodér může škodit i když použije spoustu bitů (prostě prosto, že něco zmrví).
(4. Ona ta velikost skoro nikdy není neomezená, takže ten přístup "stačí zvednout bitrate" snadno selže. Příklad: max. bitrate u DVD je 9.8kbps při 720x576 nebo 720x480, a přesto to kolikrát dopadá špatně. Důležité ovšem také je, že náročné scény můžou potřebovat mnohonásobně vyšší tok než je průměr.)
Opravu velice moc děkuji za tak obšírnou odpověď. Hlavně za tu pasáž jak to funguje. Je to pěkně lidsky napsané. Přesvědčilo mne to přestat encódovat do mpeg2. Před 2-3 lety, kdy jsem tu svou úvahu dělal bylo v mém okolí pořád hodně lidí používajících DVD. Dneska už jsme zase někde jinde. Druhým důvodem byla právě ta moje úvaha.
Byl bych Ti také vděčný pokud bys mi poradil jak nejlépe překódovat video z DV kamery (video: dvsd 720x576 a 25 snímků za sekundu s bitrate nějakých 28,8 Mbit/s, audio: stereo pcm 16 bit a vzorkování 48 kHz v kontejneru avi type-2). Kodek je mi jasný (x264), ale jak ho v tomto případě nastavit. Na nějakém tom Mbit/s mi nezáleží, ale HD se z toho stejně nedá udělat. Existuje nějaká hranice pro tak veliký obraz, že se dá říci, že další zvyšování bitrate už nemá smysl?
Docela zajímavé by bylo zkusit bezztrátový profil h.264 :).
Ještě jsem si znovu prošel odpovědi a našel že už jsi o tom něco psal "--crf" parametr pro řízení bitrate. Je pěkně popsaný na této stránce: http://mewiki.project357.com/wiki/X264_Settings#crf. Zajímavé je, že je to jednoprůchodové.
Je tam také uvedeno, že pro bezztrátové video použít --qp 0 nebo --crf 0 s tím, že prý optimalizace na qp dává video se stejnou kvalitou, ale větší soubor.
prý optimalizace na qp dává video se stejnou kvalitou, ale větší soubor.
Pozor, tohle platí jenom pro ztrátovou kompresi. S tím, že --qp je šmejd, který se hodí pouze na debugování, takže to určitě nepoužívat (prostě kvantizuje všechny bloky stejnou měrou - vůbec nefunguje adaptive quantization a podobně, což je velmi neoptimální pro vzhled)
--crf 0 a --qp 0 je speciální, protože oboje znamená bezeztrátovou kompresi, čili že se přeskočí transformace, kvantizace i loopfilter (tedy při 8bitovém kódování; pokud kódujete do high 10 profile, tak bude crf 0 ještě ztrátové, ale to je detail)
Jinak bezeztrátová komprese v reálu užitečná není, protože bitrate bude několikanásobně vyšší (než u pomyslného nekomprimovaného videa) - většinou to vyjde hůř než (už komprimovaný) zdroj.
Co se týče nastavení, tak to je dost jednoduché, protože defaultní nastavení jsou slušná (pokud používáte x264 cli), a stačí používat presety: například --preset veryslow (ne ještě nejpomalejší, ale prakticky maximální kvalita ), psychovizuální optimalizace jsou také v defaultu nastavené rozumně, tedy --psyrdo 1.0:0.0 --aq-mode 1 --aq-strength 1.0. Co se týče crf, tak tam je to trošku složitější, protože zdrojová videa se liší typem nebo i případ od případu, a hlavně lidé mají různé nároky. Defaultní nastavení crf je zaměřené na malou velikost (23), tam už je snadné vidět artefakty a ztráty. Za takový střed se často považuje 18, ale zlepšení lze pozorovat minimálně až do crf 15 až 14 (což už často soubor docela nafukuje). Jinak se doporučuje si to vyzkoušet, a to tak, že si vyberete nějaký nízký crf a pak ho zvyšujete, dokud vám výsledek ještě vyhovuje. Eventuálně, když je člověk rozhazovačný, tak obráceně, a rozhodnout se, jak dlouho ještě to zvyšování bitrate má smysl nebo je únosné.
Zkusil jsem x264 --qp 0 -o out.mkv in.avi
a video je větší než originál 1,1 GiB > 2,7 GiB. Na konci byly informace "encoded 13475 frames, 6.11 fps, 43571.93 kb/s". Pokud se nemýlím, tak se u DV kamery udává 28800 kb/s.
Dívám se tady na ta nastavení x264 a chápu to dobře, že všechno je to jednoprůchodové kódování? Trochu mne to překvapilo. Myslel jsem si, že vyšší kvality se dosahuje právě pomocí dvouprůchodového kódování.
Zřejmě, abych nemusel u každého videa spouštět 3 věci: encódování videa, zvuku a muxování, tak zkusím Handbrake, vypadá jako GUI pro různé nástroje.
Osobně se snažím chytit logiku věci. Většinou do problematiky nejlépe proniknu, když vyjádřím svůj pohled a někdo ho zkoriguje.
Není to náhodou tak, že víceprůchodové kódování má smysl, když chci nastavit konkrétní velikost videa (ať už ve smyslu velikosti nebo bitrate)? První průchod by byl informační pro to, aby se vědělo, jak se v druhém průchodu kódovat. V případě, že mi na velikosti / bitrate nezáleží, by dva průchody neměly smysl. Je to tak? Moc mi do toho nehrají ty další průchody.
Na tuto svou úvahu jsem přišel, když jsem zkusil Handbrake: když zakliknu kódování na bitrate tak je volba dvouprůchodové kódování aktivní, když zakliknu kódování na "konstantní kvalitu" (což si myslím je to "--crf" z příkazové řádky) tak ta volba aktivní není.
Znovu si pročítám odkaz, který jsem tu poslal a začíná mi to dávat smysl. Jsou tři metody řízení:
qp - Constant Quantizer: Jak píše Mandarinka "...kvantizuje všechny bloky stejnou měrou - vůbec nefunguje adaptive quantization a podobně, což je velmi neoptimální pro vzhled..." a ještě uvádí "...se hodí pouze na debugování..." Velikost pro stejnou vizuální kvalitu je větší než u "--crf" a také není známá.Ono je to skutečně taková středověká metoda, konceptuálně špatná a vůbec, takže říct, že "velikost je větší než u crf" a "neoptimální pro vzhled" je dost diplomaticky řečeno. V podstatě je to mód, v kterém je enkodér zkriplený, praktické použití neexistuje (nepočítám lossless, páč to je irelevantní). Prostě zapomeňte, že to tam je :) Jinak bitrate může být i jednoprůchodová, ale kvalita nebude tak dobrá (je těžké docílit nějakou konzistentní kvalitu, když víte, jaký máte rozpočet, ale nevíte, co všechno z něj bude třeba zaplatit).
Tak bych se připojil k otázce, na některých trackerech jsem viděl HD ripy ve vysoký kvalitě, který byly nakódovaný třeba až 10 průchody... Má to cenu?Má to "cenu" v tom smyslu, že zaplatíte na elektřině 10x tolik ;) Jinak ne (u x264).
Díky za to vysvětlení těch víceprůchodů. Mrkni co píšou na webu mencoderu: "Většina kodeků, které podporují ABR enkódování, podporují pouze dvouprůchodové enkódování, zatímco ostatní jako x264, Xvid a libavcodec podporují víceprůchodové enkódování, které s každým průchodem trochu zlepší kvalitu, ačkoli toto zlepšení již není viditelné, nebo měřitelné po asi čtvrtém průchodu. V této sekci budeme považovat dvouprůchodové a víceprůchodové enkódování za rovnocenné."
Podle mého názoru vůbec ta pasáž z mencoderu je zvláštním způsobem zavádějící / nevhodně napsaná. Člověk získá představu, že CBR určitě ne a že čím více průchodů tím lépe. Kritická je tam tato věta: "V jednoduchých režiměch, jako je CBR, však enkodéry neznají nároky na datový tok budoucích scén a tak nemohou překročit požadovaný střední datový tok na dlouhou dobu. Pokročilejší režimy, jako je víceprůchodové enkódování, umí vzít v potaz statistiky z předchozích režimů, což odstraní výše zmíněný problém."
Nevzniklo to náhodou tak, že ta pasáž je napsaná pro MPEG 4 ASP a H.264 už má jiný přístup?
Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.Myslíš, že je pomalejší než vcelku běžné starší Atomy? A tvrzení, že na malym notebooku na cestách si nechci pustit vydeo je přinejmenším přitažené za vlasy :).
Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.Záleží na prostředí, kde se člověk pohybuje. Ale i doma mám jeden počítač - Celeron 2GHz, 256 MB RAM, Win2k - který používá moje matka k naprosté spokojenosti, a nevidí důvod ho měnit. A i to video se na něm přehrává. A takový stroj má někdy problém s H264 v PAL rozlišení. Ty testy náročnosti AVC/ASP, jak jsem psal výše, jsem dělal částečně i pro jednu školu, kde tou dobou byly stroje typu Celeron 2GHz a SDRAM paměti ještě běžné. Teď už jsou zlikvidované/rozebrané na díly, ale kdyby nebyl posledních pár let zřizovatel tak štědrý, sloužily by pořád.
Preci jen dekodery MPEG-4 AVC (H.264) jsou pri srovnatelnem rozliseni a bitrate o dost narocnejsi nez dekodery MPEG-4 ASPNo tak tady bych to okořenil nějakým tím
[citation needed]
... Imho náročnost videví v AVC je přecijen dána jejich obvyklým vyšším rozlišením a bitrate.
Nebo máš nějaké srovnání náročnosti při stejném rozlišení a bitrate? Případně ještě objektivnější by bylo stejné rozlišení, ale o něco nižší bitrate u AVC, protože imho dokáže s menším bitrate vyšší kvalitu oproti ASP.
Ještě je potřeba přihodit klíče, ať máme do budoucna aspoň nějakou úroveň zabezpečení ze zmíněného repositáře :Ta uroven bude opravdu nizkawget http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2010.12.26_all.deb
zdravím vespolek, když už je tu debata o videu a audiu, tak toho využiju a zepatám se:
Máte tušesní, co může způsobova tuhle chybu při přehrávání většiny naprosté videí i audio (např. mp3)
Nemohu zjistit typ proudu.
Dělají mi to tyto přehrávače:
Bez problému jsou naopak
Mám Fedoru 16. Co s tím?
Abych nemusel z příkazové řádky ovládat tři programy (kódování videa, audia a muxování) tak hledám nějaké GUI k těmto CLI nástrojům. Porovnával jsem Handbrake a Avidemux a zdá se mi, že Handbrake se více drží toho, že používá terminologii kodeků, které používá.
Co používáte vy?
A ještě mám jednu otázku. Co považujete za nejperspektivnější z hlediska možnosti přehrávání do budoucna pro komprimaci domácího videa:
Tedy kombinace MKV: H.264 a MP3?
Jaký bitrate pro MP3? 192 kbit/s?