FFmpeg 7.0

Szerszám

Megjelent az FFmpeg nevű "univerzális multimédia eszközkészlet" 7.0-s kiadása "Dijkstra" kódnéven. Változások a 6.1-es kiadás óta:

  • DXV DXT1 encoder
  • LEAD MCMP decoder
  • EVC decoding using external library libxevd
  • EVC encoding using external library libxeve
  • QOA decoder and demuxer
  • aap filter
  • demuxing, decoding, filtering, encoding, and muxing in the ffmpeg CLI now all run in parallel
  • enable gdigrab device to grab a window using the hwnd=HANDLER syntax
  • IAMF raw demuxer and muxer
  • D3D12VA hardware accelerated H264, HEVC, VP9, AV1, MPEG-2 and VC1 decoding
  • tiltandshift filter
  • qrencode filter and qrencodesrc source
  • quirc filter
  • lavu/eval: introduce randomi() function in expressions
  • VVC decoder (experimental)
  • fsync filter
  • Raw Captions with Time (RCWT) closed caption muxer
  • ffmpeg CLI -bsf option may now be used for input as well as output
  • ffmpeg CLI options may now be used as -/opt , which is equivalent to -opt >
  • showinfo bitstream filter
  • a C11-compliant compiler is now required; note that this requirement will be bumped to C17 in the near future, so consider updating your build environment if it lacks C17 support
  • Change the default bitrate control method from VBR to CQP for QSV encoders.
  • removed deprecated ffmpeg CLI options -psnr and -map_channel
  • DVD-Video demuxer, powered by libdvdnav and libdvdread
  • ffprobe -show_stream_groups option
  • ffprobe (with -export_side_data film_grain) now prints film grain metadata
  • AEA muxer
  • ffmpeg CLI loopback decoders
  • Support PacketTypeMetadata of PacketType in enhanced flv format
  • ffplay with hwaccel decoding support (depends on vulkan renderer via libplacebo)
  • dnn filter libtorch backend
  • Android content URIs protocol
  • AOMedia Film Grain Synthesis 1 (AFGS1)
  • RISC-V optimizations for AAC, FLAC, JPEG-2000, LPC, RV4.0, SVQ, VC1, VP8, and more
  • Loongarch optimizations for HEVC decoding
  • Important AArch64 optimizations for HEVC
  • IAMF support inside MP4/ISOBMFF
  • Support for HEIF/AVIF still images and tiled still images
  • Dolby Vision profile 10 support in AV1
  • Support for Ambient Viewing Environment metadata in MP4/ISOBMFF
  • HDR10 metadata passthrough when encoding with libx264, libx265, and libsvtav1

( arpi_esp v | 2024. 04. 08., h – 15:18 )

> multi-threaded cli tool

uristen, mive lett e vilag...

Tény, hogy szerintem is kicsit vicces, mikor csak 0.1-ig jutnak, de szerintem nem feltétlen öbizalomhiány. Van, aki arra megy, hogy a szoftver végleges, feature complete verziója lesz majd csak az 1.0, minden korábbi kiadás 0.akárhány.

Az még rosszabb, amit Knuth csinált, hogy a következő TeX verziója a pi-t közelíti egyre több jeggyel.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( Raynes | 2024. 04. 08., h – 16:32 )

Ezt a VVC-t (x266) próbálta már valaki? Mert az HEVC (x265) se terjedt el, elvétve lehet benne anyagokat tölteni, pedig nem hülyeség, mert egy 720p-s átlag filmet, sorozatot össze tud nyomni egy 360-480p AVC (x264) helyigényére, de a minősége jobb lesz. Na, most gondolom az x266 még ennél is jobb, de egyrészt ami nem FFmpeg-alapú, az lehet nem támogatja, hardveres dekódolók még nincsenek hozzá.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ja, át, de ha megnézed, stream szolgáltatások nem abban nyomják, és ha megnézed a torrenteket, webről letölthető anyagokat is, akkor azok is jellemzően csak x264, elvétve más (VP9, AV1). Persze, hardveresen sok minden ismeri már, de még mindig nagyon kevesen használják. Ezt nem értem én se, hogy miért.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Oké, így már érthető. Reméljük akkor, hogy az x266 gyorsabban fog terjedni, mert már nagyon kéne valami az x264 helyett. Nem rossz az se, ha alárakják a nagy bitrátát, de alacsonyabbakra kéne valami, ami tűrhető minőséget ad. A sávszél még mindig drága, meg hiába PC-ken az olcsó, sok tera tárhely, mobileszközök azért nincsenek annyira eleresztve vele.

Annyit még tudok, hogy az x264 azért is népszerű, mert ott megegyeztek, hogy ingyenes webes videónál nincs licencdíj érte.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Hát ja, maximum a 4K-nál találkozni vele a legtöbb esetben, de pont ez az, hogy értelme van 720p-nél is. Sőt, akár 480p-nél is, ha valami nagyon kicsi tárhelybe kell beleférni, ami ma már nem gyakori, de szélsőséges esetben megtörténhet.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

szerintem aki manapsag 480p/720p tolt annak regi elavult hardvere van, ami ugyse birna a h265-ot, se hw-esen se cpu-val. persze biztos van 100-bol 1 ember akinek jo lehet, de ilyen reteg igenyekre nem keszul encode.

masik meg hogy a web bongeszok nem tudnak h265-ot lejatszani, ezert se terjedt el annyira streamingben.

A h265 (hevc) telefonokon már jópár éve támogatott videofelvételre és mostanában már ez a default (nincs menüben elásva, nem kell kézzel átállítani). Fényképezőkön úgyszintén, 4-5 éve már legtöbb modellen támogatott. Állóképben telefonokon a jpg helyett már egy ideje választható heif/heic formátum, ami belül szintén h265 I-frame, bár azt hiszem még mindig kézzel kell bekapcsolni (mert átlag user nem tudja lekonvertálni jpg-re, weben meg egy csomóan nem támogatják).

A VVC-t próbáltam, de egyelőre csak állóképtömörítésre kísérleteztem vele. Nyilván az állókép nem a teljes történetet meséli el, de én erre voltam kíváncsi. A Fraunhofer-féle VVenc valami egészen förtelmesen lassú, még fast üzemmódban is. Az uvg266-ot nem próbáltam, annak elvileg gyorsnak kéne lennie, de kevésbé jó a minősége, mint a VVenc-nek (az lényegében egy h265-ekvivalens feature subsetet használ a h266-ból). Heif (h265) és Avif (av1) nekem nagyjából fej-fej mellett van képminőségben, kicsit máshogy néznek ki az artifact-ok, de nem tudsz egyértelmű sorrendet felállítani közöttük. A vvc kicsivel (marginálisan) jobb, főleg ha nagyon alacsony minőséget célzol meg. A vvc-vel sokkal lejjebb lehet is menni fileméretben, 12MP-es képet a h265 és az avif is kb 36kB-ra tudott letömöríteni, vvc-vel kb 5kB-ig is le lehet menni. (Nem, nem úgy néz ki ahogy gondolod, annál sokkal undorítóbban. :D Nyilván semmi gyakorlati haszna nincs, ahogy a 36kB-osnak sem). Azonos fileméret mellett előfordul, hogy pl a heif-nél egy felirat már éppen olvashatatlanul blokkos, a vvc-vel még éppen olvasható marad a képen. De nagyon határeset, éppencsak azon a szinten van, hogy ki merjem jelenteni róla, hogy a vvc jobb. Ahogy mész fölfele minőségben, egyre inkább eltűnik a különbség közöttük.

Ellenben ha kifejezetten jó képminőséget célzol meg (még belezoomolva, és blink-komparálással sem tudod szemre megkülönböztetni az eredetitől, de még nem binárisan lossless), akkor a JPEG XL a nyerő. 12MP-es képnél kb 3-3.6MB-nál éred el ezt a szintet. A cipőjét nem köti meg egyik heif, avif, vvc, webp sem, azoknál 5-6-7MB-ok kellenek ugyanehhez. A jxl viszont az alsó végen nem erős.

Régóta vágyok én, az androidok mezonkincsére már!

Látom értesz a témához.

Nem az volt a mondás, h. szinte senki nem akar már a piaci játékosok közül VVC irányba menni, mert azt a licensing-hellt ami a h264/h265 környékén volt, nem akarják megismételni h266-nal is? Helyette mindenki opensource irányba menekült, AV1, VP9 és tsai?

A VVC meg megmarad a niche 8k UHD Bluray formátumának a filmipar / broadcast számára?

attol h valami opensource meg ugyanugy licensing hell... az alapveto algoritmusokat amire az osszes codec epul levedettek (patented) kb 30 eve (fraunhofer, mpeg group stb) :(  ezzel kene kezdeni valamit, mert ez most olyan mintha le lenne vedetve az osszeadas es a kivonas, es probalj meg ugy szamolni hogy ezeket nem hasznalod.

amugy is az osszes manapsag hasznalt codec (mpeg1-4/h263-265/avc/vpX/stb) lenyegeben ugyanaz az algo: motion compensation + idct + entropy coding. aprosagokban ternek el, egyre jobban tudjak becsulni (es igy kompenzalni) a mozgast (gmc, zoom, valtozo blokkmeret stb), igy kevesebb bit eleg a dct-hez, de az alapok nem valtoztak. 

voltak kiserletek wavelet-ekkel (a jpeg2000/xl is azert jobb sokkal), de ez videora nem valt be. es amugy az is le van vedve... de erdemes kiprobalni (ha meg nem vagtak ki) a SNOW codecet az ffmpegben, az egy wavelet alapu codec, anno tesztelgettem, durvan lassu de eleg jo kis bitrata mellett (vannak artifactok de nem olyan rondak/zavarok mint a dct-alapuaknal)

szerintem itt erdemi valtozas akkor lesz, ha majd AI-vel generaljak valos idoben a kepet, de ehhez meg gyenge a hw jelenleg.

az alapveto algoritmusokat amire az osszes codec epul levedettek (patented) kb 30 eve (fraunhofer, mpeg group stb)

Erről ezt írja mindannyian barátja, Wiki:

MPEG-4 Part 2 patents expired worldwide, with the exception of only Brazil. The last US patent expired on November 14, 2023.

koszi, errol lemaradtam (mondjuk mar eleg reg nem foglalkozom codec fejlesztessel)

amugy az mpegN es a h26N az 1 kulon csapat, egymassal versenyeztek sokaig. kb az mpeg2-h263, mpeg4-h264 voltak parban. a 2000-es evek elejen megjelent tobbi codec meg ezeknek valamilyen mutacioja (sorenson=h264draft, divx3=h263 stb)

Persze, ezek időről-időre lejárnak, előbb-utóbb, ezeket érdemes is figyelni. Az mp3, mp2 lejárt 2017-ben. Sőt az AAC-LC is, más variánsainak még távolabb a lejárati ideje, 2028. Ahogy írod, az MPEG-4 Part 2 is lejárt, a Part 10 is lejárna ebben az évben, de ott görények voltak, az egyik szabadalom majd csak 2030. novemberében jár le, bár ha ezt a kiegészítést kihagyják, akkor ebben az évben jöhet ki belőle olyan verzió, amiben az az egy szabadalom nincs implementálva, a többi része szabadon felhasználhatóvá válik.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A snow az érdekes volt, kísérleteztem vele anno. Mivel nem volt lefixálva backward kompatibilis módon a formátum, ezért a régebbi verzióval bekódolt videók lejátszása újabb mplayerrel igen látványos pszichedelikus effektet eredményezett. Cinetrip VJ-k is megirigyelték volna :)

Az AI-on gondolkodtam már, de van egy érdekes logisztikai probléma vele. A kép-szintézishez használt neurális háló modellek többtíz GB-osak. Ha közel végtelen tömörítési arányt is feltételezünk róla (nyilván nem lesz, de legyünk megengedőek), akkor is elképesztően nagyszámú (10e-100e) képnél lesz annyi nyereséged, hogy egyáltalán a modell méretét behozza.
Mondjuk 30GB-os modellhez (ami szerintem kicsinek számít), 10000db 12MP-es kép (hagyományosan tömörítve legyen darabja 3MB), kell hogy egyáltalán nullszaldónál legyél - feltéve, hogy egy AI-alapon tömörített kép közel 0 méretű (mondjuk pár kB) lesz, ami nyilván szélsőségesen optimista becslés. Az egész csak akkor működhet, ha a világon _mindenki_ megegyezik 1db előre betanított modellben és mindenki azt használja ki-be tömörítésre. Sejtjük, hogy erre mennyi esély van... Ráadásul a modell idővel elavul, mert azokon a képeken tanították, amik előtte álltak rendelkezésre. Ahogy idővel változik, hogy milyen kinézetű/stílusú/témájú képeket csinálunk, a modell is egyre gyengébb prediktor lesz az új képekre.

Régóta vágyok én, az androidok mezonkincsére már!

> A kép-szintézishez használt neurális háló modellek többtíz GB-osak.

nem. a stable difussion pl. 2GB-os, es meg az se kene a tomoriteshez, annal lenyegesen egyszerubb NN is eleg lenne a predikciohoz. mivel itt nem szovegbol kell generalni, csak leiro vektorokbol ujraepiteni a kepet. lenyegeben csak az embedding/VAE kell hozza, meg egy jo upscaler. ez belefer max 1GB-ba. ami a mai szoftver meretekhez kepest elenyeszo...  az szamitasigenye ami inkabb a gond, foleg mobil eszkozokben.

van aki mar implementalta is:  https://github.com/duanzhiihao/lossy-vae

> elképesztően nagyszámú (10e-100e) képnél lesz annyi nyereséged

amugy a keptarolo felhok (facebook, insta, flicker stb) tudnanak ebbol is profitalni, nekik draga a tarhely... nyilvan a friss kepeket tartjak cacheben egy ideig aztan arhivalaskor mehet az encode, es ha valaki nezegeti a regi kepeit akkor vissza generaljak.

Ez érdekes. Nyilván én a becslést arra alapoztam, hogy a végcél kb egy mai szöveges prompttal nagyságrendileg összevethető méretbe tömörítés, amihez kb akkora modell kell, ami egy szöveges promptból tud képet szintetizálni. (OK ez nyilván túl ambiciózus, ha az eredeti képet akarjuk viszontlátni és nem egy teljesen másikat, amin kb ugyanazok a dolgok vannak rajta, de tők máshogy. :) De mondjuk a jelenlegi tömörítőkön fogjon legalább 1-2 nagyságrendet.)

Ennél a lossy-vae implementációnál viszont azt látom, hogy 1.5-2 bit/pixel kell, hogy az eredetitől ne térjen el szemmel látható mértékben. Ez (24bites alapot feltételezve) 12-16x-os tömörítési arány, ami azért hagyományos képtömörítőkkel is elérhető, látványos minőségromlás nélkül. Ebből gondolom, hogy talán mégiscsak nagyobb modellek fognak kelleni, ha azt akarjuk, hogy szignifikáns előnye legyen. A kérdés - megint - a skálázódás lesz. EDIT: ahogy nézem kb 5 éves modellekkel dolgozik, szóval egy mai modellel lehet, hogy már lényegesen jobbat tudna.

A képtároló felhőknél is addig nincs probléma, amíg házon belül marad minden. De valahogy le kell juttatni az ügyfél eszközére. Ha ehhez szerver-oldalon transzkódolni kell, az fájdalmasabb lehet, mint amennyit megnyernek vele.

Régóta vágyok én, az androidok mezonkincsére már!

A h265-nél is eleve úgy indult a dolog, hogy a konzorciumi tagok megegyeztek, hogy a h264-hez képest egyszerűbb és olcsóbb licenszfeltételekkel fogják kínálni, hogy gyorsan elterjedjen. Aztán jött a Netflix és a csörtéje a throttlingoló netszolgáltatókkal (akik közben persze a saját streaming platformjukat akarták éppen felfuttatni). A Netflixnek nagyon kellett egy codec, ami azonos minőséggel megfelezi a bitrátát. A h265 szabadalomtulajdonosok egy része hirtelen vérszemet kapott, hogy ez a streaming biznisz nagyon jól tejelhetne nekik, kiléptek az eredeti (MPEG LA) patent poolból és alakítottak egy sajátot, ami stream megtekintésenként is kért volna díjat. Aztán egyes cégek kiléptek egyikből, beléptek a másikba, majd visszamentek, mint valami rossz szappanoperában. Kb itt pecsételődött meg a h265 sorsa a weben. Ennek már következménye volt, hogy a Google elkezdte tolni a VP8, VP9 majd AV1-et. A h265 ott terjedt igazán el, ahol csak a "szokásos" készülékenkénti díj érvényes, kamerákban, telefonokban stb.

A h266-nál megint fogadkoztak, hogy ez nem ismétlődhet meg. Mivel a h266 majdnem egy superset-je a h265-nek (kb mindenen növeltek, 2x mozgásvektor nagyság, 2x pontosság, 2x blokkméret, a meglevő kb 4 féle blokktranszformáció mellé felvettek még 3 másikat, 8-10 bites színmélység helyett lehet 12-16 bit is), ezért elég nehezen képzelhető el, hogy a h265-re érvényes szabadalmak ne lennének érvényesek a h266-ra is. Az írják, hogy most is 2 patent pool van és van egy csomó szabadalomtulajdonos cég, amelyik egyiknek sem tagja. Annyit írnak, hogy Braziliában tv szolgáltatásban ezt fogják használni, DVB-szabványcsaládból is kijön új verzió, amiben már benne lesz. Vagyis ha más nem, TV-kben lesz dekoder hozzá. Ezen felül lesz-e valami belőle az jó kérdés.

Régóta vágyok én, az androidok mezonkincsére már!

Lehetne, hogy ezt a licencelési összevisszaságot kicsit részletesebben kifejtitek?

Most akkor mindenkinek jogdíjat kellene fizetnie azért, ha készít valamilyen videót, és azt h264 formátumra konvertálja?

Pláne nem értem, hogy hogy lehetett a része az ffmpeg-nek a h264 codec már évek óta, ha csak nemrég járt le a licenc-je?

> hogy lehetett a része az ffmpeg-nek

ffmpegnek resze a divx, sorenson es rengeteg teljesen zart kodu codec is... durva reverse engineering stb. ott nagy ivben szartak a licenszekre (nem veletlen csinalta Fabrice Bellard es Niedermayer is az elso evekben alneven), ez legyen annak a gondja aki majd felhasznalja uzleti celra.

Szerintem ilyet senki nem mondott, hogy a konvertálási események alapján kéne fizetni.

A h264 valóban egy borzasztó öreg formátum, a rá vonatkozó szabadalmak mostanában már lejáróban vannak.

A h264-nél évekkel ezelőtt fenyegetőztek a streamelés külön díjkötelessé tételével. "Nem biztos, hogy fenn tudják tartani, hogy a webes streamelésnél ne kelljen stream-megtekintésenkénti díjat fizetni" - nem pontos az idézet, de valami ilyesmi volt, mintha valami elkerülhetetlen vis maior lenne, ami ellen küzdenek-küzdenek a szabadalomtulajdonosok, de nem tudják meddig tudják visszatartani. (Mármint a saját kapzsiságukat...) Az ötlet akkor ült el, amikor erre válaszként a Google megvette az On2-t a VP[1-8] kodekek fejlesztő cégét, elkezdték open source-olni és a formátumot nyílt szabványtervezetté alakítani.

A h265-nél az egyik banda (HEVC Advance) tudtommal szed díjat a stream szolgáltatóktól megtekintési események száma alapján. A másik (MPEG LA) nem, ők csak a szokásos eladott hardver-szoftver darabszám alapján. Az egész "patent license pool" intézménynek az lett volna a lényege, hogy egyvalakivel vagy szerződéses viszonyban, egyvalakinek fizetsz, egyvalaki feltételei alapján és onnantól jogilag teljesen rendben vagy.

A h266-nál jelenleg még rosszabb a helyzet, mert a két külön license-pool banda itt is megvan, de egy csomó cég nem lépett be ezek egyikébe sem, velük külön-külön kéne megegyezni a licenszfeltételekről.

A tisztán hardveres esetek (fényképezőgép, videokamera, tv) viszonylag egyszerűek, van egy egyszeri díj amit a gyártó kifizet és van egy eladott darabonkénti díj.

A kereskedelmi szoftvereknél szintén hasonló modell van, bár tudtommal más a díjszabás, mint a hardverre.

A szabad szoftverek a bonyolult eset, mert a szoftver készítőjének nincs konkrét darabonkénti eladásból származó bevétele, az sincs követve, hogy hány példányban "adja el", hiszen nincs eladási esemény. Bonyolítja az is, hogy nem biztos, hogy a szoftver készítője olyan joghatóság alatt van, ahol ezeket a szabadalmakat érvényesnek elfogadják (pl EU-ban nem), ettől függetlenül elérhető lehet a szoftvere ott is, ahol igen.

Szintén bonyolult kérdés, hogy ha pl egy hardverben van h265-ös (kódoló vagy dekódoló) IP blokk, akkor vajon annak a használata szabad-e? Igaz-e az, hogy a gyártó egyszer kifizette az eladott eszközszám alapján a licenszdíjat, akkor az azt használó szoftvernek már nem kell? Ezt pl szeretik vitatni.

Régóta vágyok én, az androidok mezonkincsére már!