A Spotify mérnökök 30 ezer euróval támogatták az FFmpeg-et

Open Source

Jó látni, amikor kereskedelmi szoftverek visszaadnak valamit az általuk használt vagy őket inspiráló nyílt forráskódú projekteknek. Most éppen ilyen történt: a Spotify Engineering csapat harmincezer eurós támogatást küldött az FFmpeg projektnek és emellett két másik FLOSS projektet - Mock Service Worker, Xiph.Org Foundation - is támogattak 👍‍👏

Az FFmpeg célja, hogy minden valaha készült multimédiás fájlt lejátsszon. Ennek a célnak az eredményeként széles körben használják, mind a hobbifelhasználók, akik személyes videóikat kódolják, mind a legnagyobb streaming szolgáltatások, mint például a YouTube, a Netflix, az X és a Spotify.

( H4MU | 2026. 01. 23., p – 11:54 )

Google szerint egy ottani kezdo fejleszto feleves fizuja

( pink v | 2026. 01. 23., p – 13:14 )

Az FFmpeg célja, hogy minden valaha készült multimédiás fájlt lejátsszon.

Ha Árpiék picit jobban nyomják a mencoder-t, nem szarják le a bugokat meg nem fásulnak bele, akkor most az mplayer/mencoder páros tölthetné be ezt a szerepet.

amikor a mencodert irtam, meg nem volt kozunk az ffmpeg-hez, es az ffmpeg sem tartott meg kb sehol (egy kezdetleges mpeg codec/muxer volt). kesobb kezdett a 2 projekt osszeolvadni (eloszor az ffmpegben implementalt visszafejtett divx3 codec miatt, amit fabrice meg alneven csinalt). az mplayer sokaig csak a codeceket hasznalta az ffmpegbol, evekkel kesobb kezdtek el portolni a demuxereket a libavformatba, illetve a filtereket is, igy ezutan mar az mplayer lenyegeben csak egy libav/ffmpeg frontend lett, a mencoder pedig okafogyotta valt...

a VLC mar letezett az mplayer elott is, az eredeti neve Video Lan Client, es volt hozza egy Video Lan Server is, mivel ez egy kliens-server video streaming megoldas volt, valami iskola szamara fejlesztettek hogy termek kozott tudjanak kozvetiteni vele.

evekkel az mplayer utan kezdtek el felfejleszteni a vlc reszet altalanos celu lejatszova, gyakorlatilag az mplayerbol/ffmpegbol lopkodva ezt-azt.

a Xine volt akkoriban a konkurencia, fej-fej mellett haladt a 2 projekt, van amiben ok voltak a gyorsabbak, a directvideo-s windows codec dll-ek tamogatasat ok fejlesztettek le, az mplayer onnan vette at lopta, aztan valahogy eltunt a sullyesztoben egy ido utan

igen! az egy aktivan fejlesztett mplayer fork. en is azt hasznalom :)

a keszitoje amugy nagyon korrekt volt, megkereste az osszes fejlesztot es engedelyt kert toluk egyesevel a licensz valtashoz.

bar a fork lehet eros kifejezes, mert egyes reszeit ujrairta, tehat nem 1:1 mplayer klon, de ugyanarra a kodbazisra epul.

en leginkabb a gcc 2.96-ra emlexem, ami egy nem letezo gcc verzio volt, a GNU sosem adott ki ilyet, a 2.95 utan a 3.0-at fejlesztettek. a redhat csinalta a 2.96-ot ami gyakorlatilag egy bugos 3.0 devel verzio volt, es emiatt a redhat es szarmazek linuxokban hibasan fordult az mplayer, nem mukodott sok minden benne. 

a masik szelesebb korben ismert bug pedig az akkori nvidia zart driver miatt jott elo, abban is volt valami hiba ami miatt ha jol emlexem zold csikot rajzolt a kep aljara, de nekem akkoriban nem volt nvidia kartyam igy csak olvastam rola.  egyik sem a mi hibank volt, de az usereket ez nem erdekelte egyaltalan, es tolunk vartak a javitast.

forditottam CVS-bol egy mplayert

a cvs (devel) verzio az mindig mukodott mert azt hasznlatuk mi is... de a release-ekben neha be voltak kapcsolva uj, meg nagyon beta featurek is, hogy teszteljek az userek :)

Egyetemi sztori 2000 kornyekerol: talaltam az egyik faliujsagon egy cetlit ami egy uberfasza alkalmi proggizo melot hirdetett. Jelentkeztem ra, bejott 2-3 arc a kampuszra, hogy egy nagyon bizalmas projektrol van szo, a Yahoo-nak valami flash-alapu forumara kene spammer botot irni ami regisztral es irogat mindenkinek fassagokat + monitorozza a hatekonysagot. Az elozo programozonak beletort a bicskaja a captchaba, megprobalom-e. Ok, meg. Nezem-nezem, hat mondom ezt en sem fogom tudni megugrani, de odaadtak az elozo versenyzo kodjat es milyen usernev bukkant fel itt-ott a kodban? ".so" :)

Remelem, elavult mar, bar tudtommal egyikonk sem tudott mukodo botot irni. :)

Pont ezt szerettem benne, hogy nem kell GUI-val bajlódni. mc extension file-ba beleraktam, oszt jónapot. Fasznak kell a GUI.

Az elvarratlan szálak a mencoderre vonatkozik, mplayer egész jól ment. Nehéz felidézni ennyi év távlatából; arra emlékszem, hogy voltak fájlok, filterek, amikkel nem birkózott meg. Hogy a kodek miatt vagy a felbontás miatt, azt már nem tudom. Kétesélyes volt, amikor enkódolni akartam valamit. Általában ment, de simán előfordult, hogy nem.
Akkoriban nem is nagyon volt más választás; ffmpeg később lett (legalábbis később találkoztam vele), és az ffmpeg-t később se szerettem. mencoder kiváló koncepciójú cucc volt, csak ez a megbízhatatlansága (olykor szar kimenetet állított elő, vagy adott beállításokkal egyáltalán semmilyet) elvette az ember kedvét, így kénytelen-kelletlen szépen fokozatosan migrált ffmpeg-re (ha fintorogva is), ahogy az fejlődött. Kár érte.

mencoder kiváló koncepciójú cucc volt, csak ez a megbízhatatlansága (olykor szar kimenetet állított elő, vagy adott beállításokkal egyáltalán semmilyet)

pff. most nem mondom, hogy user error, vagy RTFM hianya stb, de itt nagy valoszinuseggel az lehetett a problema, hogy olyan container (muxer) es codec parositast adtal meg, ami amugy nem elterjedt es emiatt semmi nem tudta lejatszani (lehet, hogy meg az mplayer sem, mert neha kellettek olyan metadatak amit nem minden container tudott tarolni, es a dekodolashoz szukseges volt). a mencoder nem biralta felul az usert, ha o mpeg1-et akart avi-ba rakni vagy sorensont mkv-ba, azt is megcsinalta, de minek. persze rakhattunk volna bele egy profile tablazatot, listat az elterjedt kombinaciokkal, igy felhasznalobaratabb lehetett volna, de annyira kevesen hasznaltak, es ok altalaban tudtak mit csinalnak, hogy nem ereztuk szuksegesseget ennek.

a filterek pedig a lejtszasra voltak optimalizalva, szorosan egyuttmukodtek a vo (video out) driverekkel a legoptimalisabb koztes kepformatumok, stride-k stb hasznalatara hogy minek kevesebb konverzio vagy folosleges memoria-atmasolas legyen a pipelineban. ez az encodernel nem mindig mukodott sajnos, es mivel nem az volt prioritas, telibesz@rtuk :)  

foleg hogy eleg hamar kialakult, hogy az mplayer a lejatszo es az ffmpeg a konvertalo, es a kodbazisuk nagy resze ugyis kozos volt, igy a mencoderre mar semmi szukseg nem volt. ha nem lett volna az ffmpeg, akkor valoszinu tobb energiat fektettunk volna a mencoderbe is, meg ha sok user hasznalja es bugreportol, vagy tobben fejlesztik, nyilvan mas lett volna abbol is.

A'rpi

user error, vagy RTFM hianya stb

Meglehet. Már nem emlékszem, régen volt. Sokat olvasgattam a leírását, azt tudom.
Rendszeresen használtam a scale filtert; hordozható készülékeim natív felbontására kódoltam át vele a filmeket. Volt, hogy elkezdett piros üzeneteket dobálni stdout-ra, de volt, hogy csak nem lett jó az eredmény. Ilyenkor kicsit még mókoltam vele, aztán mindig lett valahogy.
Még ezekkel a nyűgjeivel együtt is jobban szerettem, mint az ffmpeg-t valaha. Ugyanakkor tudod, hogy van ez: hamar elveszi az átlag júzer kedvét, ha valami fennforgás van.
Nagyon sajnáltam, amikor elkezdett lefelé ívelni a pályája (HOVD-n is lehetett látni a hanyatlást). Nagyon szerettem mind a lejátszót, mind az enkódert. Simán (és méltán) lehetne ma ez a páros a mainstream, ha egy kicsit másképp alakul a történet.

Simán (és méltán) lehetne ma ez a páros a mainstream, ha egy kicsit másképp alakul a történet.

ebben nem ertek egyet. amikor en 2004-ben kiszalltam, mar nem volt hova fejlodnie, minden akkor ismert fileformatumot es codecet tamogatott, linuxon is. amiben erosodni lehetett volna, az a GUI (ez a winamp stilusu megoldas akkorira kiment a divatbol), a dvd/bd menuk tamogatasa (ez jogilag is eleg aggalyos volt, es technikailag is eleg bonyi, foleg ha a hivatalos specifikaciot/patentet/SDKt nem hasznalhatod), es a nem-linux oprendszerek jobb supportja (elsosorban a windows, de ugye kinek van kedve windows hasznalni, sot, fejleszteni ra, debuggolni rajta), de engem egyik sem hozott lazba, ahogy a tobbi fejlesztot sem igazan :)

a mencoder az ffmpeg miatt ertelmetlenne valt, ez csak akkor lett volna maskepp, ha nincs az ffmpeg... ugyanazok a fejlesztok nem fognak 2 ugyanolyan celu progit fejleszteni parhuzamosan!

en egy dolog miatt hasznalok mar evek ota mpv-t az mplayer helyett: azzal megy a hang rendesen macos-en, az mplayer valami regi mac-es audio api-t hasznal ami mar az ujabb macos-ekben nincs vagy nem mukodik.

dvd menu passz, az akkor sem erdekelt amikor meg dvd-ket neztunk. mar 15 eve hd-t toltok csak le mkv-ban...

amugy manapsag mar mindenki VLC-t hasznal, ugy tapasztalom

Gabucinora gondolsz? :)  eletkepes volt, csak a gerillamarketing vonalan dolgozott :)

ha o nem trollkodja/flameli tele a netet anno, akkor az mplayert ma se ismerne kb 5 emberen kivul senki...

amikor az mplayert irtam, meg az xanim, xine, avifile, xmmp voltak az elterjedt lejatszok, mind gui-val. ezekhez kepest egy uj, gui nelkuli, csak 1-2 formatumot ismero lejatszo nem erte el az userek ingerkuszobet. hiaba volt atom stabil es gyors, a tobbivel ellentetben.

igazabol az avifile projekt csinalta meg eloszor a divx lejatszast linuxon, a dll betoltesevel (wine loader), de az meg az mplayernel is fapadosabb program (inkabb csak egy c++ library) volt... es amig az akkor meg teljesen ismeretlen ffmpegbe fabrice bellard (akkor meg gerard lantau alneven) nem implementalta reverse engineering alapjan, addig nem is volt mas lehetoseg ra. az mplayerben is az avifile dll loaderjet hasznaltuk.

remlik valami az avifile-rol es errol a dll betoltesrol is. xmps is megvan asszem, de nekem nem volt olyan videom amit lejatszott volna. a xine egy bloatware volt asszem. a regi "szep" closed-source idok amikor minden csak win/mac-re letezett es ugy orizte mindenki a forraskodjat, mint a szent gralt :)

remlik valami az avifile-rol es errol a dll betoltesrol is

az nagyon jo moka volt, engem akkoriban lenyugozott. eredetileg a wine-bol szarmazik a dll loader kod, onnan kerult valahogy az avifileba lecsupaszitva, csak a dll betoltes es a szukseges minimum win32 kernel emulacio (file i/o, memoria foglalas stb).

voltak a regi egyszeru win codecek, mint a divx3, es a microsoft egyszeru formatumai, ezeket kezelte mar az avifile is.

aztan voltak az ujabb, dcom/directx/directvideo codecek c++ rpc-s interface-el, ez nekem mar sok volt. az avifileban implementaltak c++-ban, de a xine-os arcok valahogy ezt is visszafejtettek es megirtak plain C-ben. ez kerult be az mplayerbe is vegul.

meg voltak az apple codecei, leginkabb a sorenson3 amit akkoriban hasznaltak pl. a movie trailereknel, ezeket pc-n windozon csak a quicktime programmal lehetett lejatszani. ezzel en kuzdottem meg, teljes wine alatt mukodott linuxon is, legalabbis a crossover-fele wine-al, de az meg ugye zart forraskodu volt, igy annak egyes reszeit lecsereltem az opensource wine-bol modositva ujraforditott kodokra es igy sikerult elesben debuggolni. vegul kiderult, hogy a kb 6 megas quicktime.dll lenyegeben egy komplett macos emulator, es nagyjabol a mac-es quicktime appot futtatta windozon. szoval ahelyett, hogy az apple rendesen portolta volna windozra, inkabb megvettek egy emulator fejleszto ceget es osszebarkacsoltak azzal. kb ahogy pl. a coreldraw vagy sok jatek linuxon beleforditott wine-al mukodik. ezert volt olyan lassu windozon is...  na ebbol kellett kihackelni azt a minimalis kodot ami szukseges csak a codec betoltesehez, es igy az mplayer csak a codecet futtatta a tobbi sallang (emulalt windozon emulalt macos-es gui...) nelkul. jo kis reverse engineering gyakorlat volt!

( EspOS | 2026. 01. 24., szo – 18:04 )

Picsa pénz. Ezt állami szinten kéne évente kiköhögni jóérzéssel odaadni a fejlesztőknek.

σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)

https://www.esp8266.org

Ezt programozóknak és felhasználóknak kéne elbírálni nyílt szavazással. Magánszemély, egyesület indulhat megfelelő minőségű cuccal. Ebből lölö kimaradna. Ilyen szerintem nincs. Csak Magyarországon évi 100 forint/állampolgár után bejönne évi 3M USD. Ennyit lölö kap naponta. Ennyi szétosztható pénz erősen növelné a minőségi nyílt forrású projektek számát.

σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)

https://www.esp8266.org

Ezt programozóknak és felhasználóknak kéne elbírálni nyílt szavazással.

es mi garantalja, hogy nem csaljak el? ha fiz zsuri van, akkor a haveroknak itelik, ha barki szavazhat akkro meg jonnek a botok es fake accokkkal, ahogy kb minden ilyen szavazosdin...

pénz erősen növelné a minőségi nyílt forrású projektek számát.

nem a szamat, hanem a minoseget kene novelni, azt pedig pont nem a penz fogja.

raadasul sok projekt mogott nincs ceg/alapitvany, ami a penzeket fogadna, kezelne, igy ok technikailag nem is kaphatnanak.

ha meg kapnak, akkor elojon az a problema, hogy mondjuk a multban 100 ember kuldott mar patchet bele, es kozuluk nehanyan biztos ugy erzik majd az o patchuk nelkul nem is kapott volna penzt a projekt ezert kerik belole a reszuket.

regen volt valamennyi ralatasom az ffmpeges temara, ott ugye sok ceg akarta licenszelni, hasznalni a termekeiben, es volt igeny arra is, hogy a gpl-es kodokat nem gpl alatt hasznalhassak, erre adtak volna penzt. annyira celtalanul "csak ugy" nem szoktak tamogatni ezeket amugy se. aztan ott is elojott hogy a penzeket hogyan, mire hasznaljak fel, ki dontson errol, ki kapjon belole stb. szerintem ez tobb energiat es idot vitt el a core teamtol mint maga a fejlesztes :(

Ennel a katyvasznal szerintem mukodobb model az, ha egy vagy tobb ceg foglalkoztatja az open source projekten dolgozokat, kapnak fizetest es tamogatjak oket abban, hogy az open source projekten dolgozzanak. A kodot megfeleloen licenszelve ezek a cegek beepithetik a termekeikbe, amivel bevetelt generalnak, amibol fizetik a programozokat, es igy tovabb.