Kedves MPlayer Felhasználók!
Körülbelül 5 éve használok mplayert és megfigyeltem azt a tendenciát, hogy ahogy új mplayer verziók jönnek ki, egyre lassabb a tekerés (seeking) MPEG2/MPEG4 streamekben. Az mplayer 1.0rc1 verziójában minden MPEG2/MPEG4 streamben (DVD VOB, DVB felvétel stb.) folytonos és követhető volt, de a magasabb verziókban (mplayer 1.0rc2 vagy abban, amit most használok: Sherpya-SVN-r29355-4.5.0) szinte egyáltalán nem látni képkockát tekercselés közben. Szerintem az mplayer 1.0rc2 és a magasabb verziók nem mennek keresztül a B típusú kockákon, mely a blokkosodást okozza az átmenetek közben (lásd alább a képsort). Ez már érezhető az 1.0rc2-ben, bár nem blokkosodnak a kockák tekerés közben - kb. fele olyan lassú a tekercselés.
Ezek a képsorok -vo png módban készültek, rátenyerelvén a jobbranyílra, mely az előretekerést jelenti. Ezután IrfanView Thumbnails-szel összegyűjtöttem a képeket és egymás mellé raktam. Ez bizonyítja, hogy az mplayer 1.0rc1 még így (jól) csinálja. Kipróbáltam ugyanezt Sherpya-SVN-r29355-4.5.0-val is, de az egyetlen képet sem (!) produkált tekercselés közben, csakis lejátszáskor (mellesleg ha a kimenet nem png, akkor is így van). Hasonló a helyzet a DivX/XviD filmeknél, leszámítva a B kockák okozta blokkosodást.
Nem értem, miért kellett ezt a feature-t folyamatosan kiszedni az évek során. Az mplayer régen messze vert minden más lejátszót a seeking hatékonyságával. Nem értem miért elégszenek meg az mplayer fejlesztők a középszerű seekeléssel. Remélem ez is valami default érték változás, amit könnyedén felül lehet bírálni bizonyos kapcsolók explicit megadásával (pl. -lavdopts). Van valami féle workaround?
Kösz
hajbazer
- 4789 megtekintés
Hozzászólások
A teóriád nem teljesen helyes.
Európában a képsorrend ilyen: IBBPBBPBBPBB. Ez egy GOP, ami után ugyanez van.
Az amerikai kicsit hosszabb: IBBPBBPBBPBBPBB.
13, illetve 16 képes a periodicitás, de egy másodperc alatt 25, illetve 29.94 kép van. Persze ez a GOPméret megváltozik, ha snitthatárra érünk, szóval lehet kevesebb (több asszem nem).
A gond az lehet, hogy a seek nem GOP elejére ugrik. Régen a wmv-kben produkált ilyet az mplayer, de normális MPEG cuccokban még nem láttam rossz seek-et.
A probléma kicsit bonyolódik, ha az általad említett DVD Program Streamben, vagy a DVB Transport Streamben kell nyúlkálni, mert akkor egy csomó összemultiplexelt adatfolyamból kell kibogarászni a megjelenítendőt.
TS-t nem nagyon próbáltam még, de a DVD-s cucc nekem nem csinál semmilyen bajt.
Most, hogy így végiggondolom, nem is nagyon értem a problémádat, szóval mond el kicsit érthetőbben, bocsi.
- A hozzászóláshoz be kell jelentkezni
Köszi a választ. A lényeg az, hogy egyszerűen csak két mplayer verziót hasonlítok össze - ami a "teóriám" helyességétől független (bár ott volt, hogy szerintem, azaz nem vagyok biztos benne). Egy régebbit, ami normálisan teker és az újat, ami nem. A wmv-s probléma pedig egyáltalán nem ilyen dolgokat produkált, hanem össze vissza ugrált benne kiszámíthatatlan időközöket.
Részletesebben:
Adott egy mpeg2 formátumú fájl, legyen national_geographic_csalagut.mpg. Ezt valamilyen kártyával vettem fel, ami natívan MPEG-2-be kódol, de beszélhetnék akár egy DV-ből MPEG-2-re konvertált videóról is vagy akár VHS-ről rippelt SVCD-ről. A régi verziók (az 1.0rc1 és alatta lévők) teljesen folyamatosan tekernek, tehát ha rányomok a jobbra nyílra, ami a seek forwardot jelenti (configban seek+), akkor először a képen láthatóan elblokkosodik a kép (valószínűleg közbejön egy B kocka is - ugyanis olyan tartalomnál nem tapasztaltam ilyet, amikben csak I és P kockák vannak), majd rögtön ugrik a következő I kockához. Lényeg, hogy rengeteg minden - mégha nem is teljes felbontásban - láthatóvá válik tekerés közben így nagyon könnyű megtalálni bármit akár egy többórás tartalomban is. Az új verziók (1.0rc2 és fölötte lévők) már csak I kockákhoz ugranak, azt is sokkal lassabban, mint elődeik - blokkosodás nincs, tehát valószínűleg B kocka már nem jöhet közbe. Az SVN-ből letölthető változatok pedig már egyáltalán semmit nem mutatnak tekerés közben (még az I kockákat sem), csak a hangot játsszák (ha van). Belenéztem az rc2 Changelog-jába és benne volt a " * libmpeg2 updated to 0.4.1", szóval valószínűleg ettől van, mivel libmpeg2-t használ dekódoláshoz. Bár ez akkor sem magyarázza meg ugyanezt a jelenséget MPEG4 tartalmaknál. Megnéztem a libmpeg2 ezen verziójának ChangeLog-ját is, de abban nem volt semmi erre vonatkozólag.
Ha így sem érthető, megpróbálom felvenni kamerával a különbséget és feltenni valami videómegosztóra.
- A hozzászóláshoz be kell jelentkezni
Nekem van olyan (HD) kamerával felvett videóm, ami a gyártó szerint szabványos mp4 (1920/1080i) de az mplayer egyáltalán le se tudja játszani. Sőt egyetlen olyan program se, ami az ffmpeg valamilyen származékát használja. Linuxon sajnos az összes program ilyen.
Mind ugyanolyan hibát generál. Elindul a lejátszás, de eleve nem a megfelelő képaránnyal, aztán bizonyos részeknél szétesik a kép, majd megakad a lejátszás és kihagy pár másodpercet. Mindegyik általam kipróbált linuxos lejátszón pontosan ugyanúgy történik minden. Sőt az osx-en kipróbált ffmpeg-et használó programokkal is ez a helyzet.
Bár ennek a te problémádhoz nem sok köze van...
- A hozzászóláshoz be kell jelentkezni
És az újaknál már nem is talál magára? Ha a tekerés közben csak hang van, akkor a kép idővel nem jön meg?
Elvileg meg lehet adni a lejátszáshoz használt kodeket is. Asszem -vc. Ha van valami más lehetőség is, mint a libmpeg2, akkor próbáld úgy (ezeket annyira nem ismerem).
Messzemenő következtetéseket így nem nagyon tudok levonni. A három verzió által produkált terminálkimenet kéne, hogy lássuk, mit mivel próbál és mi nem sikerül neki tekeréskor (ha egyáltalán mond rá valamit).
- A hozzászóláshoz be kell jelentkezni