c:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\igino_manfre>
| filename | scritto il | alle | dimensione | filename | tipo |
| ../hls2/hls2.m3u8 | 18/04/2016 | 18:23 | 4.109 | hls2.m3u8 | h264 288p 150kbps statico |
| ../hls5/hls5.m3u8 | 01/10/2021 | 09:06 | 705 | hls5.m3u8 | h264 dinamico (rtp_int) |
| ../hls6/hls6.m3u8 | 05/03/2021 | 22:43 | 721 | hls6.m3u8 | h264 dinamico (se rtp_ext) |
| ../hls8w/hls8w.m3u8 | 03/07/2020 | 17:40 | 2.687 | hls8w.m3u8 | h264 400p statico |
| ../hls8z/hls8z.m3u8 | 08/01/2020 | 18:37 | 2.689 | hls8z.m3u8 | h265 400p statico |
| ../hlsB/hlsB.m3u8 | 09/01/2020 | 12:38 | 2.607 | hlsB.m3u8 | h265 400p statico |
| ../hlsC/hlsC.m3u8 | 27/12/2020 | 18:38 | 2.605 | hlsC.m3u8 | h265 2k 5Mbps statico |
| ../hlsD/hlsD.m3u8 | 27/12/2020 | 18:51 | 2.605 | hlsD.m3u8 | h264 2k 10Mbps statico |
Questo file e' generato dalla seguente linea
Fino alla fine del XX secolo (eh si, sembra un'altra epoca, vero?) chiunque volesse far vedere delle immagini in movimento sulle
sue pagine web (web stesso che tanto vecchio non era) doveva utilizzare tre compressioni (real video®, windows media® e
quicktime® rispettivamente della Real Networks®, Microsoft® ed Apple®), per ognuno dei quali la piu' grande limitazione
data appunto dalla ®: Marchio Registrato.
La scelta del formato limitava la fruizione alla uscita del terno prescelto: Real, Mac o Windows?
Chiunque doveva scaricare sul suo pc i tre software (che bonagrazia erano gratuiti), la qualita' era mediamente una
schifezza.
Standard? Internet e' la casa delle liberta' ognuno fa quello che vuole, ed il successo di ogni idea e' dettato dal mercato.
Mpeg2 era adatto giusto al broadcast (il DBV-T, ora in tutte le nostre case, e' del 1997 e chi l'aveva inventato 10 anni
prima lo giudicava troppo complesso per poter essere realizzato).
Mpeg4 era una fantastica pentola ribollente di propositi ed idee, dopo venti anni non tutte sviluppate,
che realizzava molti dei sogni di ogni progettista.
Ma il cartello ha provveduto a isterilirlo.
E bada bene: per il video parliamo di compressione mp4 (non h264, che sempre mpeg4 era, ma del 2001),
quella che - per chi se la ricorda - era in pratica l'xvideo: 700 Kbps per un video 640x480 con
molti artefatti.
Del resto la rete, per la quale adesso si parla sempre piu' di Gbps, a quel tempo era mediamente supportata da linee a 56Kbps.
Cosa volevi trasmettere a 56Kbps? Il tempo reale era interdetto a scapito del piu' lento ma visibile
progressive download: connettiti, aspetta, poi vedrai il video... dopo che verra' terminata la copia
sul tuo pc/mac.
Eh si, gli smartphone non c'erano.
Per tutti questi motivi - e qualche altro, magari - fino a poco tempo fa la presenza di segmenti video in corso testo era una cosa avvolta nelle nebbie della conoscenza
degli adepti di una setta misterica.
I browser non erano in grado di gestire autonomamente il video e per farlo invocavano un plug-in
esterno: ce n'erano diversi, io impiegavo quello di VLC.
I streaming server erogano anche i conti della spesa, se si vuole, ma non generavano video stream.
L'erogazione era anche ritenuta un argomento mistico. Tra i modi piu' semplici
c'era quello di usare uno streamer/compressore sul server e poi effettuare quello che si chiama reverse proxy
sul flusso cosi' generato per poterlo ricevere attraverso la porta 80.
Era il tempo in cui YouTube utilizzava preferibilmente il flash (macromedia poi confluita in adobe): se
volevi mostrare il video dovevi utilizzare un <embed> o un <iframe>
L'html era arrivato si e no alla versione 4 e sebbene fosse una cosa sentita, fino all'html5 non
c'era una istruzione come la <video> o <audio>.
Poiche' il multicast e' da sempre proibito (anche nell'ipv6 gli viene riservato uno spazio minimo estremamente regolamentato
per sapere perche' c'e' da chiedere alle Telco), se si voleva trasmettere un video (streammare,
come si dice adesso) sostanzialmente si poteva solo affidarsi ad Akamai (o altri broker di diffusione)
che in virtu' della sua rete di reti riusciva a garantirti (se paghi: allora come oggi) un unicast
ragionevolmente capillare.
Nel 2012, uUna volta scoperto come si erogava uno stream, con l'idea di sostituire i ponti radio con
internet, notando che l'accoppiata vlc+apache sembrava gestire
l'unicast in modo molto risparmioso (e' un unicast - non puo' essere altro - ma sembra erogare uno stream comune a
tutti i client) ho pensato di cercare di emulare Akamai, utilizzando video in piccolo formato,
precompresso (a circa 100 Kbps) sfruttando il Gbps offerto da un qualsiasi server virtuale in cloud.
Quello su cui gira questo sito (ed altri tre) e' un core Xeon (virtuale) con 4 GB di RAM e 30 GB di hard disk.
L'idea - possibile fino a poco tempo fa - era di usare lo streaming di VLC e riceverlo con il plug-in di VLC oppure con
VLC o con un ricevitore hardware con uscita video (che ha oggi sempre meno senso).
Poi ho pensato anche ad un modo di realizzare una radio web a partire dalla ricompilazione di VLC che eseguiva
una playlist (estensione .xspf)
Parto da un file estremamente compresso sulla inusuale utilizzazione di molti ventilatori denza pale della Dyson.
Il file e' un mp4 denominato balloons_and_fans_80.mp4 che viene stream-mato verso lo stesso server in rtp attraverso la linea:
Ricevo sul server stesso lo stream rtp e lo ri-stream-mo verso l'esterno sulla porta 64088 aumentando considerevolmente il ttl:
Lo stream sara' poi proxato inversamente dallo streaming server apache che lo rendera' disponibile come http://iginomanfre.it/rtp_int
Lo stream cosi' generato e' ricevibile con vlc richiamando il network stream http://iginomanfre.it/rtp_int.
Era molto interessante pero' inserirlo in corso testo attraverso il plug-in
di VLC una cui versione ad un certo punto - se installato in modo esperto (senza utilizzare
l'installazione ufficiale) si era rilevato come possibile apritore di back-door sulla sicurezza del
pc. La cosa fu immediatamente corretta, ma subito Chrome seguito dagli altri browser ha tolto il sostegno al plug-in di vlc anche perche' nel
frattempo era nato l'html5 con l'istruzione <video>
Oggi solo safari per windows (non piu' supportato dopo la versione 5.1.7) riesce a mostrare quello stream in corso testo
Se ti interessa dai una occhiata a questo file.
La versione per pc di firefox si comporta diversamente da quella per mobile (android)
|
|
|
|
|
|
|
|
|
|
|
|
Sui browser dei cellulari firefox e' in grado di aprire automaticamente i metafile m3u8 dell'hls contenenti h264.
Sui desktop cio' non e' possibile, ma se si installa un player h264 e nel browser si associa il tipo m3u8 a vlc
l'apertura e' automatica.
Lo stesso risultato si puo' ottenere con una opportuna estensione del browser, ma
che non saranno aggiunte funzionalita' (in pratica la capacita' di decomprimere il file e' delegata al browser)
ma sara' resa piu' elastica la interpretazione della sintassi.
Nessuna estensione pero' aggiunge la capacita' di aprire un tag <video> contenente un metafile m3u8
come fa la versione mobile.
.
Questo e' il primo add on di David Cavar
il file hls richiamato da firefox con l'estensione estensione reperibile su addons.mozilla.org_it_firefox_addon_native-mpeg-dash-hls-playback
che comunque non permette di aprire l'istruzione <video>
|
This [ndr: that of cavar] is a fork of Native HLS with added additional features. Allows HLS and MPEG-Dash native playback in Firefox browser. Click on any m3u8 or mpd link inside Firefox to play it directly in a new tab. By default, the browser downloads any m3u8 and mpd files that were requested. This plugin checks any links to see if they match. If that's the case, it opens a new tab on a video player that uses the hls.js and dashjs library. This extension is just a wrapper for those players on Firefox. Report any issues to https://github.com/Palethorn/chrome-native-dash-hls/issues |
Questo [ndr: quello di Cavar] � un fork di Native HLS con alcune funzionalit� aggiuntive . Consente la riproduzione nativa HLS e MPEG-Dash nel browser Firefox. Fare clic su qualsiasi collegamento m3u8 o mpd all'interno di Firefox per riprodurlo direttamente in una nuova scheda. Per impostazione predefinita, il browser scarica tutti i file m3u8 e mpd richiesti. Questo plugin controlla tutti i collegamenti per vedere se corrispondono. In tal caso, apre una nuova scheda su un lettore video che utilizza la libreria hls.js e dashjs. Questa estensione � solo un wrapper per quei giocatori su Firefox. Segnala eventuali problemi a https://github.com/Palethorn/chrome-native-dash-hls/issues |
altro plug-in (ancora non provato) addon/hls-stream-detector di rowrawer.
(che comunque sembra che faccia troppe cose)
|
The Stream Detector detects playlists and subtitles used by HLS/DASH/HDS/MSS streams.
Assembles readymade youtube-dl/FFmpeg/Streamlink/hlsdl/N_m3u8DL-CLI commands. |
Lo Stream Detector rileva playlist e sottotitoli utilizzati dai flussi HLS/DASH/HDS/MSS.
Assembla i comandi youtube-dl/FFmpeg/Streamlink/hlsdl/N_m3u8DL-CLI gi� pronti. |
Fa troppe cose e non fa quello che avrei sperato: visualizzare i video in corso testo,
sfruttando le capacita' del browser.
Li apre in nuove schede, e permette inoltre di salvarli, ma la cosa non mi interessa.
Avrei gradito che avesse aggiunto la capacita' - presente nel browser mobile - di eseguire i file
m3u8 in corso testo attraverso il tag <video>.
_core_.jpg)