abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 17:55 | Nová verze

Byla vydána betaverze Fedory 33, tj. o poslední zastávce před vydáním finální verze, která je momentálně naplánována na 20. října. Výchozí souborový systému byl změněn z Ext4 na Btrfs. Výchozí prostředí GNOME bylo aktualizováno na verzi 3.38. Mezi oficiální edice přibyla Fedora IoT.

Ladislav Hagara | Komentářů: 0
dnes 14:22 | Zajímavý článek

David Revoy se před rokem rozhodl, že vydá svůj open source webový komiks Pepper&Carrot také knižně a ve vlastní režii. Použije k tomu pouze open source software. Nemá to jednoduché. V několika příspěvcích na svém blogu popsal problémy a jejich postupné řešení. Po roce testování je ale konečně s výsledkem spokojen.

Ladislav Hagara | Komentářů: 0
dnes 14:00 | Komunita

Lukáš Bařinka oznámil vydávání série video cvičení Programování v shellu na YouTube.

Ladislav Hagara | Komentářů: 1
dnes 11:11 | Zajímavý článek

Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 98 (pdf), HackSpace 35 (pdf), Wireframe 42 (pdf) a Hello World 14 (pdf).

Ladislav Hagara | Komentářů: 0
dnes 08:00 | Nová verze

Byla vydána verze 8.4 OpenSSH. Blíží se ohlášený zákaz algoritmu „ssh-rsa“ kvůli zranitelnosti SHA-1.

Fluttershy, yay! | Komentářů: 0
včera 13:22 | Zajímavý projekt

Více než 60 moderních telefonů má díky práci týmu dobrovolníků SOMainline šanci na zařazení do oficiálního linuxového jádra. Patche pro podporu chipsetu SD630 a SD660, kterým jsou tyto telefony poháněny, jsou postupně začleňovány. Tým se soustředí na zprovoznění klasických linuxových distribucí pro telefony, ale věnuje se i zprovoznění běžného AOSP. Další tým vývojářů postmarketOS již delší dobu pracuje na podpoře chipsetu MSM8953, který umožňuje vdechnout život dalším nejméně 30 telefonům vydaných v letech 2017 a 2018.

David Heidelberg | Komentářů: 22
včera 08:00 | Komunita

Svobodný kancelářský balík LibreOffice slaví 10 let od svého vzniku. Projekt byl představen 28. září 2010.

Ladislav Hagara | Komentářů: 20
včera 07:00 | Pozvánky

Ve dnech 15. až 17. října 2020 se bude konat společná openSUSE + LibreOffice konference. Původně měla konference probíhat v Norimberku, ale vzhledem k situaci bude probíhat online. Konference již zveřejnila program. Naplánováno je několik desítek přednášek. Registrace a podrobnosti naleznete na stránce konference.

Zdeněk Crhonek | Komentářů: 1
27.9. 18:11 | Zajímavý software

SimulIDE je realtimový simulátor elektronických obvodů. Podporuje také PIC, AVR a Arduino. K dispozici je verze 0.4.13. Vývojáře lze podpořit na Patreonu.

Ladislav Hagara | Komentářů: 0
27.9. 14:11 | Nová verze

Virtual Machine Manager aneb virt-manager (Wikipedie), tj. GUI pro správu virtuálních strojů podporovaných knihovnou libvirt, byl vydán ve verzi 3.0.0. Přehled novinek v příspěvku na blogu. Zdůrazněna je nová volba --cloud-init.

Ladislav Hagara | Komentářů: 4
Používáte aplikaci eRouška?
 (19%)
 (3%)
 (2%)
 (12%)
 (50%)
 (8%)
 (6%)
Celkem 469 hlasů
 Komentářů: 35, poslední 20.9. 21:50
Rozcestník

Hrajeme si s FFmpeg/Libav (1/2)

8. 2. 2012 | Max Devaine | Návody | 6174×

Co dnes na webu letí a jak připravit videa pro přehrávání na internetu, aby se na ně podívalo co nejvíce lidí? Co všechno vlastně dnešní webové prohlížeče podporují?

Obsah

Formát videa/audia + formát kontejneru a kodek

link

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í:

  • stopa (datový stream)
    • video stopa
      - video data jsou pomocí encoderu kódována do nějakého formátu určeného pro video, např.:
      MPEG-1, MPEG-2, MPEG-4 ASP, H.264 (MPEG-4 AVC), HuffYUV, RealVideo, Theora, VP8, WMV
    • audio stopa
      - audio data jsou pomocí encoderu kódována do nějakého formátu určeného pro audio, např.:
      AAC, AC3, FLAC, MP3, Speex, Vorbis, WAV, WMA
    • titulky
      bývá případ třeba kontejneru matroska (mkv), kde si titulky sviští ve své stopě
  • kontejner
    - kontejner zastřešuje encodované video, audio a jiné stopy (datové streamy), zajišťuje jejich vzájemnou synchronizaci a určuje se mj. specifickou koncovkou souboru. Kontejner může být schopen pojmout víc jak jednu video stopu a jednu audio stopu. Příkladem budiž kontejner matroška (*.mkv), do kterého můžeme vložit stop, kolik chceme.

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

Co dnes letí?

link

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 nebo Libav?

link

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):

  • mnoho vývojářů nesdílelo názor a praktiky velkého vůdce FFmpeg, které údajně nebyly zářného příkladu
  • přemýšlelo se o forku, ale vzhledem k počtu příznivců se rozhodlo udělat puč
  • puč nevyšel, majitel domény www.ffmpeg.org byl příznivcem vůdce, takže po krátké době se dostal web zpět pod kontrolu vůdce
  • udělal se tedy nakonec fork a pojmenoval se Libav s tím, že web je částečně převzatý z původního projektu FFmpeg
  • v poslední verzi Libav 0.8 došlo k přejmenování základních nástrojů, ale jména knihoven zůstaly stejné, takže jednoduchá koexistence FFmpeg a Libav v jednom systému není triviální a navíc, hodně přehrávačů a různých projektů ony knihovny používá, takže zatím ani není moc rozumné si hrát s jejich názvy
  • Libav by měl mít rychlejší vývoj a více vývojářů, lidé od FFmpeg zase pro změnu mergují funkce z jiných projektů včetně věcí z Libav, vizte poslední nedávno uvolněnou verzi FFmpeg 0.10 Freedom. FFmpeg je tedy nabušený funkcemi, které Libav nemá, otázkou je pak jejich stabilita a udržitelnost takového stylu vývoje.

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

FFmpeg

link

Ne, na minci mi nepadla hlava, ale dáme šanci oběma projektům. Začneme tedy starou klasikou, projektem FFmpeg.

GNU/Debian – FFmpeg distribučně

link

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

Libav – kompilace

link

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

Mediainfo

link

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

Závěr

link

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.

       

Hodnocení: 88 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

8.2.2012 08:30 Peto_MiG
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Možno sa mýlim, ale zdá sa mi, že H.264 je v skutočnosti referenčný KODEK. Názov FORMÁTU je MPEG-4 AVC.
Max avatar 8.2.2012 08:46 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ano, je to tak, stejně jako myslím ogg. Snažil jsem se uvádět obojí, ale nemyslím si, že by bylo nějak tragické bavit se o MPEG-4 AVC jako o h.264.
Zdar Max
Měl jsem sen ... :(
wiskas avatar 8.2.2012 09:04 wiskas | skóre: 21 | blog: Raziel
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ne, tak to není. Ten formát vyvinulo společně několik organizací a podle toho má taky mnoho jmén a přezdívek. "Oficiálně" se jmenuje "ISO/IEC 14496-10" (když se zeptáte ISO) nebo "ITU-T Recommendation H.264" (když se zeptáte ITU). Ale běžně se tomu říká H.264. Další možné názvy najdete zde
Libav developer. | The world is just a lot of people trolling each other.
Max avatar 8.2.2012 09:09 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Aj, díky za info. Tak jsem žil jen lehce v omylu :-/
Zdar Max
Měl jsem sen ... :(
David Watzke avatar 8.2.2012 14:17 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ogg je kontejner.
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
Max avatar 8.2.2012 15:30 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Samozřejmě, že je, samozřejmě jsem napsal blbost, ale už nevím, proč :-/. Ani si už ránní dění moc nevybavuju :-/.
Zdar Max
Měl jsem sen ... :(
8.2.2012 09:08 Jindřich Makovička | skóre: 17
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Mýlíte se. H.264 je pojmenování podle ITU, MPEG-4 AVC pojmenování téhož podle ISO/IEC.

Osobně bych tyhle diskuse, co je formát a co je kodek, zakázal.
pavlix avatar 8.2.2012 10:06 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
„Já bych všechny ty internety a počítače zakázala.“
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
8.2.2012 09:13 hajny
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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ě? A nevíte jak je to s podporou formátů u webových prohlížečů co se týče html5 (audio, video)? všude se většinou udávají kontejnery, ale přímo formáty, které v těch kontejnerech mohou být moc nejsou. Na foru opery jsem právě narazil na to, že opera zvládá i flac, do té doby jsem si myslel, že je html5 omezené na mp3(mpeg) vorbis wav. (source src="song.ogg" type="audio/ogg" /> type ogg má být jako co? vorbis? flac? speex? orientuje se někdo v tom guláši? Díky
wiskas avatar 8.2.2012 10:05 wiskas | skóre: 21 | blog: Raziel
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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.
Libav developer. | The world is just a lot of people trolling each other.
Max avatar 8.2.2012 10:22 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ahoj, toto všechno včetně příkladů je uvedeno v příštím díle, který už je napsán a má ho redakce, takže by měl vyjít v nejbližší době.
Zdar Max
Měl jsem sen ... :(
8.2.2012 09:18 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Dík za článek, konverze videa mě vždyckz dostane. Na první pohled to vypadá, že to na tom přeci nic nemůže být a pak strávim mnoho času googlením, kompilováním, psaním skriptů apod. než se dostanu k výsledku. Takže jsem jen rád za nějaké ucelená a hlavně aktuální informace :-)

Mám jen jednu poznámku k checkinstallu - místo něj se mi osvěčil spíš následující postup (právě proto, že většinou neskončím u první kompilace): jen zkomopilovat (tedy make) a nalinkovat potřebné binárky do ~/bin (ten mám už z jiných důvodů v PATH na prvním místě). Netřeba pak řešit odstranění staré verze, když chci přidat nějakou featuru, tak ji zapnu (doinstaluju potřebné dev knihovny), zkompiluju a používám, odstranění je pak taktéž triviální. Jediná nevýhoda je, že takto mám "nainstalovaný" ten program jen já, ale vzhledem k tomu, že svůj počítač používám jen já, to je celkem jedno.
8.2.2012 13:16 Rivon
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Mě přijde naopak checkinstall výborný nástroj. Po instalaci můžu odstranit celej adresář se zdrojákama a buildem a když chci odinstalit to, co sem kompiloval, tak prostě jen dám apt-get remove *** a je to ;)
9.2.2012 09:55 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Jasně, tenhle přístup se osvědčil mě, není to univerzálně nejlepší postup.
8.2.2012 11:01 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Moc se na články těším. Díky. Dotázek: Za jak kvalitní považuješ encodér do MPEG2, který je v těchto softech, v porovnání s konkurencí? Já nyní používám HCencoder resp. HCbatchGui (na Windos).
Max avatar 8.2.2012 13:05 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Články jsou původně o videích na internetu, ffmpeg/libav je vlastně jen vedlejší věc, primární zaměření článků je jiné. Ani nejsem žádný big boss ohledně videí a ffmpegu.
Zdar Max
Měl jsem sen ... :(
8.2.2012 17:06 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Mpeg2 encodér v ffmpegu profituje z různých brute-force algoritmů společných pro mpegovité formáty. Ty ale nejsou nijak zvlášť vytuněné pro konkrétní formát a navíc když to všecko pozapínáte, tak i hodně pomalé (QNS...). Navíc to všechno není bůhvíjak zdokumentováno, takže člověk moc netuší co má jak nastavit, aby to dopadlo dobře.

Co jsem slyšel, tak HC Encoder je obecně lepší. Sám ale mpeg2 nepoužívám. Taky existuje experimentální x262 (modifikace x264 schopná produkovat mpeg2), ale ta má daleko k použitelnosti, takže zmiňuju jen tak do budoucna (dejte tomu 4 roky a pak *MOŽNÁ*).
8.2.2012 18:34 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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áš?

Jendа avatar 8.2.2012 19:48 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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…
8.2.2012 20:14 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Jaký nastavuješ bitrate?
8.2.2012 20:44 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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í...).
8.2.2012 23:05 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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.

9.2.2012 00:22 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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.)

9.2.2012 00:28 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Nééé, kam se to zalomení podělo, zrovna když se to nejmíň hodí!

Čitelná verze mého vejšplechtu: pastebin.com
9.2.2012 00:39 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
U toho dvd měly být jednotky Mbps, předpokládám - 9.8 Mbps. To není nic moc, dnešní HD ripy s bitratem nad 10 Mbps zcela určitě kvalitou DVD předčí (nejen co se týče rozlišení).

Jinak to, že je x264 pokročilý, rád slyšim, myslíš, že je opravdu pokročilejší i než třeba CoreAVC?
Your rice wet, you fucked up.
9.2.2012 00:53 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Jistě, 9,8 Mbps. Tak jistě, že HD ripy kvalitou předčí, ale právě že mají vyšší rozlišení - to samozřejmě zdvihne nároky na bitrate. Také ale pocházejí z lepších, detailnějších zdrojů (nebo by alespoň měly, ideaálně). Právě že x264/h.264 umožňuje toho dosáhnout, mít hezky vypadající HD v toku, který je blízko dvd.

Co se týče CoreAVC, tak ti nikdy nevyprodukovali enkodér, takže srovnávat nelze... Ale v objektivních studiích (MSU) x264 vítězí nad (kvalitativně) nejbližším konkurentem, jímž je zdá se Mainconcept. Ta technologická převaha je imho dost zřejmá...
David Watzke avatar 9.2.2012 00:46 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Upravil jsem formátování tvého komentáře.
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
9.2.2012 00:47 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Vřelé díky!
9.2.2012 14:21 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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 :).

9.2.2012 14:37 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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.

9.2.2012 15:35 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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é.

9.2.2012 19:10 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
vloudila se mi tam chybka... bitrate nebude větší než u pomysleného nekompriomovaného videa. Měl jsem na mysli to, že náš zdroj už ztrátově komprimovaný je, takže se většinou stane, že pokus o překódování bezeztrátovým kodekem povede k mnohem většímu výstupu.

Když uděláte FLAC z MP3ky nebo vorbisu, tak taky velikost střelí nahoru. Příklad: WAV nekomprimováno: 1456kbps (nebo kolik to vychází u CD stopy); WAV -> FLAC: 850kbps; WAV -> Vorbis: 160kbps; vorbis -> FLAC: 840kbps :)
9.2.2012 21:55 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Rozumím.
10.2.2012 20:49 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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.

10.2.2012 21:05 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Oh, bitrate nesedí? Možná x264 špatně detekovalo fps (a tedy délku)...
10.2.2012 21:41 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ne, ne. Ale video zkomprimované bezztrátově "--qp 0" má větší bitrate 43,5 Mbit/s než zdroj 28,8 Mbit/s. Přičemž zdrojem je DV tedy "nekomprimované" video.
Jendа avatar 10.2.2012 22:39 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
DV není nekomprimované.
11.2.2012 13:36 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Schválně jsem to napsal do uvozovek.
9.2.2012 21:58 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Děkuji.
11.2.2012 21:24 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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.

11.2.2012 21:57 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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?
Your rice wet, you fucked up.
11.2.2012 23:22 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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á.
  • bitrate: Je zacílené na určitou velikost (bitrate) a proto se používá víceprůchodové.
  • crf - Constant Ratefactor: Je zacílené na kvalitu. Tedy na kvalitu stejnou jako má nějaké "qp", ale s co nejmenší velikostí, která také není dopředu známá.
11.2.2012 23:28 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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).
11.2.2012 23:31 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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).
11.2.2012 23:12 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
2 průchody jsou potřeba jenom když je cílem soubor o předem determinované velikosti.

CRF má jiný cíl - cílit na určitou kvalitu, a když video A má menší nároky a video B má nároky dvakrát vyšší, tak to to zohlední. Čili kvalita je do jisté míry předvídatelná (ale pozor, není s CRF faktorem nijak pevně spojená - některé zdroje například potřebují nižší CRF pro dobrý výsledek, než jiné, také se význam CRF faktoru hodně mění v závislosti na nastaveních dekodéru jako je mbtree/no-mbtree, aq-strength, ale i --preset, protože nejrychlejší nastavení vypínají RDO, trellis a tak).

A jinak deset průchodů je nesmysl. Říkalo se, že to potřebuje enkodér CCE (profesionální mpeg2 enkodér), ale to by jenom znamenalo, že má strašně špatnou rate control.

U x264 platí, že 2-pass použijete, pokud chcete konkrétní bitrate (= velikost), jinak crf. Jisté drobné použití mají 3 průchody místo dvou (to se dělá tak, že první průchod děláte s --pass 1, druhý a další s --pass 3), a to sice v případech, že se nepodařilo dostatečně přesně trefit cílovou bitrate; s třetím pokusem je šance, že se ten výsledek o něco přiblíží. Kvalitativní zlepšení videa ale nepřijde (tedy pokud by nedošlo k markantnímu nárůstu bitrate, že).
11.2.2012 23:32 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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?

little.owl avatar 12.2.2012 00:54 little.owl | skóre: 22 | Brighton/Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Cesky preklad vychazi z anglicke verze a prostym srovnanim lze rici ze je nepresny - jsou to niance, ale vyznam je posunut (a ani anglicky original nebyl podle vsecho psan rodilym mluvcim).
$ man rtfm
12.2.2012 21:05 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
CBR = constant bitrate, to je pro video velmi nevhodná věc.

"V jednoduchých režiměch, jako je CBR, však enkodéry neznají nároky na datový tok budoucích scén" --- tady se asi myslelo 1-pass ABR, protože při CBR kódování je to irelevantní, to prostě používá furt stejnou bitrate, přímo určenou na začátku.

"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" --- tohle je přesné, platí to pro 1-pass ABR (tedy když si řeknete o konkrétní bitrate a je jen jeden průchod). Jinak x264 používá lookahead (zná dopředu určitý počet framů), takže v malém měřítku dokáže některé nectnosti 1-pass ABR zmírnit, samozřejmě ale nemá přehled o celkové průměrné náročnosti zdroje (například nemůže vědět, že uprostřed a na konci filmu je dohromady 20 minut výbuchů, kvůli kterým by to chtělo víc šetřit v statických scénách v první třetině, a že na konci jsou titulky, které toho tolik potřebovat nebudou).

A ta dokumentace je skutečně hodně stará (četl jsem to roku 2006), z dob xvidu (tehdy existoval jen constant quantizer, nikoliv CRF mód jako má x264, proto všichni používali 2-pass); nemyslím si, že by byla příliš aktualizovaná - přidaly se sice informace o x264, ale ty obecnější části už nebyly upraveny. Pokud chcete přímo zdroje pro x264, tak je vhodnější ten soupis na Mewiki.

...

Mimochodem, ten rozdíl mezi 2-pass a CRF lze v případě x264 ilustrovat takto (není to zcela přesné, ale v praxi to lze): Enkodér má při rozhodování o tom, jak moc utrácet určitou škálu, to by byl ten "rate factor". Takže když kódujete s ---crf, tak se prostě vybere rate factor, kterým je určena politika při rozhodování, a ta se pak stejně aplikuje na celé video. Výsledkem bude tedy soubor s proměnlivým datovým tokem a velikostí, kterou nebudeme přesně vědět předem.

CQP (constant quantizer) má také stejnou politiku pro celé video a nepředvídatelnou vleikost, ale jde na to primitivně, prostě v každém bloku úpoužije stejný stupeň kvantizace, což je neefektivní.

Proti tomu metody mířící na určitou velikost:

Dva průchody: víme, že existuje určitý rate-factor, který by nám dal požadovanou velikost (při 'konstantní politice'), ale neznáme ho. Když ale zkusmo uděláme kompletní encode a poznamenáme si určité informace, které zaznamenávají náročnost scény a výsledky kódování, můžeme z toho potřebný rate factor spočítat. Pak je vlastně druhý průchod toliko o tom, že použijme --crf se spočítaným ratefactorem (x264 ve skutečnosti vezme z 1. průchodu také rozhodnutí o typu frame - I/P/B). V tomto módu tedy bude mít finální video také konstantní politiku jako CRF. Pokud tedy máme 2-pass encode a crf encode o stejné velikosti, jsou až na drobné detaily rovnocenné.

Jeden průchod: pokud chceme konkrétní velikost ale nemůžeme použít první průchod k analýze, nezbývá než spekulovat. Enkodér tedy musí 'politiku' odhadnout, a během enkódování ji měnit podle toho, jak dobře mu odhad vychází. Když najednou video začne být náročnější, tak musí rate factor snížit, pokud najednou začne být video snazší, tak zase rate factor zmírní, aby cílovou velikost nepodstřelil.
Jendа avatar 8.2.2012 22:21 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
400 kb/s. Jsou to většinou záznamy přednášek, kde se toho moc nehýbe, světelné podmínky jsou pochybné a kvalita kamery taky nic moc.
David Watzke avatar 8.2.2012 20:19 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Zcela souhlasím. Lpět na tom je fakt nesmysl, zvlášť v době, kdy je cena zařízení schopných přehrát cokoliv tak nízká.
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
8.2.2012 20:39 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Takhle - když chceš vyprodukovat DVD, tak je volba formátu jasná, když nechceš vyprodukovat DVD, tak taky (H.264). Čili potenciální debata by byla o tom, zdali produkovat dvd (důvody jsou), nebo ne.

9.2.2012 10:07 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Jeste bych tu videl jedno hledisko - vypocetni narocnost na prehravani. Preci jen dekodery MPEG-4 AVC (H.264) jsou pri srovnatelnem rozliseni a bitrate o dost narocnejsi nez dekodery MPEG-4 ASP, takze pro prehravani videa na slabsich pocitacich je MPEG-4 ASP vyrazne vhodnejsi.
wiskas avatar 9.2.2012 10:57 wiskas | skóre: 21 | blog: Raziel
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Přes pět let starý ošklivý craptop s dvoujádrem Core Duo T2050 zvládne v pohodě 720p a s trochou štěstí i některé 1080p kde není moc pohybu.

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í.
Libav developer. | The world is just a lot of people trolling each other.
pavlix avatar 9.2.2012 22:15 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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 :).
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
David Watzke avatar 9.2.2012 23:00 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Bavíme se o počítačích a ne o počítadlech :-D
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
pavlix avatar 10.2.2012 11:35 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Špatně čteš. Psalo se o přehrávání videa.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
David Watzke avatar 10.2.2012 13:35 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ehm, jsme už slušně OT, ale stejně: podívej se co cituješ / na co reaguješ. (A nechme toho, beztak to byl jen takovej kyd :-))
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
Jendа avatar 10.2.2012 00:05 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Můj Atom N270 (nejslabší na trhu) dá 720p v H.264.
pavlix avatar 10.2.2012 11:36 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
I když koukám, že já ani ten Atom nemám :).
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
10.2.2012 01:13 sigma
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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.
Grunt avatar 11.2.2012 12:00 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
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í.
Já chci přehrávatelné HD na 100Mhz 486. A Dup!
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
9.2.2012 12:24 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Preci jen dekodery MPEG-4 AVC (H.264) jsou pri srovnatelnem rozliseni a bitrate o dost narocnejsi nez dekodery MPEG-4 ASP
No 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.
Your rice wet, you fucked up.
9.2.2012 15:31 sigma
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Dnes už může být situace jiná, i software učinil určitý pokrok, ale cca v polovině roku 2008 jsem si dělal srovnání pro přehrávání videa na Windows (dekodéry z tehdejšího K-Lite Codec Pack). Kvůli archivaci DVD, S-VHS/VHS, a záznamů z DV kamer.

Testoval jsem AVC/H264 (kódováno x264) - 1500 kb/s, a ASP (kódováno Xvid4) - 2000 kb/s. Obojí rozlišení 768×576, subjektivně skoro stejná kvalita, možná trochu lepší u H264.

Zjištěná zátěž: Typ CPU / AVC / ASP:
  • Celeron 1600 MHz / 100 %, nekoukatelné / 40 %
  • Pentium M 1500 MHz / 75 % / 30 %
  • Pentium 4 2800 MHz / 55 % / 25 %
9.2.2012 15:35 sigma
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ještě upřesnění - kódován byl stejný zdroj v HUFFYUV, pomocí tehdy aktuálního Avidemux (2.4.3). Nastavení kodérů výchozí, 2 pass, average bitrate na uvedené hodnoty.
9.2.2012 19:27 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Zhruba podobny dojem z toho mam ja - 2-3x narocnejsi pri stejnem rozliseni.
9.2.2012 15:42 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ta náročnost je skutečně znatelně vyšší (při stejném rozllišení, stejné bitrate). A to zejména pokud je použit CABAC (ale kdo by ho nechtěl používat, heh), jehož spotřeba cpu roste lineárně s bitrate a je hodně komplexní. Oproti tomu entropy decode u mpeg2/4asp je mnohem rychlejší. Rovněž, mpeg2 nemá qpel a mepg4asp ho sice má, ale lidi ho nepoužívají. Navíc je tu loopfilter u h.264. Jisté zrychlení u h.264 je: iDCT je zjednodušené, aby se dalo počítat pouze sčítáním a shiftem - IIRC; byl zrušen GMC (ale tohle stejně u mpeg4asp nikdo nepoužíval). To ale není tak významné a tu zvýšenou náročnost nedokáže dohnat.
8.2.2012 12:12 Jindřich Makovička | skóre: 17
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Mimochodem, kdyby to někomu pomohlo, nedávno jsem si dal trochu práce se skriptem pro automagické převádění videa pro mobily via libav, provádějícího všechny ty základní blbosti jako je cropdetect, ořezání, zmenšování a úprava aspectu na 1:1.
pushkin avatar 8.2.2012 13:27 pushkin | skóre: 42 | blog: FluxBlog
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Dotaz trochu z jiného soudku - jak je to aktuálně s multithreadingem? Co jsem zaznamenal kdysi vznikl fork ffmpeg-mt, jak je to dnes? Už umí i základní ffmpeg / libav multithreading?
"...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
Max avatar 8.2.2012 13:39 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Měl jsem sen ... :(
pushkin avatar 8.2.2012 15:58 pushkin | skóre: 42 | blog: FluxBlog
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Díky, to jsem nějak nezaznamenal :-)
"...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
8.2.2012 17:55 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Díky, pěkný, těšim se na další díl.

Čistě na okraj, budeš povídat i o API libav?
Your rice wet, you fucked up.
Max avatar 8.2.2012 19:07 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Bohužel, ffmpeg/libav je vlastně jen vedlejší produkt dvoudílného článku, který je spíše zaměřen na cíl, tzn. html5 + tag video + podpora v prohlížečích + praktické ukázky apod.
A takové znalosti, bych mohl něco napsat o ffmpeg/libav nemám. A/V mně moc nezajímá, jen jsem před nějakou dobou dělal pár malých návrhů na jeden projekt, tak jsem o tom chtěl jen napsat, aby mé průzkumy nevyšly úplně v niveč :).
Zdar Max
Měl jsem sen ... :(
8.2.2012 20:11 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
Ok, v pohodě ;-)
Your rice wet, you fucked up.
8.2.2012 19:36 tuxmartin | skóre: 39 | blog: tuxmartin | Jicin
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
<flame>
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
Ta uroven bude opravdu nizka ;-)

</flame>
9.2.2012 13:36 OldFrog {Ondra Nemecek} | skóre: 33 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

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:

  • Exaile
  • Totem
  • Whaaw!
  • Pragha

Bez problému jsou naopak

  • VLC Player
  • XMMS
  • Audacious
  • Mplayer (GNOME Mplayer)

Mám Fedoru 16. Co s tím?

-- OldFrog
10.2.2012 17:26 Mandarinka
Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
No, neznám, a tak jenom střelím od boku...

MPlayer a VLC jsou buďto staticky nebo dynamicky linknuté s ffmpegem (xmms a audacious, netuším). Takže pokud jsou dynamicky, tak to znamená, že distribuční ffmpeg je správně zkompilovaný i s podporou treife ('nonfree') formátů. Pokud jsou staticky linknuté, tak je možné, že takto plnotučná je jen jejich vnitřní instance, a ne už distribuční ffmpeg.

Totem, Exaile, atd... tady tuším, že budou tyto přehrávače používat systémové kodeky nebo backendy, takže je třeba zjistit, co používají k přehrávání a pak zjistit, jestli ta věc nebyla zkompilována stylem FOSStard-friendly (jenom VP8, vorbis, theora), případně nemá jiné problémy.

Tím backendem může být víc věcí - gstreamer například, v tom případě by asi chyběly pluginy. Tuším, že gstreamer měl 'good', 'bad' a 'ugly' pluginy, máte nainstalováno ugly? (možná to chce také poohlédnout se po nějakém špinavém, non-free repositáři). Wikipedia taky říká, že existuje zvláštní plugin ffmpeg...

Ale může být důvod i ten, že sice backend zkriplený není, ale prostě si něco nerozumí...
11.2.2012 23:36 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Handbrake vs. Avidemux

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?

11.2.2012 23:48 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Kombinace

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:

  • Kontejner: MKV, MP4,... Mě se zdá, že největší budoucnost na hardwareových přehrávačích má MKV. Dalším kandidátem je WebM, ale toho vidím spíš na web.
  • Formát videa: H.264, VP8,... Tady bych viděl spíš H.264 a VPM (WebM) zase pro web.
  • Formát audia: MP3, OGG Vorbis, AC3, AAC,... Nevím. Rád bych tam viděl OGG Vorbis, ale zdá se mi, že na hardwareových přehrávačích tak rozšířený není. Jak je to s vlastnosti (vícekanálů apod.) a kvalitou AC3 a ACC v porovnání s MP3 nemám představu.

Tedy kombinace MKV: H.264 a MP3?

Jaký bitrate pro MP3? 192 kbit/s?

little.owl avatar 12.2.2012 19:06 little.owl | skóre: 22 | Brighton/Praha
Rozbalit Rozbalit vše Re: Kombinace
Hlavne je treba mit to v otevrenem/standardizovanem formatu, kdy je k dispozici svobodny dekoder [napsany pokud mozno v C]. Pak byste nemel mit problemy veci jednoduse prevest - drive ci pozdeji to nastane.

Zajimovou otazkou je schopnost opravy, pokud je zaznam poskozen (ponicene CD/DVD). Mam asi jedenact let stara CD (Verbatim Datalife :-D ) a presto ze nebyla casto pouzivana a dobre skladovana mam problemy s jejich ctenim i na novych mechanikach.
$ man rtfm
wiskas avatar 12.2.2012 20:16 wiskas | skóre: 21 | blog: Raziel
Rozbalit Rozbalit vše Re: Kombinace
Kontejner -- ano, matroska je asi nejmenší zlo. Má sice řadu problémů, ale to všechny existující alternativy taky. Webm je jen osekaná matroska.

Video kodek -- není o čem mluvit, na x264 v současnosti nic nemá.

Audio -- MP3 je dávno překonaný kodek z pravěku. Jediný důvod pro mp3 je kompatibilita se starým hw. To samé AC3. AAC už je lepší, ale všechny opensource implementace jsou dost hrozné. Co jsem slyšel, tak neroaacenc je celkem dobrý. Pokud nepotřebuješ kompatibility se vším možným, tak vorbis (encoder libvorbis) je dobrá volba.
Libav developer. | The world is just a lot of people trolling each other.
12.2.2012 21:09 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Kombinace
Díky za odpověď.
12.2.2012 21:16 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Kombinace
+1, AAC je i lepší z hlediska patentů/licencí... A podpora bude určitě minimálně u všech přehrávačů podporujících h264. libfaac snad není tak hrozná, ne? Ačkoli to Nero bude asi lepší...
Your rice wet, you fucked up.
12.2.2012 21:31 Mandarinka
Rozbalit Rozbalit vše Re: Kombinace
Co se týče AAC, tak hrozné jsou opensource enkodéry, ale u dekodérů je to pak už jedno. Takže když už jednou máte tu stopu hotovou, třeba i s proprietárním sw, tak už to nevadí. A přece jen, AAC je standard v průmyslu, kdežto vorbis si sice určitou pozici získal, ale coby standard je to pořád spíš "rádoby". Kvalita asi bude podobná u obou (pozor na enkodéry - u AAC použít nero nebo quicktime, který je prý teď lepší, u vorbisu použít libvorbis od Xiphu).

Pro AC3 by teoreticky mohla hovořit schopnost určitých audio receiverů ho odebírat přes spdif. Přes spdif totiž nedostanete dekódovaný/nekomprimovaný surround, vejde se ta, pouze stereo. To podle mě ale není bůhvíjak důležité.

Ovšem, pokud už máte ac3 stopu (třeba z DVD, kde bývá 192-448kbps), tak ji nemusíte překódovávat a můžete ji muxnout tak jak je, protože by se tím stejně moc místa neušetřilo. Já to tak u DVD ripů dělám, nemám ale představu o tom, jak podstatnou škodu bych nadělal, kdybych např. 384kbps stereo AC3 překomprimoval na 160kbps AAC/Vorbis. Osobně komprimuju jenom když je na zdroji LPCM nebo jiné bezeztrátové video.
12.2.2012 21:40 GeBu | skóre: 27 | blog: zápisky
Rozbalit Rozbalit vše Re: Kombinace

Díky za pěkné shrnutí.

Vstupem je video se zvukem z DV kamery tudíž zvuk PCM.

13.2.2012 01:41 J. M. | skóre: 23 | blog: JMblog
Rozbalit Rozbalit vše Re: Kombinace
On hlavně MP3 není kodek, takže nemá smysl porovnávat softwarový nástroj (x264) s formátem komprese (MP3). Jak už bylo řečeno, zásadní je kvalita implementace, tedy kodek (respektive kodér, což je jediný správný český překlad anglického slova encoder), nikoli jen použitý formát. Já pokud ještě někdy výjimečně kvůli kompatibilitě nepoužiju Vorbis, tak jedině MP3, protože LAME je zatraceně dobrý opensource kodér, AAC je z hlediska uživatele opensource softwaru podle mě úplně k ničemu.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.