GStreamer 1.20.5

Szerszám

Megjelent a GStreamer - nyílt forráskódú, keresztplatformos multimédia framework - 1.20.5-ös, hibajavító kiadása. Főbb javítások:

  • systemclock waiting fixes for certain 32-bit platforms/libcs
  • alphacombine: robustness improvements for corner case scenarios
  • avfvideosrc: Report latency when doing screen capture
  • d3d11videosink: various thread-safety and stability fixes
  • decklink: fix performance issue when HDMI signal has been lost for a long time
  • flacparse: Fix handling of headers advertising 32 bits per sample
  • mpegts: Handle when iconv doesn't support ISO 6937 (e.g. musl libc)
  • opengl: fix automatic dispmanx detection for rpi4 and fix usage of eglCreate/DestroyImage
  • opusdec: Various channel-related fixes
  • textrender: event handling fixes, esp. for GAP event
  • subparse: Fix non-closed tag handling
  • videoscale: fix handling of unknown buffer metas
  • videosink: reverse playback handling fixes
  • qtmux: Prefill mode fixes, especially for raw audio
  • multiudpsink: allow binding to IPv6 address
  • rtspsrc: Fix usage of IPv6 connections in SETUP
  • rtspsrc: Only EOS on timeout if all streams are timed out/EOS
  • splitmuxsrc: fix playback stall if there are unlinked pads
  • v4l2: Fix SIGSEGV on state change during format changes
  • wavparse robustness fixes
  • Fix static linking on macOS (opengl, vulkan)
  • gstreamer-vaapi: fix headless build against mesa >= 22.3.0
  • GStreamer Editing Services library: Fix build with tools disabled
  • webrtc example/demo fixes
  • unit test fixes for aesdec and rtpjitterbuffer
  • Cerbero: Fix ios cross-compile with cmake on M1; some recipe updates and other build fixes
  • Binary packages: pkg-config file fixes for various recipes (ffmpeg, taglib, gstreamer)
  • Binary packages: Enable high bitdepth support for libvpx (VP8/VP9 encoding/decoding)
  • Binary packages: ship aes plugin
  • Performance improvements
  • Miscellaneous bug fixes, memory leak fixes, and other stability and reliability improvements

Részletek a változások listájában és a bejelentésben.

( xc0m v | 2022. 12. 20., k – 16:55 )

Hoha nem értettem hogy mi különbség a GStreamer és az FFMpeg között?  Ha kb. ugyanazok, akkor miért van kettő?

Nem ugyanazok. Nagyon hasonló funkcionalitást érnek el, de a kettő mögött egész más a kód. A GStreamer a korábbi megoldás, és kicsit a koncepciója is eltér, pluginrendszerben old meg dolgokat. Az egy más kérdés, hogy a projektek elsöprő többsége már nem használja, szinte mindenki váltott FFmpeg-re, de ez nem jelenti azt, hogy a GStreamert kidobják, hagyják veszni. Amögött is ott vannak a fejlesztők, akik esetleg nem értenek egyet mindenben az FFmpeg fejlesztőivel.

Nincs ebben semmi új, egy csomó olyan megoldás van, amiből kettő vagy több van. Pl. mplayer, mplayer2, mpv, vagy pl. GNU coreutils és ezek BSD-s variánsa. OpenSSL vs. LibreSSL, sudo vs. doas, picom kompozitorból van ezer féle fork, Audacity-ből rengeteg fork, vim vs. neovim, stb.. Jó, néha ezeknél a licenc vagy valami más (pl. nyelvi megoldás) is eltérhet, de ugyanúgy furcsa lehet, hogy miért van belőlük kettő. Néha érhető, pl. LibreOffice vs. OpenOffice.org.

Még OS-ek szintjén is fennáll ez, pl. ha egyszer ott a Linux, minek van ott a többféle BSD, meg Illumos disztrók? Eleve Linuxból is minek ennyi disztró? Így működik az opensource, valakinek valami nem tetszik, forkolják a projektet. Eleve böngészőkből is van egy rahedli, annak ellenére, hogy azok 90+ %-a ugyanarra a Chrome/Blink motorra épül. Ablakkezelőkből szintén van egy rakat azonos klón, pl. dwm (C-ben írva), ennek vannak klónjai, spectrewm (C-ben), Qtile (ugyanaz, csak Pythonban), Xmonad (megint ugyanaz az ablakkezelő lényegében, csak Haskell-ben írva), vagy pl. i3wm (X.org-ra) és ennek waylandes klónja a SwayWM, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Úgy mondtál valamit, hogy valójában nem mondtál semmit, de azt is pontatlanul. De legalább szép hosszú hozzászólásod lett.

Based on GLib 2.0 object model for object-oriented design and inheritance

Vagyis a kettő nem teljesen alternatívája egymásnak, a GStreamer alapvetően a GLibre támaszkodik és az azt használó GTK-s környezetbe illeszkedik a legjobban. Keretrendszerként többet ad, mint maga az ffmpeg (sőt, van hozzá ffmpeg plugin), pl. a GStream segítségével akár VoIP alkalmazásokat is készíthetsz. Az ffmpeg igazából csak audió/videó kódolására és dekódolására való, de arra nagyon.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Szerintem meg te sem nagyon mondtál annyival többet, hogy ledorgálj miatta. Pl. minden környezet illeszkedik minden környezetbe. Ha Gtk kell valaminek, behúzza függőségnek, ugyanolyan jól fog futni Qt-s környezetben is. Pocsékolás persze, hogy ha már fut egyféle környezetnek a libjei, és azon felül betöltögetünk másikakat, akkor csak növeltük az erőforrás-igényt, de hát ez van.

Én egyébként úgy veszem észre, hogy egyre kevesebben használják a Gstreamert. Főleg régi lejátszókra jellemző, persze nem csak azok használják, mielőbb ebbe is belekötsz. FFmpeg is való mindenre, nem csak kódolásra, dekódolásra, de tud képernyőt rögzíteni, jó webkamerát rögzíteni, stb.. Egy teljesen univerzális tool. Szerintem még az se lehetetlen, hogy VoIP-s cuccot írjon vele az ember.

Igazából vannak még alternatívák e kettőn kívül is, pl. mpg123-nak is van egy libje, de az csak néhány formátumot támogat, néhány játék és minimalista audiolejátszó szokott ráépülni tipikusan.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szerintem ne tetézd :D

Itt arról van szó, ha egy GTK-s programot írsz, akkor a GStreamer pont beleillik a GLib-es, GObjectes (fejlesztői) környezetbe, míg pl. QT-s programnál közvetlen használni az a sajtreszelővel...

Szóval a GStreamer az egy magasabb szintű absztrakció, leginkább Gnome-os fejlesztésekhez. Ilyen (volt) pl. a Phonon a KDE 4-ben (nem tudom, mi lett vele, talán már a Qt része), ami az ffmpeget mint codec-gyűjteményt (is) tudja használni.

Nem is állítottam, hogy mennyivel alacsonyabb szintű. Továbbá azt sem, hogy Gnome-hoz és Gtk-hoz van, csak azt, hogy ez nem zárja ki, hogy akárhol használható legyen. Pl. qt-bindings-os megoldás is van rá. Ahogy egy GIMP-et sem csak Gnome-on lehet használni.

Az is világos, hogy pluginként az ffmpeg-et tudja használni, de nem értem, hogy ez min változtat. Az a baj, hogy túl sokat gondoltok bele abba, amit írok. Nincs semmi bajom a Gstreamerrel, csak megfigyeltem, hogy egyre kevesebb projekt használja. Ennyi. Azt nem állítom, hogy halott vagy ilyesmi, mert mint a hírből is kiderült, fejlesztik még. Általában nincs is fent a rendszereimen, de a mostanin ott van, és pont titeket meghazuttolva az átmeneti tesztelésre felrakott Qt5-ös Goldendict-git húzta be függőségnek gst-plugin-base-t, ami meg húzta be a többi gst-s csomagot. Ennyit a GLib-ről meg  GObjects-ről. Ennek a szoftvernek is azért kellett, mert néhány szótárban lehetnek médiafájlok, amit meg kell jeleníteni, így függőségnek kell neki.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”