Chyba ve ffmpeg umožňuje vzdálené čtení souborů (diskuse)

[Ladislav Hagara]

Opraveno ve verzích 2.8.5, 2.7.5, 2.6.7 a 2.5.10.

[Jardík]

No, ještě že JardikPlayer ffmpeg nepoužívá.

[atirage21]

Tých chýb je viacero, napríklad pre dekodovanie náročnejšieho videa v divxe, alebo celková náročnosť na procesor, ak to porovnám s platenými kodékmi v rámci fluendo - one play cez gstreamer.

[Ovocníček]

Dost pochybuju, že je fluendo rychlejší - není rozdíl v konverzi YUV-RGB (to je ale džob rendereru, měla by to dělat grafická karta). Obvykle dekodéry v FFMpegu jsou nejvýkonnější, asi s výjimkou HEVC, na který vývojáři dělající SIMD trochu kašlou (co jsem koukal tak s nadějí, že jim za to jednou někdo zaplatí).

[atirage21]

No mám iné skúsenosti. Jednak niektoré avi s vyšším bitratom sú viac rozkockatené a roztrasené (dokonca až nepozareteľne pri dnešných veľkostiach monitorov), namiesto bieleho svetla prostredia vo videozázname cez ffmpeg je slabo modré svetlo v porovnaní s fluendo, a taktiež nefunguje úplne dobre multitasking pi rozličných kodekoch (jedno jadro mi ide na 60 % v takte 2100 mhz, kým pri fluende to ide hladko a vyladene na viacerých jadrách po 10 % pri frekvencií 900 mhz). Testované na počíači s procesorom i7, nvidia quadro 880m, s relatívne novým linux mintom 17.2

[atirage21]

Ešte dodám, že som to testoval pred polrokom. Ako som zakúpil fluendo kodeky, tak si dokonca pochvaľujem mnou nenávidený totem. Kvalitu obrazu je možné jednoducho porovnať, ak si pustíte vedľa seba ten istý záznam v rovnakom čase na tom istom hardwari.

[atirage21]

A Totem má aj niečo ekologické, čo som veľmi dlho hľadal medzi prehrávačmi v linuxe - možnosť uspať alebo vypnúť pc po prehratí filmu (ak by človek zaspal): https://github.com/greenarrow/sleepy-totem

[Jiří Lisický]

mplayer vecernicek.avi; poweroff

[Ovocníček]

Kvalitu obrazu je možné jednoducho porovnať, ak si pustíte vedľa seba ten istý záznam v rovnakom čase na tom istom hardwari.

Ne vždy. Může dojít k tomu, že jeden program zabere hardwarové dekodéry a nepustí k nim jiné, a totéž se ještě častěji stává s HW akcelerací výstupu na GPU. Jinak u většiny kodeků je rozdílný výstup prostě chyba (u mpeg1/2/mpeg4asp je určitá tolerance kvůli nepřesnému DCT, ale nic velmi pozorovatelného). Formáty jako H.264 a novější mají bit-exact dekódování a FFMpeg na ně má regresní testy které to kontrolují (ale kontrolované jsou i ty starší, takže rozbité dekódování je rozhodně nestandardní projev). Nebyl miscompilovaný?

[Ovocníček]

No mám iné skúsenosti. Jednak niektoré avi s vyšším bitratom sú viac rozkockatené a roztrasené (dokonca až nepozareteľne pri dnešných veľkostiach monitorov)

Tohle bych si tipnul že bude v rozdílném nastavení post processingu (deblocking a deringing etc, IMHO to jenom rozmazává zbytky detailů, které v tom videu zbyly, takže je to akorát ještě horší než předtím, i když třeba některé kompresní artefatky zmizely). Tipl bych si, že FFmpeg ve výchozím nastavení ho neprovádí pokud si to uživatel nenastaví, kdežto Fluendo ho má nastavený na zapnuto? Za to bych se teda na FF nezlobil.

[atirage21]

To roztrasenie sa prejavovalo akoby posunutím niektorých farieb/odtienov (cca 2mm), a pri pohybe scény to vyzeralo skôr na 3D záznam a nie na bežné video, keď niektoré časti osôb boli o čosi posunuté. Ako som už písal, formátom bol divx s vyšším bitratom. Teraz som si ešte spomenul, že pri Toteme s fluendo to nerobilo (malo by mať podporu vdpau a va-api), pričom v ffmepgu sa to prejavilo pri zapnutom vdpau. Takže možno je chyba medzi ffmpeg a vdpau, ale iba u videa s vyšším bitratom.

[atirage21]

Ešte ma to napadlo, že či to možno nebude s ovladačmi Nouveau, lebo v rámci vdpauinfo chýba výpis za formáty oproti ovládačom nvidia pri tej istej grafickej karte:

DIVX4_QMOBILE DIVX4_MOBILE DIVX4_HOME_THEATER DIVX4_HD_1080P DIVX5_QMOBILE DIVX5_MOBILE DIVX5_HOME_THEATER DIVX5_HD_1080P

[Ovocníček]

Jo, rozsekaný ovladače GPU jsou IMHO mnohem pravděpodobnější zdroj problémů (holt, cokoli, co jde kolem HW), kdežto při dekódování v ffmpegu přes software je prakticky jistota, že to bude v pořádku, pokud není binárka nějak špatně zkompilovaná. Servery FATE by měly hned detekovat, že se nějakým commitem změnil výstup a dekodér je rozbitý. Periodicky se to kontroluje.

[Peter Golis]

Pripomína mi to chyby MS implementácie ASF z minulého tisícročia. Dúfam že sa ffmpeg neinšpiroval tak starými peniazmi.

[Ovocníček]

Pokud vím, tak je to funkce kontejnéru mov/mp4, který podporuje něco jako jsou linked segments v matrosce (známe jakožto "ordered chapters" u anime), ale místo sgid umožňuje na ně odkazovat přímo cestou k souboru.

Jinak samozřejmě není dobrej nápad umožnit toto ve spojení se sítí :(

[pc2005]

file:// klasická chyba

[karry]

Netušíte jak je na tom libav? Trpí těmito chybami také?