Elenco di tutti gli stream erogati da questo server
List of all the streams provided by this server

interesting panorama of streaming methods I use on this server
applied to h265 and h264 compressed streams.

Once upon a time there was the video streaming

Nowadays is basically only a tricky remote copy of a file.
Read my last article True unicast streaming has lost his appeal

Video within page

Putting away any negative approach, today I say that Yes, it is possible, with any browser, but natively only in h264 (or VP8) and not in HSL/DASH: only in plain streaming, something alike the old progressive download.

Only h264 (or VP8) video can be embedded in html page, and it is reproduced from a copy in the terminal cache.
Not all the terminals could be able to download it seamless, because not all the terminals could have enough cache for this purpose.
On the contrary almost all terminals have enough computational power to decode h264 (and generally speaking much much more).
The video is locally downloaded as it is (thanks to the TCP/IP) and reproduced through the commands.
For the peace of the sense of rights people this content will be deleted and will be hardly reacheable from outside.

This is not correct from my point of view.
You can feel this looking the timeline, which (depending on the available bandwidth) become gray since the beginning of play.

On the contrary, if the video would be downloaded while it plays, the bandwidth would be the following:

payload bitrate of the video embedded in this page.
It has no sense in progressive download, because all the available bandwidth may be used to copy the slices or the entire file.

To be html5 compliant the browsers must be able to play mp4 or webm wrappers with h264 or vp8 video and aac, mp3 or ogg audio payloads.
It is not a problem of complexity: no-one care how much power the compression drain because all is done in cloud by powerful (but not free) servers. h265 is about ten times more heavy than h264: the same video my quite old core2duo 32bit employ 2 minutes to compress a video in h264, require more than 20 to be compressed in h265.
The result is really much better. You can test the differences comparing the h264 one with what can open directly with VLC as
To see something more (such as embedded h265) you need of a plug-in that's all but free because the VLC plug-in is no more supported by the most diffused browser.

The next image shows how the page yosemite.html can be see with an old version of the most diffused browsers (). It contains embedded h265 video in true real time streaming, but the latest versions (Firefox after 51.0b9) do not support anymore VLC plug-ins

above the section of yosemite.html with an old version of most diffused browser. Below the most diffused browsers (such as what you're using now such as chrome, firefox, internet explorer, opera)

Original live http streaming with VLC
(no more supported by current browsers)

Segmented stream in HLS generated with VLC
(no more supported by current browsers)

As you can see, because the browsers are unable to open the stream (because they do not support anymore the VLC NPAPI plug-in) the videos simply disappears or - as in this case - you see an error image: the banned VLC cone i've added.

In Here you can read more about the probable reason of end of support of VLC plug-in.
In the meantime VLC plug-in has been corrected and the security problem should not exist any more. But its ban continue.

In progressive download the downloaded video will occupy its entire size in the cache of your terminal (since this one is less than 7 MB it is quite fast), while using HLS or DASH it would be copied in slices of few seconds one after the other pointed by a metafile.
Either last versions of HLS or DASH allow to adapt the video download to the speed of the connection, but this is a trick to compress live the video or to increase the number of compressions a single video may require: a 5 minute video would be splitted in 30 slices about 10 seconds long each by the number of compression and resolution planned. If you plan to serve 10 bitrates and/or resolutions, you need 10 different pre-compressions (and 300 slices), or, as the encoders companies prefere, you need to add a real time encoding capability to your media asset management.

TIM vision compressions for 8 channels source in 5 possible languages and 3 resolutions (HD, SD 16:9 and 4:3)
This considering a couple of language a time, with and without subtitle, but not multichannel audio (e.g. ITA 5+1, stereo ITA, ENG)
TIM vision uses h265 because its STB has the capability to decode it. This cannot be the case of a general purpose website.

This embedding video is different from the video present in my homepage because that video comes from youtube and it is invoked through a iframe tag, quite general purpose tag to embed a web object in another (it can be used to create a scrollable page within another).

<iframe width="400" height="225" src="https://www.youtube.com/embed/4GX6a2WEA1Q" frameborder="0" allowfullscreen> </iframe>
while this is recalled through the video tag
<video id="yosemite_h264" poster="../jpg/yosemite_poster.jpg" controls> <source src="../media/Yosemite_h264_SD100.mp4" type="video/mp4" /> </video>

hls streaming

This is the list of the hls file generated with vlc
The slices generated are pointed by the m3u8 playlist file

Un solo modo di streammare

Oggi e' praticamente impossibile inserire un video in una webpage html se il video non e' codificato in un formato direttamente supportato dal browser perche' i piu' usati tra questi non supportano piu' plug-in video esterni.

Fin dagli albori dell'html5 lo scopo principale dell'W3C e'stato quello di ripulire il codice html.
In realta' questa semplificazione ha portato alla necessita' di integrare l'html base con chiamate a decodificatori esterni. Esattamente come si faceva prima con il tag object ed i plug-in esterni.

Tra le molte istruzioni deprecate in html5 ci sono gli oggetti correlati alla architettura NPAPI derivata da Netscape.

A causa della fine del supporto dei plug-in NPAPI da parte di Firefox, Chrome e Opera, utilizzando questi browser le pagine web che incorporano video che ho scritto finora non lo includeranno in corso testo.
Finora, per la indisponibilita' di plug-in, sugli smartphone le mie pagine non mostravano video in corso testo. Era comunque possibile richiamare i flussi con applicazioni come VLC utilizzando la URL dell stream.

Al momento in ho scritto inizialmente queste righe (4 maggio 2017) l'unico modo di continuare a vedere le mie pagine con il video in corso testo e' usare Apple Safari (nell'ultima versione per Windows, ma ora non piu' supportata da Apple) perche' nel frattempo anche Microsoft Internet Explorer non lo supporta piu'. Midori e' un possibile browser alternatico, ma non sembra una cosa realmente proponibile.

Una discussione completa relativa a Firefox puo' essere trovata in questa pagina ufficiale di mozilla firefox.

Only one way of Streaming

Today it is practically impossible to embed video in webpage if video is not encoded in formats directly supported by the browser because the most used ones does not support any more plug-ins

Since the beginning of html5 the main goal of W3C has been to clean the html.
Really this semplification brought to the need of integrate basic html with call to external decoders. Exactly as did before with object tag and external plug-ins.

Between the many deprecated instructions in html5 there are the usage of objects related to the
NPAPI architecture derived from Netscape.

Due to the end of support of NPAPI plug-ins by Firefox, Chrome and Opera, using these browsers the webpages that embed video I wrote up to now will not show any more embedded video within text.
Until now I used to stream with VLC and play the video with an external call vlc plug-in, and for this reason, due to the lack of plug-ins, on the smartphones my web pages did not show text with embedded video. It was anyhow possibile to recall the streams through applications such as VLC using the URL of the stream.

Since I wrote initially this page (may 4th 2017) the only way to continue to see the webpages embedding video with plug-ins is Apple Safari (in its last windows available version but no more supported by Apple) because in the meantime Microsoft Internet Explorer also do not support it. Midori is a possible alternative browser, but it does not seem a real alternative.

A complete discussion about firefox can be found in this official mozilla firefox page.

I browser con il tag video non riproducono l'hevc ma solo l'h264 o il webm. Di seguito, usando un iframe provo ad invocare un player esterno per riprodurre un hls contentente elementary stream hevc:

With video tag the browsers are unable to reproduce hevc but only h264 and webm. In the next I try using an iframe to call an external player to reproduce an hls containing hevc elementary stream:

<iframe width="640" height="360" seamless src="http://iginomanfre.it/hls7/hls7.m3u8" frameborder="1" allowfullscreen> </iframe>
Now the automatic start is commented, it does not bory your browsing any more
Ora ho commentato la partenza automatica dell'iframe, non ti infastidira' piu'
Per ulteriori informazioni dai una occhiata a questo file: e' relativo all'hls di un wrapper mpeg4 con elementary stream h264, ma e' la stessa cosa
Se qualcosa va storto, prima di mandarmi a quel paese, prova ad aprire direttamente http://iginomanfre.it/hls7/hls7.m3u8 con vlc (versione 2.2.6 o successiva): apri flusso...

For further informations take a look to this file: it is related to the hel of a mpeg4 wrapper containing h264 elementary stream, but it is the same thing.
If something goes bad, before damning me, please try to recall directly http://iginomanfre.it/hls7/hls7.m3u8 with vlc (version 2.2.6 or later): open stream...

Maybe can be interesting to browse this article where may be compared the two ways of streaming

In realta' non c'e' nessuno che proibisce nulla a nessunaltro: puoi stream-are come vuoi ma il progetto della tua pagina deve accordarsi con le possibilita' rese disponibili dai browser. Quindi - se tu vuoi usare uno dei piu' usati (oserei dire standard) - devi pensare la pagina come loro ti permettono.

Really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you.

La nuova release 52.0 di FireFox non supporta piu' plug-ins (a parte Flash, Silverlight, Java, Acrobat) (VLC Q&A).
Di conseguenza, di che risorse pensi avremmo bisogno di raccogliere per sviluppare un plug-in affidabile sia per Chrome che per Firefox? Io penso che lo dovremmo lanciare!
Il plugin e' un importante elemento di VLC. Perdere i plug.in per Chrome e' stato duro, ma ora perdere anche quello per Firefox e' stato . VLC e' un grande esempio di comunita' di sviluppatori che deve essere mantenuta e a cui non deve poter perdere componenti come i plugin. Penso al dispiacere per tutti gli sviluppatori. (VLC Q&A,2).

The new Release 52.0 of FireFox is dropping support for plug-ins (except for Flash. Silverlight, Java, Acrobat) (VLC Q&A).
As a ball park, what funding do you think will be needed to be raised to ensure mature plugins for both Chrome and Firefox? I think we should we crowd fund this!
The plugin is an important element of VLC. Losing the Chrome plugin was difficult and now to lose Firefox is . VLC is a great example of a community developed app that must be maintained and not lose components such as the plugin. I felt the pain of all the original developers. (VLC Q&A,2).

This is the most diffused way to stream all around the world: Youtube like (vimeo or other are similar)

Do not forget: you are allowed to exist only if you consume
This video is available also in English as well in many other languages.

The next video comes from Youtube, Google empire. It is embedded through the following call

<iframe width="400" height="225" src="https://www.youtube.com/embed/oktdSO_J3Vc" frameborder="0" allowfullscreen> </iframe> It is played through the browser capabilities, that can play also webm.
The following two videos are the same in terms of content but a completely different story.

This comes from youtube servers through the following call:

<iframe width="640" height="218" src="https://www.youtube.com/embed/7FvCaQhh1Z0" frameborder="0" allowfullscreen> </iframe>
Really behind this address Youtube streams this video in 7 times for formats and codecs:

This one from this server through the html following video markup
<video src="../video/google_pizza.mp4" type="video/mp4" poster="../jpg/google pizza poster.jpg" width="640" height="218" controls> </video>
But this one is one only file stored in that directory that apache streams on request.

Google make this video available in many formats and bitrate
Google rende disponibile questo video in diversi formati e bitrate

While this one comes from this server in one only resolution and bitrate in progressive download

At left a html5 video instruction that realize a practical old progressive download video embedded video. Video is downloaded locally before and while playing. This video is on the server, is mute is 19 minutes long and it is highly compressed in h264 (29 MB 480x270). Crosshairing the pointer two timelines are showns: the blue one is the current playing position while in gray is hown the latest downloaded point
Positioning is quite fast, but in any case is not fast as HLS where every single video chunk is pointed by the metafile.
Practically progressive download is the only native way to embed video by browser characteristics.

<video width="480" height="270" controls> <source src="../video/tevere_200.mp4" type="video/mp4"> </video>

A sinistra l'applicazione della istruzione video dell'html5 che realizza il vecchio progressive download embedded video. Il video e' scaricato localmente prima e mentre viene riprodotto. Questo video e' sul server, e' muto, dura 19 minuti, e fortemente compresso in h264 (29 MB 480x270). Attraversando il video col mouse vengono mostrate due timeline: in blu la posizione corrente, in grigio l'ultimo frame scaricato.
Il posizionamento e' abbastanza veloce, ma in ogni caso non come in HLS dove ogni singolo segmentino video e' puntato dal metafile.
Praticamente il progressive download e' l'unico modo nativo html di inserire video in corso testo grazie alle capacita' del browser.

Il vantaggio e' che si vede anche sul cellulare (qui sul mio note2)
The advantage is that can be seen also on smartphones

Come dicevo all'inizio, in realta' nessuno impedisce nulla a nessun altro: tu puoi stream-mare come vuoi, ma la tua pagina deve accordarsi con quanto reso disponibile dai browser, quindi - se vuoi usare quelli piu' usati e standard - devi concepirla come ti e' permesso.

Infatti da questo sito io sto continuando a stream-mare in mpeg2, h264 e anche h265 wrapp-ati principalmente in Transport Stream o in HLS (vedi questa lista), e questi stream possono essere visionati con un player (come media player o videolan, eventualmente ricompilati in forma di app appositamente realizzata) ma non puoi inserirli in un browser perche' questi non ammettono piu' plug-in video (salvo quelli commerciali). Infine puoi utilizzare una versione obsoleta di un browser open source che supporti ancora il plug-in video di VLC.

In questa pagina utilizzo iframe per richiamare una applicazione esterna (io ho associato vlc) per aprire un video. iframe e' abbastanza pericolosa perche' puo' richiamare qualsiasi cosa, compresi malware o virus. Ma per quanto ne so - escluso il progressive download e dopo la eliminazione dei plug-in video - e' l'unico modo di richiamare un video all'interno di una pagina.

As I said at the beginning, really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you.

In fact from this site I'm continuing to stream mpeg2, h264 and even h265 wrapped mainly in transport stream or in HLS (see this list), and these stream can be loaded with a stream viewer (such as media player or videolan) or a stand alone app but you cannot see these video within a browser because no plug-in (excluding commercial ones) are any more supported for this purpose. Last you can use an obsolete version of an open source browser at the time it still support VLC video plug.in

In this page I use iframe to recall an external app (I choose vlc) to open the video. iframe is quite dangerous because can recall everything, including malware or virus. But for my knowledge - excluding progressive download and after video plug-in execution - is the only way to recall a video within a page .