Jak funguje seekování MP4/MKV/TS přes HTTP?

[Mazonochijs]

Měl bych dotaz, jak funguje seekování  videa na HTML stránkách normálně vloženého přes tag video.
Jde mi o 2 věci:
1. Je vždy nutné nutné stáhnout počátek videa? Nebo otázka zní jinak, které video formáty umožňují přehrávání tak, že  jim stačí číst od prostředka (explicitně bez nutnosti stahovat začátek) a video se ihned bude přehrávat zhruba od prostředka (samozřejmě s tím zatočí variabilní bitrate).: Konkrétně : MKV, MTS, TS, MP4, M4V, AVI, H264(ano, "kontejner" h264, nebo spíš raw videostopa bez kontejneru )   Pozor, některé kontejnery mají volbu zapsat metadata na začátek či konec ( ffmpeg -c hevc -f mp4 -movflags faststart)) -

2. Dejme tomu ,že chci seeknout na konkrétních pozici 4:00. Jak se v tomto případě zachová prohlížeč a server?
 (závisí na 1. – pokud nezná index,)
Dá se v tomto případě považovat HTTP server za CHYTRÝ NEBO HLOUPÝ? Tzn, jestli klient pošle Range: 3 000 000 - ..., analyzuje nějak server, že data je nutné nějak zarovnat směrem k předchozímu I frame ( nebo bloku ?), pošle server Range: 2 900 000, nebo prostě server tohle neřeší.
A pokud klient stáhl začátek (s indexem), ví přesně jaký Range reqeust má poslat?




3.  pokud je mp4 s metadaty na konci, řeší se to jak? Musí se čekat na celý soubor, nebo stačí stáhnout koncovou část of soubor ze serveru například  poslední 1MB (

4. Jak vlastně je veliká část metadata / indexu / moov atomu? v závislosti na délce videa.

5. mají tedy videosoubory více stupňová metadata (tzn ,jestli je nejdřív nutné stáhnout /metadata / index a pak ještě jsou nějaká data rozseta v kontejneru (proložena-interleaved), )

[Reklama]

[RDa]

1. zalezi na chytrosti prehravace(prohlizece)
- kontejnerove verze musi stahnout index/metadata, v pripade MOVu to je nedatovy strom pod atomem MOOV, pak lze seekovat na frame presne, protoze se da spocitat kde v pozici datoveho souboru je
- nekontejnerove verze musi umet parsovat bitstream - najit synchronizacni znacku (hlavicku NAL) a pak se dopracovat k nejblizsimu i-frame (je to vicemene streamovaci pristup s vypadkem dat)

2. jak se zachova prohlizec je na jeho chytrosti, v pripade opensource viz zdrojaky
- HTTP server nema poneti o tom ze servuje video kdyz pouzivate soubory (jina by byla kdyby jste jel pres RTSP)

3. kdyz jsou metadata na konci, na pocatku souboru mas MDAT o zname velikosti, takze holt udelas o jeden http request vice

4. velkosti si muzes najit kdyz si udelas rozdil velikosti souboru a offsetu mezi "MOOV" a "MDAT" (zda jsou na zacatku ci konci je jen o tom v jakem poradi je naleznes - mdat/moov  = na konci, moov/mdat = na zacatku). Pocitej typicky se 8 ci 12 byte na frame (velikost samplu je 4byte - STSZ, offset je 4 nebo 8 (CO64) - 32/64 bit soubor - jestli ho mas nad 4GB). U audia se offsety davaj spis na chunk pres nekolik framu.

5. u MOVu jsou hodnoty indexu soucasti metadat, staci se dopracovat k MOOV atomu a velikost vsechn indexu/metadat je hned u nej uvedena (v pripade ze jsou na konci, muze tam byt keyword: till-end-of-file).


PS. Implementoval jsem MOV podle dokumentace od Applu :-)

[Ondrej Nemecek]

Metadata by měla být na začátku, jinak se bude čekat na načtení celého souboru. MP4 servírovaný pomocí Apache2, Nginx nebo Tomcat a zobrazený ve Firefox či Chrome - seekuje mi v pohodě. Vše přiměřeně aktuální verze software.

Trochu mě překvapilo, že, zdá se, není ve Firefoxu v panelu Síť seekování vidět??

[Exceptions]

ano, hlavně je potřeba mít metadata na začátku.

Seekování v FF nejde vidět nejspíš proto, že tam jdou vidět až dokončená http spojení, zatímco přehrávání videa to spojení bude držet otevřené. Kdysi byl problém, že ne všechny komunikace z prohlížeče šly vidět v debug panelu dokud probíhaly, implementace přehrávání videa tady bude hrát zásadní roli, DRM a další drobnosti. Přesně nevím.

Osobně bych se spíše podíval do OS, případně, wireshart hodně pomůže. Na HTTP server jede klasický range, v indexu v metadatech je také range, stejně to funguje při přehrávání na disku, http server pak nedělá z principu nic jiného než ten range předává OS a ten dělá přesně to co běžně.

3) stačí stáhnout tu koncovou část, ale musí si to udělat klient sám nebo si z JS můžeš říct o konec souboru, sám naparsovat a poté si seekovat sám

4) odhaduji, že pár Kb, už je to ale roky co jsem něco ručně parsoval. Existují na to hotové knihovny v různých jazycích, případně je možné projít specky

5) nikterak moc dat tam není, třeba u mkv je uvnitř blocku pouze časová značka, flagy pro dekódování, velikost framů a prá drobností o samotném snímku, podobné to je u mp4. Lepší je, když si ty specky prostě nastuduješ

[Lieselotte]

On by wireshark napověděl, kdybychom neměli v http/2 vynucené TLS, žejo...

[Reklama]

[black3r]

On by wireshark napověděl, kdybychom neměli v http/2 vynucené TLS, žejo...

existuje `python2 -m SimpleHTTPServer` resp. `python3 -m http.server`, HTTP/1.1 bez TLS, staci si najst videa, pustit python a wireshark a mozes sa hrajkat.., ked otvoris v browsri priamo URL videa, vacsinou sa sprava tak, ako keby si ho mal vo <video> tagu, ked ti to nestaci, tak si mozes napisat tie 3 riadky HTML-ka, to snad zvladnes